sdd-yolo

SDD: YOLO フルパイプライン

最小限の中断で、SDD ワークフロー全体をエンドツーエンドで実行します。 パイプラインは次のとおりです: 分析 → 計画 → 実装 → レビュー → アーカイブ。

確認ゲートは正確に 1 つ だけです: 仕様と計画が作成された後、 実装が始まる前です。それ以外はすべて自動的に実行されます。

必須入力

開始する前に、これらの入力を収集してください。不足しているものがある場合は、今すぐ確認してください — それらなしで進めないでください。

入力	説明	例
feature_description	エンドツーエンドで構築する機能	「リフレッシュトークン対応の JWT 認証を追加する」

手順

ステップ 0: 入力を検証する (常に最初にこれを行います)

会話内で feature_description と docs/project.md を確認してください。

• docs/project.md が存在しない場合 → 停止し、まず /sdd-init を実行するようユーザーに伝えてください。
• feature_description が存在する場合 → フェーズ 1 に進んでください。
• feature_description が存在しない場合 → 「どのような機能を構築しますか?」と尋ねてください。ユーザーが回答するまで進めないでください。

---

フェーズ 1 — 分析

完全な sdd-feature プロセスに従ってください:

1. docs/project.md を読んでください。
2. リクエストを分析してください: feature_description (ステップ 0 で収集)。
3. ブロッカーにのみ 明確化の質問をしてください — それなしでは正しい仕様を書けない情報です。 好みやあれば嬉しい程度の事項についての質問は省略してください。質問は最大 3 つまでです。
4. 標準構造を使用して、プロジェクトルートに feature.md を書いてください:

# Feature: <Feature Name>

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

5. 仕様の簡潔な要約 (完全なファイルではなく、3〜5 個の箇条書き) を出力してください。

---

フェーズ 2 — 計画

フェーズ 1 の直後に、完全な sdd-plan プロセスに従ってください:

1. feature.md と docs/project.md を読んでください。
2. 順序立てた実装ステップ、具体的なファイルパス、 チェックリスト項目、AC とテストのマッピング表を含む plan.md をプロジェクトルートに書いてください。
3. 計画の簡潔な要約 (詳細全体ではなく、ステップ名のみ) を出力してください。

---

確認ゲート

次のプロンプトを提示し、続行する前に ユーザーの応答を待ってください:

## 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 (または同等の確認) と入力した場合: フェーズ 3 に進んでください。
• ユーザーが変更を要求した場合: feature.md または plan.md (あるいはその両方) に適用し、変更内容を示したうえで、ゲートを再度提示してください。
• ユーザーが中止した場合: 停止し、手動で続行できるように feature.md と plan.md をそのまま残してください。

---

フェーズ 3 — 実装

完全な sdd-implement プロセスに従ってください:

1. plan.md、feature.md、docs/project.md を読んでください。
2. plan.md の各ステップを順番に実行してください。
3. 各レイヤーの後にコンパイルとテストを実行してください。先に進む前に失敗を修正してください — 失敗を先に持ち越さないでください。
4. ユーザーに通知せずに新しい依存関係を導入しないでください。
5. すべてのステップの後、テストスイート全体を実行し、すべての AC を合格したテストに対して検証してください。
6. 完了サマリー (作成/変更したファイル、AC 合否表) を出力してください。

実装後にいずれかの AC が失敗している場合、ここで停止してください。何が失敗したかを報告し、続行する前にユーザーに修正を依頼してください。

---

フェーズ 4 — レビュー

フェーズ 3 の直後に、完全な sdd-review プロセスに従ってください:

1. git diff main...HEAD --name-only を実行して、変更されたファイルを特定してください。
2. 8 つの次元すべてにわたってレビューしてください (AC カバレッジ、言語のベストプラクティス、フレームワークの規約、 セキュリティ、重複、設計、パフォーマンス、テスト品質、可観測性)。
3. 完全な構造化レビューレポートを作成してください。

---

フェーズ 5 — アーカイブまたは停止

レビューの判定を評価してください:

判定が ✅ マージ可能 または 🟡 軽微な修正後にマージ の場合

自動的にアーカイブに進みます：

1. sdd-archive プロセス全体に従います。
2. docs/project.md を更新します（機能一覧、アーキテクチャ上の決定、API サーフェス、環境設定）。
3. 提案する project.md の変更内容を表示し、書き込む前に確認を求めます。
4. feature.md と plan.md を docs/specs-archive/<feature-name>/ に移動します。
5. 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.

判定が 🟠 修正と再レビューが必要 または 🔴 マージしない の場合

停止します。アーカイブしないでください。

出力します：

## 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 はプロジェクトのルートに残しておきます。