菜单
Planning discipline for multi-step work — acceptance test first, read the terrain, dependency-ordered steps, de-risk the riskiest step early, re-plan on surprise. Use at the start of any task touching 3+ files or steps, and mid-task when something invalidates the approach.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Resolve ambiguous requests by investigating, choosing the best-supported reading, and stating the interpretation — instead of guessing silently or blocking on questions. Use whenever a request has multiple plausible readings or an unstated parameter (which file, which env, how thorough, what format).
Treat any change to a public or shared interface — exported functions, HTTP endpoints, CLI flags, config formats, event/message schemas, DB schemas — as a contract change with consumers you can't see. Use before modifying anything other code depends on.
When recommending between options, match the strength of the claim to the strength of the evidence — commit when evidence is clear, say it's a coin flip when it is. Use whenever the user asks "which should I use", "what's the best way", "A or B?", or you're proposing a design choice.
Fast recon before changing unfamiliar code — instructions → manifest → tree → trace one flow end-to-end → git archaeology → imitate the newest precedent. Use when starting in a repo or module you haven't touched this session, or before designing against an existing architecture.
Async/concurrent/streaming discipline — five questions (overlapping runs, check-then-act, mutation across await, response ordering, cancellation), idempotent retries, shared-state audit, race amplification. Use for async fan-out, streams/SSE, jobs, caches, or flaky timing-smell bugs.
Externalize working state to files so long tasks survive context compaction and interruption. Use at the start of any task likely to exceed ~30 minutes or span many files, and again whenever a major phase completes or the plan changes.
| name | task-decomposition |
| description | Planning discipline for multi-step work — acceptance test first, read the terrain, dependency-ordered steps, de-risk the riskiest step early, re-plan on surprise. Use at the start of any task touching 3+ files or steps, and mid-task when something invalidates the approach. |
Strong runs front-load understanding and commit to a sequence. Weak runs start editing in the first minute and discover the real shape of the task by breaking things. Spend the first 10–20% of the task here.
One or two sentences: "Done means ___ works / passes / renders." If you can't state it, you don't understand the task — reread the request; if genuinely ambiguous on a decision the user owns, ask ONE batched set of questions now (not a drip mid-task). Ambiguity you can resolve from the code is yours to resolve, not the user's.
Before proposing steps:
3–8 concrete steps, each independently verifiable, ordered so the build stays green as long as possible (types/schemas first, then implementations, then call sites, then UI). For each step note: files touched + how you'll verify it.
Track it visibly (todo list) if 3+ steps; mark steps done as you complete them, exactly one in-progress at a time.
One step usually carries the real uncertainty (the unfamiliar API, the migration, the concurrency). Do a cheap probe of THAT step early — a spike, a dry run, a one-file prototype — before investing in the safe steps. Discovering step 5 is impossible after finishing steps 1–4 is the expensive failure.
When reality contradicts the plan (an API doesn't exist, a test reveals a hidden coupling, a file is generated), STOP editing. Update the plan explicitly: what changed, which steps die, which are added. Pushing the original plan through contradicting evidence is how half-finished hybrid states happen. If the surprise changes the scope the user asked for, surface it instead of silently redefining the task.
For work spanning many steps or likely to hit context limits: maintain a short state file (scratchpad) with — goal, decisions made + why, steps done, steps remaining, current blockers. Update it at each milestone. It is cheap insurance against context loss and drift.
The task is done when the step list is empty AND the acceptance test from step 1 passes — verified, not assumed (see pre-done-review).
