propose-issue

Issue 「$ARGUMENTS」を作成する前に、既存実装の有無を確認してください。

調査手順

1. キーワード抽出: Issue タイトル・説明から検索キーワードを2-4個抽出
2. コードベース探索: 以下のディレクトリで関連ファイルを検索
   • src/lib/ の既存モジュール
   • schemas/ の既存スキーマ
   • scripts/ の既存スクリプト
   • tests/ の既存テスト
   • runners/ の既存ランナー
3. Git 履歴確認: git log --all --oneline | grep -i "<keyword>" で関連コミット（複数単語対応のためクォート）
4. マージ済み PR 確認: gh pr list --state merged --search <keyword>
5. 既存 Issue 確認: gh issue list --state all --search <keyword>
6. 一次ソースの裏取り: 本文へ書く予定の数値・引用・前提を、記憶や過去の要約ではなく一次ソース（実ファイル・実コマンド出力・gh api の応答・原典）で確認する
7. 意図の確認: 「無い・動いていない・設定されていない」を根拠に起票する場合、それが意図された判断でないかを確かめる。確認先は、その設定が置かれる場所（workflow の条件・branch protection・設定ファイル）と、現状にした commit / PR / Issue、およびメンテナが明示した方針である。測定が正しくても「欠陥である」という結論は導けない

判定

調査結果に基づいて以下のいずれかで応答:

A. 既に実装済み

実装済みファイルと関連 PR を提示し、Issue は作成しない。ユーザーに「既に実装済みです。該当機能は以下に存在します」と報告。

B. 部分的に実装済み

既存実装と未実装部分を明示し、Issue のスコープを「既存 Y の拡張: X」に修正して提案。

C. 完全に未実装

Issue 作成の根拠となる調査結果を報告し、ユーザーの承認後に Issue を作成。本文を書くときは、手順 6 で確認した一次ソースを該当箇所に併記する（file:line・実行したコマンド・URL のいずれか）。裏取りの痕跡が本文に残っていれば、後から検算できる。

D. 欠落が意図された判断だった

欠陥としては起票しない。代わりに、その判断と食い違う記述（ゲートとして説明しているドキュメント・古いコメント・過去のレポート）が残っていないかを確認し、あればその是正としてスコープを組み直して提案する。塞ぐ対象は欠落そのものではなく、実態と異なる記述である。

禁止事項

• 調査を省略して Issue を作成してはならない
• src/lib/, schemas/, scripts/ のいずれかの探索を省略してはならない
• 「多分ない」という推測で Issue を作成してはならない
• 記憶や過去の要約にある数値は、出典を取り直さずに引き写してはならない
• 測定できなかった・実行されていなかったという事実だけを根拠に、欠陥と断定してはならない