spec-driven-auto

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

You are running the full spec-driven workflow end-to-end for a single change.

你正在为单个变更端到端运行完整的规范驱动工作流。

Prerequisites

前提条件

The

.spec-driven/

directory must exist at the project root. Before proceeding, verify:

ls .spec-driven/

If this fails, the project is not initialized. Run

/spec-driven-init

first.

项目根目录下必须存在

.spec-driven/

目录。在继续之前，请验证：

ls .spec-driven/

如果验证失败，说明项目未初始化，请先运行

/spec-driven-init

。

Steps

步骤

Assess complexity — before doing anything, evaluate the change using a three-tier model:
- Read
```
.spec-driven/config.yaml
```
  for project context
- Read
```
.spec-driven/specs/INDEX.md
```
  and relevant spec files to understand the current system
- Read the codebase files that the change will likely touch — estimate the number of files, modules, and cross-cutting concerns involved
- Classify the change into one of three tiers:
  - Green (proceed): touches ≤ 6 modules or packages, modifies ≤ 20 files, clear scope, straightforward schema migrations (add column, create table, simple backfill), additive auth/authz/payment changes (e.g., adding a new role or permission) — proceed without additional confirmation beyond the standard proposal checkpoint
  - Yellow (warn and ask): touches 7-15 modules or packages, modifies 21-50 files, schema migrations involving data transformation, auth/authz/payment changes that modify existing logic, cross-cutting changes touching multiple subsystems — show the user the specific risk factors and require explicit confirmation before proceeding
  - Red (suggest brainstorm): requires coordinating across multiple services or repositories, scope is vague or open-ended (e.g. "refactor the codebase", "improve performance"), no clear definition of done — explain why and suggest running
```
/spec-driven-brainstorm
```
    first to converge the idea, then entering
```
/spec-driven-auto
```
    to execute the resulting proposal
- If the change spans multiple tiers (e.g., module count is Green but file count is Yellow), use the highest applicable tier
- If Red, stop and suggest brainstorm
- If Yellow, list the risk factors and wait for the user to confirm before proceeding
- If Green, proceed
Propose — run
```
/spec-driven-propose
```
:
- Run
```
node {{SKILL_DIR}}/scripts/spec-driven.js propose <name>
```
- Fill all artifacts: proposal.md (with Unchanged Behavior), specs/ delta files, design.md, tasks.md (with ## Testing), questions.md (open questions)
- Show the user a summary: scope, key decisions, task count, unchanged behaviors, and any open questions
- Wait for explicit confirmation before proceeding — this is the only mandatory checkpoint
- If questions.md has open questions, list them and ask the user to resolve them before confirming
- If the user requests changes, apply them and re-confirm
Apply — implement all tasks:
- Run
```
node {{SKILL_DIR}}/scripts/spec-driven.js apply <name>
```
  to show task summary
- Check questions.md for open
```
- [ ] Q:
```
  entries — if any, ask the user and resolve before continuing
- Work through each
```
- [ ]
```
  task in order: read code, implement, verify Unchanged Behavior, mark
```
- [x]
```
- For
```
## Testing
```
  tasks: actually run the tests and confirm they pass
- Run
```
node {{SKILL_DIR}}/scripts/spec-driven.js apply <name>
```
  to confirm
```
remaining === 0
```
Verify — check completeness:
- Run
```
node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>
```
- Then perform the rest of the
```
/spec-driven-verify
```
  checks: task completion, open questions, implementation evidence, and spec alignment
- Treat script
```
errors
```
  plus any CRITICAL findings from those checks as blockers
- If there are blockers you can safely fix, fix them automatically, then rerun both the script check and the verification pass
- If any blocker cannot be auto-fixed: stop and ask the user
- Re-read delta spec files and update them to match what was actually implemented
Review — check code quality:
- Read every file changed by this change
- Check: readability, security, error handling, performance, best practices, test quality
- MUST FIX issues: fix them automatically, then re-review
- If MUST FIX issues cannot be auto-fixed: stop and ask the user
- SHOULD FIX and NITS: fix if straightforward, otherwise note in the final report
Archive — close out the change:
- Confirm there are no incomplete tasks before archiving
- List all delta files in
```
specs/
```
  and merge each into the corresponding main spec file
- If
```
changes/<name>/specs/
```
  is empty, ask the user to confirm this change has no observable spec impact before continuing
- Update
```
.spec-driven/specs/INDEX.md
```
  if new spec files were created
- Run
```
node {{SKILL_DIR}}/scripts/spec-driven.js archive <name>
```
- Report the final result: what was built, files changed, tests passing

评估复杂度 — 在执行任何操作之前，使用三级模型评估变更：
- 读取
```
.spec-driven/config.yaml
```
  获取项目上下文
- 读取
```
.spec-driven/specs/INDEX.md
```
  和相关规范文件，了解当前系统
- 读取变更可能涉及的代码库文件 — 估算涉及的文件数量、模块和横切关注点
- 将变更归类为以下三个层级之一：
  - 绿色（继续）：涉及≤6个模块或包，修改≤20个文件，范围明确，模式迁移简单（添加列、创建表、简单回填），权限/授权/支付相关的新增变更（例如添加新角色或权限） — 除标准提议检查点外，无需额外确认即可继续
  - 黄色（警告并确认）：涉及7-15个模块或包，修改21-50个文件，涉及数据转换的模式迁移，修改现有逻辑的权限/授权/支付变更，涉及多个子系统的横切变更 — 向用户展示具体风险因素，需明确确认后方可继续
  - 红色（建议头脑风暴）：需要跨多个服务或仓库协调，范围模糊或开放式（例如“重构代码库”、“提升性能”），没有明确的完成定义 — 解释原因并建议先运行
```
/spec-driven-brainstorm
```
    来统一想法，然后再运行
```
/spec-driven-auto
```
    执行最终提议
- 如果变更跨多个层级（例如模块数量为绿色但文件数量为黄色），适用最高层级
- 如果是红色，停止并建议头脑风暴
- 如果是黄色，列出风险因素并等待用户确认后再继续
- 如果是绿色，继续执行
提议 — 运行
```
/spec-driven-propose
```
：
- 运行
```
node {{SKILL_DIR}}/scripts/spec-driven.js propose <name>
```
- 填充所有工件：proposal.md（包含未变更行为）、specs/ 增量文件、design.md、tasks.md（包含 ## 测试）、questions.md（未解决问题）
- 向用户展示摘要：范围、关键决策、任务数量、未变更行为以及任何未解决问题
- 继续前需等待明确确认 — 这是唯一的强制检查点
- 如果questions.md存在未解决问题，列出这些问题并要求用户在确认前解决
- 如果用户要求修改，应用修改后重新确认
实施 — 完成所有任务：
- 运行
```
node {{SKILL_DIR}}/scripts/spec-driven.js apply <name>
```
  查看任务摘要
- 检查questions.md中是否有未解决的
```
- [ ] Q:
```
  条目 — 如果有，询问用户并解决后再继续
- 按顺序处理每个
```
- [ ]
```
  任务：读取代码、实施、验证未变更行为、标记为
```
- [x]
```
- 对于
```
## 测试
```
  任务：实际运行测试并确认通过
- 运行
```
node {{SKILL_DIR}}/scripts/spec-driven.js apply <name>
```
  确认
```
remaining === 0
```
验证 — 检查完整性：
- 运行
```
node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>
```
- 然后执行剩余的
```
/spec-driven-verify
```
  检查：任务完成情况、未解决问题、实施证据和规范一致性
- 将脚本
```
errors
```
  以及这些检查中的任何CRITICAL（严重）发现视为阻塞项
- 如果有可以安全修复的阻塞项，自动修复后重新运行脚本检查和验证流程
- 如果有无法自动修复的阻塞项：停止并询问用户
- 重新读取增量规范文件并更新以匹配实际实现内容
评审 — 检查代码质量：
- 读取此变更修改的所有文件
- 检查：可读性、安全性、错误处理、性能、最佳实践、测试质量
- 必须修复的问题：自动修复后重新评审
- 如果必须修复的问题无法自动修复：停止并询问用户
- 应该修复的问题和细微问题：如果容易修复则修复，否则在最终报告中注明
归档 — 完成变更收尾：
- 归档前确认没有未完成的任务
- 列出
```
specs/
```
  中的所有增量文件，并将每个文件合并到对应的主规范文件中
- 如果
```
changes/<name>/specs/
```
  为空，在继续前询问用户确认此变更没有可观察的规范影响
- 如果创建了新的规范文件，更新
```
.spec-driven/specs/INDEX.md
```
- 运行
```
node {{SKILL_DIR}}/scripts/spec-driven.js archive <name>
```
- 报告最终结果：构建内容、修改的文件、通过的测试

Rules

规则

The complexity check in Step 1 is mandatory — never skip it
The user confirmation in Step 2 is mandatory — never skip it
Additional confirmations are required whenever the workflow is blocked by unresolved questions or an empty delta-spec archive decision
All other steps run automatically unless blocked by an unresolvable issue
Follow all config.yaml rules (specs, change, code, test) throughout
If anything goes wrong mid-flow, stop and explain — do not silently continue
Mark tasks complete one at a time, not in bulk

步骤1中的复杂度检查是强制的 — 绝不能跳过
步骤2中的用户确认是强制的 — 绝不能跳过
每当工作流被未解决的问题或空增量规范归档决策阻塞时，需要额外确认
除非遇到无法解决的问题，否则所有其他步骤自动运行
全程遵循config.yaml中的所有规则（规范、变更、代码、测试）
如果流程中途出现任何问题，停止并解释 — 不要静默继续
逐个标记任务完成，不要批量标记