/00-start-here

name: start-here
description: Interview the user once and write a docs/gtm-cofounder/founder-brief.md that every other skill reads first, so the advice is about their real business, not a textbook. Use this before anything else, or whenever the agent lacks context on the user's product, ICP, market, or stage, or is giving generic GTM advice.

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).

Go deeper (optional, answer anytime)

Skip these to start. Each skill asks for the ones it needs, when it needs them. Every question says what answering it unlocks, so you only invest where you want the payoff.

**Positioning and story**

• What painful problem does it kill, in the user's own words? → *becomes your homepage headline and the stakes in your story.*
• What trend is making that pain worse right now? → *this is your villain, what gives your positioning urgency instead of just listing features.*
• What does your homepage or repo description say today? (paste the actual line) → *lets the agent sharpen what you have instead of guessing it.*

**Buyers and pricing**

• Who pays, if that is a different person from who adopts? → *lets the agent design pricing and a sales motion aimed at the real bu