Sparkfile

The flagship

The Founder's Claude Automation Roadmap

A 90-day plan to build a founding team of AI cofounders and run it as CEO. Plus a Claude Code path and a chat-only track, all on Claude.

You can’t add three cofounders. So add them another way.

Founder fallout is one of the top reasons startups fail. Not the market, not the product, the founders falling out with each other. The usual hedge against that is a real founding team, enough people that no single job is one person’s to drop. A solo operator can’t build that hedge. You can’t will three more humans who believe in the thing into existence, and if you find them, fallout is the exact risk you just took on.

So build the team with AI instead. Three AI cofounders, each owning a real role, plus you in the chair. That’s the Founding Four:

Every business has these four jobs, whatever it sells. Give three of them to Claude, keep the fourth for yourself, and a team of one becomes a team of four. Nobody gets replaced, because there was never anybody to replace; this is coverage you didn’t have yesterday, added without payroll and without the fallout. This roadmap is how you hire that team over 90 days and get to the point where it runs without you standing over it.

It’s the same team whatever you run

A founder building a SaaS, an agency owner living on client work, a shop owner wearing every hat, a fly-fishing outfitter booking a season of trips. The roles don’t change. Growth books the work, Ops delivers it, Brand makes people pick you, and you decide. Business type changes the examples and a couple of the files, not the team. (“Founder” in the title is shorthand for that operator, whatever your business card says.)

Two worked examples run through this roadmap so it never floats off into the abstract:

If a section only makes sense for software, it’s failing the concept. Watch for that and steal the version that fits what you actually run.

What a role is made of

A role isn’t a metaphor. Each AI cofounder is a Claude agent with two things:

  1. Its own memory file, the role’s mandate and standing context. GROWTH.md, OPS.md, BRAND.md. What this role is responsible for, what it should know, how it thinks about its job. It’s the brief you’d hand a real cofounder on day one.
  2. Its own playbooks, the recurring workflows that role runs. Growth’s are the outreach draft, the proposal, the follow-up. Ops’s are the weekly review, the report, the ship. Brand’s are the voice check and the consistency pass.

On top of that sits the shared company context every role reads: PRODUCT.md (or what you sell), USERS.md (or who you serve), GOALS.md. That’s the stuff a whole team has to agree on before anyone starts.

Give a cofounder its file and its playbooks and you’ve hired it. That’s the whole hire.

Orientation: jargon you might have seen elsewhere

If you’ve read automation material built around a separate agent framework, here’s what that jargon actually means on Claude. If you’ve never touched any of it, skip this table; you don’t need the vocabulary to hire the team.

If you’ve heard… …here’s what it means on Claude
An “agent gateway” you install and run yourself Nothing to install, Claude Desktop (Chat, Cowork, Claude Code) already does this
A custom “memory harness” or context files Your role files and shared brief: plain markdown (GROWTH.md, a CLAUDE.md, a Project’s knowledge files), no framework
Hand-written cron jobs Recurring workflows inside Cowork or Claude Code, check current capabilities in Claude for exact scheduling mechanics, since this is an active area of development
“Multi-agent orchestration” Your chief of staff: subagents in Claude Code, or one coordinating session in Cowork or Chat that works the roles in turn, real, built in, simpler than the term makes it sound
Wiring your own tool integrations Claude’s Connectors, built on the open MCP standard, one-click, not hand-rolled
A framework’s proprietary “skill” system Claude’s own Skills, reusable instruction sets you write once

The short version: other people’s roadmaps spend the first month building infrastructure. Yours spends it hiring a team, and the team is what compounds: the three cofounders, your judgment, and the cadence you run them on.

Pick your track

The 90-day spine is identical for everyone: hire three cofounders, put them to work, make them durable. What changes is which examples land and which files each role keeps.

Shared company context (everyone writes these in Phase 1): PRODUCT.md (or what you sell), USERS.md (or who you serve), GOALS.md.

The role files (everyone writes these in Phase 1): GROWTH.md, OPS.md, BRAND.md. Each role owns some sub-files, and which ones you keep depends on your business:

Role Owns Sub-files it keeps
Brand Identity, voice, design, experience VOICE.md (everyone)
Growth Sales, outreach, marketing, content ICP.md (everyone, by Phase 2), OFFERS.md (services/local especially)
Ops Delivery, systems, admin, the build CLIENTS.md, PROJECTS.md (services/local), DECISIONS.md, HIRING_BAR.md (when hiring)

For a services or local business, OFFERS.md and CLIENTS.md aren’t optional in spirit. They’re as central as PRODUCT.md is for a startup. Templates for every file are at the end.

Running it from your phone

The one job that stays yours, clearing approvals, doesn’t have to happen at your desk. Which phone surface you use depends on where the team runs, and both leave the actual work on your computer, not on your phone.

If your team runs in Claude Code (the repo-and-terminal spine this roadmap leans on), that’s Remote Control: it bridges the live session already running on your machine to your phone or a browser, so you can watch it work, approve or reject an action, and redirect it mid-task. The session stays local the whole time; nothing moves to the cloud. If your team runs in Cowork instead, the companion is Dispatch: from the Claude app you message a task and it opens a session on your desktop to do the work, then relays anything waiting on your yes back to the phone. Check current availability and plan requirements at claude.com; both surfaces are new, still changing, and gated by plan tier.

One setup step: turn on push notifications. Remote Control can ping your phone when the team needs a decision or finishes a task, but it ships with that off. Turn on both in Claude’s settings: one push for permission requests (the gate case), one for finished tasks. The exact place and labels move as the app changes, so if it isn’t where you look first, check current docs at claude.com. Tapping the notification opens the session, so the ping is also the way back into it.

This is the CEO’s actual day once the team is running: between meetings you get a push, open the session on your phone, see the thing the Founding Four flagged for your yes, approve it or send it back with a note, and move on. The team kept working the whole time. This is part of the roadmap, not an add-on: the one job that stays yours, done from wherever you happen to be standing.

The 90-day roadmap

Three phases, roughly 30 days each. Budget five-ish focused hours a week in month one, tapering to two or three by month three. This assumes a Claude plan that includes Cowork, check current plan requirements at claude.com, since this shifts.

In practice the phases blur. You’ll still be running Phase 1’s playbooks deep into Phase 2. The calendar sequences the work; it doesn’t grade you. Hire the team before you overload it, and make it durable before you trust it unwatched. The pace assumes you’re running this alongside the business, and that’s the design: speed lowers the cost of staying in the game. Nobody is timing you.

Don’t read 90 days as one long wait. Two clocks run here. The work clock is fast: you’ll have the shared brief written in week one and your first cofounder hired in week two. The proof clock is slow, and has to be: a weekly review only starts telling you anything after a few weeks, and for a services business, durable means surviving a full client cycle. The 90 days are for the proof clock. The work starts paying off in week one.

Phase 1: Hire the Team (Days 1–30)

You don’t install anything. You write the briefs that turn a blank Claude into three cofounders who know your business. One cofounder a week, plus the shared context first.

Still choosing what to build? This roadmap assumes the business is decided, even if only in your head. If you’re still weighing two or three ideas, run them through the idea filter first: four gates, two human checks, and a verdict of Keep, Bench, or Scrap. Its first gate is proven demand — check that programmatically, no screenshots, before you guess. Filter first, then come back and hire.

Week 1: Write the company brief. There’s no install step. Open Claude Desktop and create a Project. In Cowork or Claude Code, point it at a folder: ~/company-os/ (or ~/founder-os/, whatever you’d actually call it). In Chat, add those same files as the Project’s knowledge instead. Check current docs at claude.com if the mechanics have moved. Then write the shared context every role will read: PRODUCT.md (or what you sell), USERS.md (or who you serve), GOALS.md. First draft, not perfect, see What is a memory file, and why every operator should keep one if you haven’t already. Test it: ask a question only someone who’d read those files could answer well (“what’s our biggest risk right now, per GOALS.md?”). A generic answer means thin files, not a bad model.

This is the brief a whole founding team would have to agree on before anyone started. Get it down before you hire a single cofounder.

Services / agency / local: the fly-fishing outfitter’s PRODUCT.md is “guided trips” and its USERS.md is “who books them and why.” The agency set up exactly this in its first pass. If you’re working from the Starter Kit, its CLAUDE.md notices the templates are still blank and walks you through this the moment you open the folder.

Already running the business? Don’t write these from a blank page. Point Claude at what already exists, your docs, your chat history, the project repo if there is one, and have it draft PRODUCT.md, USERS.md, and GOALS.md from that, then correct the drafts by hand. Correcting a wrong draft is faster than composing a right one. One placement note: company-os sits beside an existing project repo, not inside it, and Ops gets pointed at both.

Week 2: Hire Brand. Brand owns how everything you put out sounds and looks. Write BRAND.md (its mandate: guard the voice, keep the look and the customer experience consistent). Then write its core sub-file VOICE.md: paste in two or three things you’ve written that you’re proud of, plus a running “not me” list of phrases you never want to see again. Then give Brand its first playbook: the voice check, hand it a draft and ask “does this sound like us, per VOICE.md, and what’s off?” Run it by hand on something real this week.

Staring at a blank VOICE.md is the single most common place operators stall. If that’s you, use the build-your-voice-md playbook: it builds the file through a few questions instead of a blank page.

Week 3: Hire Ops. Ops owns delivery, systems, and the internal rhythm. Write OPS.md (its mandate and the sub-files it keeps: CLIENTS.md / PROJECTS.md for a client business, DECISIONS.md for everyone). Then give Ops its first real playbook and go deep on exactly one: the Weekly Review, “read what’s changed across my notes this week, pull my top 3 priorities from GOALS.md, and flag anything I said I’d do and haven’t.” For a services or local business, point it at CLIENTS.md and PROJECTS.md too, so it flags any client gone quiet or any next-step that’s slipped. Run it by hand. Resist adding a second Ops playbook this week. The point is depth: does the output change what you do next?

Week 4: Hire Growth, then pause. Growth owns bringing in the next customer. Write GROWTH.md and its context: ICP.md (who you actually sell to, in plain language) and, for a services or local business, OFFERS.md (your packages and prices, so a quote starts from a decided model instead of a blank page). Give Growth its first playbook: whichever customer-getting motion you lean on hardest (outbound, inbound, or the proposal), draft-only for now. The proposal play is spelled out step by step in Phase 2. While you’re in GROWTH.md, add one standing line to the mandate: content starts on day one of the business, not the day the product is ready (Phase 2 explains why that line earns its place). Then stop hiring. Read back what the three cofounders produced this month and update the files where they were thin.

Phase 1 deliverable: a real folder with the shared company brief and three role files, each role with one playbook you’ve actually run more than once, and a weekly check-in habit (which is itself Ops’s first playbook).

Watch for:

  1. Hiring a cofounder and never giving it a second job. A cofounder with one playbook is a cofounder you’ve barely hired. Most of the value shows up after the second playbook, not the first.
  2. The month that quietly stalls. You build the Weekly Review, get busy, and never write Growth’s file. Block one 90-minute session per week specifically to hire the next cofounder.
  3. Voice drift. By week three you’ll stop noticing how templated Brand’s output sounds. Every couple of weeks, read the last ten outputs end to end and add anything off to VOICE.md.
  4. The files go stale. You write PRODUCT.md once in week one and never touch it, so by week four the whole team is working from a two-week-old picture. Put a recurring 10-minute “update the files” block on your own calendar, not the team’s.

Phase 2: Put the Team to Work (Days 31–60)

Three cofounders exist. Now they earn their keep against your real jobs. Each cofounder gets real playbooks, and near the end of the month you get your first taste of talking to the team through one session instead of three.

Week 5–6: Growth goes to work. Build the customer-getting playbook that matches how you actually win work. Most businesses run more than one motion; build the one you lean on hardest first.

Whichever you build, the rule is the same everywhere: give it the real artifact (the actual prospect, the actual inbound, the actual call notes), not a summary of it.

And start the content motion alongside whichever you built. Content is the one Growth motion that isn’t either/or with the others, and the one operators defer longest. The case for starting now: a page has to be published before it can be found, search engines favor pages that have had time to earn their place, and the AI assistants your buyers increasingly ask draw on that same web. You can’t buy that time back later, which is why content starts on day one of the business, not the day the product is ready. Keep the bar low and the cadence real: one page that answers a question your buyer already asks (what you do, what it costs, how you compare to the alternative they’re weighing), drafted by Growth, published by you. Publishing is public, exactly what Phase 3’s gate exists for; until you build the gate, you are the gate.

Growth’s proposal playbook, step by step

A real, documented play, not a description of one. It’s the systematized version of two website proposals the author’s agency first wrote by hand (for two contractors), then turned into a reusable playbook so the next one starts from a draft instead of a blank page. The fly-fishing outfitter runs the same five steps to quote a custom multi-day trip. Five steps:

  1. Research the prospect. Point Claude’s web search at the client. Pull whatever’s real: an existing site or the lack of one, services, their Instagram or Nextdoor, reviews. For a small local business, expect thin results. The rule that keeps it honest: grab what’s there, flag what’s missing, never invent a service list or a review to fill the gap.
  2. Open on the real pain, from your files. The draft leads with what the client actually complains about (from USERS.md), not a generic intro. For a website that’s usually “people keep asking what your site is and there isn’t one.” For the outfitter it’s “you want a trip built around your father-in-law who hasn’t cast in twenty years, not the standard float.”
  3. Price it from OFFERS.md, recommendation first. Put the offer you want them to take at the top and keep the cheaper option as the walk-away alternative. For the agency that’s a lower build fee plus a monthly care plan; for the outfitter it’s the guided multi-day with lodging over the bare day rate. Mark every number a draft until you’ve set it against the actual job.
  4. Flag every assumption inline. Budget, dates, party size, who owns what, any friends rate. A visible flag on each turns the draft into a checklist the human corrects, instead of a confident guess they have to reverse-engineer.
  5. Save it as a draft to react to. Write the file to wherever your proposals live, clearly marked as an internal working copy. Growth’s job here is a strong first draft, never a client-ready send. This is exactly the kind of thing the approval gate in Phase 3 will hold for your yes.

Set the warmth per relationship: a proposal to a friend runs warmer and leaner on the hard sell than one to a cold prospect. Same playbook, one dial.

Watch for (proposal-specific): the fastest way this goes wrong is letting the model invent scope or social proof when the research came up empty. Thin web results are a fact to state in the draft, not a hole to fill. And a proposal that reads generic is a sign the client context was thin, not that the play doesn’t work, feed it the real call notes.

Week 7: Ops runs the report you owe someone. Almost every business owes somebody a regular update. For a startup that’s the investor update; for an agency it’s the client status report or the monthly retainer recap; for the outfitter it’s the season-to-date numbers you review for yourself. This is Ops’s job and this is the week it earns its keep. Feed Claude your last two or three of these plus your actual current numbers, the real spreadsheet, not a description of it, and draft the next one in your voice. The biggest failure mode isn’t the model; it’s describing your metrics in a sentence instead of pasting the real numbers in.

Week 8: Ops ships with Claude Code. If you haven’t yet, this is the week Ops learns to build. Point Claude Code at your codebase, your landing page, or a client site and fix one small thing: a copy change, a bug, a page. Notice that it edits your actual files and shows you a diff, rather than handing you a new blob to reconcile by hand. That’s the whole value of moving Ops past chat for anything that touches files. (No code in your business at all? Ops still ships here: point Code at a folder of documents and have it build your quote template or your trip itineraries as real files.)

If you’ve got a cofounder or an early hire, this is also a reasonable week to share your company-os folder with them, their own Claude, their own login, never yours.

Week 8, also: meet your chief of staff (the cameo). By now you’re running three roles by opening three chats and keeping it all straight in your head. That doesn’t scale, and you don’t have to. Here’s the preview: one session that works all three roles. You tell it “draft this week’s outreach and make sure it matches the new positioning,” and it drafts as Growth, checks the voice as Brand, and comes back with one answer. Don’t build it out yet, just run one cross-role job through a single Project this week so you feel the difference between talking to a team and juggling three tools. You’ll stand it up for real in Phase 3.

Phase 2 deliverable: at least two cofounders running real playbooks against real jobs (Growth’s customer motion plus Ops’s report is the common pair), one thing shipped with Claude Code, and one cross-role job run through a single coordinating session.

Watch for:

  1. Feeding it a description instead of the real thing. The report and the outreach draft both go flat the moment you summarize your situation instead of pasting the actual numbers or the prospect’s public info. This is the most common way Phase 2 output goes generic.
  2. The shared folder nobody opens. You hand a cofounder access to the company-os in week 8 and never check whether they use it. Ask directly two weeks later.
  3. Hand-juggling three roles forever. If the chief-of-staff cameo doesn’t click this month, don’t force it, but don’t skip Phase 3’s Week 9 either. Running three chats by hand is the thing Phase 3 fixes.
  4. A cofounder inventing your first-person line. When a draft needs something only you can say, your take, your history with this client, the cofounder should leave an explicit [founder] slot rather than write it for you. Ten visible slots beat one confident fabrication. That behavior showed up unprompted in the live run (Build Log #2); put it in the role files as the standard.
  5. Content sliding to next month, every month. The classic deferral: every other Growth motion arrives with a deadline attached (the prospect, the inbound, the quote due Friday) and content never does. One published page a month beats the sprint you keep not starting, and every unpublished month is indexing time you don’t get back.

Phase 3: Make the Team Durable (Days 61–90)

Three cofounders work. Now you turn a pile of playbooks into a company that runs: one place to talk to the team, a clear line on what it does without you, and a schedule.

Week 9: Stand up the chief of staff, for real. The chief of staff is a coordinating session that routes work between the roles and surfaces only what needs you. In Claude Code it’s subagents, purpose-built helpers that work in parallel and report back. In Cowork or Chat it’s one coordinating session: a Project with the shared brief and all three role files in its context, working the roles in turn. (Projects can’t invoke each other, so this isn’t your Growth Project calling your Ops Project. One session, all the files, role by role.) Build it, then route a real cross-role job through it: “we lost that deal, figure out why and what to change.” Watch it review the outreach as Growth, check what got delivered as Ops, ask whether the proposal felt off as Brand, and come back with one answer and a recommendation. This is the week you stop running three tools and start running a team. You talk to one session; it works all three roles.

Week 10: Draw the approval gate. This is the week that makes “autonomous except when I’m needed” a safe thing to say instead of a scary one. Draw the line explicitly:

The one-line version: the team acts freely up to the point where a mistake would be hard to take back, and stops there. Set that gate on every live playbook. Then start loosening it, one playbook at a time, on the ones you’ve watched run clean. After twenty good outreach drafts and two corrections, maybe Growth sends the low-stakes follow-ups on its own and only stops for first contact with a real prospect. The gate isn’t fixed; it’s a leash you let out on evidence, never all at once. Claude Code’s permission modes work the same way: start conservative, loosen only on what you’ve seen succeed.

Week 11: Harden the roster. No new playbooks. Read back everything the team produced. Kill any playbook nobody reads: a workflow nobody opens isn’t a system, it’s clutter with a schedule attached. If a whole role’s job isn’t earning its keep, say so and cut it back.

Week 12: The retrospective. Read 90 days of the team’s output. Write a one-page retro into DECISIONS.md (Ops’s file): which role is clearly earning its keep, what you built and abandoned, where you loosened the gate and whether that was right, what you’d tell yourself on day one. This is the file that makes day 180 easier than day 90 was.

Watch for:

  1. Loosening the gate too fast. The gate loosens on watched, proven playbooks, one at a time, on evidence. If you open it wide because the team “seems reliable,” you’ve traded the one protection that made autonomy safe.
  2. Skipping straight to daily. The competitive scan and anything else you schedule is tempting to run daily, just in case. Match the schedule to how often the thing actually moves. Daily on something that rarely changes just trains you to ignore it.
  3. Declaring victory instead of hardening. Week 11 exists to kill playbooks, not add them. If you reach day 90 having never turned anything off, you haven’t been honest yet about what’s actually working.

What day 90 actually looks like

A three-cofounder team with a chief of staff, running on a schedule, that stops for you only where it should. Growth drafts the outreach, the proposals, and the next public page; Ops runs the weekly review, the report, and the small ships; Brand keeps it all sounding like you. A coordinating session you talk to instead of three chats you juggle. A gate that holds the handful of things that could actually hurt you, and lets everything else run. You check in from your phone between meetings, pull up the live session with Remote Control, clear the two things waiting on your yes, and the team keeps working.

Nothing you couldn’t have built starting from a blank chat window, just sooner than you’d have found this sequence on your own. What hasn’t changed: you’re still the CEO. The output is still reviewed, not auto-sent, and it should stay that way past day 90 too. What’s different is that the review happens against a real draft that already sounds like you, from a team that already knows your business.

A Claude Code path, if you’ve never opened a terminal

This mirrors the shape of a “learn the tool” course, built from what Claude Code actually does today. Budget about an hour a session, one session every few days, over three or four weeks. The whole path is really “hire and run the team in Claude Code”, the steps below name where the team shows up.

  1. Why this beats a chat tab for anything recurring. A chat conversation starts from zero every time. Claude Code reads a folder on your machine and remembers it session to session, via a CLAUDE.md file. That’s the whole pitch, read this, then move on.
  2. Install and orient. If you’re on Claude Desktop, the Code surface is already there. For the standalone CLI: npm install -g @anthropic-ai/claude-code, then run claude inside a project folder. Either way, point it at a real folder and ask it a real question.
  3. The six terminal commands you actually need. cd, ls, pwd, opening a text editor, saving a file, and Ctrl+C to stop something. If you’re using the Desktop app’s Code surface, you can skip most of this.
  4. Your first real session. Take something you already have, a deck, a messy notes file, and ask Claude to draft something from it. Notice it edits the file in place and shows you a diff, instead of handing you a new blob to merge by hand.
  5. Write the company brief and the role files. The CLAUDE.md at the root of the folder is your shared context (PRODUCT, USERS, GOALS). Alongside it, write GROWTH.md, OPS.md, BRAND.md, one brief per role. If you did the Phase 1 work above, you’re mostly reusing it here. This is where the three cofounders come to live on your machine.
  6. Slash commands are a role’s playbooks. Save a prompt once, invoke it by name from then on. Growth’s proposal, Ops’s weekly review, Brand’s voice check, each becomes a named command you run in seconds. This is where “one screen, thirty seconds” workflows come from.
  7. Subagents are your chief of staff. For anything that spans roles, Claude Code can delegate to purpose-built subagents that work in parallel and report back. This is the coordinating layer, built in. Don’t file it under advanced: it’s how the team runs as a team instead of three separate tools. Stand up one subagent that routes a cross-role job and you’ve built your chief of staff.
  8. Permissions are your approval gate. Claude Code has explicit permission modes, from “ask before every edit” up to more autonomous ones. This is the “hand on the wall” made mechanical: start conservative on anything touching real business files or money, and loosen only for a playbook you’ve watched succeed a dozen times. Anything published where the public can read it keeps stopping for your yes; that one isn’t a dial. The permission mode is the gate.
  9. Rebuild your roles’ real playbooks, one per session, against your own files: Ops’s weekly review, Ops’s report, Growth’s cold-outreach draft, Ops’s competitive scan, and one real shipped fix to your product or site.
  10. Make it recurring. Turn any of the above into a recurring workflow, and let the chief of staff run them on a schedule inside the gate. This is the bridge back into the 90-day roadmap. From here you can build your own team’s cadence without following anyone’s template, including this one.

What doesn’t change no matter how good you get: it’s the same Claude whether you’re in chat or in Code. What improves is context (it remembers your files) and editing (it changes documents in place). It still won’t replace you reviewing the output. That stays the default, on purpose. You’re the CEO in Code too.

Starting from zero, chat only

No terminal, no files on disk, no connectors required. You can hire two or three cofounders as Projects and run them by hand from the chat window you already have.

1. Name where you actually are. If your current use of Claude is “paste a messy email in, ask for a cleaner draft, close the tab”, that’s a fine starting point, and a sliver of what’s available. The gap is habit, not skill: routing the expensive, recurring work through a team you’ve briefed, not just the small one-off stuff.

2. Three postures. Assistant (plain chat: you ask, it answers, you decide every step) is where most of your judgment calls belong, and it maps onto the approval gate: you at every step. Agent (Cowork, Claude Code, recurring workflows) takes several steps on its own and reports back. That’s more power, and it’s earned after you trust its judgment in Assistant mode first. Tool (AI embedded in something you already bought) matters to you as a buyer, ask what job it does, not whether it “has AI.”

3. Your first cofounder is a Project. Create a Project for your company inside Claude and add the shared brief (goals, users, what you sell) plus one role’s context. That Project, briefed that way, is that cofounder. Do it two or three times and you’ve got Growth, Ops, and Brand as three Projects you can talk to.

4. Hire the cofounder whose job is eating your week. Leverage is roughly (time it costs you today − time it’d cost with Claude drafting) × how often you do it. Whichever cofounder owns that job (usually Growth or Ops) is the one to hire first. Paste this in:

I run [business]. Here are the recurring tasks that eat the most of my week: [list 4–6]. For each, tell me which cofounder owns it, Growth (sales, outreach, marketing), Ops (delivery, systems, admin), or Brand (voice, identity, experience), and in one sentence how that cofounder could take real time off it. Then tell me which cofounder to hire first, and why.

5. Give it the real thing, not a description of it. The single biggest reason operators get thin output: they describe their situation in a sentence instead of pasting the actual email, the actual numbers, the actual draft. Give the cofounder the real artifact.

6. Build that cofounder’s first playbook. Run it with full context. If the draft is generic, that’s a signal to add more of your own real writing and real data to the cofounder’s files, not a signal that this doesn’t work for your business. By run three or four, save the prompt somewhere durable.

7. Decide if you want to cross into Cowork or Claude Code. Chat plus a few Projects genuinely gets you two or three cofounders you run by hand. The automated chief of staff and the scheduled approval gate live on the other side of the Cowork/Code door. Walk through it when a job needs to touch real files, run without you starting it, or coordinate the cofounders on a schedule. It’s optional.

Templates you can copy directly

What follows is the sampler. The guide ships the full walkthrough and the complete template set this section is cut from.

Shared company context

PRODUCT.md

# Product (or: what we sell)
What we're building / selling:
Who it's for:
What stage we're at:
What makes it different:
The thing we're most unsure about right now:

USERS.md

# Users (or: who we serve)
Who they actually are:
The problem they hired us to solve:
What they complain about most:
The request we keep hearing:
The one we've been ignoring (and why):

GOALS.md

# Goals, [Quarter]
Top 3 priorities right now:
1.
2.
3.
Metrics we check weekly:
Metrics we check monthly:
What "on track" looks like this quarter:

The role files

Each role file is a mandate plus a pointer to the sub-files that role owns. Keep it short; it’s a brief, not a manual.

BRAND.md (the hipster, identity, voice, design, experience)

# Head of Brand, mandate
What this role owns: how everything we put out sounds, looks, and feels.
Guard the voice, keep the look consistent, protect the customer experience.
Sub-files I keep: VOICE.md
What "off-brand" looks like for us:
The experience we want a customer to have:
When to stop and ask the CEO: anything public that sets or changes how we
present ourselves.

VOICE.md (owned by Brand)

# Voice
Writing I'm proud of:
1. [paste]
2. [paste]
3. [paste]

Words and phrases to avoid:
-
-

"Not me", add over time:
-

GROWTH.md (the hustler, sales, outreach, marketing, content)

# Head of Growth, mandate
What this role owns: bringing in the next customer and keeping the last one warm.
Outreach, proposals, marketing, content, follow-up.
Sub-files I keep: ICP.md, OFFERS.md (if I sell services/packages)
The motions we actually win work with (rank them):
When to stop and ask the CEO: anything sent to a real prospect or published
publicly, anything that quotes a real price.

ICP.md (owned by Growth)

# Ideal customer
Who they are, in plain language:
The problem that makes them buy:
Where they actually hang out / how they find businesses like ours:
What makes a good-fit prospect vs. a bad one:

OFFERS.md (owned by Growth, for services, agencies, local)

# Offers & pricing
So a quote or proposal starts from a decided model instead of a blank page.

## [Package name]
What's included:
Price (one-time and/or recurring):
Overage / out-of-scope rate (skip if you sell at set prices):
Who it's the right fit for:

OPS.md (the hacker, delivery, systems, admin, the build)

# Head of Ops, mandate
What this role owns: turning a yes into a shipped thing, and keeping the lights
on behind it. Delivery, the weekly rhythm, the report we owe, the build, admin.
Sub-files I keep: CLIENTS.md, PROJECTS.md (if client work), DECISIONS.md,
HIRING_BAR.md (when hiring)
The recurring things I run:
When to stop and ask the CEO: anything that spends money, ships to a customer,
or can't be undone.

CLIENTS.md (owned by Ops, services/agency/local)

# Clients, active roster
One entry per active client. Keep it honest; a stale "in progress" is how work
gets lost.

## [Client name]
What they need:
Work type:
Status:
Next step:

PROJECTS.md (owned by Ops)

# Projects, what's in flight
## [Project name], [client]
Goal / scope:
Where it stands:
What's owed, and when:
Blocked on:

DECISIONS.md (owned by Ops)

# Decision log
[Date], Decision:
Why:
What we expect to happen:
Revisit by:

The chief of staff and the approval gate

CHIEF-OF-STAFF.md (the coordinating session’s brief)

# Chief of staff, how to route work
The team: Growth (sales/outreach/marketing/content), Ops (delivery/systems/
admin/build), Brand (voice/identity/experience). CEO is the human.

When a job comes in:
1. Decide which role(s) own it. Cross-role jobs pull more than one.
2. Work the job as those roles, from their files. (In Claude Code, delegate
   to their subagents.)
3. Apply the approval gate (below) before anything leaves.
4. Report back to the CEO in one place: what's done, what's waiting on a yes,
   what needs a decision.

Only surface to the CEO what needs the CEO. Everything reversible and internal,
just do and log.

APPROVAL-GATE.md (starter policy, copy and tune)

# Approval gate
The team acts freely up to the point where a mistake would be hard to take back.

RUNS ON ITS OWN (reversible / internal / draft):
- Weekly reviews, internal drafts, research, competitive scans
- First-draft proposals and emails saved to a folder for my review
- Anything I'll read before it goes anywhere

STOPS FOR MY YES (irreversible / public / spends money / speaks as me):
- Sending an email or message to a real person
- Publishing anything public
- Paying an invoice or moving money
- Signing or committing us to a client or vendor
- Anything that goes out under my name

LOOSENING THE GATE:
Move a playbook from "stops" to "runs" only after I've watched it run clean
several times. One playbook at a time. Never all at once.

A reusable weekly-review prompt (Ops)

Read [folder/files]. Give me one screen covering:
1. What changed since last time
2. Decisions I made but haven't reflected in GOALS.md
3. Open items and who owns them (which role)
4. The thing I'm avoiding that I shouldn't be
Write it in my voice, per VOICE.md. Keep it under 300 words.

Quick-start checklist

A note on currency: Claude’s specific product surfaces, plan requirements, and scheduling mechanics are under active development, so exact menu names and steps may shift. If anything here doesn’t match what you see in the app, check current capabilities at claude.com, that’s the source of truth over this document, always.

Want the full depth version?

This is the outline. The Founder's Claude Automation Guide is the complete version: real setup walkthroughs, the full workflow library, copy-paste templates, appendices. $49. It's being written from a live run, not from theory: read the log.

Get the next 90 days of this, one play at a time