@takuma-hirai/hirai-method 0.1.0

package/.claude/commands/discharge-byproduct.md

@@ -0,0 +1,208 @@
+---
+description: next-actions.md の指定 entry を処理 (draft 起こし / parking-lot 移行 / 無視) し処理結果列を更新する
+args: <entry-number>
+related: [/new-draft, /new-task, /task-bypass, .claude/rules/workflow.md, docs/tasks/next-actions.md]
+---
+
+# /discharge-byproduct — 副産物 entry の処理
+
+`docs/tasks/next-actions.md` の **エントリ一覧** に記録された副産物 (byproduct) entry を、(a) draft 起こし / (b) parking-lot 移行 / (c) 無視 のいずれかで処理し、処理結果列を更新して entry を履歴セクションに移動する。
+
+設計→承認→タスク追加フローの **前段** にある「副産物 discharge」ループを閉じるためのコマンド。
+
+## 使い方
+
+```
+/discharge-byproduct <entry-number>
+```
+
+例:
+
+```
+/discharge-byproduct 4            # next-actions.md の # 4 entry を処理
+```
+
+## 引数
+
+- `<entry-number>` — `docs/tasks/next-actions.md` の「エントリ一覧」table の `|  # |` 列に並ぶ整数。連番なので **未処理 entry のうち最大の番号 + 1** ではなく、**処理したい entry の現在の番号** を指定する。
+
+## 動作
+
+### Phase 1: 引数検証
+
+1. `docs/tasks/next-actions.md` を Read
+2. 「エントリ一覧」セクションを抽出し、指定 `<entry-number>` 行の存在を確認
+3. 不在の場合: `❌ entry # <entry-number> が next-actions.md に見つかりません。/init-tasks で再生成 or 番号確認してください。` で中断
+4. 既に処理結果列が **空でない** (`—` も含む) 場合: `⚠️  entry # <entry-number> は既に処理済 (処理結果: <既存値>)。再処理するなら手動で処理結果列を空に戻してから再実行してください。` で中断
+5. **本リポ管理外** entry (例: 処理結果列が `—` 固定で「本リポ管理外」と推奨処理欄に明記) の場合: 「別リポで対応してください。本コマンドは本リポ entry のみ処理します」と user に提示して中断
+
+### Phase 2: entry 読み取り
+
+該当行から以下を抽出:
+
+- **タイトル** — title 列の最初の `—` 区切り前 (例: `PR 作成 (feat/loop-mode → main)`)
+- **発生源** — 発生源列
+- **緊急度** — 🔴 / 🟡 / 🟢
+- **推奨処理** — (a) / (b) / (c) の prefix
+
+タイトルから **slug 候補** を kebab-case 化:
+
+- 日本語 / 記号を除去
+- 連続空白を `-` に
+- 49 文字以内に切り詰め (`git-workflow.md` の branch 命名 regex に揃える)
+- 例: `PR 作成 (feat/loop-mode → main)` → `create-pr-feat-loop-mode`
+
+### Phase 3: 処理選択肢の提示
+
+#### Normal モード (default)
+
+user に以下を提示し、選択を待つ:
+
+```
+📋 entry # <N>: <タイトル>
+    発生源: <発生源>
+    緊急度: <緊急度>
+    推奨処理: <推奨処理>
+
+処理方法を選んでください:
+  (a) draft 起こし    — /new-draft <slug 候補> を起動して docs/draft/<slug>.md 生成
+  (b) parking-lot 移行 — docs/tasks/parking-lot.md に entry を transcribe (要設計書 link)
+  (c) 無視             — 理由を入力してもらい、履歴に記録のみ
+
+選択: (a / b / c)
+slug (a の場合のみ、空なら推奨値): <slug 候補>
+```
+
+#### Loop モード時の挙動
+
+- 緊急度 🔴 / 🟡: **(a) を default 採用**。slug は推奨値を使用。user 確認なしで進行
+- 緊急度 🟢: user に提示して回答待ち (Loop モードでも保留判断は禁止 — 副産物が滞留しないよう必ず明示的処理を要求)
+
+### Phase 4: 処理実行
+
+#### (a) draft 起こし
+
+1. `/new-draft <slug>` を **Skill tool 経由で起動** (内部 command 呼び出し)
+   - `<slug>` は Phase 3 で確定した値
+   - `--title <タイトル>` を渡す
+   - `--origin <発生源>` を渡す
+2. 生成された `docs/draft/<slug>.md` の path を保持
+3. next-actions.md の処理結果列を更新:
+
+```
+✅ → [`docs/draft/<slug>.md`](../draft/<slug>.md) (YYYY-MM-DD)
+```
+
+4. user に通知:
+
+```
+📝 Draft 起こしました: docs/draft/<slug>.md
+次の操作: 設計を埋めて user 承認後 /new-task <id> <slug>
+```
+
+#### (b) parking-lot 移行
+
+1. `docs/tasks/parking-lot.md` に entry を append (必須 7 項目フォーマット):
+
+```markdown
+### 🧊 <タイトル>
+
+**起案:** YYYY-MM-DD (next-actions.md entry # <N> から移行)
+**保留日:** YYYY-MM-DD
+
+**保留理由:**
+<user に入力を求める>
+
+**設計書:**
+- (未起こし — parking-lot 入りには本来 docs/draft 起こしを推奨。理由を保留理由に明記すること)
+
+**実装状態:**
+- 未着手
+
+**再検討トリガー (いずれか成立時に list.md へ移行):**
+1. <user に入力を求める>
+
+**代替現状:**
+<user に入力を求める>
+
+---
+```
+
+2. **設計書 link 必須** の制約上、user に「設計書 link 無しで parking-lot に入れる場合は理由を保留理由に明記してください。推奨は (a) draft 起こし → parking-lot 」と警告を提示
+3. next-actions.md の処理結果列を更新:
+
+```
+🧊 → [`parking-lot.md`](parking-lot.md) #<N> (YYYY-MM-DD)
+```
+
+#### (c) 無視
+
+1. user に **無視理由** を求める (空回答は禁止 → 再要求)
+2. next-actions.md の処理結果列を更新:
+
+```
+❌ 無視: <理由> (YYYY-MM-DD)
+```
+
+### Phase 5: 履歴セクションへの移動
+
+処理完了後 (a) / (b) / (c) いずれの場合も:
+
+1. next-actions.md の「エントリ一覧」table から該当行を削除
+2. 「履歴セクション」に移動 (時系列で append):
+
+```markdown
+| <N> | <記録日> | <タイトル> | <発生源> | <緊急度> | <推奨処理> | <処理結果> |
+```
+
+3. 「エントリ一覧」table の `#` 列はそのまま (番号の振り直しはしない — 履歴トレース可能性のため)
+
+### Phase 6: 完了報告
+
+```
+✅ entry # <N> 処理完了
+  処理方法: <a/b/c>
+  処理結果: <移行先 link or 無視理由>
+  next-actions.md 履歴セクションに移動済
+
+次の操作:
+  - (a) の場合: 設計を埋めて user 承認 → /new-task <id> <slug>
+  - (b) の場合: 必要なら設計書 link を後追いで追加
+  - (c) の場合: 同パターンの副産物発生時に同じ判断ができるよう CLAUDE.md / docs/tasks/ に教訓を記録
+```
+
+## エラーハンドリング
+
+| シナリオ | 動作 |
+|---|---|
+| `<entry-number>` 不在 | `❌ entry # <N> が見つかりません` で中断 |
+| `<entry-number>` 既処理 (処理結果列が空でない) | `⚠️  既に処理済 (処理結果: <既存値>)` で中断、再処理は手動 |
+| 本リポ管理外 entry (例: 推奨処理欄に「本リポ管理外」明記) | 「別リポで対応してください」と user に提示して中断 |
+| next-actions.md 自体が不在 | `❌ docs/tasks/next-actions.md が見つかりません。/init-tasks で再生成してください` で中断 |
+| 「エントリ一覧」table の format 不正 (列数不一致 等) | format 不正の行を提示し、user に手動修復を依頼 |
+| (a) で同 slug の draft が既存 | `/new-draft` 内部チェックで中断 → user に「既存 draft を編集するか別 slug にするか」を確認 |
+| (b) で設計書 link 入力なし | warning を出して append は実行するが、保留理由に「設計書未起こし」を明記するよう user に要請 |
+| (c) で無視理由が空 | `❌ 無視には理由が必要です。再入力してください` で再要求 |
+
+## Loop モード時の挙動 (再掲)
+
+- 緊急度 🔴 / 🟡 entry: **(a) draft 起こしを default 採用**。slug 推奨値で進行、user 確認省略
+- 緊急度 🟢 entry: user に提示して回答待ち (副産物滞留防止のため Loop でも保留判断は禁止)
+- 「本リポ管理外」 entry: Loop モードでも user に提示して中断 (誤処理防止)
+
+## Normal モード時の挙動 (再掲)
+
+- 全 entry で処理選択肢 (a)(b)(c) を user に提示して回答待ち
+- slug 候補は提示するが user が上書き可能
+- (c) 無視時の理由入力も user に求める
+
+## 関連
+
+- [`/new-draft`](new-draft.md) — (a) 処理で内部呼び出しされる設計 draft 起こしコマンド
+- [`/new-task`](new-task.md) — (a) 処理後の draft 承認 → タスク化フロー
+- [`/task-bypass`](task-bypass.md) — task-rule-guard の bypass (本コマンドとは別系統)
+- [`.claude/rules/workflow.md`](../rules/workflow.md) — workflow 強制機構 (副産物 discharge は前段)
+- [`docs/tasks/next-actions.md`](../../docs/tasks/next-actions.md) — 副産物 registry (本コマンドの対象 SSoT)
+- [`docs/tasks/parking-lot.md`](../../docs/tasks/parking-lot.md) — (b) 移行先
+- [`.claude/hooks/next-actions-surface.sh`](../hooks/next-actions-surface.sh) — SessionStart hook (未処理 entry 警告)
+- [`.claude/hooks/byproduct-discharge-guard.sh`](../hooks/byproduct-discharge-guard.sh) — Stop hook (🔴 未処理 entry の BLOCK)

package/.claude/commands/doc-review.md

@@ -0,0 +1,165 @@
+---
+name: doc-review
+description: "ドキュメントレビュー - 読み合わせ中の不備報告・疑問解消・修正を即実行"
+category: workflow
+complexity: intermediate
+model: opus
+---
+
+# /doc-review - ドキュメント読み合わせ中のレビュー・修正コマンド
+
+## 概要
+
+ドキュメント読み合わせ中に不備や疑問を見つけた際、AIにサクッと伝えて即座に対応するコマンド。
+
+**設計書:** `doc_draft/basic-design/ドキュメント読み合わせ運用/README.md`
+
+## 使用方法
+
+```
+/doc-review [ドメイン名] [内容]
+```
+
+**引数:**
+
+- `ドメイン名`: 読んでいるドメイン名（`doc/domains/` 配下のフォルダ名、部分一致OK）
+- `内容`: 不備の説明、疑問、修正依頼などを自由記述
+
+## 使用例
+
+```
+# 設計書の記述が実装と違う
+/doc-review 自動申込 フロー図のStep3、実際のコードだとOCCTO APIの呼び出し順が逆になってる
+
+# 仕様がわからない
+/doc-review イタンジ連携 イタンジBBとイタンジの違いって何？どこで使い分けてる？
+
+# 情報が古い
+/doc-review 空室通電 MoveIn__c.Status__cの選択値が現在の本番と一致してない気がする
+
+# 設計書に情報が足りない
+/doc-review 従業員管理 スキルマスタとの連携部分の記載がない
+
+# 誤字・表記ミス
+/doc-review ZoomPhone Zoom Phone の API 名が間違ってる。ZoomPhoneLog__c じゃなくて ZoomCallLog__c
+```
+
+## 実行手順
+
+### Step 1: ドメイン特定
+
+引数の `ドメイン名` から対象ドメインを特定する。
+
+1. `doc/domains/` 配下のフォルダ名と部分一致検索する
+2. 一致するものが複数ある場合は AskUserQuestion で確認
+3. 一致するものがない場合は `doc_draft/basic-design/` も検索
+4. 対象ドメインの `README.md` を読み込む
+
+### Step 2: 内容の分類
+
+引数の `内容` を以下の3タイプに自動分類する:
+
+| タイプ         | 判定基準                                             | アクション                                 |
+| -------------- | ---------------------------------------------------- | ------------------------------------------ |
+| **不備・修正** | 「間違い」「違う」「誤り」「古い」「更新」「修正」等 | 設計書を直接修正する                       |
+| **疑問・質問** | 「わからない」「なぜ」「違いは」「どう」「?」等      | コードベース・メタデータを調査して回答する |
+| **追記・補足** | 「足りない」「記載がない」「追加して」等             | 設計書に情報を追記する                     |
+
+> 分類に迷う場合は AskUserQuestion で確認する。
+
+### Step 3: タイプ別の処理
+
+---
+
+#### A. 不備・修正の場合
+
+1. **現状確認**: 対象ドメインの設計書（README.md）の該当箇所を特定
+2. **事実確認**: 以下のソースで正しい情報を確認
+   - `force-app/main/default/` 配下のメタデータ（XML）
+   - Apex クラス・トリガーのコード
+   - `doc/detailed-design/objects/` のオブジェクト設計書
+3. **修正実行**: 設計書を Edit ツールで直接修正
+4. **差分表示**: 修正箇所を明確に表示
+
+**出力フォーマット:**
+
+```
+## 修正完了
+
+**ドメイン:** [ドメイン名]
+**ファイル:** doc/domains/[ドメイン名]/README.md
+**修正内容:**
+- [修正前] → [修正後]
+
+**確認元:** [確認に使用したファイル/メタデータのパス]
+```
+
+---
+
+#### B. 疑問・質問の場合
+
+1. **調査**: 以下のソースを並列で調査
+   - 対象ドメインの設計書
+   - 関連するオブジェクト設計書（`doc/detailed-design/objects/`）
+   - メタデータ（`force-app/main/default/`）
+   - Apex コード
+   - 他のドメインの設計書（関連がある場合）
+2. **回答**: 簡潔に回答する（長文にしない）
+3. **参照先提示**: 詳細を知りたい場合の参照先を提示
+
+**出力フォーマット:**
+
+```
+## 回答
+
+**質問:** [元の質問]
+
+[簡潔な回答（3-5行程度）]
+
+**参照:**
+- [関連ファイルパス1]
+- [関連ファイルパス2]
+```
+
+---
+
+#### C. 追記・補足の場合
+
+1. **不足情報の収集**: メタデータ・コードから必要な情報を収集
+2. **追記案の提示**: まず追記内容を表示して確認
+3. **確認後に追記**: ユーザーの確認後、設計書に追記
+
+**出力フォーマット:**
+
+```
+## 追記案
+
+**ドメイン:** [ドメイン名]
+**追記箇所:** [セクション名]
+**追記内容:**
+
+[追記する内容のプレビュー]
+
+この内容で追記してよいですか？
+```
+
+---
+
+### Step 4: ログ記録
+
+実行結果を読み合わせログとして記録する:
+
+**ログファイル:** `doc_draft/basic-design/ドキュメント読み合わせ運用/review-log.md`
+
+追記フォーマット（ファイルが存在しない場合は新規作成）:
+
+```
+| [日付] | [ドメイン名] | [タイプ] | [概要（1行）] | [対応状況] |
+```
+
+## ルール
+
+- **簡潔に対応する**: 読み合わせは30分しかない。長い調査が必要な場合は「後で `/investigate` で詳細調査」と伝えて概要だけ回答する
+- **修正は直接行う**: 確認が取れた不備は即座に設計書を修正する。PRは後でまとめて作る
+- **推測で修正しない**: メタデータやコードで事実確認できない場合は修正せず、確認事項として記録する
+- **既存フォーマットを崩さない**: 設計書の既存の構成・スタイルを維持して修正・追記する

package/.claude/commands/document-pair.md

@@ -0,0 +1,76 @@
+---
+name: document-pair
+description: "ドキュメント読み合わせペア決定 - 本日の出勤者を選択し、2人以上のペアを自動生成"
+category: workflow
+complexity: basic
+model: haiku
+---
+
+# /document-pair - ドキュメント読み合わせペア決定
+
+## 概要
+
+DEVチームの「ドキュメント読み合わせ」運用で、本日の出勤者からペアを自動決定するコマンド。
+
+**設計書:** `doc_draft/basic-design/ドキュメント読み合わせ運用/README.md`
+
+## 使用方法
+
+```
+/document-pair
+```
+
+## 実行手順
+
+### Step 1: 出勤者の選択
+
+以下の7名のメンバーから、本日出勤している人を選択してもらう。
+AskUserQuestion を使用し、multiSelect: true のチェックボックス形式で表示する。
+
+**メンバー一覧:**
+
+- 古谷
+- 岡田
+- 棟安
+- 森下
+- 村上
+- 加古川
+- 山野
+
+質問文: 「本日出勤しているメンバーを選択してください」
+
+### Step 2: バリデーション
+
+- 選択された出勤者が **2名未満** の場合 → 「ペアを組むには2名以上の出勤が必要です。本日の読み合わせは中止してください。」と表示して終了
+
+### Step 3: ペア生成
+
+選択された出勤者をランダムにシャッフルし、以下のルールでペアを組む:
+
+1. **出勤者が偶数の場合:** 全員を2人ずつのペアに分割
+2. **出勤者が奇数の場合:** 2人ペアを基本とし、**最後の1組だけ3人組**にする
+
+### Step 4: 結果表示
+
+以下のフォーマットで出力する:
+
+```
+## 本日のドキュメント読み合わせペア（YYYY-MM-DD）
+
+**出勤者:** [選択されたメンバーをカンマ区切りで列挙]
+
+| ペア | メンバー |
+|---|---|
+| A | [名前] - [名前] |
+| B | [名前] - [名前] |
+| C | [名前] - [名前] - [名前] |
+
+**読み合わせ時間:** 11:00 〜 11:30
+**対象ドメイン:** 前回の続きから（進捗はSFの保有スキルで確認）
+```
+
+## ルール
+
+- ペアは毎回ランダムに決定する（固定パターンにしない）
+- 2人以上の出勤がないと実行不可
+- 出力は簡潔にする（余計な説明を加えない）