plan
Use after design approval for milestone plans with executable acceptance.
它会碰到什么
这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。
技能内容
Plan
docs/staging/plans/YYYY-MM-DD-<topic>.md. Reference the spec; don't restate it.
If unresolved spec notes affect implementation or task order, return to design.
Multi-module plan
If topology=multi-module (triage announcement or coordinator spec/plan declaration), read ../references/multi-module.md. Open the workspace plan with the declaration block (topology: multi-module, change-set, coordinator, repos, module plan paths, integration task) - it is the on-disk mode marker downstream skills rely on.
- Write the workspace plan in the coordinator repository and a module plan in every affected module's owning repository.
- The workspace plan lists the change-set ID, coordinator, repositories, module plan paths, and the integration task.
- Every task names exactly one
repository:and onemodule:. Cross-module verification is anintegrationtask owned by the coordinator. - Order contract tasks before consumers, local acceptance before integration, and integration before linked commits.
- Mark tasks parallel only when they have independent write scopes and acceptance.
- Adding a repository after implementation starts: update the declaration block and confirm with the user. Return to
designonly if the addition changes a shared contract.
Rolling wave
Spec references a milestone (milestone: MN)? Check docs/ROADMAP.md — expand only that milestone. Leave the rest as stubs.
After ship: open docs/ROADMAP.md, confirm which milestone is next, then expand it. Return to design only if the milestone's goal materially changed.
Milestone tasks (30-60 min each)
Every task is - [ ] T<n>: <name> - always a checkbox, never a heading. tdd/subagents flip it to - [x] on completion; ship refuses to run while any - [ ] remains.
goal: <one sentence>
files: <paths>
acceptance: <test or cmd>
spec: <docs/staging/specs/...#anchor>
No exact code. No step-by-step. Acceptance is verifiable: a test, command, or scripted check — or, when none is possible, an explicit manual check (steps + expected result). Each task leaves the repo green.
Mark independent tasks: [parallel] T3, T4, T5.
Only mark [parallel] when shared contracts, state, errors, and acceptance are closed.
Atomic expansion is deferred until dispatch time - subagents expands a milestone into 2-5 min steps at dispatch time, not here.
for New project: derive an initialization task — scaffold code, tests, CI, and always include: README.md, CHANGELOG.md, .gitignore, and a Makefile (or equivalent task runner config).
Don't put in the plan
background, architecture, rationale (spec), CI commands, copy-pasted acceptance.
Hand off
<gate> The plan must exist on disk before handing off to tdd/subagents. For multi-module work, this means the coordinator workspace plan and every affected module plan in its owning repository. </gate>
Confirm plan with the user.
mostly [parallel] → subagents. Otherwise → tdd.
想直接用这个技能?
本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。
它属于哪个仓库
plugins/ouonet/praxis/skills/plan/SKILL.md同一个仓库里的其他技能
同名技能的其他版本
有 4 个不同仓库或目录里都有叫 plan 的技能。它们内容并不相同,别混用:
- hashgraph-online/awesome-codex-plugins — Plan a feature or initiative through a computed route: the conductor derives the canon del
- hashgraph-online/awesome-codex-plugins — Define intended behavior, review write scope and assess reversible decisions. Use when: ac
- hashgraph-online/awesome-codex-plugins — Plan a new project, feature, or retrospective with structured requirement gathering