用途
Spec Writer 用于把一个粗略的想法转化为一份简短、清晰的 SPECS.md，以便交给架构设计或规划类技能继续处理。它的目标是把想法发展到足以避免重大误解的程度，同时把架构与实现细节留给下一个工作流。
其预期交接对象是 arch-design 或 plan，使它们无需重复基础探索即可继续。它本身不是完整的产品需求文档、测试计划、架构设计或实现计划。
主要能力
- 围绕“细化 → 调研 → 提问”循环组织工作流。
- 在提问前先检查可用上下文，不询问仓库文件或已提供材料能够回答的问题。
- 只调研可能实质改变范围、可行性、约束或后续问题的事实。
- 以小轮次提出聚焦问题，而非进行通用需求访谈。
- 将不确定性保留为假设或待决问题，而不是编造细节。
- 偏好结果和外部有意义的行为，而非实现选择。
- 当后续架构或规划技能已有足够信息安全推进时停止细化。
- 在写入 SPECS.md 前呈现简洁的确认简报并取得明确批准。
- 在该技能激活期间不设计架构、不创建实现计划、不实现代码。
使用方式
工作流分为以下步骤：
-
细化（Refine）：阅读原始请求及相关上下文，产出紧凑的工作摘要，包括问题或机会、期望结果、目标用户或相关方、初始范围内与范围外边界、已知约束、重要未知项，以及预期的下一步交接类型（架构、简单计划或复杂计划）。
-
调研（Research）：在让用户决定重要未知项之前先进行调研。使用仓库检查了解当前行为、接口、约定和约束；使用当前外部来源了解 API、标准、法规、版本、限制或生态事实。调研保持适度：多数想法使用一次聚焦调研；仅在存在真正独立的未知项时使用并行轨道；优先使用一手或官方来源；当进一步调研不太可能改变简报或问题时停止。仅为下一工作流可能需要验证的论断保留简洁的来源链接。
-
提问（Ask）：基于细化后的想法和调研，提出一小轮高影响问题。只询问用户最适合决定的事项。每轮优先 2–5 个问题，绝不超过 7 个。在权衡已明确时使用带推荐选项的选择题。优先关注结果、用户、范围边界、关键行为、约束和成功信号。仅在相关时询问安全、隐私、可靠性、规模、兼容性或发布问题。总结回答并更新工作简报。
-
按需重复：当某个回答引入重要未知项或改变范围时，重复“细化 → 调研 → 提问”。对于下游工作流可以解决的细微措辞或细节，不重复该循环。当简报能清楚回答以下问题时即准备就绪：我们为谁、为何解决什么问题？期望的结果和基本行为是什么？范围内和明确范围外是什么？哪些约束或现有系统事实影响工作？什么表明成功？下一工作流必须考虑哪些假设、风险或待决事项？
-
确认（Confirm）：呈现简洁的确认简报，包含问题与期望结果、用户、范围与非目标、基本需求、约束与相关调研事实、成功信号、假设/风险/待决问题、预期下一技能、建议输出路径。请用户选择：批准并写入 SPECS.md、修改、回答剩余问题或取消。批准必须是明确的。如果用户要求更改，更新简报并再次确认。在批准前不写入文件。
-
写入交接简报：默认写入仓库根目录的 SPECS.md，除非用户选择其他路径或仓库有明确约定。替换现有目标文件前先阅读，并在确认期间总结实质性更改。使用 templates/SPECS.template.md 作为灵活指南而非强制形式，省略空或无关章节，保持文档简洁并使用直接语言。
适用场景
适用于需要把初步想法整理成可供架构设计或实现规划使用的交接简报的场景。典型情况包括：想法尚粗糙、需要澄清关键范围与约束；希望避免下游流程重复基础探索；需要一份简短、经用户确认的 SPECS.md 作为交接产物。
限制
- 不设计架构、不创建实现计划、不实现代码。
- 不是完整的产品需求文档、测试计划、架构设计或实现计划。
- 默认最终长度约 50–150 行，仅在用户要求更多细节或想法具有实质复杂约束时超出。
- 使用要点而非长文；仅包含能增加有用交接上下文的章节。
- 调研笔记仅保留结论和来源链接，不包含证据台账、来源分级或调研记录。
- 默认不创建需求 ID、验收标准 ID、追溯矩阵、修订历史或详尽边界情况目录。
- 需求限于重要行为和约束，下游架构或规划工作流可进一步展开。
- 仅记录可能影响范围、架构、排序或可行性的风险与待决问题。
- 写入前需用户明确批准；批准前不写入文件。
- 写入后仅报告：保存路径、一句话摘要、建议的下一技能、任何重要的未解决问题。
完成检查
写入前需验证：用户已明确批准确认简报；问题、结果、用户和范围清晰；没有重要需求与非目标或约束矛盾；调研论断简洁且在有用处标注来源；不确定性可见而非作为事实呈现；未编造架构和实现选择；文档比例适当并准备好用于预期交接。