一键导入
spec-creator
内部步骤(Task 4),由 quickspec 编排器调用,不从用户直接触发。 从 PRD 分析和代码库映射结果生成精确的、编码 Agent 可执行的实现规格文档。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
内部步骤(Task 4),由 quickspec 编排器调用,不从用户直接触发。 从 PRD 分析和代码库映射结果生成精确的、编码 Agent 可执行的实现规格文档。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
内部步骤(Task 3),由 quickspec 编排器调用,不从用户直接触发。 将 PRD 需求映射到代码库,识别技术栈、相关模块、编码约定和扩展点。
内部步骤(Task 2),由 quickspec 编排器调用,不从用户直接触发。 对 PRD 内容进行 5-zone 结构化分析,提取功能、用户故事、业务实体、约束和验收条件。
内部步骤(Task 1),由 quickspec 编排器调用,不从用户直接触发。 分析用户原始输入,自适应选择工具加载 PRD 内容到工作目录。
将产品需求文档(PRD)转化为精确的、编码 Agent 可直接执行的实现规格文档。 触发:用户要生成 spec / 规格文档 / 实现方案,或要把 PRD 转成可执行规格。 不触发:写 PRD、改 PRD、代码 review、或非文档生成任务。
内部步骤(Task 5),由 quickspec 编排器调用,不从用户直接触发。 对规格文档进行结构化质量审查,检查 PRD 覆盖度、任务可操作性和验收条件可测试性。
| name | spec-creator |
| description | 内部步骤(Task 4),由 quickspec 编排器调用,不从用户直接触发。 从 PRD 分析和代码库映射结果生成精确的、编码 Agent 可执行的实现规格文档。 |
| user-invocable | false |
| context | fork |
| allowed-tools | ["Read","Write","Edit"] |
从分析后的 PRD 需求和代码库上下文中,生成精确的、编码 Agent 可执行的实现规格文档。
$ARGUMENTS/prd-analysis.md(由 prd-analyzer 产出)+ $ARGUMENTS/codebase-mapping.md(由 codebase-mapper 产出)$ARGUMENTS/{feature-name}-spec.md$ARGUMENTS/prd-analysis.md,获取 PRD 分析结果(功能列表、业务实体与交互需求、约束条件、验收条件)$ARGUMENTS/codebase-mapping.md,获取代码库上下文(技术栈、目录结构、相关模块、约定、扩展点)feature-name,用于 spec 文件命名将每个 PRD 功能转化为有序的、可操作的实现任务。参考 prd-analysis.md 中的业务实体和交互需求,结合 codebase-mapping.md 中的技术栈和现有代码结构,将业务描述转化为具体的技术任务。
### 任务 N:<动词> <内容> <位置>
**文件**: `path/to/file.ext`
**操作**: create | modify | delete
**依赖**: 任务 M(如适用)
<实现内容的描述>
**细节**:
- <具体实现细节 1>
- <具体实现细节 2>
**错误处理**:
- <情况 1>: <预期行为>
- <情况 2>: <预期行为>
从 prd-analysis.md 中的业务实体、属性、关系和交互需求出发,结合 codebase-mapping.md 中的技术栈和代码约定,推导生成技术规格。
#### <实体名称>
| 字段 | 类型 | 必填 | 默认值 | 校验规则 |
|------|------|------|--------|----------|
| id | UUID | 自动 | gen | 主键 |
**索引**: <字段: 索引类型>
**关联关系**: <实体: 关系类型>
#### <方法> <路径>
**用途**: <此端点做什么>
**鉴权**: <鉴权要求>
**请求**:
| 参数 | 位置 | 类型 | 必填 | 描述 |
|------|------|------|------|------|
| | | | | |
**响应(200)**:
<响应结构>
**错误响应**:
| 状态码 | 条件 | 消息 |
|--------|------|------|
| | | |
- [ ] <预期行为的描述>
- **验证方式**: <如何测试>
- **测试类型**: unit | integration | e2e | manual | visual
使用 ${CLAUDE_PLUGIN_ROOT}/skills/spec-creator/references/spec-template.md 作为输出结构模板,填充实际内容生成规格文档:
$ARGUMENTS/{feature-name}-spec.md{feature-name} 从 prd-source.md 元数据头中获取。
如果 $ARGUMENTS/review-report.md 存在且审查结论为 NEEDS_REVISION:
$ARGUMENTS/review-report.md,获取关键问题列表$ARGUMENTS/{feature-name}-spec.md读取 ${CLAUDE_PLUGIN_ROOT}/skills/spec-creator/references/quality-gate.md,逐项核对产出物 $ARGUMENTS/{feature-name}-spec.md 是否满足所有验收标准。如有未通过的项,使用 Edit 工具修复产出文件后重新核对。最多重试 2 次,仍未通过则将未通过项记入返回状态的 issues 中。
完成所有工作后,输出以下格式的状态信息(不要包含其他内容):
[STATUS: success | partial | failed]
[OUTPUT: {feature-name}-spec.md]
[WARNINGS: 警告列表,没有则为 none]
[ISSUES: 阻塞问题列表,没有则为 none]
[SUMMARY: 一句话摘要]