메뉴
在已有设计文档或清晰需求、但还没开始实现时，把目标写成可执行的分步实施计划。适用于跨文件改动、非平凡功能、重构，以及任何需要明确测试或验证命令的任务。只要用户要把已定需求、现成 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명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? 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 自检。