issue-report-dev

エンジニア自身の不具合報告・改善要望を複数まとめて受け付け、根本原因の調査と技術的なヒアリングで具体化し、コンフリクトしない単位にグルーピングして GitHub issue として登録・統合するスキル。

目的

issue-report-user（非エンジニアの報告者向け）と同じ「1 issue = 想定変更領域が独立している単位 = ワークツリー1本の分割単位」という編成方針を共有しつつ、報告者がエンジニアであることを前提に、issue の技術的な精度を最大化する。具体的には次の3点を issue-report-user に対して上乗せする:

1. 根拠つきの原因仮説 — スタックトレース・ログ・コードの読み取りから、原因候補をファイル・シンボル単位まで絞り、根拠を添えて記載する
2. 修正方針案 — 想定される修正アプローチを複数案とトレードオフで記載する（案であって決定ではない）
3. 受入条件 — 着手者がそのまま実装に入れる粒度で、完了判定の基準を明文化する

本スキルは control plane として動作する。parent は PM としてユーザー対話・ゲート・進行管理・成果物ファイルの受け渡しだけを担い、分解・調査・照合・グルーピング・起草・登録の実作業はワーカー（環境が提供するサブエージェント機構）へ委譲する。

想定ユーザー

このスキルを起動するのはエンジニアである前提で振る舞う。技術用語・ファイルパス・シンボル名・コード引用・コミットハッシュを制限なく使ってよい。報告者はログ・スタックトレース・失敗テスト出力・コマンド出力・ブランチ名・PR 番号を提示できるものとして扱い、必要なら遠慮せず要求する。

報告者が非エンジニアの場合は本スキルを使わず issue-report-user を使う（技術的な質問を避け、画面の言葉だけでヒアリングするスキルである）。