菜单
Use after a spec is agreed and before coding a multi-step change, to break the work into small, independently verifiable tasks with exact files and a check per task. A plan an agent can execute without re-deciding scope, and that survives compaction.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when several pieces of work are genuinely independent and can run at once, to fan them out across parallel agents instead of doing them in sequence. Cuts wall-clock time and keeps each strand in its own clean context.
Use when a written plan exists and you are about to build it in the current session, to work it task by task with a checkpoint after each. Keeps execution honest against the plan instead of drifting into a freehand build.
Use when work needs its own isolated checkout — parallel strands that would fight over files, or a risky change you want quarantined from the main tree. Gives each strand a real working directory on its own branch without re-cloning.
Use whenever the user says "use slipstream", "use superpowers", or starts any task in a project that has slipstream. A hard, always-on discipline that forces scoped reads over whole-file reads to save tokens, recalls memory before acting, and records what is durable every turn so memory grows constantly.
Use when a site needs to look designed rather than defaulted, before building sections: establish a cohesive design system of type scale, spacing, colour, radius and shadow tokens so every component shares one premium visual language.
Use when building the top of a landing page, to produce a high-impact hero with confident display type, a clear single call to action and balanced composition, the kind of opening a polished marketing site leads with.
| name | write-plan |
| description | Use after a spec is agreed and before coding a multi-step change, to break the work into small, independently verifiable tasks with exact files and a check per task. A plan an agent can execute without re-deciding scope, and that survives compaction. |
| slipstream | {"category":"context","requires":["brainstorm-spec"],"tags":["planning","discipline","token-efficiency"]} |
A good plan is the difference between executing and improvising. Without one, a long change drifts: the agent re-decides scope every few turns, forgets what it already did after a compaction, and burns tokens reconstructing its own intent. This skill produces a plan made of small tasks — each a few minutes of work, each naming the exact files to touch and the exact check that proves it done — so execution is mechanical and a resumed session picks up precisely where it left off.
Each task in the plan has: a one-line goal, the specific files/symbols it changes, the steps, and a verification command. Keep tasks small enough that one can fail without dragging the others down, and order them so each builds on verified ground.
brainstorm-spec first if there is none).docs/plans/<short-name>.md and record the open task with sp_remember (type todo) so the next session and the PreCompact digest carry it forward.A written plan exists where every task names its files and carries its own verification command, the tasks are ordered by dependency, and the plan is saved to disk and reflected in memory (npx slipstream memory list --root .). If any task has no way to prove it done, it is not specified well enough yet.