用途：编写可让智能体或维护者自主实现功能的技术规格。核心是给出上下文而非具体指令，围绕“为什么”和“是什么”，把“怎么做”留给实现者；记录研究而非结论，并在开放问题部分保留待定问题，便于智能体进一步核实和扩展。
主要能力：规格应包含一句话总结、概述、动机（当前状态、问题、期望状态）、研究发现（含对比表与关键结论）、设计决策（按证据、一致性、偏好分级并注明理由）、架构（优先用文本图、文件树、路由表）、实施计划（分阶段、Phase 1 更细）、边界情况、开放问题、成功标准与参考文件。对涉及素材决策的可写为 docs/adr/ 中的 Proposed ADR。可引入目录式清单集中展示新原语，并用“被考虑并拒绝的候选”表说明取舍。
使用方式：所有实现规格放在根 /specs/ 目录，命名如 specs/YYYYMMDDThhmmss-feature-name.md，采用本地时间戳与 kebab-case。提示与交接产物可用 .prompt.md、.handoff.md、.execute.md 后缀，并应链接回主规格。规格首屏需回答：这是什么、处于活跃/已实现/被取代/历史哪种状态、当前形状、目标形状、什么证明完成。大规格可拆分或加“如何阅读本规格”区块。
适用场景：功能规划、API 或架构变更、迁移清理、需要给智能体提供启动点的工作。限制：资料未说明具体平台、收费、价格或效果；规格是进行中的脚手架而非永久记录，不具权威性且工作完成后应退休，历史由 Git 和 docs/spec-history.md 保留。