用途：根据功能规格（spec）生成技术实现计划，产出架构、数据模型与接口契约文档，不生成代码。应在完成规格编写后、生成任务列表前使用。
必要用法：需要提供或推断变更名称，读取 specs/changes/<name>/spec.md；若不存在，应先使用 spec-kit-specify 技能。同时载入相关 specs/features/ 文档。若规格中仍有 [NEEDS CLARIFICATION] 标记且影响架构，应暂停并建议先使用 spec-kit-clarify，除非用户明确要求继续。
产出：写入 specs/changes/<name>/plan.md，包含架构（限界上下文、受影响层次、依赖方向）、数据模型（实体、值对象、聚合、身份与结构相等性、不变量）、接口契约（端口、用例签名、领域事件，与技术无关）、实现阶段、决策与理由、约束与风险。
规则：依赖方向必须为 infrastructure -> application -> domain，不得倒置；影响业务行为的外部依赖须置于端口之后；仓储按聚合根而非表划分；领域层与应用层设计中不得出现框架名称；跨上下文通信仅通过领域事件或应用服务。完成前需做“章程检查”，确认不违反 FRAMEWORK.md 的不可协商架构规则。
输出与后续：确认文件位置，指出值得注意的架构决策，并提示下一步使用 spec-kit-tasks 技能生成任务列表。
限制：只做计划、不生成代码；对影响架构的未决澄清应显式提出而非猜测；优先保护领域模型，基础设施围绕其适配。