菜单
Build authority by teaching the problem space, not announcing features. Use when the founder finds "marketing" distasteful and does none, publishes only product updates, or wants a sustainable content and GitHub-README strategy that developers actually respect.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Interview the founder 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 founder's product, ICP, market, or stage, or is giving generic GTM advice.
After the founder brief, turn it into an honest diagnosis and a prioritized, stage-aware GTM roadmap saved as docs/gtm-cofounder/gtm-roadmap.md. This is the hub the founder returns to every session to see where they are and the single next move. Use right after start-here, whenever the founder doesn't know what to work on next, wants a plan instead of a one-off task, or is drowning in disconnected tactics.
Refresh the founder's competitive and market context. Re-scan named rivals and the category for what changed since the brief was written (rebrands, repositioning, new entrants, pricing shifts, renamed categories) and update docs/gtm-cofounder/founder-brief.md and the roadmap with anything that moves positioning. Use on a cadence, or whenever a competitor rebrands, a new tool appears, or the founder senses the market has shifted under them.
Get the first 50 real users through channels the founder's ICP already uses. Use when the product shipped and nobody came, the founder is "posting more" with no result, or is reaching for paid ads before product-market fit.
Measure GTM with the metrics that matter (net developer retention, DREAM funnel) instead of vanity numbers. Use when the founder has dashboards full of stars and pageviews but can't tell if go-to-market is working, or is optimizing acquisition over a leaky bucket.
Plan a developer launch (Show HN, Reddit, Product Hunt) that earns goodwill instead of a flaming. Use when the founder is sitting on a launch out of fear, wants to "go viral," or is about to post a press-release-style announcement to a developer community.
| name | founder-led-content |
| description | Build authority by teaching the problem space, not announcing features. Use when the founder finds "marketing" distasteful and does none, publishes only product updates, or wants a sustainable content and GitHub-README strategy that developers actually respect. |
You don't have to "do marketing." You have to become the person developers trust on the problem. Sell the category, not the product, and let the authority pull people in.
Use this when: content feels slimy so you avoid it, your "blog" is a changelog, or a competitor is quietly becoming the go-to voice while you ship in silence.
Developers reward technical depth, honesty, and a real point of view, and punish polished fluff. The move isn't promotion; it's education. Be the trusted expert on the problem, take a stance on where the space is heading, and the product sells itself as the obvious answer.
Before product-market fit, only the founder can do this. It's the #2 hire (DevRel) later, not now.
The "O'Reilly book" content plan (Frankl): imagine the definitive book on your problem, ~10 chapters, ~10 sections each. That's ~100 genuinely useful pieces mapped out. Publish against the outline consistently. You're writing the book that makes you the authority.
Do you have a real, contrarian-but-true opinion about your problem space?
├─ YES → write that. POV posts build authority fastest.
└─ NO → write the tutorial you wish existed when you hit this problem.
(Useful-to-a-stranger is the bar. If it only helps someone who already bought, rewrite it.)
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.