用途：为小型、快速的变更做轻量规划。它把 propose、spec 和可选的 design 合并成一次聚焦对话，最终写出 tasks.md，交给没有对话历史的实现代理使用。
主要能力：产出简短的 proposal.md、每个能力一份 spec、可选的 design.md 以及 tasks.md。产物需自包含，便于实现代理独立执行。流程包括：理解问题、期望行为、成功标准与范围；轻量查看相关规格与代码；用 codagent:ask-questions 只澄清关键行为、边界、错误、边缘情况和范围；判断是否需要 design.md（默认不需要，仅在有重要架构选择、非显然理由、迁移、集成策略或实现约束时写）；向用户展示能力集、设计文档决定、输出位置和关键假设并获批；一次性写出全部产物并统一检查遗漏决策或矛盾。
使用方式：遵循项目定义的位置；否则建议 ~/.agent-skills/changes/<kebab-slug>/ 并在写入前确认。不要变成完整的 propose/spec/design 仪式，也不要写详细任务分解。
产物要求：proposal.md 保持简短，含 Why、What Changes、Capabilities（新增与修改）、Out of Scope、Impact。specs/<capability>/spec.md 是核心产物，使用 SHALL 或 MUST、可观察行为，每条需求至少一个 #### Scenario: 带 WHEN/THEN；修改需求时先复制完整原需求及全部场景到 ## MODIFIED Requirements 再编辑；若行为依赖未决架构选择，可标记 <!-- deferred-to-design: <reason> --> 并在设计中解决；适用时使用 ## REMOVED Requirements（含 Reason 与 Migration）和 ## RENAMED Requirements（含 FROM 与 TO）。design.md 仅在需要时记录上下文、方法、决策与理由、风险或权衡、迁移细节。tasks.md 写一条占位条目，链接所有产物。
适用场景：小型、快速变更的规划与交接。限制：不适用于完整规划仪式或详细任务分解；输出位置需确认；资料未提供收费、价格、平台或效果信息。