メニュー
在已有设计文档或清晰需求、但还没开始实现时，把目标写成可执行的分步实施计划。适用于跨文件改动、非平凡功能、重构，以及任何需要明确测试或验证命令的任务。只要用户要把已定需求、现成 spec、明确目标，或 /grill-with-docs / /grilling 后达成的共识，拆成 step-by-step plan，就优先使用这个 skill；如果设计还没定，不要硬写计划，退回 brainstorming 或 grill-with-docs 把设计做扎实。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/iasiv5/ob-harness --skill writing-plansコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
在开始实现前，把需求澄清成设计文档。适用于新增功能、修改行为、组件设计、接口设计、流程改造、架构取舍和多方案比较。只要改动跨文件、改行为或涉及多方案取舍，就值得先做设计，无论体量大小；单点直改不必走本 skill。用户说'先想一下''先给方案''先规划一下''先比较两种做法'时优先使用这个 skill。
在任务完成后，对仓库内长期知识做深度整理、沉淀与规范审计。仅在用户明确要求 cleanup、最终沉淀、长期知识同步、收尾整理，或明确要求检查仓库规则执行情况时触发；不要用于中途续做、普通总结、状态同步或实现过程中的正常文档更新。默认保守触发，强制 cleanup 也不默认写入用户记忆。
为新的 chat / 新会话生成面向下一会话目标的 handoff / continuation context。仅在用户明确要把当前工作交接到新 chat 继续时触发；不要用于普通总结、状态同步、代码评审、changelog 或文章摘要。基于只读证据输出可直接粘贴到新 chat 的中文优先接续上下文。
SOC 職業分類に基づく
SKILL.md を表示中
| name | writing-plans |
| description | 在已有设计文档或清晰需求、但还没开始实现时，把目标写成可执行的分步实施计划。适用于跨文件改动、非平凡功能、重构，以及任何需要明确测试或验证命令的任务。只要用户要把已定需求、现成 spec、明确目标，或 /grill-with-docs / /grilling 后达成的共识，拆成 step-by-step plan，就优先使用这个 skill；如果设计还没定，不要硬写计划，退回 brainstorming 或 grill-with-docs 把设计做扎实。 |
| argument-hint | 提供已批准的设计文档、需求摘要、目标功能或期望路径；可留空 |
这个 skill 用于把已批准的设计或足够清晰的需求，转换成普通编码 agent 或人工执行者可直接消费的实施计划。
这是一个 planning skill，不是 execution skill。 在这个 skill 中，先写计划，再决定是否开始实现。
在以下场景优先使用这个 skill：
以下请求默认不要使用这个 skill：
如果还没有批准过的设计或达成共识，走 PHASE 0 的"方案未定"三选 fork（brainstorming / grill-with-docs / 补需求）。
命中下列已知翻车点时按"信号 → 一线动作"先处理，再跳到"详见"里的处理器。本表是诊断索引——每条只写一线动作并指向详细规则归属，不在此重复正文：
| 信号 | 一线动作 | 详见 |
|---|---|---|
设计未批准 / 方案未定就硬写计划（unapproved-design-stop） | 🛑 STOP，走三选 fork（brainstorming / grill-with-docs / 补需求） | PHASE 0（方案未定分支） |
编造文件、命令或测试框架（missing-design-path-stop） | 🛑 STOP，说明缺口，不猜路径、不猜命令 | PHASE 0（路径分支）、PHASE 1 |
一个请求横跨多个独立子系统（multi-subsystem-split） | 🛑 STOP，先拆成多份计划，每份独立可验证 | PHASE 0（多子系统分支） |
跳过文件结构直接列任务（skip-file-structure-first） | 回 PHASE 2 先规划文件结构与职责 | PHASE 2 |
其余（不要占位符 / 不要省略接口契约 / 交接终点是 handoff 等）已在硬约束与各 PHASE 里正面规定，此处不重复。
TODO、TBD、later、add validation 这类空话。开始前先确认：
/grill-with-docs 或 /grilling 后达成的共识（盘上有 ADR / CONTEXT 就读作设计来源，没有就把对话本身当足够清晰的需求）；或至少足够清晰、能直接拆任务的需求如果设计仍然覆盖多个独立子系统：
如果输入仍然存在明显的方案未定、关键约束缺失或逻辑矛盾：
brainstorming（还在比较方案 / 需要多选澄清 / 目标边界没钉住时）、grill-with-docs（已有想法或草稿 / 对抗式压力测试 / 顺带沉淀 ADR glossary 时）、或直接补一份更清晰的需求（只是缺几条约束 / 不必走完整设计流程时）如果用户给出的设计文档路径表达不确定、文件不存在或不可读：
如果还不知道关键路径、受影响文件范围或主要验证方式：
在写计划前，先读取最小必要上下文：
目标不是把全仓库看完，而是回答：
如果这三个问题已经答清，就停止继续搜索，不要把 Phase 1 扩成仓库漫游。
在定义任务前，先列出文件结构和职责：
规则：
如果计划会被分任务交给不同执行者，每个任务都要能单独读懂。前序任务产出的函数、类型、配置键、路径或文档章节，必须在后续任务的接口契约里重复写明，不要要求执行者“参考前文”。
任务要足够小，通常以 2-5 分钟的单步为粒度。
每个任务都只覆盖一个可独立验证的工作块。出现以下信号时，必须继续拆分：
任务也不能拆得过碎：setup、配置、脚手架、文档更新通常应折进真正需要它们的交付任务。这叫 reviewer gate——只有当 reviewer 可以单独拒绝某个任务、同时接受相邻任务时，独立任务边界才成立。
对代码变更，优先使用验证驱动循环：
如果某类工作不适合严格 TDD：
任务必须满足：
如需固定骨架，先读取 references/task-skeleton.md。
路径选择顺序：
docs/plans/<YYYY-MM-DD>-<feature>-implementation-plan.md如需固定骨架，先读取 references/plan-template.md。
实施计划至少覆盖：
计划正文格式要求：
写完计划后，读取 references/plan-self-review.md 并完成单轮 inline 自检。
优先修复会让执行者卡住或把事情做错的问题：
不要为了措辞做多轮循环。修完就继续。
计划通过自检后，立即停下，让用户先审阅。未获批准，不进入实现。
交接时使用如下表述：
实施计划已写好并保存到
<path>。请先确认这份计划；如果没问题，下一步可以按计划由普通编码 agent 或人工继续执行。
如果用户要求修改：
如果用户批准：
把下面的纪律写进计划正文：
main 或 master，且用户没有明确同意，开始实现前先确认File structure first · Reviewer gate · Consumes / Produces · Bite-sized · Follow the repo · Stop when blocked · Runtime-neutral（各词已在对应 PHASE 与硬约束里定义）
先验证输入是否足够，然后读取最小必要上下文，规划文件结构，拆任务，写计划并完成 inline 自检。