pm-spec-writing 用于把（往往模糊的）想法转化为可被开发者或 AI 智能体实际构建的规格说明，与具体技术栈无关。适用场景包括：把想法翻译为可构建的功能规格、撰写 PRD、提交他人可执行的缺陷报告、立项前界定范围、对功能请求清单排优先级、为已有功能编写验收标准、把大型计划拆分为可交付增量。不适用：跨多项计划的季度/年度规划、代码审查或调试、已定规格功能的设计决策、验证想法的用户研究。
必需输入：待解决的问题或想法、受影响的用户群体、已有约束（技术栈、截止时间、依赖）、成功指标。想法模糊时，第一步是先澄清，不围绕模糊点写规格。
流程分四个阶段。阶段一澄清：回答四个问题——解决什么用户问题、谁具体受益、成功指标是什么、为什么是现在；任一答案为“不知道”就回到用户。阶段二按影响/成本划分：高影响低成本立即做，高影响高成本规划并批量做，低影响低成本作为可选批量，低影响高成本跳过或无限期延后；合规、无障碍、安全等强制项作为例外标注。阶段三写规格，有三种格式：功能规格（标题、问题、用户、提案、用户故事、验收标准、范围外、依赖、成功指标、预估工作量、优先级）、开发简报（上下文、任务、约束、验证）、缺陷报告（URL 或上下文、症状、预期、复现步骤、假设、待查文件、优先级、浏览器/设备）。阶段四排序并交付：单个功能找出最小可交付增量，先发最小版本再迭代；清单则先按依赖、再按优先级、最后按影响/成本排序，顺序比优先级标签更重要。
输出为 markdown，按工作类型命名：spec-[功能名].md、brief-[任务名].md、bug-[摘要].md；大型计划可按 specs/计划名/ 目录组织并附 README。验证步骤必须明确、可观察，“测试一下”不算验证。
常见失败模式：先写方案后写问题、缺少成功指标、验收标准不可测、规格里混入实现细节、没有范围外段落、缺陷报告没有复现步骤、验证步骤含糊、跳过最小可交付增量练习。参考资料包括功能规格模板、开发简报模板、优先级框架（RICE、加权评分、MoSCoW）。