sdd-yolo

用途

SDD: YOLO 全流程用于以最小打断方式端到端运行 SDD 工作流。整条流水线固定为：analyse → plan → implement → review → archive。全流程只有一个确认关口，位于规范与计划产出之后、实现开始之前，其余环节自动执行。

必需输入

开始前需收集以下输入；若缺失，应立即向用户索取，不得在缺少输入的情况下继续。

feature_description：需要端到端构建的功能，例如「Add JWT authentication with refresh token support」。

使用方式

第 0 步：校验输入（始终最先执行）

在对话中检查 feature_description 与 docs/project.md。

若 docs/project.md 不存在 → 停止，并提示用户先运行 /sdd-init。
若 feature_description 存在 → 进入 Phase 1。
若 feature_description 缺失 → 询问「What feature would you like to build?」，在用户提供前不得继续。

Phase 1 — Analyse

遵循完整的 sdd-feature 流程：

读取 docs/project.md。
分析请求：第 0 步收集到的 feature_description。
仅针对阻塞性问题追问澄清——即缺少该信息就无法写出正确规范的问题；跳过偏好性或锦上添花的问题；最多 3 个问题。
在项目根目录写出 feature.md，使用标准结构：

# Feature: <Feature Name>

## Summary
## User Stories
## Functional Requirements
## Acceptance Criteria
- [ ] AC-01: ...
## Technical Scope
## Non-Functional Requirements
## Out of Scope
## Open Questions

打印规范的紧凑摘要（3–5 个要点，而非完整文件）。

Phase 2 — Plan

紧接着 Phase 1 立即遵循完整的 sdd-plan 流程：

读取 feature.md 与 docs/project.md。
在项目根目录写出 plan.md，包含有序实现步骤、具体文件路径、清单项，以及 AC 到测试的映射表。
打印计划的紧凑摘要（仅步骤名称，不含完整细节）。

确认关口

呈现以下提示并等待用户回应后再继续：

## Ready to implement

Spec: feature.md ✓
Plan: plan.md ✓

[Compact spec summary — 3–5 bullets]
[Plan steps — numbered list of step names]

Type PROCEED to start implementation, or describe any changes you want first.

若用户输入 PROCEED（或等价确认）：继续进入 Phase 3。
若用户请求修改：将修改应用到 feature.md 和/或 plan.md，展示变更内容，然后重新呈现关口。
若用户中止：停止，并保留 feature.md 与 plan.md 以便手动继续。

Phase 3 — Implement

遵循完整的 sdd-implement 流程：

读取 plan.md、feature.md 与 docs/project.md。
按顺序执行 plan.md 中的每一步。
每层之后编译并运行测试。在继续之前修复失败——绝不把失败带入下一步。
未经向用户提示，不得引入新依赖。
所有步骤完成后，运行完整测试套件，并对照通过的测试验证每一条 AC。
打印完成摘要（创建/修改的文件、AC 通过/失败表）。

若实现后仍有 AC 失败，在此停止：报告失败内容，并要求用户先修复再继续。

Phase 4 — Review

紧接着 Phase 3 立即遵循完整的 sdd-review 流程：

运行 git diff main...HEAD --name-only 以确定变更文件。
在全部 8 个维度上评审（AC 覆盖、语言最佳实践、框架约定、安全、重复、设计、性能、测试质量、可观测性）。
产出完整的结构化评审报告。

Phase 5 — Archive or Stop

评估评审结论：

若结论为 ✅ Ready to merge 或 🟡 Merge after minor fixes

自动进入归档：

遵循完整的 sdd-archive 流程。
更新 docs/project.md（功能列表、架构决策、API 表面、环境配置）。
展示拟议的 project.md 变更，并在写入前请求确认。
将 feature.md 与 plan.md 移动到 docs/specs-archive/<feature-name>/。
创建 docs/specs-archive/<feature-name>/README.md。
然后打印最终流水线摘要：

## YOLO Pipeline Complete ✓

Feature: <Feature Name>
Archived to: docs/specs-archive/<feature-name>/

Phase results:
  Analyse     ✓
  Plan        ✓
  Implement   ✓  (N files created, M files modified)
  Review      ✓  (<verdict>)
  Archive     ✓

Next: commit docs/specs-archive/<feature-name>/ and docs/project.md to version control.

若结论为 🟠 Requires fixes and re-review 或 🔴 Do not merge

停止，不归档。打印：

## YOLO Pipeline Stopped — Review issues require attention

Feature: <Feature Name>

Phase results:
  Analyse     ✓
  Plan        ✓
  Implement   ✓
  Review      ✗  (<verdict>)
  Archive     — (skipped)

Critical/Major findings must be resolved before archiving.
Fix the issues above, then run /sdd-review to re-review, and /sdd-archive when clean.

将 feature.md 与 plan.md 留在项目根目录，便于用户手动继续。

适用场景

适用于已经运行过 /sdd-init、存在 docs/project.md 的项目，需要以最少人工干预完成从需求分析到归档的完整规范驱动开发流程。

限制

必须先存在 docs/project.md，否则需先运行 /sdd-init。
feature_description 为必需输入，缺失时无法开始。
澄清问题最多 3 个，仅限阻塞性问题。
引入新依赖须向用户提示。
评审结论为 🟠 或 🔴 时不会自动归档。
资料未提供该技能的安装方式、收费、价格与平台信息。