SDDワークフロー全体を統括するオーケストレーター。要求管理・タスク計画・実装・逆順レビューの一連のフローを管理する。複数フェーズにまたがるワークフロー管理、エラー・バグの体系的な分析と修正に使用する。
要求は requirement-management、設計はPR本文が既定の記録先であり、requirements-defining と software-designing は非推奨。Do NOT use for 個別フェーズのみの作業（requirement-management、task-planningを直接使用すること）。
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
ソフトウェア設計ドキュメント（SDD）の作成・管理・実装を統括するオーケストレータースキルです。
既定の記録先が変わりました。
対象 既定の記録先 旧サブスキル 要求・ユーザーストーリー・理由 requirement-management（docs/requirements/*.yaml）requirements-defining（非推奨） 設計 PR本文とGitHubコメント（永続化しない） software-designing（非推奨） 要求の整合性チェック reqctl.py validatesdd-document-management（非推奨） タスク GitHub Issue（ label:sdd:task）変更なし 非推奨サブスキルは、既存の
docs/sdd/を保守・参照する場合にのみ使用します。移行手順はsdd/requirement-management/references/migration_from_sdd_ja.mdを参照してください。
スキルが長時間応答しない問題を防止するため、以下のルールを厳守すること。
オーケストレーターは1つのサブスキル工程を完了するごとに、必ずユーザーに結果を報告して応答を返すこと。複数のサブスキルを連続実行してはならない。
禁止パターン（タイムアウトの原因）:
スキル呼び出し → requirements作成 → design作成 → tasks作成 → ... → 40分以上無応答
必須パターン:
スキル呼び出し → requirements作成 → ユーザーに報告・確認待ち
ユーザー承認 → design作成 → ユーザーに報告・確認待ち
ユーザー承認 → tasks作成 → ユーザーに報告・確認待ち
禁止: 19個のテンプレートと19個のリファレンスを一括読み込み
必須: 「今からrequirements/index.mdを作成する」→ その時点でindex用テンプレートのみ読み込む
各サブスキル実行中は、処理ステップをユーザーに出力して進捗を可視化すること。
出力例:
[requirement-management] ステップ 1/6: 入力要件を読み込み中...
[requirement-management] ステップ 2/6: 情報を分類中（明示/不明）...
[requirement-management] ステップ 3/6: 既存要求との衝突を確認中...
[requirement-management] ステップ 4/6: 要求とストーリーをYAMLに追記中...
[requirement-management] ステップ 5/6: validate で検査中...
[requirement-management] 完了: 要求5件を追加、エラー0件
ユーザーからの入力が長文の場合、情報分類を一括で行わず段階的に処理すること。
禁止: 長文入力を一度に全て分類（LLMへの単一リクエストが重くなりハングの原因）
必須: 段階的に分類
Phase 1: 必須情報のみ確認（プロジェクト名、目的、対象ユーザー）
Phase 2: 機能要件の整理
Phase 3: 非機能要件の整理
スキルが正常に動作しない場合（長時間応答なし、エラー等）の代替手段を明確にしておくこと。
フォールバック手順:
1. スキル実行を中断
2. テンプレートファイルを直接参照:
- requirements: requirement-management/assets/templates/
- tasks: task-planning/assets/templates/
3. Writeツールでテンプレートに基づきドキュメントを手動作成
4. 作成後にチェックリストで品質確認
スキルの代わりにテンプレートを直接使用する手動作成は、スキル経由と同等の品質を達成できる。実績として手動作成は約5分で完了する。
このスキルは、以下のサブスキルを連携させて、要求管理から実装・メンテナンスまでの全工程を管理します（先頭4件が現行、残り3件は非推奨）：
| サブスキル | 役割 | 成果物 |
|---|---|---|
| requirement-management | 要求・ストーリー・理由の管理と矛盾の機械検証 | docs/requirements/ |
| EARS記法による要件定義 | docs/sdd/requirements/（保守のみ） | |
| 技術アーキテクチャ設計 | docs/sdd/design/（保守のみ）。今後の設計はPR本文へ | |
| task-planning | AIエージェント向けタスク分解 | GitHub Issue（デフォルト） / docs/sdd/tasks/（オプション） |
| task-executing | タスク実行・逆順レビュー | 実装コード |
| sdd-troubleshooting | 問題分析・修正方針策定 | docs/sdd/troubleshooting/, GitHub Issue（修正タスク） |
| ドキュメント管理・メンテナンス | docs/sdd/archive/, docs/sdd/reports/（保守のみ） |
タスクの出力先（重要）: タスクはデフォルトでGitHub Issueとして起票する（1タスク＝1 Issue、詳細はIssue本文に集約、
label:sdd:taskで一覧＝目次）。ユーザーが「ファイルで管理」を明示した場合のみdocs/sdd/tasks/にファイル生成する。詳細はtask-planning/SKILL.mdを参照。
docs/sdd/
├── requirements/ # 要件定義
│ ├── index.md # 目次・概要
│ ├── stories/US-XXX.md # ユーザーストーリー詳細
│ └── nfr/*.md # 非機能要件
├── design/ # 設計
│ ├── index.md # 目次・アーキテクチャ概要
│ ├── components/*.md # コンポーネント詳細
│ ├── api/*.md # API設計詳細
│ ├── database/schema.md # データベーススキーマ
│ └── decisions/DEC-XXX.md # 技術的決定事項
├── tasks/ # タスク管理（ファイルモード＝オプション時のみ）
│ ├── index.md # 目次・進捗サマリ
│ └── phase-N/TASK-XXX.md # タスク詳細
│ # ※デフォルトはGitHub Issue起票（このディレクトリは作成しない）
├── troubleshooting/ # トラブルシューティング
│ └── [YYYY-MM-DD]-[issue-name]/
├── archive/ # アーカイブ（完了済み）
│ ├── tasks/ # 完了済みタスク
│ ├── decisions/ # 古い決定事項
│ └── troubleshooting/ # 完了した問題分析
└── reports/ # 管理レポート
├── consistency/ # 整合性チェックレポート
├── sync/ # 実装同期チェックレポート
├── archive/ # アーカイブレポート
└── optimize/ # 最適化レポート
以下の状況では、必ずsdd-troubleshootingサブスキルを使用してください：
重要: 修正コードを書く前に、必ず根本原因を分析してください。推測に基づく修正は禁止です。
特定の工程のみ実施する場合は、各サブスキルを直接使用：
requirement-managementtask-planningtask-executingsdd-troubleshootingdocs/sdd/ の保守のみ → 非推奨サブスキル（requirements-defining / software-designing / sdd-document-management）重要: 各ステップ完了後に必ずユーザーに結果を報告し、承認を得てから次のステップに進むこと。
1. 初期化 → docs/sdd/ディレクトリ構造を作成
↓ ★ ユーザーに報告 ★
2. requirement-management → docs/requirements/（要求・ストーリー・理由）
↓ ★ ユーザーに結果を提示・承認待ち ★（ここで応答を返す）
3. 設計はここでは作らない（実装時にPR本文へ記載する）
↓
4. task-planning → GitHub Issue起票（デフォルト） / docs/sdd/tasks/（オプション）
↓ ★ ユーザーに結果（起票Issue番号一覧）を提示・承認待ち ★（ここで応答を返す）
5. 実行モード判定: Jules API / Agent tool並列処理（タスク実行フェーズのみ）
↓
6. ドキュメント逆順レビュー
↓ ★ ユーザーに結果を提示・承認待ち ★（ここで応答を返す）
7. task-executing → 実装コード
↓ ★ ユーザーに結果を提示 ★（ここで応答を返す）
8. 実装逆順レビュー → 完了
各ステップの所要時間目安: 1ステップあたり3-10分。10分を超える場合は作業が肥大化している可能性があるため、スコープを見直すこと。
注意: 並列処理判定はタスク実行フェーズ（ステップ5）でのみ実施する。ドキュメント作成フェーズ（ステップ1-4）では判定不要。
判定条件:
isolation: worktree）で並列実行方式: Agent toolのisolation: worktreeを使用し、各サブエージェントが独立したgit worktreeで動作。並行作業中の上書き衝突を防止できるが、統合時にマージコンフリクトが発生し得るため必要に応じて手動解決する。
並列処理パターンと呼び出し例: references/agent_teams_guide_ja.md
Jules API（JULES_API_KEY）が利用可能な場合のモード判定とアサイン戦略の詳細は task-executing/references/jules_integration_ja.md を参照。
エラーやバグに遭遇したら、このフローに従ってください。修正コードを先に書くことは禁止です。
エラー/バグ発生
↓
┌─────────────────────────────────────────────────┐
│ ⚠️ 禁止: 推測で修正、原因不明のまま修正 │
└─────────────────────────────────────────────────┘
↓
1. 問題事象の確認（エラーメッセージ、再現手順、期待動作）
↓
2. 根本原因の分析（コードを追跡して原因を特定）
↓
3. 仕様との照合（docs/sdd/requirements/, docs/sdd/design/）
↓
4. 修正方針の策定（どう直すか、影響範囲は）
↓
5. ★ ユーザー承認 ★（必須ゲート - 承認なしで実装禁止）
↓
6. タスク分割 → GitHub Issue起票（ラベル `sdd:task` + `sdd:bugfix`）※デフォルト
↓
7. task-executing → 修正実装
「docsディレクトリを初期化してください」と依頼されたら：
requirement-management の初期化手順に従い、glossary.yaml と <ドメイン>.yaml を作成するtasks/ は作成しない。ファイルモード（オプション）指定時のみ tasks/index.md を作成 - テンプレート: task-planning/assets/templates/tasks_index_template_ja.mddocs/sdd/tasks/ → docs/sdd/design/ → docs/sdd/requirements/
詳細なチェック項目は references/checklist_ja.md を参照。
詳細は requirements-defining/references/ears_notation_ja.md を参照（同スキルは非推奨だが、EARS記法のリファレンスとしては引き続き有効）。
複数フェーズを自律的に実行する場合は、orchestrating-agents スキルの3階層エージェント構造を活用する。
自律実行モード開始前に以下を分類する:
不明情報がある場合は、実行を開始せずユーザーに確認してから進行する。
詳細: orchestrating-agents/SKILL.md
| サブスキル | 階層モード | 理由 |
|---|---|---|
| requirement-management | 2階層 | 単一作業、並列化不要 |
| task-planning | 2階層 | 同上 |
| task-executing | 3階層 | 複数タスクの並列実行が可能 |
| sdd-troubleshooting | 条件分岐 | 仮説3つ以上なら3階層 |
| sdd-document-management | 3階層 | フルスキャン時に5機能を並列実行 |
条件を満たす場合は積極的に使用する。 判定基準・パターン・呼び出し例は references/agent_teams_guide_ja.md を参照。
docs/sdd/tasks/のタスクとTodoWriteの同期ルール。詳細は references/task_sync_guide_ja.md を参照。
references/workflow_guide_ja.mdreferences/checklist_ja.mdreferences/agent_teams_guide_ja.mdreferences/task_sync_guide_ja.mdrequirement-management/SKILL.mdtask-planning/SKILL.mdtask-executing/SKILL.mdsdd-troubleshooting/SKILL.mdrequirement-management/references/migration_from_sdd_ja.md非推奨（既存 docs/sdd/ の保守時のみ）:
requirements-defining/SKILL.md / software-designing/SKILL.md / sdd-document-management/SKILL.mdNo reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
指定されたPRを6観点（セキュリティ、ドキュメント乖離、可読性、ライブラリ選定、PR説明、既知脆弱性）でレビューし、人間向け・AI向けの2形式でPRにコメントする。初回レビューおよび修正後の再レビューに使用する。Do NOT use for レビューコメントへの修正適用（pr-comment-fixerを使用すること）。
The English summary is being prepared. Showing the original description.
キャリア設計のためのデプスインタビューを実施し、本人の価値観・強み・動機を引き出す。5 Whys、ラダリング法を用いてキャリアビジョンの明確化を支援する。転職相談、自己理解、キャリアカウンセリング、1on1面談の深掘りに使用する。Do NOT use for 製品・サービスのユーザーリサーチ（depth-interviewing-productを使用すること）。
The English summary is being prepared. Showing the original description.
サービス開発のためのデプスインタビューを実施し、ユーザーの真のニーズ・課題・動機を引き出す。5 Whys、ラダリング法を用いてプロダクト開発に活かせるインサイトを発見する。ユーザーリサーチ、課題発見、ペルソナ構築、プロダクト仮説検証に使用する。Do NOT use for キャリア相談やキャリアカウンセリング（depth-interviewing-careerを使用すること）。
The English summary is being prepared. Showing the original description.
インフラメトリクスの定期調査を体系的に実施し、サービスの健全性を評価する。2層アプローチで11カテゴリのメトリクスを確認し、構造化レポートを作成する。定期的なサービス監視、障害予兆の検出、パフォーマンス評価に使用する。Do NOT use for 個別インシデントの根本原因分析（incident-rcaを使用すること）。
The English summary is being prepared. Showing the original description.
インシデント調査で根本原因を特定するためのなぜなぜ分析ファシリテーター。推測を避け、ユーザーの発言を記録し、マインドツリーで全体を可視化する。障害発生後の原因究明、ポストモーテム、再発防止策の策定に使用する。Do NOT use for 定期的なサービス健全性チェック（health-checkを使用すること）。
The English summary is being prepared. Showing the original description.
IPA非機能要求グレード2018（可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境）の記入済み要件を入力として、運用設計書を生成する。非機能要件定義が完了しているプロジェクトの運用設計フェーズで使用する。Do NOT use for 非機能要件の定義自体（requirement-managementを使用すること）。Do NOT use for 業界調査やヒアリングから始める運用設計（operations-designを使用すること）。
The English summary is being prepared. Showing the original description.