菜单
Turn an unstructured backlog into a weekly plan of 3 features to build, 3 bugs to fix, and 3 users to talk to, using the 3-3-3 method. Use at the start of each work week, especially when the founder has more ideas than a week can hold.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | weekly-plan |
| description | Turn an unstructured backlog into a weekly plan of 3 features to build, 3 bugs to fix, and 3 users to talk to, using the 3-3-3 method. Use at the start of each work week, especially when the founder has more ideas than a week can hold. |
There's no sprint board here, only an unbounded backlog and a founder who will happily skip talking to users in favor of building one more thing. 3-3-3 caps scope on purpose and makes user contact non-optional, on purpose.
Cap Build at 3. If the founder lists more, push back — "which 3
ship first?" Check each item against PRD.md's non-goals list and the
## Status checkboxes for what's already in flight before adding
anything new.
Cap Fix at 3. Pull from known bugs: ask the founder directly, check
recent /debug-seb sessions, or scan CHANGELOG.md's ### Fixed
entries. Rank by actual user impact, not founder annoyance.
Require 3 real user contacts — don't let this slot go empty. This
is the one founders skip first under build-momentum pressure. State
explicitly why it stays: as /validate-demand already established,
distribution and demand are the bottleneck here, not speed of building.
Write the plan using the WEEK OF / BUILD / FIX / LEARN / DONE WHEN shape, with a concrete "done when" condition — not just a task list with no definition of finished.
Reconcile at week's end. Compare what got done against what was planned. Carry unfinished items forward explicitly rather than letting the backlog grow silently in the background.
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.
