---
name: waiting-user-handler
description: status:waiting-user の Issue を定期トリアージし、ユーザー確認最小化（A/B/C/D分類）で自動解決できるものは自律処理、真にユーザー判断が必要なものだけを事前リサーチ＋推奨案付きで AskUserQuestion でまとめて提示し、回答に基づいて処理するスキル。「waiting-user対応して」「waiting-userのIssueを確認して」「/waiting-user-handler」と依頼された時、またはプロジェクト定義の棚卸しスロットで自動実行する。
effort: medium
---

# waiting-user-handler — waiting-user Issue 定期トリアージ

## 目的

`status:waiting-user` の Issue を放置せず、**CP-6（ユーザー介入最小化）** に基づいて棚卸しする。
多くの waiting-user は実は自律処理できる（C/D カテゴリ）。それらを自動解決し、**真にユーザーの最終判断が必要なもの（A カテゴリ）だけ** を、事前リサーチ済みの推奨案付きでユーザーに提示する。

> **正本参照**: 分類基準は `docs/rules/user-confirmation-minimization.md`（A/B/C/D・既約境界外 A-1〜A-6）。確認に回す前に同 §3 のエスカレーション前必須チェックリストを満たすこと。

## いつ使うか

- ユーザーが「waiting-user対応して」「waiting-user のIssueを確認して」と依頼したとき
- **「waiting-user 棚卸しスキャン」スロット（hourly-routing.md・プロジェクト定義）から自動起動**
- waiting-user が 3 件以上溜まったとき（project-sync の衛生レポートで検知）

## フロー

### Step 0: 取得

```bash
gh issue list -R kai-kou/claude-wiki-hub --label "status:waiting-user" --state open \
  --json number,title,labels,updatedAt,body --limit 1000
```

0 件なら即終了（報告不要・CP-6）。

### Step 1: 各 Issue を A/B/C/D に分類（user-confirmation-minimization.md §2）

各 Issue 本文・直近コメントを読み、必ずいずれかに分類する。

| 分類 | 判定 | アクション |
|------|------|-----------|
| **重複** | 同一 comment-id・同一テーマの Issue が複数 | 古い方をクローズ（新しい方にリンク）し、以降は1件として扱う |
| **C-1: コメント技術質問（自律返信）** | 配信先（プロジェクト定義）のコメント技術質問 | **Step 1.5-A** の自律返信フロー（research→draft→レビュー役監修→自動投稿）。品質ゲート未通過時のみユーザー提示にフォールバック |
| **C-2: 週次/マーケレポート（自律判断）** | 週次マーケレポート等の情報通知 | **Step 1.5-B** の専門チーム判断フロー（改善要否を自律判断→必要なら Issue 化→レポートはクローズ）。ユーザーに判断を委ねない |
| **C-3: その他ルール整備で自律化** | ワークフローフェーズ（プロジェクト定義）の誤ラベル・公開済み・自明な情報通知 | §5（user-confirmation-minimization.md）の自律処理（auto-close / `status:waiting-claude` へ再分類 等） |
| **D: 外部要因** | 課金・BAN・プラットフォーム制約 | フォールバックで影響最小化。設定変更（A-6）のみ提示候補へ |
| **B: ツール改修で自律化可能** | 「ローカル必須」と書かれているがクラウド実行可能なもの 等 | §4 のクラウド実行を試行 → 失敗証跡を残し実装 Issue（B）へ。ユーザー提示から除外 |
| **A: 既約境界外** | A-1〜A-6 に一致（収益/ブランドの不可逆判断・新規マイルストーン・アカウント/課金設定 等） | Step 2 へ（ユーザー提示対象） |

**重要**: 迷ったら A 扱い（過剰な自動クローズを避ける）。ただし C-1/C-2/C-3 の明示条件を満たすものは品質ゲート付きで自律処理する（ユーザー明示指示・CP-6）。

### Step 1.5-A: コメント技術質問 自律返信（ユーザー承認不要）

> **ユーザー明示指示**: コメントは「自律的にリサーチ・レビューして適切なコメントを自動投稿」する。

コメント返信を担う {関連スキル}（プロジェクト定義・例: コメント返信スキル）の **自律返信フロー** に委譲する（research→draft→レビュー役監修+検証→ガードレール→投稿スクリプトで自動投稿→Issue クローズ）。品質ゲート（ドメイン固有の検証 rank≥B・レビュー役 critical なし・キャラ属性の誤用なし・ガードレール通過・重複なし）を全通過した場合のみ自動投稿し、未通過時のみユーザー提示にフォールバックする。

### Step 1.5-B: 定期レポート 専門チーム自律判断（ユーザー承認不要）

> **ユーザー明示指示**: レポートは「ユーザーに判断を委ねず、専門チームを組成して改善すべきか判断し Issue 化」する。

```
1. 専門チーム並列起動（Agent Teams・Haiku/Sonnet）:
   ├ アナリスト: プロジェクト定義の KPI を読み、平均比・トレンドで異常/機会を抽出
   └ ストラテジスト: 抽出結果を施策（構成改善・成功パターン横展開 等）に翻訳し ROI/緊急度を判定
2. 改善要否の自律判断（しきい値・プロジェクト定義）:
   ├ KPI が平均を一定以上下回る対象が複数 → 改善 Issue を起票
   ├ 高パフォーマンスの成功パターンあり → 横展開 Issue を起票
   └ 緊急度低・既存施策で対応済み → Issue 化せず記録のみ
3. Issue 化: type:improvement 等（具体施策・対象・根拠KPI・完了条件を本文に）
4. レポート Issue はクローズ（情報通知の役目は完了・判断結果は起票 Issue に引き継ぐ）
```

### Step 2: A カテゴリ（真にユーザー判断が必要）の事前リサーチ（L-077・推奨案の準備）

Step 1.5-A/B で自律処理されなかった **A カテゴリのみ** が対象。ユーザーに「丸投げ質問」をしないため、提示前に必ず推奨案を用意する。

| Issue 種別 | 事前準備 |
|-----------|---------|
| 公開/収益の不可逆判断（A-2 相当） | 選択肢ごとのメリット・リスク・推奨理由を1〜2文で整理 |
| 設定変更（A-6） | 必要な設定内容・手順・代替自動化の可否を整理 |
| 新規マイルストーン（A-5） | 追加理由・既存計画への影響を整理 |

> コメント技術質問は Step 1.5-A、週次/マーケレポートは Step 1.5-B で自律処理されるため、原則 Step 2（ユーザー提示）には到達しない（品質ゲート未通過時のみフォールバック）。

### Step 3: AskUserQuestion でまとめて提示

- 1 Issue = 1 問。**推奨案を第1選択肢** にし「(推奨)」を付ける
- 最大4問/回。5件以上は2バッチに分ける
- 各選択肢に「選ぶと何が起きるか」を明記
- **公開チャネルへの投稿は必ず「ドラフト提示→承認後に投稿」の2段階**（いきなり投稿しない）

### Step 4: 回答に基づき実行

| 回答 | 実行 |
|------|------|
| 返信案を作成/投稿 | ドラフトを提示 → 承認後、投稿スクリプト（プロジェクト定義）で投稿 → Issue クローズ |
| クローズ | `status:waiting-user` 除去 + 理由コメント + close |
| 実装 | 作業ブランチ → PR → AIレビュー → 自動マージ |
| 別Issue化して追う | type ラベル付き Issue を作成し、元 Issue はクローズ or 再分類 |
| 保留 | そのまま（次回棚卸しで再提示） |

### Step 5: ラベル更新・記録

- 処理済みは `status:waiting-user` を除去
- 実行内容を該当 Issue にコメント記録（観測可能性）
- ファイル変更を伴った場合は session-safety-rules.md に従いコミット

## ガードレール

- **公開チャネル（配信先のコメント返信・記事公開 等・プロジェクト定義）への投稿は必ずユーザー承認後**（ドラフト先行提示）
- 自動クローズは C カテゴリの明示条件を満たす場合のみ（定期レポート×Slack済み×7日 等）
- A への安易な分類で「確認の押し付け」をしない一方、過剰クローズで取りこぼさない（迷ったら A）
- 技術質問の返信は **ファクトの裏取り必須**（誤情報はブランド毀損・CLAUDE.md 最優先: 正確性）

## 関連ファイル

| ファイル | 役割 |
|---------|------|
| `docs/rules/user-confirmation-minimization.md` | A/B/C/D 分類・既約境界外の正本（SSOT） |
| `docs/rules/problem-investigation-protocol.md` | A 提示前の事前リサーチ義務（L-077） |
| `.claude/skills/{関連スキル}/SKILL.md` | コメント返信ドラフト生成（プロジェクト定義） |
| `.claude/skills/project-sync/SKILL.md` | C カテゴリ auto-close（Step 2.6）との連携 |
| `docs/rules/hourly-routing.md` | waiting-user 棚卸しスキャンの定期実行（プロジェクト定義のスロット） |