用途
feature-spec 用于为一个明确指定或当前唯一确定的功能（Feature）编写或修订持久的行为契约。其目标是：把已经达成一致的行为一次性记录下来，让后续每个任务都消费同一份契约。
当一个功能需要由多个执行者（executor）分担时，在任务规划之前必须先有一份持久的行为契约。对于未被拆分的小型功能，如果其结果、范围、规则和验收已经可评审，可以在 feature.md 中保留一份紧凑契约，不要仅仅为了满足某种布局而单独创建文件。
主要能力
确定功能边界
在编辑之前先解析出唯一确切的功能：
- 优先使用请求中给出的 ID、链接、路径或名称；
- 否则从请求、.waypoint/local.yaml 或外部跟踪器解析执行者，再按负责人筛选活跃功能；
- 只有当恰好剩下一个候选时才继续，否则询问。
绝不回退到其他负责人的功能、列表顺序、最近时间、Git 历史或当前分支。显式指定目标并不转移所有权。
随后阅读仓库说明、该功能记录、相关产品上下文、现有行为以及本地规范约定。
识别稳定的功能 ID、负责人、预期结果、范围、非目标以及可观察的完成证明。负责人优先复用功能记录或已配置外部跟踪器中的值，其次是当前请求中显式给出的值。如果仍然缺失，在 .waypoint/local.yaml 存在时直接读取它，并使用其中的 actor_id 作为当前执行者；如果这样仍无法确定功能负责人，则询问用户。绝不从 Git 作者元数据、运行框架、机器、分支或窗口身份来猜测。
综合用户和仓库已经确立的决策。写作时不要再次访谈、扩大范围、添加技术选择，也不要悄悄替未来意图做决定。
当行为仍然模糊到足以改变验收或任务边界时，停止并返回未解决的决策。
写行为，不写实现
只包含最小有用集合中的内容：
- 问题、动机、结果和参与者；
- 包含的行为和有意义的非目标；
- 可观察的输入、输出、规则和状态转换；
- 在契约边界可见的失败、兼容、安全或运维行为；
- 当能澄清重要边界情况时的代表性场景；
- 外部施加的约束；
- 当没有更强的功能记录拥有验收时，作为权威的功能验收。
不要包含架构、模块接缝、模式、算法、文件路径、任务分解、执行顺序、编写测试的步骤、发布机制或提交说明。应链接现有设计，而不是对其进行总结。
更新与收尾
如果存在合适的仓库原生规范，则更新它；否则使用 references/spec-template.md。当功能记录存在时，把权威验收保留在 feature.md 中；规范应解释使这些检查有意义的行为，而不复制检查清单。
在达成一致的行为被持久化后即结束。批准仅授权这份规范；除非当前请求明确点名了那个单独的计划结果，否则不要继续进入设计、任务规划、实现规划或代码。规划从不授权实现。
使用方式
该技能以技能（skill）形式提供，可通过 npx skills 安装。安装命令示例：
npx skills add mattpocock/skills --skill <name>
上述命令用于安装所需的配套技能，仅安装需要的那个。
配套技能
当已安装时，可使用 grilling 处理未解决的产品意图，使用 research 处理重要的外部事实。这些配套技能来自 mattpocock/skills，且是可选的。
适用场景
- 需要为一个功能建立或修订持久行为契约时；
- 功能将由多个执行者分担，需要在任务规划前统一契约时；
- 需要把已达成一致的行为固化，避免后续任务各自理解不一致时。
限制
- 只写行为，不写实现；不涉及架构、模块、模式、算法、文件路径、任务分解、执行顺序、测试步骤、发布机制或提交说明。
- 不再次访谈、不扩大范围、不添加技术选择、不替未来意图做决定。
- 行为模糊到足以改变验收或任务边界时，必须停止并返回未解决的决策。
- 批准仅授权规范本身，不授权设计、任务规划、实现规划或代码。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。