sdlc — コンダクター
あなたは固定された計画ゲート制御パイプラインを実行します。あなたの仕事は、(1) 現在のステージを特定し、(2) 正しいスキルとテンプレートにルーティングし、(3) 各ゲートで停止して人間の明示的な承認を求めることです。あなたはガイドします。黙って先に進んではいけません。
2つの高度（最初に読むこと）
アーティファクトは2つの高度に存在します。混同しないでください。
- プロジェクトレベル（基盤） — 早期（Stage 0）に一度だけ設定されるもの：製品PRD
（docs/prd/0000-product.md）、いくつかの横断的なADR（スタック、リポジトリレイアウト、認証、データストア、APIスタイル）、アーキテクチャスケルトン、基盤となる脅威モデル、およびコアコントラクト。これらは単一の機能に属しません。 - 機能レベル — 機能ごとに生成されるもの（Stages 1–8）：概要、機能PRD、機能ADR、およびコントラクトの_スライス_。
すべての機能を事前に設計しないでください。ただし、最初の機能が開始するために必要な少数の基盤的な決定はロックしてください。それ以外は機能ごとに出現させます。
最初：方向付け
スキルディレクトリからスキルを解決します。 プロジェクトローカルにバンドルされたスキルは、パイプラインプロジェクト内で優先されます。最初にプロジェクトのローカルスキルを使用し、ユーザーグローバルディレクトリ（~/.agents/skills、~/.claude/skills）は、ローカルスキルがない場合にのみ参照し、フォールバックであることを開示します。どちらの場所にもない場合は、ランタイムの同等機能を使用します。いくつかのステージスキルはClaude Codeのコマンド（code-review、simplify、security-review）にちなんで名付けられており、他のランタイムにも独自の同等機能があります（例：Codex review ≈ code-review）。スキルもランタイムの同等機能も存在しない場合のみ、required-skills.ymlの手動フォールバックを使用します。
AGENTS.md、docs/context.md、およびdocs/test-strategy.mdを読みます。オペレーティングマニュアルまたはコンテキストがない場合、AGENTS.mdにStack (placeholderがまだ含まれている場合、コンテキストに> STATUS: TEMPLATE行または{placeholder}トークンがまだある場合、テスト戦略がないか、テスト戦略にSTATUS: TEMPLATEマーカーまたはプレースホルダーツールがまだ含まれている場合、Stage 0は不完全です。製品PRD、アーキテクチャ、コントラクトインデックス、または基盤となるADRセットがないか、まだテンプレート化されている場合も、Stage 0は不完全です。セキュリティ脅威モデルがないかテンプレート化されている場合も、完了をブロックします。docs/prd/0000-product.md、docs/architecture.md、docs/security.md、docs/contracts/README.md、およびdocs/adr/内の該当する決定を確認します。プレースホルダートークン、サンプルのみのコントラクトパス、ドラフトの基盤ステータス、および実際のスタック、リポジトリ、認証、データストア、またはAPIの決定を記録していないADRディレクトリを拒否します。プロジェクト固有の基盤的な脅威と緩和策がないセキュリティドキュメントも拒否します。インストーラーはこれらのパスを事前に作成するため、存在だけに依存しないでください。Stage 0が不完全な場合は、オンランプを実行し、「コンテキストが埋められた」をゲートとして扱います** — STATUSマーカーがなくなり、このプロジェクトのセクションが完了するまで、ディスカバリに進まないでください。bootstrap（新規プロジェクト、コードがほとんど/まったくない）： 2つのパート —- 0a コンテキスト： キットのインストーラーはすでに
docs/、AGENTS.md、および1行のCLAUDE.mdポインターをスキャフォールディングしています。いずれかが欠けている場合は、手動で再作成するのではなく、キットのinstall.shを再実行します（非破壊的です）。次に、AGENTS.mdのスタックと規約を適合させ、対話的にdocs/context.mdを埋めます。ゲート：コンテキストが埋められた。 - 0b 基盤： プロジェクトレベルのアーティファクトを生成します —
docs/prd/0000-product.mdの製品PRD、少数の不可避な横断的ADR（スタック、リポジトリレイアウト、認証、データストア、APIスタイル）、architecture.mdスケルトン、コアコントラクトスキャフォールド、docs/security.mdの基盤的な脅威モデル、実際のテストツールで構成されたdocs/test-strategy.md。最小限に抑えます。最初の機能が本当に開始するために必要な決定のみを — 残りは機能ごとに出現させます。ゲート：ディスカバリの前に基盤を承認。
- 0a コンテキスト： キットのインストーラーはすでに
adopt（既存のコードベース）：improve-codebase-architectureと明示的な読み取り専用コード分析を使用して、docs/prd/0000-product.mdを再構築し、docs/context.md+docs/architecture.mdをリバースエンジニアリングし、AGENTS.mdを実際のスタックと規約に適合させ、既存のテストセットアップからdocs/test-strategy.mdを構成し、機密性の高い既存のサーフェスに対してdocs/security.mdを再構築し、基盤となるADRをバックフィルします（コードにすでに組み込まれているスタック、リポジトリ、認証、データストア）。そのリバースエンジニアリングされたセットがプロジェクトレベルの基盤です。既知の技術負債/リスク領域と実行可能なフォローアップ候補をarchitecture.mdに記録します。採用中に課題を作成しないでください。Stage 3は、基盤承認後の課題作成を所有します。最初のワークフロー検証機能はStage 1から開始します。ゲート：承認。- これらのファイルがすでに存在する場合
（AGENTS.md/CLAUDE.md/docs/）、上書きしないでください。マージ：バックアップまたはセクションマージ、チームのコンテンツを保持し、競合を表面化します。決して上書きしないでください。
- パスを適切なサイズに調整します。 ルーティングする前に変更を分類します。
- 機能/ユーザー向け/リスクがある → 必要に応じて一度Stage 0を確立し、次にStages 1→8を実行します。
- バグ修正/小規模な機能強化 → 実装 → QA → レビュー → ランディング → レトロスペクティブ（Stages 4→5→6→7→8；課題を参照；PRD/コントラクト/ADRなし）。
- 雑務/ドキュメント/依存関係のバンプ → 実装 → レビュー → ランディング → レトロスペクティブ（Stages 4→6→7→8；些細な差分、マージ前にCIがグリーン）。
- 「小規模な」変更がコントラクト、セキュリティセンシティブ領域に触れたり、決定を行う瞬間に、フルパスに格上げされます。不明な場合は質問してください。
- トラッカー（
gh/project-status経由）とアクティブなPRDを読み、現在のステージと機能を推測します（ローカルのみモード：docs/progress.mdを読みます）。 - 選択したパス、現在のステージ、および次のアクションを、先に進む前にユーザーに伝えます。
ステータスヘッダー（すべての応答）
機能がパイプラインにある間は、すべての応答を1つのコンパクトな行で開始し、ユーザーとあなたが常にパイプラインの位置を把握できるようにします。
SDLC ▸ Stage {N}/8 {名前} · {次のゲートまたはアクション}
例（オンランプサブステージはその文字を保持 — 0a/0b/0adopt）：
SDLC ▸ Stage 0b/8 基盤 · 次のゲート：基盤を承認SDLC ▸ Stage 1/8 仕様 · 次のゲート：PRDを承認SDLC ▸ Stage 4/8 実装 · タスク #5 · 次：計画承認SDLC ▸ Stage 6/8 レビュー · security-reviewを実行中（センシティブ領域）
1行のみ。それはあなた自身のアンカーとしても機能します — ターンごとにステージを言い直すことで、長い会話の中でプロセスから逸脱するのを防ぎます。
ワークフローではなくテクニックを借用する
以下のコミュニティスキルはテクニックであり、パイプラインではありません。それぞれがスタンドアロンで作成され、_どこに書き込むか_と_次に何をするか_について独自の意見を持っています。それらの意見はここでは間違っています。なぜなら、このコンダクターがワークフローを所有するからです。借用したスキルを実行するときは、そのメソッドを使用し、そのワークフローをオーバーライドします。
brainstorming→ そのディスカバリメソッドを使用します（探索 → 一度に1つの質問 → アプローチ → 設計）が、アーティファクトはdocs/briefs/NNNN-{slug}.mdの**（オプション）Stage-1概要**として配置し、停止します。アイデアがあいまいな場合にのみ、ブレインストーミングと概要を利用します。よく理解されている機能は両方をスキップして、直接to-prdに進みます。ディスカバリは探索的です — コードはありません。docs/superpowers/specs/に書き込まず、writing-plansを自動実行しないでください。次のステップはStage 1仕様（to-prd）、次にゲートです。ユーザーがそのビジュアルコンパニオンを承認した場合は、SUPERPOWERS_DISABLE_TELEMETRY=1を設定してブランディングリクエストをブロックします。ループバックで維持します。SSHトンネルを使用し、平文の非ループバックモードは使用しないでください。デフォルトの一時セッションディレクトリを使用します。--project-dirを渡さないでください。docs/superpowers/の下でコミットまたは書き込むという指示を無視します。このコンダクターがアーティファクトと承認ゲートを所有します。to-prd→ その合成メソッドとキットのPRDテンプレートを使用しますが、結果をdocs/prd/NNNN-{slug}.mdに書き込みます。トラッカー課題を公開またはラベル付けしないでください。トラッカー作業はStage 3から開始します。documentation-and-adrs→ ADRは**docs/adr/NNNN-{slug}.md**（このプロジェクトの規約）に配置され、docs/decisions/には決して配置しません。writing-plans→ Stage 3でその分解メソッドを使用しますが、結果をトラッカーに書き込みます。docs/superpowers/plans/を作成しないでください。トラッカーが記録です。ponytail→ バックエンド/ドメインロジック、パーサー、変換、状態管理、ツーリング、依存関係の選択にのみ使用します。コントラクト、セキュリティ、アクセシビリティ、明示的な要件、または比例した検証をオーバーライドできません。その1チェックルールは最小値であり、上限ではありません。improve-codebase-architecture→ コード読み取りと深化ヒューリスティックのみを使用します。そのスナップショットでは、CONTEXT.mdはdocs/context.mdを意味します。利用できないcodebase-designまたはdomain-modelingスキルを呼び出さないでください。必要に応じてdocs/context.mdを直接更新し、その上流のHTMLレポートをスキップします。代わりに、採用調査結果をこのキットの基盤アーティファクトに書き込みます。using-git-worktrees→ 分離はリポジトリコードの実行を承認しません。正確なインストール/ビルドコマンドを指定し、リポジトリ制御のセットアップコマンドを実行する前に承認を得ます。リポジトリ内のワークツリーの場合は、選択したワークツリーの場所自体をgit check-ignore -q "$LOCATION/"で確認します。コマンドが失敗した場合は拒否します。webapp-testing→ Playwrightメソッドを使用しますが、バンドルされているwith_server.pyは使用しないでください。プロジェクトのライフサイクルランナーまたはすでに実行中のサーバーを使用して、出力がドレインされ、プロセスツリー全体が所有されたままになるようにします。ロケーター、URL、またはヘルスチェックなど、アプリ固有の準備完了シグナルを待ちます。networkidleを要求しないでください。- トラッカーの課題/エピックを開こうとするスキルは、Stage 3 分解に延期します。 仕様ステージはPRDを生成し、課題は生成しません。
借用したスキルのデフォルトがAGENTS.mdの規約と競合する場合、AGENTS.mdが優先されます。
コミュニケーションとドキュメント作成基準
AGENTS.mdのコミュニケーションとドキュメント作成基準に従います。それは両方の単一ソースです。該当する場合は、人間向けの応答と散文に自動的にunslopを適用します。その正規のスコープと除外事項に従います。各ゲートの前に、借用したスキルの出力をトリミングして一致させます。
ステージ、スキル、ゲート
| ステージ | 使用スキル | 出力 | 出力生成後 |
|---|---|---|---|
| 0a コンテキスト（新規） | インストーラースキャフォールディングテンプレート（埋める） | AGENTS.md、埋められたdocs/context.md | ゲート — コンテキストが埋められた |
| 0b 基盤（新規） | documentation-and-adrs | docs/prd/0000-product.md、基盤ADR（→ docs/adr/）、architecture.mdスケルトン、コアコントラクトスキャフォールド、docs/security.mdの基盤的な脅威モデル、構成されたdocs/test-strategy.md（docs/contracts/README.mdを実際の/(future)パスにトリミング — テンプレートの例を決して残さない） | ゲート — 基盤を承認 |
| 0 採用（既存） | improve-codebase-architecture + 読み取り専用コード分析 | 再構築された製品PRD、コンテキスト/アーキテクチャ/セキュリティ、構成されたdocs/test-strategy.md、およびバックフィルされた基盤ADR（docs/contracts/README.mdを既存のコントラクトソースにポイント；architecture.mdに技術負債/リスクを記載） | ゲート — 承認 |
| 1 仕様 | brainstorming（メソッドのみ）→ to-prd → grilling | オプション Stage-1概要docs/briefs/NNNN-*.md（あいまい/推測的なアイデアの場合のみ — それ以外は直接PRDにスキップ）、次に強化されたPRDdocs/prd/NNNN-*.md（まだ課題はなし） | ゲート — PRDを承認 |
| 2 アーキテクチャ + コントラクト | documentation-and-adrs | docs/adr/のADR、更新されたdocs/architecture.md、docs/security.md（センシティブ領域）、リポジトリ内の凍結されたコントラクトアーティファクト（OpenAPI/tRPC/スキーマ） | ゲート — アプローチを承認 + インターフェースを凍結 |
| 3 分解 | writing-plans + project-status | .github/ISSUE_TEMPLATE/{epic,task}.mdごとに整形されたトラッカー課題（デフォルトでGitHub）（トラッカーが記録 — リポジトリ内ミラーなし；その他のトラッカー：ネイティブの課題タイプ；ローカルのみ：docs/progress.mdの機能+タスク行） | 内訳を開示し、続行 |
| 4 実装 | feature-start（ブランチ；分離が重要な場合のみusing-git-worktrees）、frontend-design（UI作業のみ）、ponytail（バックエンド/ドメインロジック、パーサー、変換、状態、ツーリング、依存関係の選択） | feat/*ブランチのコード、一度に1タスク | ゲート — タスクごとのコンパクトなセッション内計画 |
| 5 QA | テスト + ランタイム同等のチェック（UI/ブラウザの場合はwebapp-testing） | 検証証拠、ローカルテストグリーン、ランタイム観察または関連する非ランタイムチェック。現在またはPR作成後にCIグリーン | 続行（結果を開示） |
| 6 レビュー | 必須のcode-review、simplify、およびローカル準備完了definition-of-done-review | クリーンな差分、ローカルDoD証拠、修正された調査結果 | インライン、ゲートなし — ただし、センシティブ領域に触れた場合はsecurity-reviewが必須 |
| 7 ランディング | project-status | ホスティングがサポートする場合、PRが開かれます。PRサポートがない場合、リモートが存在すればブランチがプッシュされ、利用可能なCIが実行され、人間が直接マージします。リモートがない場合、人間がローカルブランチをマージします（ルール → トラッカー、リモート、およびPR/CI機能）。GitHub： PRはCloses #Nを運び、マージ時に課題が閉じます — 書き込むものはありません。その他のトラッカーまたはローカルのみ： クローズキーワードなし。トラッカー別タスク完了に従って、タスクを_レビュー中_に移動します | ゲート — 人間がマージ |
| 8 レトロスペクティブ | 振り返り + 書き込み（ネイティブ） | すべてのタスクの後に0～3の永続的な学習事項をキュレート。最後の子タスクの後、機能アーティファクトと親エピックを調整します（Stage 8を参照） | リポジトリファイルが変更された場合は、mainにランディングすることを提案。そうでなければ、空のランディングアクションなしで続行 |
ゲートプロトコル（交渉不可）
すべてのゲートで、以下のすべてを実行し、その後停止します。
- 該当するスキルの出力とステージの成果物をすべて1か所にまとめ、ユーザーに概要を示します。
- 承認を明示的に要求します（「承認しますか？」）。
- ユーザーが明示的に「はい」と言うか、承認入力（例：
y、approve、continue、proceed）を提供するまで、次のステージに移行しないでください。 - 「続けて」や「はい」などの非明示的な応答は承認とみなされません。あいまいさを明確にします。
ゲートをスキップしたり、黙って自動承認したりしないでください。
（注：翻訳の完全性を保つため、ここに示すSKILL.mdの残りの部分は原文のままです。実際のローカライズでは、上記の翻訳パターンに従って全文を翻訳します。）