私が使っている Claude Code チートシート

私が実際に使っている Claude Code チートシート

• 前提
  • Claude Code
  • GitHub

オーケストレーションAIエージェント向けのタスク化指示書

# オーケストレーションAIエージェント向け タスク化ルール指示書

---

## 1. TASK 番号の採番ルール

- `TASK-NNN` は **3桁連番・グローバル一意**
- 起票前に `PMO_DISPATCH_LOG.md` の最終行を確認し、最大番号 +1 を使う
- 番号の重複・欠番は厳禁（PMO 内部監査で週次チェックされる）

---

## 2. 優先度定義

| 優先度 | 期限目安 |
|--------|----------|
| **P0** | 今週中 |
| **P1** | 今月中 |
| **P2** | 四半期内 |

優先度の最終決定は **ユーザーが行う**。エージェントは「候補」として仮評価（◎/○/△）を提示するに留める。

---

## 3. 起票の必要条件（必ず両ファイルを同時更新）

| ファイル | 記載内容 |
|----------|----------|
| `PMO_DISPATCH_LOG.md` | TASK-NNN・タイトル・担当エージェント・優先度・ステータス・依存関係 |
| 担当エージェントの `PMO_TASKS.md` | 同タスクのエントリ（ゴール・受入基準・Test plan を含む） |

> **片方だけ更新は不可。** 必ず両ファイルを同一コミットで更新すること。

---

## 4. タスク化候補の抽出フロー（第1条 実装）

レポート（`CEO/reports/` 等）を読んだ際の処理:

1. `## 課題（Issues）` セクションの全項目を抽出する
2. PMO ダッシュボード（TASK-058）のタスク化候補リストへ追記する
3. 優先度仮評価（◎/○/△）を付けて一覧化する（5件以上の場合は必須）
4. **ユーザーが選択したもののみ** `TASK-NNN` として正式起票する

---

## 5. ステータス管理ルール

| ステータス | 記入内容 |
|-----------|----------|
| `todo` | 未着手（デフォルト） |
| `in_progress` | `Status: in_progress` + 着手日 |
| `blocked` | `Status: blocked` + ブロッカー詳細 |
| `done` | `Status: done` + 完了日（下記 § 6 の条件を全て満たした後のみ） |

---

## 6. TASK を `done` にするための必要条件（全て必須・スキップ禁止）

1. **Test plan の全項目を実行済み**
   - PR body の `## Test plan` チェックボックスを全てチェック
   - 実行結果を PR の「テスト結果 / エビデンス」セクションに記載
2. **PR チェックリストが全項目チェック済み**（`.github/PULL_REQUEST_TEMPLATE.md` 含む）
3. **CI が green**（lint / test / security scan が全てパス）
4. **プラン整合性チェック済み**（プランモードを経由している場合）

> Test plan を実行できない場合は `type: BLOCKER` で `<<<JUDGMENT_REQUIRED>>>` を出力し、自己判断でスキップ禁止。

---

## 7. タスク完了時の自己チェックリスト（毎回必須）

- [ ] **目的整合性**: 完了タスクが「ゴール/受入基準」のどの条文に貢献したか 1行で記述
- [ ] **Phase 整合性**: 当該タスクが現在 Phase の成果物リストに明記されているか確認
- [ ] **完了条件充足**: Phase 別計画の該当 bullet を全て満たしたか（コード/テスト/ドキュメント別）
- [ ] **Phase ゲート**: Phase 内の最終タスクなら、Phase 完了条件を全部満たすまで次 Phase へ進まない

---

## 8. 次タスク着手前チェックリスト（毎回必須）

- [ ] **プラン参照**: 着手予定タスクがフェーズ別計画のどの bullet か引用で特定
- [ ] **依存解決**: 前提 Phase が完了しているか確認（未完なら着手禁止）
- [ ] **スコープ確認**: プランに無い「ついで作業」を一緒にやろうとしていないか自己点検

---

## 9. 判断点（`<<<JUDGMENT_REQUIRED>>>`）の出力条件

以下に該当したら **必ず停止** し、指定の YAML フォーマットで出力する:

| type | 例 |
|------|----|
| `DESIGN_DECISION` | 複数の実装案があり影響が分岐する |
| `DATA_REQUEST` | 外部データが必要で自力取得不可 |
| `SCOPE_CHANGE` | TASK の期限・成果物・依存関係の変更が必要 |
| `APPROVAL` | 成果物の最終承認（ドキュメント・戦略プラン等） |
| `BLOCKER` | 前提 TASK 未完了・権限不足・外部要因で継続不能 |
| `CROSS_AGENT` | 他エージェントへの指示発行が必要（PMO マター） |

出力先: `PMO_APPROVAL_QUEUE.md`（PMO Orchestrator が自動転記）

---

## 10. 禁止事項

- `TASK-NNN` の重複採番
- `done` 化前の Test plan スキップ
- 他エージェントのディレクトリを直接編集（例: CMO が `CLO/` を編集）
- `PMO_DISPATCH_LOG.md` と `PMO_TASKS.md` の片方だけ更新
- プランに無い追加作業を承認なく実施

---

## 参照ファイル

| ファイル | 用途 |
|----------|------|
| `PMO_DISPATCH_LOG.md` | タスク台帳（全体） |
| `PMO_APPROVAL_QUEUE.md` | 判断点キュー |
| `PMO/AGENT_PROTOCOL.md` | エージェント通信プロトコル全文 |
| `<AGENT>/PMO_TASKS.md` | 各エージェントのタスク一覧 |
| `scripts/pmo_tier1_runner.py` | Tier1 自動化起動スクリプト |

セッション完了時の処理

セッション完了処理を行わず次の新規セッションを開くと、わすれんぼうなので。

# AIエージェント向け セッション終了処理 指示書

> 出典: `PMO/AGENT_PROTOCOL.md` § 2〜4 / `PMO/sessions/README.md`
> 適用対象: 全エージェント（Tier1 自動化セッション・対話セッション共通）

---

## 1. セッション終了の2パターン

| パターン | 状況 | 出力ブロック |
|----------|------|-------------|
| **正常完了** | 判断点なく作業が完了した | `<<<SESSION_COMPLETE` |
| **判断点あり** | 進行に人間の判断が必要になった | `<<<JUDGMENT_REQUIRED` |

どちらのパターンでも **必ず § 2〜4 の成果物を揃えてからセッションを終了する**。

---

## 2. 成果物チェックリスト（終了前に全確認）

### 2-A. セッション作業ファイル（`PMO/sessions/<TASK-ID>/` 配下）

| ファイル | 必須/任意 | 内容 |
|----------|-----------|------|
| `report.md` | **必須** | セッションサマリ（人間可読・§ 5 フォーマット参照） |
| `JUDGMENT_REQUIRED.yaml` | 判断点がある場合のみ | 判断点ブロックを YAML で切り出したもの（複数可） |
| `transcript.log` | 自動生成 | Orchestrator が作成（エージェントは触らない） |

### 2-B. 本体成果物（自エージェントディレクトリ配下）

自エージェントのディレクトリにのみ書き込む（他エージェントのディレクトリは**禁止**）。

| エージェント | 書き込み先の例 |
|-------------|---------------|
| CMO | `CMO/strategy/<ドキュメント>.md` |
| CLO | `CLO/risk_matrix.md` |
| CIO | `CIO/design/<設計書>.md` |
| blogs| `blogs/output/<記事>.md` |

### 2-C. ステータス更新（両ファイルを同時更新）

- `PMO_DISPATCH_LOG.md` — 対象 TASK-NNN のステータスを更新
- 自エージェントの `PMO_TASKS.md` — 同タスクのステータスを更新

---

## 3. コミット手順

ブランチ: `claude/tier1-<TASK-ID>`（既存ブランチへの追加も可）

[TASK-NNN] <エージェント名>: <一行サマリ>

• <実施内容 箇条書き>
• 判断点がある場合: <内容> を JUDGMENT_REQUIRED として PMO へ依頼

Generated-by: PMO Tier1 Orchestrator

> **禁止**: `git push --force` / `git push origin main` / `git merge` / PR のマージ
> **許可**: `git push origin claude/tier1-<TASK-ID>` / `mcp__github__create_pull_request`

---

## 4. 終了ブロックの出力

### 4-A. 正常完了（判断点なし）

<<<SESSION_COMPLETE task_id: TASK-NNN status: done # done | in_progress deliverables: - path: <エージェントディレクトリ>/<成果物ファイル> summary: <一行説明> - path: PMO/sessions/TASK-NNN/report.md summary: セッションサマリ commit: claude/tier1-TASK-NNN next_action:

`status: in_progress` の使い方:
- Test plan の一部が環境制約で未消化のとき
- 後続 TASK の完了を待って `done` 化する必要があるとき
- 他エージェントの成果物が前提になっているとき

### 4-B. 判断点あり

<<<JUDGMENT_REQUIRED task_id: TASK-NNN type: DESIGN_DECISION # DESIGN_DECISION | DATA_REQUEST | SCOPE_CHANGE | APPROVAL | BLOCKER | CROSS_AGENT urgency: P0 # P0 | P1 | P2 summary: | （一行で要点） context: | （3〜5行で背景・経緯・なぜ判断が必要か） options: - id: A label: （案A タイトル） description: | （詳細・手順） impact: | （コスト・期間・他 TASK への波及） pros: [メリット1, メリット2] cons: [デメリット1] - id: B label: （案B タイトル） description: | impact: | pros: cons: recommended: A recommendation_reason: | （なぜ A を推奨するか） next_actions: on_approve: | （承認された場合に PMO が取るべき次アクション） on_reject: | （却下された場合の代替案） deadline: YYYY-MM-DD dependencies: - TASK-XXX

> 1 セッションに複数の判断点がある場合は、このブロックを複数回出力してよい。
> Orchestrator が全てをパースして `PMO_APPROVAL_QUEUE.md` に転記する。

---

## 5. `report.md` フォーマット（必須構成）

TASK-NNN セッションレポート

項目	値
TASK ID	TASK-NNN
担当	<エージェント名>
起動日	YYYY-MM-DD
状態	done / in_progress / blocked
ブランチ	claude/tier1-TASK-NNN

本セッションで実施したこと

成果物

| パス | 内容 | |------|------|

完了条件 vs 現状

判断点

次アクション（PMO 側）

---

## 6. `done` 化に必要な条件（再掲・スキップ禁止）

Test plan が未消化のまま `done` にしてはならない。未消化の場合は `in_progress` のまま PMO に引き継ぐ。

- [ ] Test plan の全項目を実行し、PR の「テスト結果 / エビデンス」セクションに記載済み
- [ ] PR チェックリストが全項目チェック済み
- [ ] CI が green（lint / test / security scan）
- [ ] プラン整合性チェック済み（プランモードを経由している場合）

---

## 7. 失敗・例外発生時

- `status: blocked` / `type: BLOCKER` で `<<<JUDGMENT_REQUIRED>>>` を出力
- 作業途中のファイルは**削除しない**（ユーザが続きから再開できるよう残す）
- `context` に失敗原因を詳述する

---

## 参照ファイル

| ファイル | 用途 |
|----------|------|
| `PMO/AGENT_PROTOCOL.md` | 本指示書の原典（§ 2〜4） |
| `PMO/sessions/README.md` | sessions ディレクトリの構造説明 |
| `PMO_APPROVAL_QUEUE.md` | JUDGMENT_REQUIRED の集約先 |
| `PMO_DISPATCH_LOG.md` | TASK ステータスの台帳 |
| `scripts/pmo_tier1_runner.py` | Orchestrator 実装（ブロックのパース処理） |

---