一键导入
spec-create
在 `spec-propose` 阶段为单个需求生成结构化 `spec.md`。用于把已澄清的目标、约束、接口、风险和验收条件落成 AI 可消费的 Markdown 规格,并与本插件内的 `spec-driven-development` 规范保持一致时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
在 `spec-propose` 阶段为单个需求生成结构化 `spec.md`。用于把已澄清的目标、约束、接口、风险和验收条件落成 AI 可消费的 Markdown 规格,并与本插件内的 `spec-driven-development` 规范保持一致时使用。
用 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-create |
| description | 在 `spec-propose` 阶段为单个需求生成结构化 `spec.md`。用于把已澄清的目标、约束、接口、风险和验收条件落成 AI 可消费的 Markdown 规格,并与本插件内的 `spec-driven-development` 规范保持一致时使用。 |
生成一个适合 spec-propose 阶段落盘的 spec.md,让后续 spec-apply、spec-review、spec-fix 都能直接把它当作执行合同。
skills/spec-driven-development/SKILL.md 的结构要求兼容在执行本 skill 时,同时遵守 ../../references/full-sdd-lifecycle.md 中 spec-create 阶段的协同规则。
skills/spec-driven-development/SKILL.md 提供规格完整性标准spec-propose 提供事实输入、代码出处和待澄清项spec.md 至少应包含以下结构:
---
title: [需求标题]
version: [可选,例如 1.0]
date_created: [YYYY-MM-DD]
last_updated: [可选,YYYY-MM-DD]
owner: [可选,团队或责任人]
tags: [可选,例如 `process`, `design`, `app`]
status: [默认 `propose`]
---
# 背景
[一句话说明本次变更要解决什么问题。]
## 1. 目标与成功标准
- 用户价值
- 业务目标
- 成功判定方式
## 2. 代码现状
- 当前实现
- 关键入口
- 相关依赖
- 已知限制
- 以上每条都要附代码出处
## 3. 变更范围
- 会修改什么
- 不会修改什么
- 对外影响面
## 4. Requirements, Constraints & Guidelines
- **REQ-001**: 功能要求
- **CON-001**: 约束条件
- **GUD-001**: 编写或交互约定
- **PAT-001**: 需要遵循的模式
- **RISK-001**: 已知风险或回滚关注点
## 5. Interfaces & Data Contracts
[接口、数据契约、外部集成点、兼容性要求。]
## 6. 测试与验证策略
- Test Levels
- Frameworks / Commands
- Coverage expectations
- 验证证据要求
## 7. 技术决策
[已确认方案、被放弃方案及原因。]
## 8. 待澄清项
[仍未关闭、必须由用户确认的问题。]
## 9. 验收标准
- **AC-001**: Given [上下文], When [动作], Then [预期结果]
- **AC-002**: 关键边界条件
- **AC-003**: 非目标与禁止扩展项
skills/spec-driven-development/SKILL.md 强调的目标、边界、测试、成功标准