設計書から実装タスクへの分解を行う。デフォルトで各タスクをGitHub Issueとして起票し（1タスク＝1 Issue、詳細はIssue本文に集約、ラベルでフェーズ・ステータス管理）、ユーザーがファイル管理を明示した場合のみdocs/sdd/tasks/にファイル生成する。AIエージェント向けの具体的な実装指示やTDD手順を定義する。
タスク計画フェーズのみを単独で実行する際に使用する。Do NOT use for SDDワークフロー全体の管理（sdd-documentationを使用すること）。
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
設計書を基に、AIエージェント（Claude Code等）が実行可能な具体的なタスクに分解します。
このスキルは、タスクを デフォルトで GitHub Issue として起票 します。1タスク = 1 Issue とし、 受入基準・TDD手順・技術仕様などの詳細はすべて Issue 本文に集約します。
| モード | 出力先 | 使う場面 |
|---|---|---|
| Issue起票（デフォルト） | GitHub Issue（github MCPツール） | 指定がない場合は常にこちら |
| ファイル生成（オプション） | docs/sdd/tasks/[phase]/TASK-XXX.md | ユーザーが「ファイルで」と明示した場合のみ |
mcp__github__* を用いてIssue起票する（MCPの有無で出力先を変えない。ラベルが未作成なら作成する）。このスキルは、以下を作成・管理します：
[TASK-XXX] タイトル、本文にタスク詳細を集約sdd:task（識別）、sdd:phase-N（フェーズ）、sdd:status/*（ステータス）docs/sdd/tasks/index.md は作成しない。label:sdd:task でフィルタしたGitHub Issue一覧が目次代わりGitHub Issues（label:sdd:task でフィルタ = タスク一覧＝目次）
├── #12 [TASK-001] ユーザー認証API [sdd:phase-1][sdd:status/todo]
├── #13 [TASK-002] データモデル定義 [sdd:phase-1][sdd:status/todo]
├── #14 [TASK-003] API統合テスト [sdd:phase-2][sdd:status/todo] (依存: #12,#13)
└── ...
[TASK-XXX] タスクタイトル（TASK-XXXは設計・要件ドキュメントとの相互参照用に維持）assets/templates/task_issue_template_ja.md のフォーマットに従うsdd:status/{todo|in-progress|review|blocked}。DONEはIssueをclose（state_reason: completed）依存: #12）sdd:group-A または本文に明記| 操作 | ツール | 補足 |
|---|---|---|
| Issue作成 | mcp__github__issue_write（method: create） | title/body/labels を指定 |
| Issue更新（ステータス・close） | mcp__github__issue_write（method: update） | labels付け替え、state: closed |
| タスク一覧取得 | mcp__github__list_issues / mcp__github__search_issues | labels: ["sdd:task"] |
| 重複確認 | mcp__github__search_issues | 起票前に既存タスクを確認 |
注: 起票前に
mcp__github__get_meで権限・対象リポジトリを確認する。ラベルが未作成の場合は初回起票前に作成する（テンプレートの「ラベル体系」を参照）。
ユーザーが「ファイルで管理したい」と明示した場合のみ、従来のファイル構成を使用する：
docs/sdd/tasks/
├── index.md # 目次・進捗サマリ
├── phase-1/
│ ├── TASK-001.md # タスク詳細
│ └── TASK-002.md
├── phase-2/
│ ├── TASK-003.md
│ └── TASK-004.md
└── phase-3/
└── TASK-005.md
docs/requirements/（requirement-management）が存在する場合:
docs/requirements/generated/traceability.md を読み込み、対象の要求IDとユーザーストーリーを特定する設計書は読み込まない。設計は実装時にPR本文へ記載するため、タスク計画時点では存在しない。
docs/sdd/requirements/、docs/sdd/design/しか存在しない場合（旧構成）:
requirements-defining / software-designing は非推奨。移行が済むまでは旧ドキュメントを読み込んでよいが、移行手順（requirement-management/references/migration_from_sdd_ja.md）の実施を検討する。
| 分類 | 作業時間 | 内容例 |
|---|---|---|
| シンプル | 10-20分 | 単一ファイル作成、基本関数実装、設定追加 |
| 標準 | 20-40分 | 複数ファイル、APIエンドポイント、基本テスト |
| 複雑 | 40-90分 | 複数コンポーネント統合、包括的テスト |
| 要分解 | 90分以上 | さらに小さいタスクに分解 |
#### タスク1.1: [タスクタイトル]
**説明**:
- 対象ファイルパス: `src/components/Button.tsx`
- 実装する機能の詳細
- 使用する技術・ライブラリ
**技術的文脈**:
- フレームワーク: Next.js 14 (App Router)
- スタイリング: Tailwind CSS
- 参照すべき既存コード: `src/components/Card.tsx`
**情報の明確性**:
| 分類 | 内容 |
|------|------|
| 明示された情報 | [ユーザーから明確に指定された仕様] |
| 不明/要確認の情報 | [推測が必要な項目] |
**実装手順（TDD）**:
1. テスト作成: `src/components/Button.test.tsx`
2. テスト実行: 失敗を確認
3. テストコミット
4. 実装: テストを通過させる
5. 実装コミット
**受入基準**:
- [ ] `src/components/Button.tsx`が存在する
- [ ] TypeScriptの型定義が含まれている
- [ ] テストが3つ以上ある
- [ ] `npm test`で全テスト通過
- [ ] ESLintエラーがゼロ
**依存関係**: なし
**推定工数**: 30分（AIエージェント作業時間）
**ステータス**: `TODO`
各タスクにTDD手順（テスト作成 → 失敗確認 → テストコミット → 実装 → 通過確認 → 実装コミット）を記載する。具体的なテストファイルパスとテストケースを明記すること。
docs/requirements/generated/traceability.md を読み込み、実装対象の要求IDとストーリーを特定する（旧構成の場合は docs/sdd/requirements/）mcp__github__get_me で対象リポジトリ・権限を確認。ラベル（sdd:task等）が未作成なら作成assets/templates/task_issue_template_ja.md に従って本文を構築mcp__github__search_issues で既存タスクを確認mcp__github__issue_write（method: create）で各タスクをIssue化。タイトル [TASK-XXX] タイトル、ラベル sdd:task / sdd:phase-N / sdd:status/todo を付与依存: #12）を記載。必要に応じてラベル sdd:group-Xsdd-documentation/references/task_sync_guide_ja.md 参照）注: 目次（index.md）は作成しない。タスク一覧は
label:sdd:taskのGitHub Issue検索で参照する。
task_issue_template_ja.md に従い、情報の明確性・受入基準・TDD手順を記述mcp__github__search_issues で既存タスクを確認mcp__github__issue_write（method: create）でラベル付きIssueを作成ユーザーが「ファイルで管理」を明示した場合のみ、従来フローを使用する：
docs/sdd/tasks/ 以下にフェーズ別ディレクトリを作成assets/templates/tasks_index_template_ja.md）[phase]/TASK-XXX.md として作成（assets/templates/task_detail_template_ja.md）タスク → 要求の整合性を確認する（各タスクが要求IDに対応し、対象ストーリーの受入要求が漏れなく覆われているか）。詳細チェック項目は sdd-documentation/references/checklist_ja.md を参照。不整合発見時はリストアップしてユーザーに確認してから修正する。
タスク計画完了時にTodoWriteへ同期する。ステータスマッピングと運用ルールは sdd-documentation/references/task_sync_guide_ja.md を参照。
**タスク計画時は常にエージェントチームでの並列実行を前提として設計する。**並列実行可能なタスクが3つ以上になるようタスクを分割・構成することを目指す。
注意: 並列化のためだけにタスクを過剰に分割しないこと。各タスクの粒度（20-40分目安）を維持することを優先し、自然に3つ以上に分かれない場合は順次実行で問題ない。
sdd:group-A を付与し、各Issue本文の「依存関係」にグループと依存Issue番号を記載Issueモード（デフォルト）: 各Issueにラベル sdd:group-X を付け、本文に依存を明記。
<!-- #12 [TASK-001] の本文「依存関係」 -->
- 並列実行: グループA（#13, #14 と並行実行可能）
- 前提Issue: なし
ファイルモード（オプション）: index.mdに並列実行グループ表を記載。
## 並列実行グループ
### グループA（並列実行可能）
| タスク | 対象ファイル | 依存 |
|--------|-------------|------|
| TASK-001 | src/auth/** | なし |
| TASK-002 | src/api/** | なし |
| TASK-003 | src/models/** | なし |
### グループB（グループA完了後に並列実行可能）
| タスク | 対象ファイル | 依存 |
|--------|-------------|------|
| TASK-004 | src/services/auth-service.ts | TASK-001 |
| TASK-005 | src/services/api-service.ts | TASK-002 |
詳細: sdd-documentation/references/agent_teams_guide_ja.md
各タスクに以下が含まれているか確認：
技術仕様:
実装詳細:
テスト仕様:
assets/templates/task_issue_template_ja.mdassets/templates/tasks_index_template_ja.mdassets/templates/task_detail_template_ja.mdreferences/task_guidelines_ja.mdIssueモード（デフォルト）:
| 種別 | 命名規則 | 例 |
|---|---|---|
| Issueタイトル | [TASK-XXX] タイトル | [TASK-001] ユーザー認証API |
| フェーズラベル | sdd:phase-N | sdd:phase-1 |
| ステータスラベル | sdd:status/{todo|in-progress|review|blocked} | sdd:status/todo |
ファイルモード（オプション）:
| ファイル種別 | 命名規則 | 例 |
|---|---|---|
| フェーズディレクトリ | phase-N | phase-1, phase-2 |
| タスクファイル | TASK-XXX.md | TASK-001.md, TASK-002.md |
No 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.