@k2works/claude-code-booster 0.18.0 → 0.19.0

package/lib/assets/.claude/commands/dev.md

@@ -5,15 +5,24 @@
 ### 使い方
 
 ```bash
-/dev
+/dev [オプション]
 ```
 
+### オプション
+
+- なし : 開発フェーズ全体のワークフローを表示
+- `--codex` : Claude（計画・設計・受入）と Codex（実装）の分業体制で開発
+
 ### 基本例
 
 ```bash
 # 開発フェーズ全体のワークフロー表示
 /dev
 「開発フェーズの全体的な進め方と TDD サイクルの説明」
+
+# Claude と Codex の分業体制で開発
+/dev --codex
+「US-103 お知らせ管理を開始。計画・設計は Claude、実装は Codex が担当」
 ```
 
 ### 詳細機能
@@ -43,6 +52,7 @@ Red-Green-Refactor サイクルを厳密に実行：
 
 #### 参照ドキュメント
 
+- @docs/reference/CodexCLIMCPアプリケーション開発フロー.md を参照
 - @docs/design/architecture.md を参照
 - @docs/design/architecture_backend.md を参照
 - @docs/design/architecture_frontend.md を参照
@@ -60,23 +70,145 @@ Red-Green-Refactor サイクルを厳密に実行：
 - **インサイドアウト**: データ層から開始し上位層へ展開（バックエンド推奨）
 - **アウトサイドイン**: UI から開始しドメインロジックを段階的に実装（フロントエンド推奨）
 
-### Claude との連携
+#### Codex を活用した開発モード（--codex）
+
+`--codex` オプションを指定すると、Claude と Codex の分業体制で開発を進めます。
+
+**前提条件**:
+- Codex MCP サーバーが設定済みであること
+- @docs/reference/CodexCLIMCPサーバー設定手順.md を参照
+- @docs/reference/CodexCLIMCPアプリケーション開発フロー.md を参照
+
+**役割分担**:
+
+| フェーズ | 担当 | 責務 |
+|---------|------|------|
+| 計画 | Claude | 要件分析、タスク分解、優先度決定 |
+| 設計 | Claude | API 設計、UI 設計、データモデル設計 |
+| 実装 | Codex | コード実装、ユニットテスト作成 |
+| 受入 | Claude | 設計レビュー、E2E テスト作成・実行、品質確認 |
+
+**開発フロー**:
+
+```mermaid
+graph LR
+    A[計画] --> B[設計]
+    B --> C[実装指示]
+    C --> D[受入]
+
+    subgraph Claude
+    A
+    B
+    D
+    end
+
+    subgraph Codex
+    C
+    end
+```
+
+**Codex MCP ツールのパラメータ**:
+
+| パラメータ | 説明 | 推奨値 |
+|-----------|------|--------|
+| `prompt` | 実装指示（詳細な要件を含む） | タスク単位で明確に記述 |
+| `sandbox` | 実行環境の権限レベル | `danger-full-access`（推奨） |
+| `approval-policy` | コマンド実行時の承認ポリシー | `never` |
+| `cwd` | 作業ディレクトリ | プロジェクトルート |
+
+**指示サイズに関する注意**:
+
+| 粒度 | 推奨度 | 説明 |
+|------|--------|------|
+| タスク単位（1-3 ファイル） | ✅ 推奨 | 1 つのコンポーネントや機能単位 |
+| 機能単位（3-5 ファイル） | ⚠️ 注意 | 進捗確認を頻繁に行う |
+| ユーザーストーリー単位 | ❌ 非推奨 | タスクに分割して実行 |
+
+**Codex が書き込みできない場合の対処**:
+
+1. Claude が勝手に直接編集を進めてはいけない
+2. ユーザーに状況を報告し、確認を待つ
+3. ユーザーの許可を得てから代替手段を実行
+
+### 開発フローの実践
+
+`/dev --codex` を使用した開発フローの実践例：
+
+#### 1. 計画フェーズ（Claude）
 
 ```bash
-# プロジェクト情報の確認後に開発開始
-ls -la apps/
-cat README.md
-/dev
-「プロジェクトの現状を踏まえた開発フェーズの進め方を提案」
+# イテレーションのユーザーストーリー開始
+/dev --codex
+「US-103 お知らせ管理を開始。計画・設計は Claude、実装は Codex が担当」
+```
+
+Claude の活動:
+1. イテレーション計画を読み込み
+2. 受入条件を確認
+3. 既存コードを調査（API、フロントエンド構造）
+4. タスクリストを作成
+
+#### 2. 設計フェーズ（Claude）
+
+Claude の活動:
+1. API エンドポイント設計を確認
+2. フロントエンドコンポーネント設計
+3. Codex への詳細指示を作成
 
-# バックエンド開発の開始
-/dev-backend --tdd
-「User エンティティのテストから開始します」
+#### 3. 実装フェーズ（Codex）
+
+**Codex への指示例**:
+
+```
+mcp__codex__codex
+  prompt: |
+    お知らせ管理機能を実装してください。
+
+    ## 開発ガイド
+    docs/reference/コーディングとテストガイド.md に従って実装すること。
+    特に TDD サイクル（Red-Green-Refactor）を厳守すること。
+
+    ## タスク
+    1. AuthContext に role と canManageAnnouncements を追加
+    2. API クライアントに create/update/delete 関数を追加
+    3. ConfirmDialog コンポーネントを作成
+    4. AnnouncementForm コンポーネントを作成
+
+    ## 既存パターン参照
+    - API クライアント: src/lib/api.ts
+    - フォームコンポーネント: src/components/ui/Input.tsx
+
+    ## 完了条件
+    - ESLint エラーなし
+    - 既存テストがパス
+    - TDD サイクルに従って実装
+
+  sandbox: danger-full-access
+  approval-policy: never
+  cwd: プロジェクトルート
+```
+
+**継続指示**（codex-reply ツール使用）:
 
-# フロントエンド開発の開始
-/dev-frontend --tdd
-「LoginForm コンポーネントのテストから開始します」
 ```
+mcp__codex__codex-reply
+  threadId: "<前回のスレッドID>"
+  prompt: "テストを実行して結果を確認してください"
+```
+
+#### 4. 受入フェーズ（Claude）
+
+Claude の活動:
+1. 設計レビュー: 実装が設計に準拠しているか確認
+2. E2E テスト作成: 成功基準に基づくテストを作成
+3. E2E テスト実行: 機能が正しく動作することを検証
+4. バグ修正: 問題があれば修正
+
+**受入基準**:
+- [ ] すべての受入条件が満たされている
+- [ ] E2E テストがすべてパス
+- [ ] ESLint エラーがない
+- [ ] 既存テストが壊れていない
 
 ### 注意事項
 
@@ -95,3 +227,5 @@ cat README.md
 
 - `/dev-backend` : バックエンド開発ガイド
 - `/dev-frontend` : フロントエンド開発ガイド
+- @docs/reference/CodexCLIMCPアプリケーション開発フロー.md : アプリケーション開発フロー
+- @docs/reference/CodexCLIMCPサーバー設定手順.md : Codex MCP サーバー設定手順

package/lib/assets/.claude/commands/plan-github.md

@@ -13,9 +13,9 @@
 - なし : 全体の同期を実行（Project作成、Issue作成、フィールド設定、Milestone作成）
 - `--project` : GitHub Project のみを作成
 - `--issues` : Issue のみを作成（Project が存在する前提）
-- `--fields` : Project フィールド値のみを設定
+- `--fields` : 各 Issue に対して Project フィールド値を個別に設定（リリース、イテレーション、優先度、SP、カテゴリ、Status）
 - `--milestones` : Milestone のみを作成し Issue に割り当て
-- `--verify` : release_plan.md と GitHub の差異を確認
+- `--sync` : release_plan.md と GitHub の差異を確認し、差異があれば同期を実行
 - `--status` : 現在の GitHub Project 状態を表示
 
 ### 基本例
@@ -29,9 +29,9 @@
 /plan-github --project
 「GitHub Project を作成して」
 
-# 差異確認
-/plan-github --verify
-「release_plan.md と GitHub Issue の差異を確認して」
+# 差異確認と同期
+/plan-github --sync
+「release_plan.md と GitHub の差異を確認して同期して」
 
 # 現在の状態確認
 /plan-github --status
@@ -76,20 +76,99 @@ release_plan.md に基づいて GitHub Project を作成し、カスタムフィ
 
 #### フィールド値の設定
 
-各 Issue の Project フィールドに release_plan.md の値を反映します。
+各 Issue に対して Project のカスタムフィールド値を個別に設定します。
 
-**設定される情報**:
+**設定手順**:
 
-- リリース（マイルストーン対応）
-- イテレーション番号
-- 優先度（必須/重要）
-- ストーリーポイント
-- カテゴリ
+1. **フィールド ID とオプション ID の取得**
+   ```bash
+   gh project field-list <PROJECT_NUMBER> --owner <OWNER> --format json
+   ```
+
+2. **Project Item ID の取得**
+   ```bash
+   gh project item-list <PROJECT_NUMBER> --owner <OWNER> --format json --limit 50 \
+     | jq -r '.items[] | "\(.content.number):\(.id)"'
+   ```
+
+3. **各 Issue にフィールド値を設定**
+   ```bash
+   # Single Select フィールド（リリース、イテレーション、優先度、カテゴリ、Status）
+   gh project item-edit --project-id <PROJECT_ID> --id <ITEM_ID> \
+     --field-id <FIELD_ID> --single-select-option-id <OPTION_ID>
+
+   # Number フィールド（SP）
+   gh project item-edit --project-id <PROJECT_ID> --id <ITEM_ID> \
+     --field-id <FIELD_ID> --number <VALUE>
+   ```
+
+**設定されるフィールド**:
+
+| フィールド | タイプ | 設定内容 |
+|-----------|--------|---------|
+| **リリース** | Single Select | Release 1.0 MVP Alpha / 1.1 MVP Beta / 1.2 MVP / 2.0 完成版 |
+| **イテレーション** | **Iteration** | IT-1 〜 IT-6（2週間スプリント） |
+| **優先度** | Single Select | 必須 / 中 / 低 |
+| **SP** | Number | ストーリーポイント（2〜5） |
+| **カテゴリ** | Single Select | 認証 / お知らせ / 社員名簿 / カレンダー / 規定集 / マニュアル / ツール / 問い合わせ / 申請 / 承認 / ユーザー管理 |
+| **Status** | Single Select | Todo / In Progress / Done |
+
+**Iteration フィールドの作成**:
+
+イテレーションフィールドは `gh project field-create` では作成できないため、GraphQL API を使用します:
+
+```bash
+# Iteration タイプでフィールドを作成
+gh api graphql -f query='
+mutation {
+  createProjectV2Field(input: {
+    projectId: "<PROJECT_ID>"
+    dataType: ITERATION
+    name: "イテレーション"
+  }) {
+    projectV2Field {
+      ... on ProjectV2IterationField {
+        id
+        name
+        dataType
+      }
+    }
+  }
+}'
+```
+
+**注意**: Iteration フィールドの期間設定（開始日、スプリント期間）は GitHub Web UI から設定する必要があります:
+1. Project Settings → 「イテレーション」フィールド → 設定
+2. 各イテレーション（IT-1〜IT-6）を追加し、開始日と期間（14日）を設定
+
+**設定例**:
+
+```bash
+# Issue #1 にフィールド値を設定
+PROJECT_ID="PVT_kwDOBz-FwM4BNAQ9"
+ITEM_ID="PVTI_lADOBz-FwM4BNAQ9zgj6ixU"
+
+# リリース: Release 1.0 MVP Alpha
+gh project item-edit --project-id $PROJECT_ID --id $ITEM_ID \
+  --field-id PVTSSF_xxx --single-select-option-id 32cce308
+
+# イテレーション: IT-1（Iteration フィールドの場合）
+gh project item-edit --project-id $PROJECT_ID --id $ITEM_ID \
+  --field-id PVTIF_xxx --iteration-id <ITERATION_ID>
+
+# SP: 5
+gh project item-edit --project-id $PROJECT_ID --id $ITEM_ID \
+  --field-id PVTF_xxx --number 5
+
+# Status: Done
+gh project item-edit --project-id $PROJECT_ID --id $ITEM_ID \
+  --field-id PVTSSF_xxx --single-select-option-id 98236657
+```
 
 ```bash
 # フィールド値の一括設定
 /plan-github --fields
-「release_plan.md の内容で Project フィールドを更新して」
+「release_plan.md の内容で各 Issue のフィールド値を個別に設定して」
 ```
 
 #### Milestone の作成
@@ -108,9 +187,9 @@ release_plan.md に基づいて GitHub Project を作成し、カスタムフィ
 「リリースを Milestone として作成して Issue に割り当てて」
 ```
 
-#### 差異確認
+#### 差異確認と同期
 
-release_plan.md と GitHub Issue/Project の整合性を確認します。
+release_plan.md と GitHub Issue/Project の整合性を確認し、差異があれば同期を実行します。
 
 **確認項目**:
 
@@ -118,11 +197,22 @@ release_plan.md と GitHub Issue/Project の整合性を確認します。
 - ストーリーポイントの一致
 - リリース/Milestone 割り当ての一致
 - 優先度の一致
+- Status の一致
+
+**同期動作**:
+
+1. release_plan.md と GitHub Issue/Project の差異を検出
+2. 差異レポートを表示（追加/変更/削除項目）
+3. 差異がある場合は同期を実行:
+   - **新規ストーリー**: Issue を作成し Project に追加
+   - **変更されたストーリー**: Issue のフィールド値を更新
+   - **削除されたストーリー**: Issue をクローズ（削除はしない）
+   - **Status 変更**: release_plan.md の Status を GitHub に反映
 
 ```bash
-# 差異確認
-/plan-github --verify
-「release_plan.md と GitHub の差異がないか確認して」
+# 差異確認と同期
+/plan-github --sync
+「release_plan.md と GitHub の差異を確認して同期して」
 ```
 
 ### 出力例
@@ -148,7 +238,11 @@ release_plan.md と GitHub Issue/Project の整合性を確認します。
 ├─ リリース 2.0 機能拡張版: 12件（期日: 2026-04-24）
 └─ リリース 3.0 完成版: 8件（期日: 2026-06-19）
 
-✅ 差異確認: release_plan.md と完全一致
+🔄 差異確認・同期結果
+├─ 新規 Issue: 2件（US-401, US-402）
+├─ 更新 Issue: 3件（SP変更、Status変更）
+├─ クローズ Issue: 0件
+└─ ✅ 同期完了: release_plan.md と GitHub が一致
 ```
 
 ### Claude との連携
@@ -161,8 +255,8 @@ cat docs/development/release_plan.md
 
 # 計画更新後の差異確認と同期
 cat docs/development/release_plan.md
-/plan-github --verify
-「更新したリリース計画と GitHub の差異を確認して」
+/plan-github --sync
+「更新したリリース計画と GitHub の差異を確認して同期して」
 
 # 既存 Project へのフィールド更新
 /plan-github --fields
@@ -179,18 +273,20 @@ cat docs/development/release_plan.md
   - 既存の Project/Issue がある場合は重複作成に注意
   - フィールド値の更新は既存値を上書き
 - **推奨事項**:
-  - 初回は `--verify` で差異確認してから同期
+  - 初回は `--sync` で差異確認してから同期
   - 大規模な変更前にはバックアップを推奨
 
 ### ベストプラクティス
 
 1. **初回同期**: `/plan-github` で全体を一括作成
-2. **計画更新時**: `/plan-github --verify` で差異確認後、必要な部分のみ更新
+2. **計画更新時**: `/plan-github --sync` で差異確認と自動同期
 3. **定期確認**: `/plan-github --status` で進捗状況を定期的に確認
-4. **一貫性維持**: release_plan.md を Single Source of Truth として管理
+4. **一貫性維持**: release_plan.md を Single Source of Truth として管理し、`--sync` で GitHub に反映
 
 ### 同期フロー
 
+#### 初回同期フロー（`/plan-github`）
+
 ```mermaid
 graph TD
     A[release_plan.md] --> B{/plan-github}
@@ -201,8 +297,24 @@ graph TD
     F --> G[フィールド値設定]
     G --> H[Milestone 作成]
     H --> I[Issue に Milestone 割当]
-    I --> J[差異確認]
-    J --> K[同期完了]
+    I --> J[同期完了]
+```
+
+#### 差異確認・同期フロー（`/plan-github --sync`）
+
+```mermaid
+graph TD
+    A[release_plan.md] --> B[GitHub Issue/Project 取得]
+    B --> C{差異検出}
+    C -->|差異なし| D[✅ 一致確認]
+    C -->|差異あり| E[差異レポート表示]
+    E --> F{同期実行}
+    F --> G[新規 Issue 作成]
+    F --> H[既存 Issue 更新]
+    F --> I[削除された Issue クローズ]
+    G --> J[同期完了]
+    H --> J
+    I --> J
 ```
 
 ### 関連コマンド

package/lib/assets/docs/reference/CodexCLIMCP/343/202/242/343/203/227/343/203/252/343/202/261/343/203/274/343/202/267/343/203/247/343/203/263/351/226/213/347/231/272/343/203/225/343/203/255/343/203/274.md

@@ -0,0 +1,532 @@
+# アプリケーション開発フロー
+
+## 概要
+
+本ドキュメントは、Claude（AI アシスタント）と Codex（実装エージェント）を活用した開発フローを定義します。計画・設計は Claude が担当し、実装は Codex に委譲することで、効率的かつ品質の高い開発を実現します。
+
+---
+
+## 開発フローの全体像
+
+```plantuml
+@startuml
+title 開発フロー
+
+skinparam rectangle {
+  BackgroundColor<<claude>> LightBlue
+  BackgroundColor<<codex>> LightGreen
+}
+
+rectangle "1. 計画\n\n・要件分析\n・タスク分解\n・優先度決定" <<claude>> as plan
+rectangle "2. 設計\n\n・API設計\n・UI設計\n・データ設計" <<claude>> as design
+rectangle "3. 実装指示\n\n・コード実装\n・テスト作成\n・リファクタ" <<codex>> as impl
+rectangle "4. 受入\n\n・設計レビュー\n・E2Eテスト\n・品質確認" <<claude>> as accept
+
+plan --> design
+design --> impl
+impl --> accept
+
+note bottom of plan : Claude
+note bottom of design : Claude
+note bottom of impl : Codex
+note bottom of accept : Claude
+
+@enduml
+```
+
+```plantuml
+@startuml
+title 開発フロー シーケンス図
+
+actor ユーザー as user
+participant Claude as claude
+participant "Codex MCP" as codex
+database コードベース as code
+
+user -> claude : /dev US-103 開始
+activate claude
+
+== 計画フェーズ ==
+claude -> code : イテレーション計画読み込み
+claude -> code : 既存コード調査
+claude -> claude : タスク分解・優先度決定
+
+== 設計フェーズ ==
+claude -> code : 既存パターン確認
+claude -> claude : API/UI/データ設計
+claude -> claude : Codex指示作成
+
+== 実装フェーズ ==
+claude -> codex : 実装指示（MCP）
+activate codex
+codex -> code : コード実装
+codex -> code : ユニットテスト作成
+codex -> codex : Lint/テスト実行
+codex --> claude : 実装完了
+deactivate codex
+
+== 受入フェーズ ==
+claude -> code : 設計レビュー
+claude -> code : E2Eテスト作成
+claude -> code : E2Eテスト実行
+claude -> code : バグ修正（必要に応じて）
+claude --> user : 完了報告
+
+deactivate claude
+
+@enduml
+```
+
+### 役割分担
+
+| フェーズ | 担当 | 責務 |
+|---------|------|------|
+| 計画 | Claude | 要件分析、タスク分解、優先度決定 |
+| 設計 | Claude | API 設計、UI 設計、データモデル設計 |
+| 実装指示 | Codex | コード実装、ユニットテスト作成 |
+| 受入 | Claude | 設計レビュー、E2E テスト作成・実行、品質確認 |
+
+---
+
+## フェーズ 1: 計画
+
+### 目的
+
+イテレーション計画とユーザーストーリーに基づき、実装すべきタスクを明確化する。
+
+### 入力
+
+- イテレーション計画（`docs/development/iteration_plan-*.md`）
+- ユーザーストーリーと受入条件
+
+### 活動
+
+1. **要件分析**: ユーザーストーリーの受入条件を確認
+2. **既存コード調査**: 関連する既存実装を確認
+3. **タスク分解**: 実装タスクを細分化
+4. **優先度決定**: 依存関係を考慮してタスク順序を決定
+
+### 出力
+
+- タスクリスト（TODO）
+- 実装方針
+
+### 例: US-103 お知らせ管理
+
+```markdown
+## タスクリスト
+
+1. AuthContext に role と canManageAnnouncements を追加
+2. API クライアントに CRUD 関数を追加（create/update/delete）
+3. ConfirmDialog 汎用コンポーネント作成
+4. AnnouncementForm コンポーネント作成
+5. AnnouncementFormPage 作成（新規作成・編集兼用）
+6. App.tsx にルーティング追加
+7. AnnouncementsPage に新規作成ボタン追加
+8. AnnouncementDetailPage に編集・削除ボタン追加
+9. ユニットテスト作成
+```
+
+---
+
+## フェーズ 2: 設計
+
+### 目的
+
+実装前に詳細な設計を行い、Codex への指示内容を明確化する。
+
+### 入力
+
+- タスクリスト
+- 既存のアーキテクチャ・パターン
+
+### 活動
+
+1. **API 設計**: エンドポイント、リクエスト/レスポンス形式
+2. **データモデル設計**: 型定義、バリデーションルール
+3. **UI 設計**: コンポーネント構造、状態管理
+4. **既存パターン確認**: プロジェクトの既存実装に合わせる
+
+### 出力
+
+- 詳細設計仕様
+- Codex への実装指示
+
+### 例: AnnouncementForm 設計
+
+```typescript
+// 設計仕様
+type FormValues = {
+  title: string       // 必須、最大200文字
+  content: string     // 必須
+  category: AnnouncementCategory  // GENERAL | IMPORTANT | EVENT | HR
+  publishedAt: string // datetime-local 形式
+}
+
+// バリデーション
+- title: z.string().min(1).max(200)
+- content: z.string().min(1)
+- category: z.enum(['GENERAL', 'IMPORTANT', 'EVENT', 'HR'])
+- publishedAt: z.string().min(1)
+
+// コンポーネント構造
+- AnnouncementForm
+  - Input (タイトル)
+  - TextArea (本文)
+  - Select (カテゴリ)
+  - DateTimeInput (公開日時)
+  - Button (キャンセル/保存)
+```
+
+---
+
+## フェーズ 3: 実装指示（Codex）
+
+### 目的
+
+Codex MCP サーバーを通じて、設計に基づいた実装を委譲する。
+
+### Codex MCP 呼び出し方法
+
+```
+mcp__codex__codex ツールを使用
+
+パラメータ:
+- prompt: 実装指示（詳細な要件を含む）
+- sandbox: danger-full-access（workspace-write ではread-onlyエラーになることがある）
+- approval-policy: never（自動承認）
+- cwd: プロジェクトルート
+```
+
+### 指示サイズに関する注意
+
+> **重要**: ユーザーストーリー単位など大きな単位で Codex に指示を出すと、処理が長時間化しレスポンスがなくなることがあります。
+
+#### 推奨される指示の粒度
+
+| 粒度 | 推奨度 | 説明 |
+|------|--------|------|
+| タスク単位（1-3 ファイル） | ✅ 推奨 | 1 つのコンポーネントや機能単位 |
+| 機能単位（3-5 ファイル） | ⚠️ 注意 | 進捗確認を頻繁に行う |
+| ユーザーストーリー単位 | ❌ 非推奨 | タスクに分割して実行 |
+
+#### 大きなタスクの分割例
+
+```
+❌ 悪い例: ユーザーストーリー全体を一度に指示
+「US-103 お知らせ管理機能を全て実装してください」
+
+✅ 良い例: タスク単位で分割して指示
+1. 「AuthContext に role と canManageAnnouncements を追加」
+2. 「API クライアントに create/update/delete 関数を追加」
+3. 「ConfirmDialog コンポーネントを作成」
+4. 「AnnouncementForm コンポーネントを作成」
+5. ...
+```
+
+#### レスポンスがない場合の対処
+
+1. `codex-reply` で進捗を確認
+2. 長時間応答がない場合はタスクを中断
+3. より小さな単位に分割して再実行
+
+#### Codex が書き込みできない場合の対処（重要）
+
+Codex が read-only 制限やファイルロック等で書き込みできなかった場合：
+
+1. **Claude が勝手に直接編集を進めてはいけない**
+2. ユーザーに状況を報告し、確認を待つ
+3. ユーザーの許可を得てから代替手段（Claude による直接編集等）を実行
+
+```
+❌ 悪い例:
+Claude: 「Codex が read-only 制限で書き込みできませんでした。直接編集を行います。」
+→ 勝手に進めている
+
+✅ 良い例:
+Claude: 「Codex が read-only 制限で書き込みできませんでした。
+以下の選択肢があります:
+1. Claude が直接編集を行う
+2. 環境の問題を解決してから Codex で再実行
+どちらで進めますか？」
+→ ユーザーの確認を待っている
+```
+
+### 実装指示のベストプラクティス
+
+1. **明確な要件**: 何を実装するか具体的に記述
+2. **既存パターン参照**: 既存ファイルを参照先として指定
+3. **型定義の明示**: TypeScript の型を事前に定義
+4. **テスト要件**: テストも同時に作成させる
+5. **適切な粒度**: タスク単位（1-3 ファイル）で指示を分割
+
+### 例: Codex への実装指示
+
+```
+prompt: |
+  お知らせ管理機能を実装してください。
+
+  ## タスク
+  1. AuthContext に role プロパティと canManageAnnouncements を追加
+  2. API クライアント（src/lib/api.ts）に以下を追加:
+     - createAnnouncement(input: AnnouncementCreateInput)
+     - updateAnnouncement(id, input)
+     - deleteAnnouncement(id)
+  3. ConfirmDialog コンポーネントを作成（既存の Button を参考に）
+  4. AnnouncementForm コンポーネントを作成（React Hook Form + Zod）
+  5. AnnouncementFormPage を作成（/announcements/new と /announcements/:id/edit）
+  6. App.tsx にルーティングを追加
+
+  ## 既存パターン参照
+  - API クライアント: src/lib/api.ts
+  - フォームコンポーネント: src/components/ui/Input.tsx
+  - ページコンポーネント: src/pages/AnnouncementsPage.tsx
+
+  ## 完了条件
+  - ESLint エラーなし
+  - 既存テストがパス
+
+sandbox: workspace-write
+approval-policy: never
+```
+
+### Codex 実行中の確認
+
+- Codex の進捗は `codex-reply` ツールで確認
+- 問題発生時は追加指示で修正を依頼
+
+---
+
+## フェーズ 4: 受入
+
+### 目的
+
+実装された機能が設計通りに動作することを確認する。
+
+### 活動
+
+1. **設計レビュー**: 実装が設計仕様に準拠しているか確認
+2. **コード品質確認**: ESLint、テストカバレッジの確認
+3. **E2E テスト作成**: 成功基準に基づくテストを作成
+4. **E2E テスト実行**: 機能が正しく動作することを検証
+5. **バグ修正**: 問題があれば修正
+
+### E2E テスト作成のポイント
+
+```typescript
+// 成功基準に対応するテストケース
+test.describe('お知らせ管理機能（管理者）', () => {
+  test('管理者がお知らせを新規作成できる', async ({ page }) => {
+    // 1. 新規作成ボタンをクリック
+    // 2. フォームに入力
+    // 3. 保存
+    // 4. 詳細ページで確認
+  })
+
+  test('管理者がお知らせを編集できる', async ({ page }) => {
+    // ...
+  })
+
+  test('管理者がお知らせを削除できる（確認ダイアログあり）', async ({ page }) => {
+    // ...
+  })
+})
+```
+
+### 受入基準
+
+- [ ] すべての受入条件が満たされている
+- [ ] E2E テストがすべてパス
+- [ ] ESLint エラーがない
+- [ ] 既存テストが壊れていない
+
+---
+
+## 実践例: US-103 お知らせ管理
+
+```plantuml
+@startuml
+title US-103 お知らせ管理 開発フロー
+
+|Claude|
+start
+:イテレーション計画読み込み;
+:受入条件確認;
+:既存コード調査;
+:タスクリスト作成;
+
+|Claude|
+:API設計確認;
+:フロントエンド設計;
+:Codex指示作成;
+
+|Codex|
+:AuthContext拡張;
+:APIクライアント追加;
+:ConfirmDialog作成;
+:AnnouncementForm作成;
+:AnnouncementFormPage作成;
+:ルーティング追加;
+:既存ページ修正;
+:ユニットテスト実行;
+
+|Claude|
+:設計レビュー;
+:E2Eテスト作成;
+:E2Eテスト実行;
+
+if (テスト失敗?) then (yes)
+  :バグ修正;
+  :再テスト;
+else (no)
+endif
+
+:完了報告;
+stop
+
+@enduml
+```
+
+### 1. 計画フェーズ
+
+```
+ユーザー: /dev iteration3 US-103: お知らせ管理 開始
+         計画・設計は claude 実装は codex が担当する
+
+Claude:
+  1. イテレーション計画を読み込み
+  2. 受入条件を確認
+  3. 既存コードを調査（API、フロントエンド構造）
+  4. タスクリストを作成
+```
+
+### 2. 設計フェーズ
+
+```
+Claude:
+  1. API エンドポイント設計を確認（既に実装済み）
+  2. フロントエンドコンポーネント設計
+     - AuthContext の拡張
+     - AnnouncementForm コンポーネント
+     - AnnouncementFormPage
+     - 既存ページの修正
+  3. Codex への詳細指示を作成
+```
+
+### 3. 実装フェーズ
+
+```
+Claude → Codex MCP:
+  prompt: "お知らせ管理機能を実装..."
+  sandbox: workspace-write
+  approval-policy: never
+
+Codex:
+  1. AuthContext に role, canManageAnnouncements 追加
+  2. API クライアントに CRUD 関数追加
+  3. ConfirmDialog コンポーネント作成
+  4. AnnouncementForm コンポーネント作成
+  5. AnnouncementFormPage 作成
+  6. App.tsx ルーティング追加
+  7. AnnouncementsPage, AnnouncementDetailPage 修正
+  8. テスト作成・実行
+```
+
+### 4. 受入フェーズ
+
+```
+Claude:
+  1. 設計レビュー
+     - 実装が設計に準拠しているか確認
+     - コード品質確認
+
+  2. E2E テスト作成
+     - announcements.spec.ts に管理機能テストを追加
+
+  3. E2E テスト実行
+     - npm run test:e2e -- --grep "お知らせ"
+
+  4. バグ修正
+     - publishedAt の ISO 8601 形式変換を追加
+     - テストの待機処理を追加
+
+  5. 最終確認
+     - 15 tests passed
+```
+
+---
+
+## コマンドリファレンス
+
+### 開発開始
+
+```bash
+# イテレーションのユーザーストーリー開始
+/dev iteration3 US-103: お知らせ管理 開始
+```
+
+### Codex MCP 呼び出し
+
+```
+mcp__codex__codex
+  prompt: "実装指示..."
+  sandbox: workspace-write
+  approval-policy: never
+  cwd: /path/to/project
+```
+
+### テスト実行
+
+```bash
+# ユニットテスト
+npm run test
+
+# E2E テスト（全体）
+npm run test:e2e
+
+# E2E テスト（特定機能）
+npm run test:e2e -- --grep "お知らせ"
+```
+
+### 品質チェック
+
+```bash
+# Lint + Format + Test
+npm run check
+```
+
+---
+
+## ベストプラクティス
+
+### 計画・設計
+
+1. **既存パターンを尊重**: プロジェクトの既存実装に合わせる
+2. **受入条件を明確に**: テスト可能な条件を定義する
+3. **依存関係を考慮**: タスクの実行順序を適切に設定
+
+### 実装指示
+
+1. **具体的な指示**: 曖昧さを排除した詳細な要件
+2. **参照ファイルの明示**: 既存のパターンを参照先として指定
+3. **完了条件の明示**: 何をもって完了とするか明確に
+
+### 受入
+
+1. **設計レビュー先行**: テスト前にコードを確認
+2. **E2E テストで検証**: 成功基準に対応するテストを作成
+3. **継続的なフィードバック**: 問題があれば即座に修正
+
+---
+
+## 関連ドキュメント
+
+- [開発環境セットアップ](dev_app_instruction.md)
+- [Codex CLI MCP サーバー設定](codex_instruction.md)
+- [イテレーション計画](../development/iteration_plan-3.md)
+- [コーディングとテストガイド](../reference/コーディングとテストガイド.md)
+
+---
+
+**作成日**: 2026-01-19
+**更新日**: 2026-01-19

package/lib/assets/docs/reference//351/226/213/347/231/272/343/202/254/343/202/244/343/203/211.md

@@ -33,7 +33,7 @@ state 配置 #lightblue
 
 アプリケーション開発は、アジャイル開発手法（XP）に基づいて進めます。
 
-詳細は [エクストリームプログラミング](エクストリームプログラミング) を参照。
+詳細は [エクストリームプログラミング](エクストリームプログラミング.md) を参照。
 
 ## 分析
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@k2works/claude-code-booster",
-  "version": "0.18.0",
+  "version": "0.19.0",
   "description": "AI Agent Development Support Tool",
   "main": "main.js",
   "bin": {