メニュー
Issue Finder agent がコードベースを変更せず、指定された finder 分野の課題を根拠付きで調査し、優先順位付けした Markdown を指定ディレクトリへ出力するときの共通手順、安全制約、品質基準、出力 contract を定義する。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/version-1/agents-docs --skill issue-finder-playbookコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Git リポジトリで新しい作業を始める前に、最新のデフォルトブランチへ追従し、タスク内容に合う作業ブランチを作成して、不要なローカルブランチ整理を非同期に依頼するときに使う。ユーザーが「ブランチ切って」「作業を始める準備して」「新しいタスク用ブランチを作って」「最新 main から始めたい」などを依頼した場合はこの skill を使い、ブランチ名を報告してからタスク詳細の入力を待つ。
コード、設定、依存関係、権限境界にある悪用可能な脆弱性を安全に調査し、コードを変更せず課題レポートへ整理するため issue-finder agent に委譲するときに使う。一般的なコードレビュー、侵入や攻撃の実行、脆弱性修正には使わない。
コードベースに潜む再現可能な不具合、仕様違反、境界条件や異常系の欠陥を発見し、コードを変更せず課題レポートへ整理するため issue-finder agent に委譲するときに使う。実装済み差分のマージ可否レビュー、修正の実装、保守性だけの評価、脆弱性が主題の調査、文書だけの不整合調査には使わない。
SOC 職業分類に基づく
SKILL.md を表示中
| name | issue-finder-playbook |
| description | Issue Finder agent がコードベースを変更せず、指定された finder 分野の課題を根拠付きで調査し、優先順位付けした Markdown を指定ディレクトリへ出力するときの共通手順、安全制約、品質基準、出力 contract を定義する。 |
対応する role-*-finder-playbook と併用する。分野別 playbook は「何を課題と判定するか」、この playbook は「どう調査し、どう出力するか」を所有する。
/tmp/issue-finder/ を使う。依頼から次を確定する。
/tmp/issue-finder/。指定先を canonical path に解決し、symlink を含まず、解決後も $TMPDIR または /tmp 配下にある場合だけ使う。それ以外が指定された場合は、system temporary directory 配下の出力先を利用者に指定してもらう。調査対象、除外対象、未調査領域を成果物に明記する。「リポジトリ全体」は完全性の保証ではなく、実際に確認した範囲を併記する。
件数を満たすために弱い候補を課題へ昇格させない。
再現可能な事象、仕様との矛盾、またはコードから追跡できる因果関係があり、影響と解決方針を説明できる候補だけを課題とする。
問題の可能性はあるが、成立条件、contract、実行環境などが不足している候補は課題にせず investigation-needed.md に分離する。
既存課題と実質的に同じ候補は新規課題にせず、duplicates.md に既存課題への参照と今回得た追加根拠を記録する。
重要度は Critical / High / Medium / Low、確信度は High / Medium / Low を使い、判定理由を必須にする。重要度の具体的基準は分野別 playbook に従う。
課題ごとに <finder種別>-<対象名>-<YYYYMMDD-HHMMSS>-<slug>.md を作成する。finder種別、対象名、slug はそれぞれ英小文字、数字、ハイフンだけへ正規化し、先頭・末尾のハイフンを除去する。path separator、.、..、空白、絶対 path を含めず、正規化後のファイル名が出力先直下にあることを確認してから書き込む。slug は課題ごとに一意にする。
各課題ファイルへ次の順で記載する。
最大件数を超えた有力候補は additional-candidates.md に概要、根拠、優先順位を記録する。課題がなければ no-findings.md に調査範囲、実施した検証、未調査領域を記録する。補助ファイルが不要なら作成しない。
変更方針が一意に明確で、利用者の仕様判断が残らず、現在の責務、公開 interface、contract、依存関係を根拠から確定できる場合は、modification-design を使い、その規定8章を課題ファイルの「Modification Design」以下へ完全に含める。境界判断では lego-programming を併用する。
複数の解決案から利用者の判断が必要な場合や、設計を左右する情報が不足する場合は Modification Design を推測で作らず、選択肢または不足情報を「未解決事項」と investigation-needed.md に記録する。
出力先、作成した課題数、補助ファイル、最重要課題、未調査領域を利用者へ報告する。コードベースを変更していないことを確認して明記する。