Back to Details

start-here

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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.
其他所有技能模块的实用性，完全取决于Agent对你业务的了解程度。这份文档就是提供这些背景信息的。只需完成一次，后续所有技能模块都会给出个性化建议。
适用场景： 这是你首次使用该工具，或者Agent给出的建议过于通用、照搬教科书，因为它实际上不了解你的产品、用户或业务阶段。

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.
回答五个核心问题，Agent会在你的项目中生成一份**
docs/gtm-cofounder/founder-brief.md
**文档，足以在几分钟内为你提供真实的业务诊断和路线图。其他所有问题都是可选的，可在后续逐步回答：每个技能模块会在需要时提取它实际需要的更深层次问题，并告知你回答这些问题能带来什么价值。这样你能快速看到成效，并且使用次数越多，这份简报就会越完善，而不是在第一天就面对一堆问题。
最重要的一点：区分你已经验证过的内容（来自非亲友的真实用户反馈）和你正在假设的内容（你目前的最佳猜测）。假设内容完全可以作为起点，它们会被标记为待
talk-to-users
模块处理，转化为真实信息，这样你就永远不会基于猜测构建一套完美的上市策略。

How to run this (for the agent)

如何运行此模块（针对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.
  • 一次只问一个核心问题，不要问其他问题。 一个问题，等待回答，再根据回答调整下一个问题。这应该像和联合创始人对话，而不是填写表单。切勿一次性粘贴多个问题。（如果创始人希望一次性看到所有五个问题并统一回答，可以提供问题列表，但默认采用逐个提问的方式。）
  • 根据这五个问题的回答撰写简报，然后切换到
    strategy-and-roadmap
    模块。创始人应该在回答任何可选问题之前，先得到业务诊断和下一步行动建议。
  • 按需提取更深层次的问题。 当后续技能模块需要更多信息时（比如定位需要明确“对手”，定价需要明确“买家”），只在当时提出两三个相关问题，并说明回答这些问题能解锁什么价值。切勿提前全部抛出。
  • 对于每一个实质性回答，询问：“这是真实用户告诉你的，还是你目前的判断？” 并标记为
    [validated]
    或
    [assumption]
    。
  • “尚未采访任何用户”是一个有效且能反映现状的答案。如实记录，不做评判，并将
    talk-to-users
    标记为最高优先级的下一步行动。
  • 保留创始人的原话。不要将他们提到的痛点润色成营销话术。
  • 核心简报撰写完成后，不要直接跳入任务或开始指定工作。将任务交接给
    strategy-and-roadmap
    模块，或者询问创始人想要解决什么问题。主动提供选择，而非强加安排。

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.
在提问之前，检查你是否能访问创始人的repo。如果可以，先快速进行有限范围的扫描，让访谈更有针对性，而非从零开始：
  • README和任何
    docs/
    下的介绍文档：项目声称能实现什么功能，以及他们目前如何描述它。
  • 包清单（
    package.json
    、
    pyproject.toml
    、
    go.mod
    等）：使用的语言、依赖项、集成的工具。
  • 最近约15条提交主题和近期PR标题：他们目前实际在构建什么内容。
  • 开放议题的主题：真实用户反复遇到的问题，这可以反映用户的痛点和受众群体。
这只是快速扫描，而非全面审计。不要逐行阅读代码、遍历完整提交历史，或提取任何敏感信息。根据扫描到的内容撰写简报，并将这些事实标记为
[validated]
，因为它们来自真实的项目文件，而非猜测。
两个注意事项：
  • repo是用于评估的输入，而非金科玉律。 README通常包含创始人现有的、往往比较通用的定位表述。可以说“这是你目前的描述方式”，然后提出挑战。切勿将薄弱的定位视为既定事实。
  • repo只能告诉你已构建的内容，无法告诉你谁会付费。 它能明确产品和大致的用户群体，但无法说明买家、付费意愿或市场情况：这些信息仍需来自创始人和
    talk-to-users
    模块。
如果你无法访问项目（比如是粘贴的技能模块，或者没有repo），跳过此步骤，直接进入五个核心问题。

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).
这是所有必填的初始信息。回答这些问题后，Agent就已经可以进行业务诊断和规划。如果你已经扫描过repo，不要生硬地提问：确认或完善你推断出的内容，将问题聚焦于项目文件无法告诉你的信息，比如ICP、买家以及是否有人愿意付费。
  1. 用一句平实、无术语的话描述：它能做什么？
  2. 它的目标用户具体是谁？（职位、公司规模和类型、技术背景）
  3. 用户目前使用什么替代方案，为什么你的产品比它更好？
  4. 业务阶段和用户粘性：有多少用户，他们会回头使用吗？
  5. 你最核心的优势：你拥有的最强大、可验证的资产（知名客户logo、硬核数据、真实用户评价、明确的需求信号）。

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 buyer, not just the user.
  • Who is it clearly not for? → a sharp "not for" makes your ICP believable and your messaging land.
  • The job they hire it for: "When [situation], I want to [motivation], so I can [outcome]." → becomes your value proposition.
Distribution and motion
  • Motion: open source, PLG, inbound, sales-led, or unsure? → picks which channels and tactics actually fit you.
  • Where do your users already hang out and discover tools? → tells us where to launch and find your first users.
Focus
  • What are you deliberately saying no to right now? (the roadmap you're protecting, the requests you turn down) → keeps the agent from recommending work you've already ruled out.
Evidence (be honest, this is the whole point)
  • Which known companies or notable developers already use it, that you can name? → your strongest proof; even a couple of logos does your credibility work.
  • How many real users have you interviewed who are not friends? → tells the agent how much of this is validated versus guessed, so nothing gets built on sand.
  • Which answers are still assumptions? → routes the guesses to 
    talk-to-users
    to make them real.
一开始可以跳过这些问题。每个技能模块会在需要时提出相关问题。每个问题都会说明回答后能解锁什么价值，因此你只需在能获得回报的方面投入精力。
定位与叙事
  • 它能解决用户的什么痛点？用用户自己的话描述。→ 将成为你的首页标题和叙事中的核心痛点。
  • 当前什么趋势正在加剧这个痛点？→ 这是你的“对手”，能让你的定位更具紧迫感，而非仅仅罗列功能。
  • 你的首页或repo描述目前是怎么写的？（粘贴原文）→ 让Agent能优化你现有的表述，而非凭空猜测。
买家与定价
  • 如果付费者和使用者不是同一人，那么谁是付费者？→ 让Agent针对真实买家设计定价和销售流程，而非仅仅针对使用者。
  • 它明确不适合哪些用户？→ 清晰的“非目标用户”能让你的ICP更可信，你的信息传递更精准。
  • 用户雇佣它来完成的任务：“当[场景]，我想要[动机]，这样我就能[成果]。”→ 将成为你的价值主张。
获客与模式
  • 获客模式：开源、PLG、 inbound、销售驱动，还是不确定？→ 选择适合你的渠道和策略。
  • 你的用户通常在哪里聚集并发现工具？→ 告诉我们应该在哪里发布产品并找到首批用户。
聚焦方向
  • 你目前刻意拒绝的是什么？（你正在维护的路线图、你拒绝的需求）→ 避免Agent推荐你已经排除的工作。
证据（请诚实回答，这是关键）
  • 有哪些已知公司或知名开发者已经在使用它，且你可以公开提及？→ 这是你最有力的证明；即使只有几个logo，也能提升你的可信度。
  • 你已经采访了多少非亲友的真实用户？→ 告诉Agent哪些内容是已验证的，哪些是猜测的，避免基于不确定的信息开展工作。
  • 哪些回答仍然是假设？→ 将这些猜测路由到
    talk-to-users
    模块，转化为真实信息。

Write the brief

撰写简报

Save the answers to 
docs/gtm-cofounder/founder-brief.md
in the founder's project (create the 
docs/gtm-cofounder/
folder if it does not exist), using the template in this repo (
founder-brief.template.md
). Keep the 
[validated]
/ 
[assumption]
tags on each answer. This file is the shared memory for every other skill. Write it in plain, human prose, with no em-dashes (use commas, colons, or periods), so it never reads as machine-generated.
Lead the brief with the strongest asset (core question 5) at the very top, so the single most powerful thing this founder has anchors every downstream skill. Founders routinely bury it under modesty or detail. As deeper questions get answered over time, add them to the brief under their category.
将答案保存到创始人项目中的
docs/gtm-cofounder/founder-brief.md
文件中（如果
docs/gtm-cofounder/
文件夹不存在则创建），使用本repo中的模板（
founder-brief.template.md
）。在每个回答上保留
[validated]
/
[assumption]
标签。这份文件是所有其他技能模块的共享记忆。用平实的人类语言撰写，不要使用破折号（改用逗号、冒号或句号），避免让它看起来像是机器生成的。
在简报的最顶部突出显示最核心的优势（核心问题5的答案），让创始人拥有的最强大资产成为后续所有技能模块的基础。创始人常常会因为谦虚或细节过多而掩盖这一点。随着后续深入问题的回答，将它们添加到简报对应的分类下。

Keep it alive

持续更新简报

The brief is a living document, not a form you fill once and forget. Every time the founder learns something real from a user (a 
talk-to-users
call, a lost deal, a piece of feedback), update the relevant line and flip its tag from 
[assumption]
to 
[validated]
. A brief that is mostly 
[validated]
is a company that knows itself. And run 
market-scan
periodically to refresh what has changed outside the brief: a rival's rebrand, a new entrant, a shifted category.
简报是一份动态文档，而非填写一次就遗忘的表单。每次创始人从用户那里获得真实信息（比如
talk-to-users
模块的访谈、丢失的订单、用户反馈），更新相关内容并将标签从
[assumption]
改为
[validated]
。一份大部分内容为
[validated]
的简报，代表公司对自身有清晰的认知。定期运行
market-scan
模块，更新简报之外的变化：竞争对手的品牌重塑、新进入者、品类的转变。

Your next 30 minutes

接下来30分钟的行动

  • Answer just the core five. Rough and honest beats polished and fake.
  • Tag each answer 
    [validated]
    or 
    [assumption]
    .
  • Save it as 
    docs/gtm-cofounder/founder-brief.md
    in your project so your agent reads it.
  • Run 
    01-strategy-and-roadmap
    to get your diagnosis and first move. Don't answer the optional questions yet.
  • Answer deeper questions later, only when a skill asks and tells you what it unlocks.
Built from real dev-tool GTM experience, with frameworks from Adam Frankl (The Developer-Facing Startup) and Jakub Czakon (markepear.dev). When a framework can't make the call, that's what a human is for: The DevTool GTM Company.
  • 仅回答五个核心问题。粗糙但诚实的答案好过华丽但虚假的内容。
  • 为每个答案标记
    [validated]
    或
    [assumption]
    。
  • 将答案保存到项目中的
    docs/gtm-cofounder/founder-brief.md
    文件，以便你的Agent读取。
  • 运行
    01-strategy-and-roadmap
    模块，获取业务诊断和第一步行动建议。暂时不要回答可选问题。
  • 后续仅在技能模块提出并说明解锁价值时，再回答深入问题。
基于真实开发工具GTM经验构建，融合了Adam Frankl（《面向开发者的创业公司》）和Jakub Czakon（markepear.dev）的框架。 当框架无法做出决策时，就需要人类的介入：The DevTool GTM Company。