I first researched the top questions people ask about Claude usage limits. They are:

1. “Why does my usage limit reset every 5 hours?” — This is Claude’s session-based quota system, not a daily reset like some other AI tools
2. “How many messages can I send?” — The answer varies dramatically by plan and message complexity, not a fixed number
3. “What counts toward my usage limit?” — Everything: message length, file attachments, conversation history, and which features you use
4. “Do usage limits apply across all Claude products?” — Yes, all surfaces (claude.ai, Claude Code, Claude Desktop) share the same unified limit
5. “What’s the difference between usage limits and length limits?” — Usage limits control total consumption over time; length limits control how long any single conversation can be

Maximizing Your Limits: Tips & Strategies

1. Message Composition & Batching

• Combine multiple questions into one message — Each message forces Claude to reprocess your entire chat history. Asking 5 questions in one message costs less than sending 5 separate messages
• Keep messages focused — A well-structured, comprehensive message consumes fewer tokens than scattered follow-ups
• Use direct language — Avoid unnecessary verbosity; concise prompts use fewer tokens

2. Model Selection

• Switch to Sonnet from Opus when possible — Opus models consume 1.5–2x more computational resources per message. Use Sonnet for simpler tasks like summarization, brainstorming, and initial research
• Reserve Opus for complex reasoning, multi-step analysis, and tasks requiring superior accuracy
• For Pro users: Sonnet is the default and is perfectly capable for most workflows

3. File & Attachment Optimization

• Avoid re-uploading files — Claude remembers files you uploaded earlier in the chat. Reference them again instead of uploading the same document multiple times
• Be mindful of file size — A free-tier user uploading three 20-page PDFs might exhaust their entire 5-hour quota in just 5-8 messages
• Upload only the files you actually need; remove unnecessary attachments from previous messages when possible
• Claude accepts up to 20 files per chat with a 30 MB maximum per file

4. Projects & Knowledge Base Strategy

• Use Projects with retrieval-augmented generation (RAG) — Projects allow Claude to work with larger amounts of information more efficiently by only loading relevant content into the context window
• Store reference materials in a project’s knowledge section instead of pasting them into every chat
• Keep project instructions concise — lengthy instructions consume tokens unnecessarily. Use them only for general context, key guidelines, and Claude’s role
• Remove unused project files regularly — clean up files you’re no longer actively using

5. Conversation Management

• Start fresh conversations every 20–30 messages — Conversation history accumulates tokens with each message. A fresh chat resets this overhead
• When your conversation approaches the context window limit, Claude automatically summarizes earlier messages (with code execution enabled) — this doesn’t count toward your usage limit and allows conversations to continue
• Avoid extremely long chat threads for repetitive tasks; use new conversations strategically

6. Feature & Tool Management

• Toggle extended thinking off when you don’t need Claude’s enhanced reasoning
• Temporarily disable non-critical tools and connectors — disable web search, Research, and MCP connectors from your settings when they’re not needed. Tools and connectors are token-intensive
• Disable Projects integration when working on one-off tasks that don’t benefit from persistent knowledge

7. Peak-Hour Strategy

• Free users may face slower responses or limited access during peak hours on weekdays
• If you’re on Free tier, schedule heavy usage during off-peak times (late evening, weekends, early mornings outside business hours)
• Pro users have priority access and face fewer restrictions

8. Prompt Engineering for Efficiency

• Ask for structured outputs — requesting JSON or markdown makes responses more concise and reduces token waste on explanation
• Use examples sparingly — every example you include consumes tokens. Use one or two high-quality examples instead of multiple
• Break down complex tasks — sometimes a simple follow-up is cheaper than one massive, detailed prompt

9. Upgrade Strategic Analysis

• If you hit limits repeatedly: Free → Pro ($20/mo) gives you 5x the usage. For most occasional users, this is sufficient
• For daily power users: Max 5x ($100/mo) or Max 20x ($200/mo) eliminate the need to monitor limits
• For teams: Team Premium seats offer more per-session capacity (6.25x) than Max 5x (5x), making them cost-effective for collaborative work
• For enterprises: Usage-based billing removes fixed caps and lets you scale predictably with spend controls

10. Caching & Reference Strategy

• Use Projects for anything you’ll reference multiple times — the more you use the same content, the more benefit you get from caching
• Store your coding standards, brand guidelines, or writing style in Projects so Claude doesn’t need you to re-explain them
• Provide complete context in your initial message — when reviewing code or debugging, include entire relevant code snippets in one message instead of pasting piece by piece

Summary

The key to maximizing your Claude usage is understanding that usage isn’t about message count—it’s about token consumption. Every character, file, and feature adds up. The smartest strategies combine batching questions, choosing the right model, managing files efficiently, and using Projects for recurring work. For regular users, upgrading to Pro pays for itself quickly; for power users, Max plans remove the constraint entirely.

Detailed Comparison Table

Update: this post is now updated using my new AWS AI Lab pipeline! We’ve all been there: It’s 2:00 PM, and a VP drops a “fire drill” request for a board-level strategy deck due by 4:00 PM. In the past, this meant canceling your afternoon, hunting down last year’s files, and manually wrestling with bullet points.

In this edition, we’re breaking down how to stop being a manual formatter and start acting as an AI Workflow Architect. Using a real-world “Cloud Grind SAS” scenario, we’ll show you two distinct methods to bridge the gap between messy strategy notes and high-stakes technical reality—without losing your mind (or your evening).

This guide provides the specific prompts and instructions used in the Cloud Grind SAS project to transform messy stakeholder notes into a board-ready executive presentation.

Method 1: The “Rapid Bridge” Prompting Workflow

This method is for the Tactical Executioner. It focuses on using high-leverage, sequential prompts to quickly synthesize messy data into structured content. It’s perfect for one-off requests where you need to move from “raw notes” to “final draft” in a single session.

Phase 1: Strategic Extraction 🔍

The first step is to define the “Northstars”—the high-level goals—from the raw, messy notes/outline provided by leadership.

• Prompt: “Turn below notes into high level board room ready slide outline for 1 executive slide (with title,subtitle, and content that should be included in the slides)”
• Goal: To filter out the noise and focus on the primary objectives that the leadership team cares about most.

Phase 2: Make the g-slide based on the above outline

Once the goals are clear, we can get started and create the slide using Gemini Canvas

• Prompt: “Create ONE g-slide based on the above outline, pick the layout as of you are an execitive level content specialist”
• Goal: To turn the summarized executive level outline into Google slide that is high level and board room ready.

Method 2: Use Gemini Gem To Build Custom System with Corporate Theme

This method shifts you from manual formatting to a Systemic Workflow. By creating a Custom Gem (Custom GPT), you codify your brand’s “DNA,” ensuring every strategy note you drop in is instantly converted into content that fits your specific corporate slide layouts.

Set Up: Building the Custom Gem 💎

Gemini Gems are customized versions of Google’s Gemini AI. They serve as AI assistants with specific personas. They allow users to save instructions, knowledge, and preferences to handle repetitive tasks. This eliminates the need to re-prompt the AI for each task.

Configuration Logic: Upload your corporate “Source of Truth.” This should include:

• A PDF of last year’s successful Board Deck (for tone and structure).
• Your brand’s style guide (font names, hex codes, and icon styles).
• Template layouts (e.g., “The Executive Summary Slide,” “The 3-Column Strategy Slide”).

The System Instructions: “You are an expert Presentation Strategist. Your role is to take raw, messy strategy notes and map them into the specific 5-slide structure of our [Company Name] Board Template. Always prioritize ‘Northstar’ goals and use professional, concise executive language.”

Optimization Tips for Corporate Decks 🚀

The final step is to ensure the language is appropriate for a board-level audience—concise, authoritative, and strategic.

To ensure your Custom Gem produces elite, board-ready results, apply these optimization layers to your configuration:

1. The “One-In, One-Out” Strategic Rule Instruct the Gem that for every technical problem or bottleneck identified in the raw notes, it must generate exactly one corresponding strategic solution.

    Benefit: This prevents "data dumping" and ensures the slides remain solution-oriented rather than just listing grievances.
   

2. Constraint-Based Text Prompting Give the Gem strict character and line limits to prevent your slides from becoming a “wall of text.”

   • Limit: Maximum 45 characters per bullet point.
   • Limit: Maximum 5 bullets per slide.

   Instruction: “If a point is too long, break it into a sub-point or simplify the vocabulary.”

3. Recursive Tone Matching Use a “Source of Truth” comparison prompt to maintain consistency with previous successful presentations.

Prompt: “Mirror the level of technical depth and linguistic style found in the attached ‘2025 Strategy Deck’—neither more complex nor more simplified.”

1. Spatial & Visual Cueing Since the Gem can’t “see” your final design layout in real-time, force it to provide metadata for the designer (or yourself).

   Instruction: “At the end of every slide content block, include [Slide Design Notes] in brackets. Suggest where a diagram, high-res image, or KPI callout box should be placed based on the content weight.”

2. The “Executive Summary” Auto-Generator Program your Gem to always conclude the workflow by generating a Slide 0: Executive Summary.

   Instruction: “Once the deck content is finalized, synthesize the entire narrative into three high-impact sentences for a VP-level summary slide.”

   Pro Tip: If your corporate deck uses specific visual metaphors (e.g., “The Growth Flywheel” or “The Security Moat”), upload an image of those specific slides to the Gem’s Knowledge. This allows the AI to understand the spatial relationships of the data it is generating, making the hand-off to the design phase seamless.

The “Architect” Mindset 🧠

Remember, the goal is to stop being a “slide formatter” who manually transfers content and start being the “connective tissue” that uses AI to accelerate technical reality.

📺 Watch the Full Walkthrough If you prefer to see these workflows in action, watch the full deep dive where Monica demonstrates the exact transformation from raw notes to board-ready slides.

Watch on YouTube: [Video Link]

But we are now living in the AI Age of Acceleration. For modern founders and strategic leaders, the “Years of Experience” metric is officially broken.

If you are building a high-growth company in 2026, you don’t need “tenured employees.” You need Connective Tissue.

1. Shift from “Time” to “Impact Cycles”

The traditional resume is a timeline of months and years. But months are a measurement of presence, not performance.

In the AI age, a single high-performer with the right systems can do in 5 months what used to take a team 2 years. When I recently audited my own professional footprint, I removed the months from my history. Why? Because the “HR Math” of tenure is a distraction from the Outcome Math of the business.

The Founder’s Takeaway: Stop looking for “long-term stays.” Look for leaders who can complete a “Value Cycle”—someone who comes in, identifies a translation gap, builds the system to fix it, and moves the needle immediately.

2. The Rise of the “Strategic Interventionist”

Modern enablement isn’t about “putting in time.” It’s about Engineering Clarity. When a company is in the middle of a multi-billion dollar shift—like the rumored Cisco/Axonius acquisition—the “loyalist” who sits quiet for years is less valuable than the “Interventionist” who builds:

• The BVA Engine: Turning raw technical specs into ROI stories.

• The SME Recording Standard: Turning tribal knowledge into scalable assets using IBM/AWS-level rigor.

• The Facilitation Bridge: Managing 100+ person technical summits to ensure the field is “Business context-ready”, not just “Feature fluent”.

3. Agility is the New Loyalty

Founders often fear “short stints.” But in a volatile landscape, Agility is the only true security. A leader who builds a their personal brand isn’t “job hopping” — they are System Hopping. They are moving to wherever the complexity is highest and the “translation” is most needed. They don’t have “gaps” in their resume; they have a portfolio of Delivered ROI.

4. Enablement as a “System,” Not a “Department”

In the AI age, content is cheap. Synthesis is expensive. The goal of modern enablement isn’t to “train” people; it’s to create the Connective Tissue between:

• The Engineer’s Code
• The Seller’s Pitch
• The CFO’s Budget

If you can bridge those three things in 6 months, you have provided more value than someone who “managed the LMS” for six years.

The New Standard

To my fellow founders and “Company of One” architects: Release the guilt of the “Perfect Track.” Your value isn’t measured by how many Januarys you saw at a single desk. It is measured by the strength of the systems you left behind and the clarity you engineered while you were there.

Stop counting months. Start counting bridges built.

Are you a founder struggling to translate features into revenue? Let’s connect - I’m building the systems that turn technical specs into business wins.

Follow my newsletter to learn more about building AI-powered enablement solutions for your field teams

Yesterday, I did nothing for The Connective Tissue.

I didn’t write code. I didn’t build workflows. I didn’t even tweak my website. I just… existed. And by 9:00 PM, the guilt set in. “I’m falling behind. I should be building. I should be moving.”

This is the Employee Mindset talking.

In the corporate world, our value is measured in Motion. How many tickets did you close? How many meetings did you attend? How many emails did you send? If you aren’t moving, you aren’t working.

But as I build The Connective Tissue - my consultancy for the AI age - I’ve realized that this metric is a trap. For a founder, and especially for the “Company of One,” motion is often just a distraction from the real work.

The Pivot: From Motion to Clarity

When you are the architect of a system, your job isn’t to turn the crank; it’s to design the machine.

• Motion is spending 4 hours manually cleaning data in a spreadsheet because it feels like “hard work.”
• Clarity is staring at the wall for 30 minutes, realizing the process is broken, and spending 1 hour writing a Python script to automate it forever.

The first feels like progress because you are tired afterwards. The second is progress because you never have to do the task again.

The Biological Metaphor

My brand is built on the concept of “Connective Tissue” - the ligaments and tendons that hold a business together.

In biology, connective tissue doesn’t get stronger while you are lifting the heavy weight. It tears. It breaks down. It only gets stronger when you rest.

If you are constantly in motion - constantly “lifting” - your business becomes brittle. You make reactionary decisions. You install tools you don’t need. You hire people you can’t afford. You snap.

Measuring Clarity as a Metric

So, how do we measure progress if we aren’t counting hours? I’ve started tracking “Clarity Events” instead of tasks.

A Clarity Event is any moment where I:

1. Removed a bottleneck (Deleted a step in a workflow).
2. Automated a decision (Built a Gemini Gem to handle a repetitive query).
3. Defined a strategy (Decided not to pursue a bad customer segment).

One “Clarity Event” is worth 100 emails.

The Permission to Pause

To my fellow founders and future “Companies of One”: Stop glorifying the grind.

If you are drowning in tasks, you aren’t succeeding; you are just a busy employee of a company you own.

Take the break. Let the guilt pass. The goal is not to be the busiest person in the room. The goal is to be the one who sees the path clearly enough to build the bridge.

Motion is cheap. Clarity is expensive.

Are you a founder struggling to translate features into revenue? Let’s connect - I’m building the systems that turn technical specs into business wins.

Follow my newsletter to learn more about building AI-powered enablement solutions for your field teams

Lately, I’ve been spending time working with a brilliant Subject Matter Expert (SME) from the technical account management team of my company. He told me that the team knows every line of code in the product. They know exactly how it works.

But when customers asked, “Why would a CFO pay $100k for this?” … silence.

This is the Translation Gap. And it kills more startups than bad code ever will.

In my work building the “Connective Tissue” for technical sales teams, I’ve realized that my job isn’t to teach features. It’s to teach Business Value Assessment (BVA). It’s the art of translating technical capabilities into financial metrics.

Luckily, the brilliant SME I worked with got it all figured out into a automated system. It started with value extraction, completed by advanced automation, and built to help technical teams run the business value assessments with their customers to justify the spending they had.

How It Automates the “Value Extraction” in the calculator

The spreadsheet uses a “hub and spoke” calculator which is designed to take raw customer inputs, process them against industry benchmarks, and output a polised financial and operational business case.

The structure with different layers

1. Input Layer: This is where the customer enters their specific data points (e.g., number of users, current costs, etc.). This is the “Face” of the tool. It is the only place where data entry happens.

Key Components

- User Input Fields: Clearly labeled cells for customer data entry.
- Instructional Text: Guidance on what data to enter and where to find it.
- Questionnaire: Targeted questions for each use case (e.g., "How long does it take to prepare for an audit?") Data Flow: inputs entered here are mirrored to the specific "Spoke" sheets. 

1. Spoke Sheets: Each spoke sheet corresponds to a specific use case or feature set. These sheets contain the logic and calculations needed to process the input data. These sheets hold the “Brain” of the BVA. They contain:

Key Components

- Calculation Logic: Formulas that process input data against benchmarks.This is being used as the logic to calculate the "After" state. usually Current_State * (1-specific_factor)
- Benchmark Data: Industry standards for comparison. (e.g., "30-40% of endpoints have missing agents")
- Intermediate Results: Breakdown of calculations for transparency.This is also used to map technical wins to business outcomes. E.g., finding a missed device helped risk reduction.  Data Flow: inputs from the Input Layer are processed here, and results are sent to the Hub sheet.

1. Hub Sheet: The hub sheet aggregates results from all spoke sheets to provide a comprehensive business case. This is the “Storyteller” of the BVA. It compiles all the data

Key Components

- Summary Tables: Consolidated results from all spokes. It sums up cost savings accross all active use cases.
- KPI Improvements: Aggregates percentage improvements (e.g., "Reduced MTTR by X%")
- Visualizations: Graphs and charts to illustrate key metrics.
- Executive Summary: A narrative that ties the data together into a compelling story.

How ROI is Calculated

The ROI calculation is performed in the Hub sheet using the aggregated data from the spoke sheets. The formula used are:

1. Soft Savings: ROI (%) = (Hours Spent Before - Hours Spent After) x (Staff Salary / 2000 Hours) Where:
   • Hours Spent Before is the total time spent on tasks before implementing the solution.
   • Hours Spent After is the total time spent on tasks after implementing the solution.
   • Staff Salary is the average annual salary of the staff involved in these tasks.
2. Hard Savings: ROI (%) = (Unused Licenses Found) x (Avg License Cost) Where:
   • Unused Licenses Found is the number of licenses identified as unused.
   • Avg License Cost is the average cost per license.
3. Rish Reduction for Quantified Risk: ROI (%) = (Total Assets x % Unmanaged Benchmark) = Risk Surface Reduction Where:
   • Total Assets is the total number of assets managed by the customer.
   • % Unmanaged Benchmark is the industry benchmark percentage for unmanaged assets.

Using AI to Build the Translation

Traditionally, building a BVA course takes weeks of interviewing experts. Today, I used a different approach to bridge the gap:

1. Ingestion: I fed the raw technical documentation into NotebookLM.
2. The CFO Persona: I used a custom Gemini Gem trained to act like a cynical CFO.
3. The Interrogation: I asked the AI: “Here is a feature. Tell me exactly how this reduces risk or increases revenue. If you can’t, flag it as ‘Fluff’.”

The result? We stripped away 40% of the training material that was just “feature noise” and focused entirely on the 3 metrics that actually drive revenue.

The Lesson for Founders

If you are a founder running a “Company of One,” you don’t have a Sales Enablement team to do this for you. You are the SME, the Sales Rep, and the Trainer.

You need a Translation Layer. You need an AI workflow that takes your product updates and instantly converts them into a value proposition.

That is the difference between “having a product” and “closing a deal.”

Are you a founder struggling to translate features into revenue? Let’s connect - I’m building the systems that turn technical specs into business wins.

Follow my newsletter to learn more about building AI-powered enablement solutions for your field teams

I wanted a way to write my blog posts in Markdown and have them automatically appear in my newsletter. While Substack is a great platform, its lack of a developer-friendly API makes automation feel like a “hack.” I’ve learned that Ghost has an official API and can be used to create another worklow from markdown to html. So I’ve decided to give it a try.

Today, I moved from “manual vibes” to “technical enablement.”

What I Learned

1. API vs. Scraping: Using a headless browser (like Playwright) to mimic a human is cool, but using an official Admin API (like Ghost’s) is professional and stable.
2. Data Transformation: I learned that my Jekyll “Front Matter” (the stuff between the ---) needs to be peeled off before a blog platform can read the story.
3. GitHub Actions: My GitHub repository isn’t just a storage box; it’s a tiny computer that can run scripts for me every time I hit ‘Save’.

The Setup

I’m now using a Node.js script with gray-matter and marked to translate my local Jekyll files into Ghost-ready HTML.

If you see this post on my newsletter, the automation worked. 🚀 Follow me to get the most updated content and resources on AI Enablement.

For the last few years, especially when I was teaching developing courses in AWS, this narrative has been seductive: “You don’t need to learn to code. AI will do it for you.”

In my role leading Product Enablement at a $2.6B cybersecurity firm, I lived comfortably in that “No-Code” world. I built complex systems using drag-and-drop tools, LMS platforms, and logic. I was the bridge between Product and Sales—the human connective tissue that made sure the technology actually got used.

But as I look toward the next era of work—specifically the rise of the Billion-Dollar Company of One—I’ve realized something critical.

AI can write the code. But it needs an Architect to design the blueprint.

That is why, this month, I am doing something that seems counter-intuitive for a strategic enablement leader: I am learning to code with Claude.

From Enablement Lead to AI Enabling Architect

I am not trying to become a full-stack developer. I have no interest in debating the merits of React vs. Vue or memorizing syntax for 8 hours a day.

My goal is Code Literacy, not Code Fluency.

In 2026, the bottleneck for non-technical founders isn’t “having an idea.” It’s the friction of execution. They have 20 different AI subscriptions—Relevance AI for agents, Clay for data, Slack for communication—but those tools don’t talk to each other. They are “over-tooled and under-enabled.”

I am learning to code so I can build the Connective Tissue between those tools.

Why Claude Code? (The “Centaur” Advantage)

I just picked up a subscription to Claude Code, Anthropic’s advanced coding agent. Why? Because it changes the learning curve entirely.

• Old Way: Learn syntax → Write Code → Debug Errors → Build Logic
• The Centaur Way: Define Logic → Architect System → Claude Writes Code → I Review & Deploy

By taking a focused 5-hour course on video coding alongside Claude, I am skipping the “Syntax Valley of Death.” I am learning how to ask the machine to build “Glue Scripts”—simple Python or JSON bridges that automate the boring stuff.

Example: Instead of manually downloading a transcript from a PM demo, summarizing it, and uploading it to an LMS, I can now ask Claude to: “Write a script that watches this Drive folder, sends new audio to Gemini for synthesis, and pushes the JSON output directly to the Docebo API.”

That is not “coding.” That is Automated Enablement.

The “Unfair Advantage” for Non-Technical Founders

This journey isn’t just about me. It’s about the market I’m preparing to serve.

There is a massive wave of non-technical founders entering the arena. They have vision, they have sales skills, and they have grit. But they are terrified of the “Black Box” of engineering.

By becoming an AI Architect who speaks their language (Business/Sales) and the machine’s language (Code/Logic), I can offer them something a standard dev shop cannot:

1. Security: I apply “Cybersecurity-grade” governance to their AI agents (thanks to my background).
2. Context: I ensure the AI understands their GTM strategy (thanks to my Enablement roots).
3. Independence: I build systems they can run themselves, rather than locking them into an expensive engineering retainer.

The 5-Hour Challenge

I am giving myself a deadline. I am taking a 5-hour “Code with Claude” crash course. My goal is not to build a Facebook clone, but to build one functioning, autonomous agentic workflow that solves a real problem in my current day-to-day work.

I’m building the nervous system for the next generation of companies. And I’m starting with my own.

Are you a non-technical founder drowning in tools but starving for a system? Let’s connect. I’m building the connective tissue you’ve been looking for.

I decided to “clean up” my GitHub Blog site by adding custom Jekyll layouts.

What followed was a full-site disappearance, several moments of self-doubt, and a crash course in how Jekyll really works once you remove the training wheels.

This post is a field report from the debugging trenches.

The Symptom: Everything Went Blank

No errors. No warnings. No failed builds.

Just… white pages.

My About page? Gone.

My blog posts? Gone.

My immediate thought:

“Did I just nuke my site?”

Spoiler: no.
But I did remove a bunch of invisible scaffolding I didn’t realize I was relying on.

Phase 1: CSS Panic (Red Herring)

My first instinct was styling.

I had just removed the default Jekyll theme and added my own layouts, so maybe I messed up CSS?

I checked:

• Text color
• Background color
• CSS loading in DevTools

I even added the nuclear test:

body {
  color: red !important;
}

Still blank.

That was the clue: 👉 This was not a CSS problem.

Phase 2: Understanding Layout Chaining (The Real Culprit)

Here’s the thing no one tells you clearly:

Jekyll layouts do not auto-compose.

You must explicitly chain them.

I had:

• default.html
• page.html
• post.html

But my page.html originally looked like this:

---
layout: default
---
<section>
  <h1>{{ page.title }}</h1>
  {{ content }}
</section>

I changed it to look like this:

---
layout: default
---

<article>
  {{ content }}
</article>

I changed it and suddenly, the About page came back to life. However, my blog posts were still missing. The reason?

This is where Jekyll gets very strict.

Posts must follow all of these rules or they fail silently:

Must live in _posts/

Must be named YYYY-MM-DD-title

Must have valid front matter

Must use a supported extension

That’s when I noticed something subtle:

Working posts: .markdown

Broken post: .md I had renamed one post to .markdown, and that was the problem.

The .md extension is not supported by Jekyll for posts, and it silently fails to render. Changing it back to .markdown fixed the issue immediately.

Key Takeaways

1. Jekyll is very particular about file structure and naming conventions.
2. Layouts must be explicitly chained; they do not auto-compose.
3. Always check the file extension and front matter when debugging missing content.
4. When in doubt, check the Jekyll documentation for supported file types and structure.
5. Use DevTools to check for CSS issues, but remember that not all problems are styling-related.
6. When you break something, take a step back and methodically check each layer of your site’s architecture.
7. Don’t be afraid to experiment and learn from mistakes; that’s how you truly understand how things work.

Final Thoughts

This experience was a humbling reminder that even tools designed to be user-friendly have their quirks and complexities. It’s easy to assume that everything will just work, but when it doesn’t, it’s an opportunity to learn the underlying mechanics. In the end, I’m grateful for the experience because it deepened my understanding of Jekyll and how GitHub Pages works.

If you’re a technologist writing in public:

Breaking your own site once is not a failure.

It’s the moment you stop renting abstraction and start owning the stack.

And honestly?

That’s where the fun begins.

Then I walked away.

When I came back, I remembered none of the details—only that it worked and that I was slightly afraid to touch anything.

This post documents how I reverse-engineered my own setup, confirmed everything was still healthy, and published a new Markdown blog post without breaking the pipeline.

If future you is reading this: you’re welcome. :)

The Problem: “I Know I Did This Before… But How?”

I didn’t remember:

• How the site was deployed
• What triggered the build
• Where blog posts were supposed to live
• Whether I used Jekyll, Pages, or some custom magic

What I did know:

• The site was live
• I had pushed posts before
• GitHub Actions was involved

So instead of guessing, I treated this like a troubleshooting exercise.

Step 1: Find the Source of Truth (The Repo)

First, I identified the repository that actually powers the site.

This was either:

• username.github.io, or
• A repo with GitHub Pages enabled under Settings → Pages

Once I found it, I stopped worrying about memory and started trusting the repo history.

Step 2: Confirm How GitHub Pages Is Deploying

In Settings → Pages, I checked the Source.

Seeing “GitHub Actions” immediately answered a big question:

Okay, I didn’t manually deploy this. A workflow does it for me.

That meant:

• I don’t need to run commands locally
• A git push is all it takes
• If something breaks, the answer will be in Actions logs

Step 3: Inspect the GitHub Actions Workflow

Next stop: the Actions tab.

I opened the most recent workflow run and then the actual workflow file under: .github/workflows/

Key things I verified:

• The workflow triggers on pushes to main
• It builds the site
• It deploys to GitHub Pages

At this point, I knew:

If I commit the right files to the right place, the rest is automatic.

Step 4: Confirm This Is a Jekyll Blog

To avoid posting content in the wrong format, I checked the repo structure.

Seeing these files made it clear:

• _posts/
• _config.yml
• Gemfile

This is a Jekyll-powered GitHub Pages blog.

That answered another critical question:

Blog posts must go in _posts/ and follow Jekyll conventions.

Step 5: Reverse-Engineer a Past Post

Instead of guessing the format, I opened an existing blog post.

Things I noted immediately:

• Filename pattern: YYYY-MM-DD-title.md
• YAML front matter at the top
• Layout name (post)
• Date format

That old post became my template.

This is a highly underrated move: let your past work tell you what’s required.

Step 6: Create the New Markdown Post

With confidence restored, I created a new file: From there, it was just writing Markdown. No tooling. No local preview. No overthinking.

Getting Started: The Basics

The goal was to set up a Jekyll-powered blog hosted on GitHub Pages. I started by creating a new repository following the naming convention for GitHub Pages, learned about the necessary configuration (_config.yml), and set up the basic folder structure including _posts for blog entries.

Navigating Common Pitfalls

1. Homepage Display Issues

One of the first challenges I faced was with the homepage not displaying as expected. After some trial and error, I realized the problem was with the front matter in my pages. Copilot quickly pointed out the correct format for front matter and how it affects page rendering.

2. Broken Links (404 Errors)

After fixing the homepage, I noticed internal links were leading to 404 errors. Copilot helped me understand the difference between url and baseurl in _config.yml, and how these settings depend on whether the site is a user/organization site or a project site. With Copilot’s guidance, I adjusted my _config.yml and updated my links to use Jekyll’s relative_url filter, ensuring they worked regardless of site location.

3. Repository Naming and Site URL

I was confused about why my site was appearing at a subpath instead of the main GitHub Pages domain. Copilot explained the difference between user/organization sites and project sites, emphasizing the importance of naming the repository correctly (username.github.io for user/org sites), and clarified the expected site URL for each scenario.

4. Creating and Publishing Blog Posts

I wanted to add new blog posts, but sometimes they wouldn’t appear on the site. Copilot provided a thorough checklist: verifying the _posts folder name, the filename convention, correct front matter, and waiting for GitHub Pages to rebuild. This step-by-step troubleshooting made it easy to spot and fix mistakes.

5. Enhancing the Blog

Once the basics were working, I asked Copilot how to add features like a to-do list app, images in blog posts, and even a comments section. Copilot provided ready-to-use code snippets and layout templates, making it simple to extend the site’s functionality.

Problem Solving with GitHub Copilot

Throughout the project, GitHub Copilot was an invaluable assistant. Here’s how it helped:

• Instant Answers: Whenever I hit a roadblock, Copilot provided clear explanations, code samples, and configuration advice.
• Troubleshooting Checklists: For every issue, Copilot gave me actionable checklists to systematically diagnose and resolve problems.
• Customization Tips: From adding images to integrating third-party comments, Copilot offered practical examples tailored to my project.
• Learning as I Build: Instead of just solving problems, Copilot explained the reasoning behind each fix, helping me learn the “why” and not just the “how.”

Conclusion

Building a Jekyll site on GitHub Pages is a fantastic way to learn about web development and static site generation. With GitHub Copilot’s help, I was able to overcome common issues quickly, understand best practices, and expand my site with new features. If you’re working on a similar project, don’t hesitate to ask Copilot for troubleshooting advice—it’s like having an expert by your side, 24/7.

This is related to [2026-01-09-jekyll-layout-learning]