We Ran a Claude Code Workshop for Non-Technical Founders. Here’s Everything We Covered.

Most Claude Code content online is made by developers, for developers. Our founders aren’t developers. Here’s what we actually teach in our live sessions — and what you need to know to set it up yourself.

TL;DR: We run live Claude Code setup sessions for the women in our Women Build Cool Sh*t cohort. Most of them are non-technical founders. The tutorials online assume you know what a terminal is and what a markdown file does. Our founders don’t — and they shouldn’t have to. This post covers everything from our latest session: what CLAUDE.md is and why it matters, how to use multiple memory files, what tools, skills, and MCPs are, how plan mode works, and the shortcuts that actually save time. If you’ve been staring at Claude Code wondering where to start, this is the post.

What You Will Learn in This Post

• Why We Run These Sessions
• CLAUDE.md: The Brain of Claude Code
• Multiple CLAUDE.md Files: The Nesting Strategy
• A Good CLAUDE.md Takes Days, Not Minutes
• Tools, Skills, and MCPs: What They Are and Why They Matter
• Plan Mode vs. Build Mode
• The Shortcuts That Actually Matter
• You Don’t Need to Be a Developer to Use This

Why we run these sessions

Every other Tuesday, Kyle — our tech lead — runs a live Claude Code session for the cohort. We alternate between teaching sessions and troubleshooting office hours. The teaching sessions cover setup, features, and workflows. The office hours are for when you’re stuck and need someone to look at your screen and tell you what went wrong.

We do this because most of the Claude Code content online is made by developers who assume you already know what a terminal is, what a repo is, and what “navigating your file system” means. Our founders are nurses, jewelers, speech pathologists, and astrophysicists. They’re brilliant. They’re building real products. But nobody taught them how to open a terminal, and the YouTube tutorials skip that part.

So we teach it. From scratch. No assumptions. And everything we cover gets documented in a Notion guide that founders can reference between sessions. If you get stuck next Tuesday, you bring screenshots to Kyle’s office hours. That’s the system.

CLAUDE.md: the brain of Claude Code

If you’ve been on social media at all, you’ve seen a thousand posts about CLAUDE.md files. Everyone’s sharing theirs. Everyone has opinions. Here’s what actually matters.

CLAUDE.md is a file that Claude Code reads every time you start a session. It’s the first thing it looks at. Everything you put in that file becomes context that Claude carries through your entire conversation. Think of it like the settings you’d put into ChatGPT or Claude’s chat — “this is how I like you to write, this is my communication style, these are my preferences” — except it’s far more powerful because Claude Code can actually act on it.

Here’s what a good CLAUDE.md includes:

• Who you are. Your role, your business, your stage. Claude should know if you’re a solo founder at pre-revenue or a team of five at $200K ARR.
• How you communicate. Do you want short responses or detailed explanations? Do you hate em dashes? Do you want one recommendation or five? Put it in there.
• What tools you use. Gmail, Notion, Dubsado, Slack, Google Calendar — whatever your stack is. This is underrated. Claude can tell you which tools have MCPs or APIs worth connecting.
• Your rules. Things like: never send anything without my review. Never delete files. Always ask before installing something new. Don’t give me five options when I ask a question — give me the best one and tell me why.
• Your tech stack (if you’re building a product). What frameworks you use, what’s already built, what’s planned.

Here’s what most people online get wrong: they share these massive CLAUDE.md files with thousands of words. The problem is that Claude Code reads about 500 to 1,000 characters of the file before it says “okay, I’ve got enough” and moves on. So if your most important rules are buried at line 200, Claude might never see them.

“Keep your CLAUDE.md short and direct. Claude reads the top of the file most carefully. Put your most important rules first. Be specific without being verbose.”

One thing Kyle mentioned that I think is underrated: you can tell Claude to self-regulate. Put something like “if you notice I’m redirecting you often to do something a different way, flag it so we can add it as a rule.” Claude will start catching its own patterns and suggesting updates to your CLAUDE.md. That’s how the file gets better over time without you having to remember every preference.

You can also have Claude help you create the file from scratch. Give it a prompt like: “I want you to ask me questions about my business, my preferences, my tools, and my communication style. Let’s create a CLAUDE.md file together.” It’ll interview you and generate a solid starting template.

Multiple CLAUDE.md files: the nesting strategy

This is the part that clicked for a lot of founders in the session. You don’t just get one CLAUDE.md file. You can have many — and they stack.

Here’s how it works. You put a CLAUDE.md in your top-level folder. That’s the master file — the one CLAUDE.md to rule them all. It applies to everything you do in that folder and everything inside it. Then if you create a subfolder — say, a folder for a specific project — you can put another CLAUDE.md inside that subfolder. When Claude is working inside that project folder, it reads both files, but it treats the closer one as more important.

So your top-level file might say: “I’m Nomiki, I run Theanna, here’s how I communicate.” And then your project-level file says: “This project uses Next.js and Supabase. Here’s what’s been built. Here’s what’s planned.” Claude gets both, but it prioritizes the project-specific context when it’s working in that folder.

The key rule: don’t put two CLAUDE.md files in the same folder. That will confuse Claude. One CLAUDE.md per folder level. Nest them in subfolders if you need more specificity.

You can also reference other files from inside CLAUDE.md. Something like: “reference my memory file when we talk about past decisions.” Claude will go read that file when it’s relevant. Files inside files inside files. It’s a rabbit hole, but it’s a useful one — especially when your context is too large for a single file.

A good CLAUDE.md takes days, not minutes

I want to be honest about this because nobody online is. A good CLAUDE.md file takes days to prep. Not minutes. Not an hour.

Everyone shares their file like it’s a copy-paste job. “Here’s my perfect CLAUDE.md!” But your file needs to be tailored to you. Your business, your tools, your communication style, your specific workflows. A developer’s CLAUDE.md is going to be 100% code-focused, and that’s useless if you’re using Claude Code to draft emails, research competitors, and manage your CRM.

Kyle put it well: he’s always tweaking his. It’s a living document. You start with a template. You use Claude for a few days. You notice it keeps doing something you don’t like — giving you five options when you want one, recommending tech stacks you’ve already decided on, writing too formally. You update the file. You keep going. Over a few days, it gets really good.

The founders in our cohort start with a template we provide. Then they iterate. And the ones who invest the time in getting their CLAUDE.md dialed in are the ones who get the most out of every session after that.

Tools, skills, and MCPs: what they are and why they matter

These three concepts come up constantly in Claude Code conversations online, and most people conflate them. Here’s the simple version.

Tools

Tools are the built-in capabilities that Claude Code comes with. These let it navigate your terminal, browse the web, create files, read images, make PDFs — the basics. You probably won’t think much about tools because Claude Code ships with most of what you need. You’ll just be surprised at what it can do. “Oh, it can do that?” Yes. It probably can.

Skills

Skills are where it gets fun. These are custom capabilities you create — or that Claude creates for you — that become slash commands you can run anytime. Type /morning and it kicks off your daily briefing. Type /newlead and it creates a CRM entry, checks your email, and updates your Notion.

Kyle showed us his. He has skills for everything: weekly planning, end-of-day summaries, client follow-ups, revenue snapshots, even a Reddit scout that finds threads where he can add genuine value. Some he built intentionally. Some Claude created on the fly when he asked it to do something new, and he just kept them.

Here are some real examples from the session:

• Morning briefing. Kyle types one command and gets: what he tackled yesterday, what’s on his plate today, and a list of active clients. I built something similar that goes through my email and calendar and tells me who to respond to, who’s a cold DM, and what meetings I have.
• End of day. Summarizes everything he did, asks if anything’s missing, updates his task lists and Notion, syncs his Google Calendar, and tells him what’s coming tomorrow.
• New lead. Creates a CRM entry in Notion, checks email for context, reviews the proposal system, and pulls in scope details. One command.
• Content research. Scours social platforms for viral posts, analyzes formats, and suggests content ideas based on your content pillars.
• Competitor research. Checks competitor URLs for pricing changes, new posts, updated messaging, and ad creative.

You can create skills two ways. Tell Claude what you want: “I want a skill that checks my email every morning and summarizes what needs my attention.” Or just ask Claude to do something, and when it builds a tool to accomplish it, you keep it as a skill for next time.

Fair warning: you will build skills you never use again. Kyle admitted to this. Claude creates slash commands every time it builds something new, and you end up with a list of commands that mean nothing because they were one-time asks. That’s fine. The ones you use daily are worth it.

MCPs

MCPs — Model Context Protocol connections — are how Claude Code connects to your other apps. Think of them as APIs that let an AI have control. Gmail, Notion, Google Calendar, Slack, GitHub — these all have MCP connections.

When Kyle connects Claude to his Gmail, it can monitor his inbox, flag emails he hasn’t responded to in five days, review the thread, and either tell him “you’re waiting on them, this is fine” or “you should follow up, here’s a draft.” When he connects to Notion, it updates his CRM and task lists automatically. When he connects to Google Calendar, it blocks off prep time before meetings and tells him what’s coming tomorrow.

The security note here is important: be careful about which MCPs you connect. MCPs give significant access in both directions. Stick with MCPs made by the official app teams — Notion’s official MCP, Google’s official MCP. If it’s a third-party MCP from a random developer, check the GitHub stars, check how many people use it, and ask Claude to review it before you connect. If you’re unsure, literally ask Claude: “What am I risking by connecting this?” It will tell you.

Plan mode vs. build mode

This is one of the most underused features, and one of the most valuable — especially if you’re not a developer.

By default, Claude Code is in build mode. You tell it something, it starts doing it. That’s great for small tasks. But for anything complex — a landing page, a new feature, a content system — you want plan mode first.

Plan mode tells Claude: don’t build anything yet. Let’s talk through what we’re doing first. Claude will ask you clarifying questions. Should this process payments or just collect emails? What’s the vibe — clean and premium or over the top? Where should this live? It prompts you with things you didn’t think of, and that’s the whole point.

Kyle demoed this live by asking Claude to build a spicy pickle landing page. In plan mode, Claude asked: should it process payments or just be a waitlist? What’s the visual style? Should it be a separate repo or a subdirectory? It laid out a plan — single HTML file, no framework, hero section with urgency hooks, bold colors — and waited for approval before building anything.

One of our founders, Kristy, asked a great question: why use plan mode when Claude sometimes walks you through things anyway? Kyle’s answer was practical. Two use cases:

• When the task is large and complex and you want to make sure Claude understands all the pieces before it starts. It’s harder to fix a bad foundation than to plan a good one.
• When you have a specific vision and you want Claude to prompt you for the details you forgot. Plan mode surfaces questions like “should this be mobile responsive?” that you might not have mentioned in your initial prompt.

You can toggle plan mode with Shift+Tab, or just tell Claude: “let’s make a plan before we build.” It’s smart enough to understand.

The shortcuts that actually matter

Claude Code has a lot of features. Here are the ones Kyle highlighted as actually useful day-to-day:

• Shift+Tab toggles between three modes: normal mode, accept edits on (Claude asks permission before changing files), and plan mode. Accept edits on is a good default — it prevents Claude from making changes you didn’t approve.
• Context window management. You’ll see a percentage that tells you how much context you’ve used. When it gets high, Claude compresses the conversation by summarizing. You can also manually clear context before starting a big task so Claude has maximum room to work.
• Cost tracking. You can check how much a specific prompt cost, how much you’ve used total, and switch models to manage spending.
• Model switching. Claude Code defaults to Opus, which is the most powerful but uses the most tokens. If you’re using Claude’s chat interface for non-coding tasks, switch to Sonnet to save tokens.
• Branch creation. If you’re about to make a big change and you’re nervous about breaking things, tell Claude to create a separate branch. It’s like saving a version of your Google Doc before letting someone else edit. If the experiment fails, your original version still exists. You don’t have to say “create a branch” — just say “let’s make a separate version so I can try this without breaking anything.”

The context window problem is real

One of our founders, Joy, came into the session early with a problem I’m hearing more and more: Claude was hallucinating. It was grabbing context from previous conversations, referencing things that didn’t exist, and generally getting confused.

The diagnosis was simple: too much context in one chat. She’d been treating everything as one long conversation instead of resetting between tasks. Once the context window fills up, Claude starts compressing and summarizing, and that’s where it loses precision.

The fix is straightforward: start new conversations for new tasks. Don’t pile everything into one session. If you’re switching from building a feature to writing an email to researching competitors, those should be separate conversations.

We’re actively working on a better solution for this at Theanna — implementing Pinecone for long-term context management so that founders can maintain continuity without cramming everything into one window. It’s not done yet, but it’s a real problem and we’re building for it.

You don’t need to be a developer to use this

I need to say this directly because I know some of you are reading this and thinking: this sounds like developer stuff. It’s not. Or rather — it doesn’t have to be.

Kyle is a developer. He uses Claude Code for development maybe 50% of the time. The other 50% is business operations, client management, content research, email triage, and task management. I’m a non-technical founder. I use Claude Code every day, and I’m at $207K ARR. The tool is only as limited as the instructions you give it.

The terminal is just a way to talk to your computer. The CLAUDE.md file is just a way to tell Claude who you are. Skills are just saved workflows. MCPs are just connections to your other apps. None of this requires you to write code. It requires you to think clearly about what you want and communicate it.

One founder in the session said something that stuck with me: she gets anxious about setting rules because she’s worried she’ll over-constrain Claude and lose impact. Here’s what I’d tell her and anyone else feeling that: the rules aren’t constraints. They’re leverage. The more Claude knows about what you want, the less time you spend redirecting it. The rules are what make it fast.

Also — if you’re using GitHub, remember that you can always go back. Every version is saved. You can experiment as aggressively as you want and never lose your working version. That’s the whole point of version control. It exists so you can break things safely.

What’s next

Our next session will be Kyle’s troubleshooting office hours, where founders bring screenshots of what’s not working and we fix it live. After that, we’re planning the April sessions — and they’re going to get more complex. More advanced skills. More MCP integrations. More real-world workflows.

If you want to be in these sessions, you need to be in the cohort. Every recording is saved. Every workflow is documented. And you get Kyle for 1:1 tech support between sessions.