Start Here

Start here (your founder brief)

Every other skill is only as sharp as what the agent knows about your business. This is that context. Do it once, and every skill after it gets personal.

Use this when: it's your first time here, or the advice you're getting feels generic and textbook because the agent doesn't actually know your product, your users, or your stage.

The core idea

Answer five core questions and the agent writes a docs/gtm-cofounder/founder-brief.md in your project, enough to give you a real diagnosis and a roadmap in minutes. Everything else is optional and answered as you go: each skill pulls the deeper questions it actually needs, when it needs them, and tells you what answering unlocks. So you start seeing value fast, and the brief gets richer the more you use it, instead of facing a wall of questions on day one.

And the part that matters most: separate what you have validated (a real user who is not your friend told you) from what you are assuming (your best guess for now). Assumptions are completely fine to start with. They just get sent to talk-to-users to become real, so you never build a beautiful go-to-market on a guess.

How to run this (for the agent)

• Ask the five core questions one at a time, and nothing else. One question, wait for the answer, let it shape the next. It should feel like a conversation with a co-founder, not a form to fill in. Never paste multiple questions at once. (If the founder would rather see all five and answer in one go, give them the list, but default to one at a time.)
• Write the brief from those five, then move to strategy-and-roadmap. The founder should get a diagnosis and a next move before they answer anything optional.
• Pull the deeper questions just-in-time. When a later skill needs more (positioning needs the villain, pricing needs the buyer), ask only the two or three relevant ones right then, and say what answering unlocks. Never front-load them.
• For every substantive answer, ask: "have you heard a real user say this, or is that your read for now?" Tag it [validated] or [assumption].
• "Zero users interviewed" is a valid and revealing answer. Note it plainly, no judgment, and flag talk-to-users as the highest-priority next step.
• Keep the founder's own words. Don't polish their pain into marketing language.
• Once the core brief is written, do not jump into a task or start prescribing work. Hand off to strategy-and-roadmap, or ask the founder what they want to tackle. Offer, never impose.

First, read what they've already shipped (only if you're in their project)

Before asking anything, check whether you're running inside the founder's repo. If you are, do a quick, bounded scan first, so the interview sharpens instead of starting cold:

• The README and any docs/ intro: what the project claims to do, and how they currently describe it.
• The package manifest (package.json, pyproject.toml, go.mod, and the like): language, dependencies, what it integrates with.
• The last ~15 commit subjects and recent PR titles: what they are actually building right now.
• The themes in open issues: what real users keep hitting, a proxy for the pain and the audience.

This is a quick scan, not an audit. Do not read code line by line, crawl the whole history, or pull anything sensitive. Draft the brief from what you find and tag those facts [validated], they come from real artifacts, not a guess.

Two cautions:

• The repo is input to critique, not gospel. A README usually carries the founder's existing, often generic, framing. Say "here is how you currently describe it," then challenge it. Never inherit weak positioning as if it were true.
• The repo tells you what was built, not who pays. It grounds the product and roughly the user. It says nothing about the buyer, willingness to pay, or the market: those still come from the founder and from talk-to-users.

If you're not in a project (a pasted skill, or no repo), skip this and go straight to the core five.

The core five (answer these first)

This is the whole required intake. Answer these and the agent can already diagnose and plan. If you already scanned the repo, don't ask these cold: confirm or refine what you inferred, and spend your questions on what the artifacts can't tell you, the ICP, the buyer, and whether anyone will pay.

1. In one plain sentence, with no jargon, what does it do?
2. Who exactly is it for? (role, company size and shape, technical context)
3. What do they use today instead, and why you over that?
4. Stage and traction: how many users, and do they come back?
5. Your single strongest asset: the most powerful, provable thing you have (a marquee logo, a hard number, a real user quote, a live demand signal).