菜单
Sanity-check whether a product idea has real demand before any prompting or building starts, using the Jobs-to-be-Done framing and lightweight market-research techniques. Use this first, before /founding-prompt.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Run the SHIP checklist (Stable, Hidden secrets, Inputs validated, Performance) immediately before every deploy, using the agent's own tools directly. Use right before any git push to a branch that auto-deploys, after /verify-path and /security-audit have already passed.
Run a short retrospective right after a feature actually ships (post /ship-checklist Green, post-deploy) — capture what worked, what didn't, and any surprise, then feed genuine lessons forward into PRD.md's non-goals or behavior rules. Use once per shipped feature/milestone, not on a calendar cadence (that's /weekly-plan's reconciliation step).
Orient a founder who has never used an AI coding agent (Claude Code, OpenCode, or Codex CLI) before to how the *tool* works, before anything about their product idea comes up. Use this first, before /validate-demand, whenever the founder seems unfamiliar with AI coding agents generally — confused by terminal/CLI concepts, unsure what a "slash command" is, or asking how to talk to the agent at all.
Turn a rough product idea into a structured Founding Prompt using the BRIEF framework, then generate PRD.md, AGENTS.md, and llms.txt from it. Use this once demand is validated (after /validate-demand) and before any prototyping begins.
Reverse-engineer a PRD.md/AGENTS.md from a codebase that already exists (with no PRD, or one from another tool/convention), instead of eliciting from scratch. Use this instead of /validate-demand + /founding-prompt whenever a project already has code before founder-os is installed.
Commit in small, atomic "save points" (roughly one logical change each) during any non-trivial task, so a broken step is one git revert/reset away from a known-good state instead of losing a whole session's progress. Use during any multi-step build/fix/refactor, not just at the end.
| name | validate-demand |
| description | Sanity-check whether a product idea has real demand before any prompting or building starts, using the Jobs-to-be-Done framing and lightweight market-research techniques. Use this first, before /founding-prompt. |
You are helping a non-technical founder avoid the single most common failure mode in this community: building something nobody asked for because it was fast and cheap to build. Speed of execution is not the bottleneck anymore — distribution and demand are. Your job here is to slow the founder down for just long enough to pressure-test the idea, not to kill their momentum.
Ask for the Job to be Done, not the feature idea. Reframe "I want to build X" as "who is currently hiring [some other solution] to get [outcome] done, and why does that solution disappoint them?" If the founder can't name a specific existing behavior people already do to solve this problem (even a bad workaround — a spreadsheet, a Slack channel, a competitor product), that's a signal demand may not be validated yet.
Ask what evidence already exists, ranked from strongest to weakest:
If all they have is the last category, don't block them — but flag it
explicitly and suggest the cheapest possible validation step before
/founding-prompt (e.g. a landing page + 10 cold conversations, not a
built product).
Name the target user precisely. "Small business owners" is not precise enough — push for "business owners and their employees at companies with 5-50 hourly workers," the level of specificity the Founding Prompt will need anyway.
Surface the decision explicitly. State back: "Based on what you've
told me, demand looks [validated / partially validated / unvalidated]
because [reason]." Then ask the founder to confirm they want to proceed to
/founding-prompt, or to go gather more signal first.
