菜单
在需求提案阶段以“人主导、AI 辅助”的方式梳理代码现状、逐轮澄清需求，并在 `docs/changes/templates/` 下为单个需求创建 `spec.md`、`tasks.md`、`log.md`。当用户要求先做方案设计、先写规格文档、先澄清再实现、进入 propose/spec 阶段，或明确要求在编码前完成设计审视与确认门控时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
Tests in real browsers. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data via Chrome DevTools MCP.
Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.
Optimizes agent context setup. Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project.
| name | spec-propose |
| description | 在需求提案阶段以“人主导、AI 辅助”的方式梳理代码现状、逐轮澄清需求，并在 `docs/changes/templates/` 下为单个需求创建 `spec.md`、`tasks.md`、`log.md`。当用户要求先做方案设计、先写规格文档、先澄清再实现、进入 propose/spec 阶段，或明确要求在编码前完成设计审视与确认门控时使用。 |
在执行本 skill 时，同时遵守 ../../references/full-sdd-lifecycle.md 中 spec-propose 阶段的协同规则。
skills/idea-refine/SKILL.md 做问题收敛spec.md 时，继承本插件 skills/spec-driven-development/SKILL.md 的六大核心域tasks.md 时，继承本插件 skills/planning-and-task-breakdown/SKILL.md 的依赖拆解与验收口径在编码前完成提案阶段文档，而不是直接进入实现。
docs/changes/templates/<需求目录>/ 下生成 spec.md、tasks.md、log.md按下面顺序执行，不要跳步。
先阅读仓库内与需求相关的代码、配置、文档和测试，再开始提问。
一次只问一个问题，或一组紧密相关的问题。
推荐问题格式：
问题：是否需要兼容旧接口返回结构？
- 选项 A（推荐）：完全兼容旧结构
影响：前端和调用方无需改动，但实现复杂度更高
- 选项 B：新增版本化接口
影响：边界更清晰，但需要调用方配合切换
- 选项 C：允许直接替换
影响：实现最简单，但存在明显升级风险
在 docs/changes/templates/ 下为当前需求创建一个新目录。
spec.md、tasks.md、log.mdspec.md生成 spec.md 时必须使用 $spec-create 的结构化写法；如果无法直接调用，也要保持同等结构化程度。
并且必须补齐本插件 skills/spec-driven-development/SKILL.md 中强调的关键域：
至少覆盖以下内容：
若存在未解决问题，spec.md 必须反映这些问题仍处于待确认状态，而不是假装已定稿。
tasks.md将任务拆成可执行、可验收的条目，但保持“提案阶段”语义。
skills/planning-and-task-breakdown/SKILL.md 的 S/M 任务标准，避免直接生成 XL 级任务推荐结构：
# tasks
## 已完成
- [x] 分析相关代码现状并记录出处
- [x] 完成关键问题澄清
## 待确认
- [ ] 用户确认提案文档可进入 Apply
- [ ] 用户确认仍未关闭的取舍项
## 实施任务（确认后执行）
- [ ] 更新后端接口
- [ ] 补充测试
- [ ] 准备回滚和验收说明
log.md创建即可，内容可暂时为空，后续记录apply阶段的决策变更、用户反馈、实施过程中的发现等。
始终执行下面约束：
spec.md、tasks.md、log.md 生成完成后，必须等待用户显式确认交付前自行检查：
docs/changes/templates/<需求目录>/ 是否存在且只包含当前需求的三个文件spec.md 是否包含代码现状、功能点、变更范围、风险、技术决策、待澄清tasks.md 是否把实现任务保持为未开始状态log.md 是否已创建向用户汇报时至少包含：
spec.md、tasks.md、log.md 已生成docs/changes/templates/下修改README.md，添加新需求目录的链接和简要说明。feature/<需求目录>。