用途：在决定是否开发某个软件想法时，先做诚实评估，若值得推进再写出提案文档 proposal.md。提案重点说明动机、高层级变更边界，并给出刚好足以论证可行性和暴露结构性风险的技术思路；详细行为应放入规格文档，详细架构应放入 design.md。
主要流程：1）理解与研究：当问题、受众、预期结果、成功标准、约束或范围边界不清晰时，使用 codagent:ask-questions 提问；阅读相关规格与代码，了解当前行为、架构与既有模式；调查以往尝试、可用工具与可信替代方案；外部实践、产品或已知坑点重要时进行网络调研。2）评估：判断问题重要性、不构建的替代方案、机会成本、维护负担以及与现有系统的契合度，直接给出 go、go with caveats 或 no-go 的结论及理由和改变结论的条件；no-go 不产出提案，除非用户讨论权衡后决定继续。3）确定高层方案：对可行想法识别最小有用范围、受影响能力、架构契合度、重大技术决策与主要风险；存在真实替代方案时推荐其一并说明关键权衡；仅当选择会改变产品范围或方向时才询问用户；低风险实现默认值可从仓库上下文推断。4）批准与撰写：写之前先向用户展示建议、范围和方案并获得批准，列出有影响的假设或默认值。输出路径优先使用调用方或项目定义路径，否则建议 ~/.agent-skills/changes/<kebab-slug>/proposal.md 并与用户确认。
产物模板包含 Why、What Changes（破坏性变更标注 BREAKING）、Capabilities（New Capabilities 与 Modified Capabilities，均用 kebab-name 命名）、Technical Approach、Out of Scope、Impact 等章节。限制：技术方案刻意比设计更轻，仅在澄清重要关系或决策时使用图或对比；不调用其他生命周期技能；关于具体收费、平台支持、效果等资料暂未提供。