用途：编写并迭代项目规格文档 docs/spec.md，明确产品要做什么、为什么存在。规格是活的产品文档，只定义“做什么”和“为什么”，不定义“怎么做”——技术栈、项目结构、命令、代码风格、测试、git 流程属于 CLAUDE.md 或技能，架构与系统设计、任务清单和时间线也不属于规格。
使用时机：用户明确要求创建或更新规格；或在其他工作中出现产品决策时主动提示“这听起来应该写进规格，要我加到 docs/spec.md 吗”，用户拒绝则不再追问。
创建新规格：采用头脑风暴模式，一次只问一个问题，尽量用选择题。逐节走查规格各部分，针对每节提出聚焦问题，不预设答案。全部覆盖后逐节撰写，每节写完请用户确认再继续，最后把已确认的各节组装成 docs/spec.md（docs/ 目录不存在则创建）。
更新已有规格：先读 docs/spec.md，询问要改什么或加什么，只走查受影响的章节，沿用“提议—确认”节奏，写入前展示改动供批准。主动提示场景下，先读现有规格，提出该决策适合放在哪一节，展示更新供批准。
规格固定结构（按此顺序）：# 项目名；## Objective 一段话说明问题、受众和核心价值；## Users 使用者及其关注点，多种用户类型时分述；## Features 用户能做什么，按领域组织，描述可观察行为而非实现细节；## Non-goals 刻意不做的事，防止范围蔓延；## Constraints 影响决策的硬性要求，如监管、性能、兼容性、数据驻留、预算，只写真实约束；## Success criteria 具体可观察的指标，如“用户能在无 Y 的情况下完成 X”，而非虚荣指标；## Open questions 尚未决定的问题及为何重要，解决后移入其他章节。
写作准则：简洁具体，是参考文档而非散文；从用户视角描述行为；用具体例子代替抽象描述，如“用户按公司名搜索并在 200ms 内看到匹配结果”而非“快速全文搜索”；非目标与约束和功能同等重要，需认真对待。
限制：资料未提供该技能的安装方式、平台支持、收费或价格信息。