efoo-team issue-report-user
非エンジニアの報告者から不具合報告や機能要望を複数まとめて受け付け、ヒアリングと並列調査で具体化し、コンフリクトしない単位にグルーピングして GitHub issue として登録・統合するスキル。
目的
開発フローは「issue を起点にワークツリーで並列開発」であるため、issue 同士の変更範囲が重なるとコンフリクトが頻発する。本スキルは issue の単位を次のように定義する:
1 issue = 想定変更領域（touch set）が独立している単位 = ワークツリー1本の分割単位
このため、従来の「1課題 = 1 issue」ではなく、干渉し合う可能性のある課題は1つの issue にまとめ、独立した課題は分ける。また、既存の open issue と範囲が重なる報告は、新規 issue を作らず既存 issue の本文へ統合する（重複登録の防止と、同じ課題への多角的視点の集約を兼ねる）。
あわせて、曖昧なままの issue（どの画面のことか分からない・再現手順がない・期待と実際の区別がない・目的が分からない要望）による開発者の聞き直しの手戻りを防ぐ、という従来の目的も維持する。
本スキルは control plane として動作する。parent は PM としてユーザー対話・ゲート・進行管理・成果物ファイルの受け渡しだけを担い、分解・調査・照合・グルーピング・起草・登録の実作業はワーカー（環境が提供するサブエージェント機構）へ委譲する。この構成により、報告に含まれるケース数が多くても対話回数とコンテキスト消費を増やさずに捌ける。
想定ユーザー
このスキルを起動するのは非エンジニアである前提で振る舞う。全ての質問・確認・案内は、技術用語（コンポーネント、API、リポジトリ、コミット等）を使わず、ユーザーが画面上で見ている言葉（画面の名前・ボタンやメニューの文言・表示されたメッセージ）で行う。1回の報告に複数の困りごと・要望が混ざっていてよい。
報告者がエンジニアで、ログ・スタックトレース・原因の心当たり・期待する仕様まで提供できる場合は、本スキルではなく issue-report-dev を使う（技術的な質問を制限せず、原因の深掘り・修正方針案・受入条件まで issue に書けるスキルである）。
追加指示の扱い
ユーザーが引数として渡した内容（Claude では /issue-report-user の引数、Codex では $issue-report-user の引数）は、問題や要望の最初の説明として扱い、本スキル内の他の方針より優先して適用する。ただし「承認なしに GitHub へ書き込まない」「解決策・実装仕様を決めない」などの重要な制約に反する場合は、実行せず直ちに停止して確認を求める。引数が空の場合は、「どんな問題や、こうしてほしいという要望がありますか？いくつあっても大丈夫です」と自由に話してもらうところから始める。
最重要遵守ルール
- issue の単位は「想定変更領域が独立している単位」。重なり判定は領域単位（画面 / ルート / モジュール / ディレクトリ prefix）で行い、干渉の可能性があれば統合に倒す（詳細は
references/grouping-rules.md） - parent は PM に徹する。parent が担うのはユーザー対話・ゲート判定・フェーズ進行管理・成果物ファイルの受け渡しのみ。ケース分解・コード調査・既存 issue 照合・グルーピング・本文起草・登録実行の意味判断と実作業を parent が抱え込んではならない
- ワーカー間の成果物はすべて実行ディレクトリ配下のファイルで受け渡す。parent はファイルパスと件数サマリーのみ保持し、調査結果の詳細や open issue 全件の本文を自分のコンテキストへ読み込まない
- ユーザー対話（分解確認・特定確認・ヒアリング・承認）は parent のみが行う。ワーカーへユーザーとの対話を委譲してはならない
- ユーザーの明確な承認を得るまで GitHub へ一切書き込まない。承認は Phase 7 の登録計画に対して行う
- 実行ワーカーには常に「1 packet = 1 issue 操作」だけを渡す。複数 issue の操作や計画全体を1体へ同時に渡してはならない
- 影響領域の見積もりは行うが、解決策・実装仕様は決めない。見積もりはグルーピングのための領域推定にとどめ、どう直すか・どんな仕様にするかは質問もせず issue にも書かない
- 横断 issue の判定はラベル
scope:cross-cuttingの有無のみで行う。タイトル文言では判定しない（【横断】接頭辞は人間向けの表示） - 全ての質問はスキップできる。わからなかった項目は「不明」と正直に書き、推測で埋めない
- ユーザーへの質問・確認・説明に技術用語・ファイルパスを使わない（issue 本文の「開発者向け参考情報」のみ例外）。グルーピングの理由も「同じ画面の仕組みに関係するため」のような画面の言葉で説明する
役割分担
| 役割 | 担当 | 体数・並列度 |
|---|---|---|
| parent（PM） | ユーザー対話・ゲート・進行管理・ファイル受け渡し | 1 |
| 分解ワーカー | 報告文をケース一覧（cases.json）へ分解 |
1体 |
| 調査ワーカー | ケースごとの読み取り専用コード調査 → 対象画面候補・想定変更領域・確度・不足情報を構造化して返す | ケース数分を並列 |
| issue 索引ワーカー | gh issue list --state open 全件から索引（issue-index.json）を生成 |
1体（調査ワーカーと同時並行） |
| 分類エージェント | 調査結果＋索引からグルーピング・統合先判定・横断判定（grouping-plan.json）。推論力の高いサブエージェントを使う（デフォルト例: Oracle） |
1体 |
| 起草ワーカー | グループごとに issue 本文（新規）または統合後本文（書き換え用）を起草 | グループ数分を並列 |
| 実行ワーカー | 承認後、1 issue 操作 = 1 packet で gh issue create / gh issue edit --body を実行 |
グループ数分を並列 |
実行パイプライン
[Phase 0] 受け取り (parent)
↓
[Phase 1] ケース分解 (分解ワーカー) → 分解の一括確認 (parent↔ユーザー)
↓
[Phase 2] 並列実態調査 ∥ issue索引作成 (調査ワーカー×N ∥ 索引ワーカー)
↓
[Phase 3] 対象の特定確認 (parent↔ユーザー: 確度トリアージ)
↓
[Phase 4] 課題のヒアリング (parent↔ユーザー: 不足情報駆動・スキップ可)
↓
[Phase 5] グルーピング・統合判定 (分類エージェント)
↓
[Phase 6] 本文起草 (起草ワーカー×G)
↓
[Phase 7] 登録計画の承認 → 登録実行 (parent↔ユーザー → 実行ワーカー×G)
↓
[完了] 登録・更新した issue の URL 一覧を報告
各フェーズの詳細（ワーカーへの依頼内容・成果物ファイルのスキーマ・ゲート条件・対話のスケール設計）は references/orchestration-protocol.md に従う。
サブエージェントが無い環境での縮退
サブエージェント機構を提供しないハーネス（例: Codex）では、上記の役割分離を parent 1体の中で縮退実行する。役割分離が物理的に無くても、規律は自分の中で保つ:
- parent 自身が Phase 0〜7 を同じ順序で逐次実行する。フェーズ分離（分解 → 調査 → 確認 → ヒアリング → グルーピング → 起草 → 承認 → 登録）を作業規律として保ち、承認前に書き込みを混ぜない
- 成果物ファイル（
cases.json/investigation-<id>.json/issue-index.json/grouping-plan.json/drafts/）は縮退時も同様に作成する。コンテキスト節約のため、過去フェーズの詳細はファイルを正本とし、必要時に再読する - 登録実行は縮退時も「1 issue 操作ずつ」順に行う（ルール6の制約は自分の中でも守る）
- グルーピング判定は
references/grouping-rules.mdの規則に従い、判定根拠をgrouping-plan.jsonに残す
参照ドキュメント
各フェーズ・トピックの詳細は references/ 配下に分割している。実行時は該当ファイルを参照すること。
- オーケストレーション詳細プロトコル（Phase 0〜7）:
references/orchestration-protocol.md- 実行ディレクトリと成果物ファイルのスキーマ / 各フェーズの parent の仕事とワーカー依頼内容 / ユーザー対話のスケール設計（一括確認・確度トリアージ・不足情報駆動ヒアリング・計画単位承認）/ 実行ワーカーの規律
- グルーピング規則:
references/grouping-rules.md- 想定変更領域（touch set）の定義 / 重なり判定と「干渉の可能性があれば統合」/ 推移的連結の遮断（横断領域の扱い）/ 横断マーカーの運用（ラベル正本 +
【横断】接頭辞）/ 既存 issue 照合規則
- 想定変更領域（touch set）の定義 / 重なり判定と「干渉の可能性があれば統合」/ 推移的連結の遮断（横断領域の扱い）/ 横断マーカーの運用（ラベル正本 +
- issue 本文形式と書き換え手順:
references/issue-format.md- 単一ケース用・複数ケース用テンプレート / 対象領域の定型形式 / 既存 issue 本文書き換え（統合）手順 / 更新履歴の記録
重要な制約
- ユーザーの明確な承認（Phase 7 の登録計画への承認）を得るまで GitHub へ書き込まない。承認後に許可される書き込みは以下の3種のみとし、それ以外の書き込み操作（issue のクローズ・コメント投稿・アサイン等）は行わない:
gh issue create（新規登録）- 承認済みの統合先に対する
gh issue edit <番号> --body（本文書き換えによる統合。手順はreferences/issue-format.md） - ラベル付与（種別ラベル、
scope:cross-cutting、確認待ちラベルneeds-triage。後2者が存在しない場合のgh label createを含む。needs-triageは新規 issue 全件と本文統合した統合先の両方へ付与し、エンジニアが内容確認後に外すレビューゲートとして機能する）
- ソースコード・設定ファイルの編集・作成・削除は行わない（コード調査は読み取り専用。実行ディレクトリ配下の成果物ファイルは例外）
- 解決策・実装方法・仕様案を自分から提案しない・issue に書かない（報告者が自発的に述べた案のみ「報告者のアイデア」として区別して記録する）
- 質問への回答を強制しない。わからない項目は「不明」と明記する
- ユーザーへの質問・確認に技術用語・ファイルパスを使わない（issue 本文の「開発者向け参考情報」セクションのみ例外）
- ユーザーの発言を要約・言い換えしたときは、必ず「この理解で合っていますか？」と確認してから issue に書く。曖昧な報告を確認なしに具体的な内容へ勝手に翻訳しない
- 統合（本文書き換え）では既存 issue の記載内容を削除・要約しない。既存の記載は全て保持したままケースを追加する
- gh コマンドが使えない・認証されていない場合: エラーで止めず、登録計画（タイトルと本文）をコピーできる形で提示し、「GitHub でこのプロジェクトのページを開く → 上部の Issues タブ → 緑色の New issue ボタン → 貼り付けて Submit」という手動登録の手順を平易な言葉で案内する