القائمة
需求规格评审。Use when 启动新项目/新功能、需求还模糊、在任务拆分或写代码之前，需要先和用户对齐需求边界并产出结构化 Spec 时。也适用于用户给的需求一句话太笼统、缺少边界与非功能性要求的场景。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
对照 Issue 与验收标准开发。Use when 一个 Issue 被分配、准备写代码/写测试/修 Bug 时。也适用于需要按验收标准实现功能、并保证产出包含测试与示例、提交前自查的场景。
Use when 需要在当前项目中实现新功能、优化现有代码或修复 bug。触发场景：用户提出功能需求、代码需要重构、发现 bug 需要修复、需要对齐架构文档规范进行开发。
问题记录与定期总结提炼。Use when 同一问题反复出现、Milestone 结束、或需要把踩过的坑提炼成可复用规则/新 Skill 时。也适用于定期复盘、更新验收标准或拆分策略、沉淀方法论的场景。
可观测性与模型降质检测。Use when 一次开发会话结束、需要记录 Session 摘要、或怀疑模型出现降质（反复返工、标准滑坡、摸鱼）时。也适用于需要追踪 Issue 状态、生成 PR 摘要、复盘 token 花费的场景。
任务归约拆分与验收标准前置。Use when 已有 Spec 或较清晰的需求、要把大需求切成可执行任务、准备启动开发之前。也适用于需求太大、一个 Agent 无法独立完成、需要拆成 Epic/Milestone/Issue 并定义 P0-P3 验收标准的场景。
Use when 进入一个新项目或项目结构发生重大变化，需要生成/更新架构文档（docs/ARCHITECTURE.md）。触发场景：首次接入项目、重构后文档过时、新成员需要上下文、agent 需要理解项目全貌。
| name | plan-spec |
| description | 需求规格评审。Use when 启动新项目/新功能、需求还模糊、在任务拆分或写代码之前，需要先和用户对齐需求边界并产出结构化 Spec 时。也适用于用户给的需求一句话太笼统、缺少边界与非功能性要求的场景。 |
和用户一起过需求，确保双方理解一致，产出一份结构化 Spec 文档作为后续拆分（plan-breakdown）的输入。
核心原则： 标准前置。写代码之前先把「要做什么、不做什么、做到什么程度」说清楚，避免后期返工。
何时不用：
一份 Spec 文档（Markdown，约 200-500 字），使用 templates/spec-template.md 模板，包含：
保存位置建议：docs/spec/<项目名>.md。
我想做一个【XXX】。请你像产品经理一样向我提问（一次一个问题），帮我澄清需求边界、异常场景和非功能性需求。问完后，输出一份结构化 Spec 文档，包括一句话描述、核心功能、边界条件、非功能性需求、技术约束、P0 验收总纲。
templates/spec-template.mdskills/plan-breakdown/SKILL.md（把 Spec 拆成 Epic → Milestone → Issue）docs/AI 编程方法论 v1.2 — 可操作版.md 第 1.1 节