菜单
Use when creating, editing, or validating reusable agent skills and their trigger behavior. Do NOT use for ordinary project documentation or one-off prompts.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a request leaves material product, architecture, behavior, or scope decisions unresolved. Do NOT use for approved, well-bounded implementation work.
Use when 2 or more substantial tasks are independent, have disjoint state, and parallel execution will save meaningful time. Do NOT use for coupled or sequential work.
Use when implementing an approved written plan with dependent tasks in the current session. Do NOT use when the plan is missing, unapproved, or naturally parallel.
Use when verified implementation is ready and the user must choose whether to keep, merge, or publish the branch. Do NOT use before applicable checks pass.
Use when receiving code review feedback that may be unclear or technically questionable and needs verification. Do NOT use for an unrequested general code review.
Use when a completed change is high-risk, crosses subsystem boundaries, or the user explicitly requests independent review. Do NOT use by default for low- or medium-risk changes.
| name | writing-skills |
| version | 6.2.0 |
| category | workflow |
| description | Use when creating, editing, or validating reusable agent skills and their trigger behavior. Do NOT use for ordinary project documentation or one-off prompts. |
Treat skills as behavior-shaping interfaces. Validate them in proportion to the cost of a wrong instruction.
Read ../using-superpowers/references/risk-policy.md.
SKILL.md focused on a reusable trigger and workflow.name, a semver version, category, and a description
with explicit Use when and Do NOT use conditions.| Change | Validation |
|---|---|
| Typo, link, metadata, wording clarification | Static validation and direct inspection |
| Ordinary workflow change | Static validation plus one focused scenario |
| Safety-critical discipline or broad automatic behavior | Baseline scenario, changed scenario, and additional cases only for observed loopholes |
A scenario may be an isolated manual prompt, a harness check, or a subagent when delegation is available and justified. Subagents, 5-repetition micro-tests, and adversarial review loops are not mandatory for every edit.
Do not create tests when the control does not exhibit the failure. Do not keep adding scenarios after the intended behavior is demonstrated unless a specific gap remains.
Do not commit or publish without user authorization.