できること
指定された基準点(コミット、ブランチ、タグ、main、HEAD~5)が解決でき、差分が空でないことを確認し、仕様の出どころ(コミットメッセージ内の issue 参照、指定されたパス、docs や specs 下の仕様ファイル)と、リポジトリの規約文書を探します。2つのサブエージェントを並列に動かして互いに干渉させません。規約レビュアーは、文書化された規約違反ごとにルールを引用し、Fowler の12のコードの臭いを判断の基準として適用します。仕様レビュアーは、不足または一部のみの要件、スコープの拡大、実装されているように見えて誤っている要件を、仕様の原文を引用して報告します。2つの報告はあえて分け、統合した順位付けはしません。
出力
「規約」の節、「仕様」の節、各軸の1行の要約と最も深刻な問題。
こんな場面に
チームの決まりと元の issue の両方に照らしてブランチやプルリクエストをレビューしたい人。
補足とリスク
中リスク:指示のみのファイルでスクリプトはありませんが、git コマンドを実行し、リポジトリの文書にある手順で issue トラッカーから元の issue を取得し、コードを読むサブエージェントを起動することがあります。ファイルは読み取り専用です。作者の setup Skill が作る docs/agents/issue-tracker.md を前提としており、なければ仕様の場所を尋ねます。未試用:実際の git リポジトリ、トラッカー、サブエージェントが必要なためデモはなく、フロントでは「未検証」と表示されます。作者 Matt Pocock、MIT。
SKILL.md 原文パッケージ内 3 ファイル