pma-cr

PMA コードレビュー

このスキルを使うと、シグナルが多くノイズの少ないプロセスで、コードとエンジニアリング品質をレビューできます。PMA の開発ワークフローとは独立して動作します。

このスキルは、次の用途を想定しています。

• コミットまたはマージ前のローカル差分レビュー
• 変更行とその周辺コンテキストを対象としたプルリクエストレビュー
• 既存コードベース全体の監査
• プロジェクトの要件に基づき、技術スタックを考慮したレビューが必要なリポジトリ

範囲

このスキルには、1 つのエントリポイントと複数の内部レビューパックがあります。

• 共通のレビュー方針とエンジニアリングの基準
• TypeScript フロントエンドレビュー
• TypeScript バックエンド／Bun レビュー
• Go レビュー
• Rust レビュー
• Python レビュー

エントリスキルは簡潔に保ちます。検出された技術スタックに必要な参照ファイルのみを読み込みます。

クイックスタート

ローカルレビュー：

/pma-cr

PR レビュー：

/pma-cr <PR-number-or-URL>

リポジトリ監査：

/pma-cr audit
/pma-cr repo
/pma-cr --repo

ワークフロー

ステージされた変更のみのレビューや、指定された比較ベースなど、自然言語で明示されたレビュー意図に従います。以下の引数ルールは、簡略な呼び出しの解釈を明確にします。

1. 次の順序でレビューのモードを判定します。
   • まず PR 参照を確認します。単独の PR 番号、または /pull/ や /pulls/ を含む URL は PR レビューです。
   • それ以外の場合、audit、repo、または --repo が独立した引数として完全一致する場合は、リポジトリ監査です（単語、パス、URL の一部として含まれる場合は該当しません。.../audit-service/pull/12 は監査ではなく PR です）。
   • それ以外の場合、ローカルまたは origin/ の既存ブランチを指定する引数はブランチレビューです。ブランチ参照を正確に解決してコミットを特定し、ローカルモードのベース手順を使います。
   • それ以外の場合、既存のファイルまたはディレクトリを指定する引数は、そのパスに限定したローカル差分レビューです。
   • 上記以外の引数の場合、意図を確認します。モードを推測してはいけません。
   • 引数がない場合は、ローカル差分レビューです。
2. 該当するリポジトリの指示と受け入れ基準を収集します。references/core-review-policy.md と references/engineering-baseline.md を読みます。
3. スナップショット、対象範囲、期待される動作、影響を受ける利用側を確認します。リポジトリ監査の場合は、references/repository-audit.md も読みます。
4. レビュー対象のファイルとマニフェストから、技術スタックとサポート対象バージョンを検出します。監査モードでは、リポジトリのインベントリを使います。関連する品質ゲートと、このスナップショットにおける実際の結果を記録します。ツールが検出した失敗であっても、破棄してはいけません。
5. 該当する技術スタックのパックのみを読みます。
   • references/typescript-frontend.md
   • references/typescript-backend.md
   • references/go.md
   • references/rust.md
   • references/python.md
6. レビューの意図と設計を確認し、影響を受ける境界を越えて動作を追跡し、テストの有効性を調べます。関連する場合は互換性と運用上の確認を適用し、主張を検証できるだけのコンテキストを調査します。
7. 問題を反証し、重複を取り除きます。証拠、確認結果、対象範囲、適切な判定または監査の優先事項を報告します。レビューだけでは、修正やリモートへの書き込みは許可されません。

スタックの選択

次のヒューリスティックを使用してください。

• TypeScript フロントエンド：tsx、React、Next.js、Vite、ルーティング、UI コンポーネント、ブラウザーの状態、クライアントフォーム
• TypeScript バックエンド／Bun：Hono、Express、Fastify、Nest、Bun のサーバーコード、API ルート、DB アクセス、ワーカー
• Go：go.mod、*.go
• Rust：Cargo.toml、*.rs
• Python：pyproject.toml、setup.py、requirements.txt、*.py

Next.js の Route Handlers／Server Actions では、TS フロントエンドと TS バックエンドの両方のパックを読み込んでください。

変更が複数のスタックにまたがる場合は、関連するすべてのパックを読み込み、変更された各領域を適切なパックに照らして確認してください。

スタックパックの例は調査用プロンプトです。共通ポリシーに基づき、その証拠と影響が指摘事項に値するかどうかを判断してください。

リストにない言語や設定のみの変更には、共通のベースラインと関連するプロジェクトのルールを適用してください。言語固有の確認を完了したと主張するのではなく、専門知識やツールの制約を明示してください。

pma-cr はレビューのワークフローと指摘事項を管理します。PMA スタックスキルは実装の受け入れ基準を提供します。プロジェクトが採用している場合に限り、補助的なポリシーとして読み込んでください。その開発上の手順を適用したり、別の組織の推奨事項をプロジェクトの必須ルールとして扱ったりしないでください。

レビューの優先事項

レビューの順序、証拠要件、確信度による絞り込みについては、references/core-review-policy.md を参照してください。

ローカルレビューモード

決定論的なスナップショットをレビューするには、ローカルモードを使用してください。明示的に指定されたステージ済み、ブランチ、ベース、またはパスのリクエストは、デフォルト設定より優先されます。

• git status --short、ステージ済みおよび未ステージの差分、関連する未追跡ファイル（テストや設定を含む）を確認してください。未追跡ファイルだけの変更は作業ツリーのレビューです。無関係なシークレットや依存関係の出力を読まずに、ファイルの内容全体を確認してください。
• ローカルの変更があり、スナップショットの明示的な指定がない場合は、HEAD に対する変更後の作業ツリーをレビューしてください（git diff HEAD -- と関連する未追跡ファイル）。ステージ済みと未ステージのパッチを連結して、矛盾する指摘事項を作成しないでください。インデックスと作業ツリーの内容が異なる場合は、どちらをレビューしたかを明記してください。
• ステージ済みのみのリクエストでは、git diff --cached を使用し、インデックスからコンテキストやマニフェストを読み取ってください（git show :path）。後から更新された作業ツリーのバージョンは使用しないでください。ブランチレビューでは、解決された HEAD コミットのファイルを使用し、ローカル編集を混在させないでください。
• HEAD がないリポジトリでは、ベースを推測せず、関連する追加内容を新しいスナップショットとしてレビューしてください。
• クリーンなツリーまたは明示的なブランチレビューでは、ベースを次の順序で解決してください。ユーザーが明示したベース、既知の PR のターゲット、リモートのデフォルトブランチ（refs/remotes/origin/HEAD）、次に、曖昧さのない既存の origin/main または origin/master。アップストリームは、フィーチャーブランチの追跡用コピーにすぎない場合ではなく、意図された統合ベースであることが確認できる場合にのみ使用してください。
• HEAD とベースをコミット ID に解決し、マージベースから HEAD までを比較してください（git diff <merge-base-sha> <head-sha> --）。ref／path の引数は引用符で囲み、パス指定は -- で分離してください。信頼できるベースが存在しない場合、または候補が曖昧な場合は、独立した調査を続けながら、不足しているベースを確認してください。
• 解決された比較結果が空であれば、そのスコープに変更はありません。任意の直近のコミット範囲や、依頼されていないリポジトリ全体の監査に置き換えないでください。
• 名前変更や削除、およびそれらを利用する箇所を追跡してください。パスを限定したレビューでは、依頼された指摘事項のスコープを暗黙に広げず、スコープ外のコンテキストは証拠として使用してください。
• 依頼された人間が作成した変更を読み取ってください。サイズやコンテキストの不足により完了できない場合は、対象範囲の一部のみを確認したことと、未レビューの領域を報告してください。
• レビュー中にローカルの内容が変わった場合は、影響を受ける指摘事項を更新するか、レポートが対象とする以前のスナップショットを明記してください。
• 指摘事項を最初に提示し、その後にスコープ、確認事項、対象範囲、および references/core-review-policy.md で定められた判断を示してください。

PR レビューモード

GitHub または確立された Gitea インスタンスでは、PR モードを使用します。

• origin からフォージを特定し、指定された PR URL がそのリポジトリを示していることを確認します。ユーザーが提示した PR テキストから推測したホストには、認証情報を送信しないでください
• github.com では gh を使用します。適用されるユーザー／プロジェクトの指示によって、すでにホストが Gitea と宣言されている場合は、再検出せずに gitea スキルを使用します
• 不明な GitHub 以外のホストでは、SSH ホストエイリアスを解決し、SSH ポートを使わずに HTTPS ホストを使用します。https://<host>/api/v1/version を確認します。version フィールドを含む HTTP 200 の JSON が返れば、Gitea と判定できます。401／403 は認証が必要な状態なので、利用可能な場合はそのホスト用に設定された認証情報を使って再試行します。応答から判定できない場合は、推測せずフォージについて確認してください
• 選択したフォージクライアントを使い、PR の状態、ターゲットブランチ、ベース／ヘッド SHA、変更ファイル、差分、関連するチェック結果を調べます。そのヘッドからコンテキストを読み込み、API による切り詰めやファイルの欠落があれば明示します
• マージ済みまたはクローズ済みの PR は、状態を報告して終了します。ただし、ユーザーが明示的に振り返りレビューを依頼した場合を除きます
• ドラフト PR は通常どおりレビューし、ドラフトであることを記載します。ドラフトのレビューをマージ承認として扱わないでください
• 無関係なレガシーコードではなく、変更された動作とその周辺のコンテキストのみをレビューします
• ユーザーが委任を明示的に依頼した場合に限り、agents/code-reviewer.md を使用します。それ以外の場合は現在のセッションでレビューします
• 既定では、指摘はローカルで提示します。ユーザーから明示的に許可された場合に限り投稿し、セッション内ですでに与えられた許可も尊重します
• GitHub では、既定で gh pr review --comment を使用します。--approve または --request-changes は明示的に依頼された場合に限り使用します（注意：自分の PR では --approve は失敗します）
• Gitea では、確立されたベース URL と gitea スキルの PR レビューまたは Issue コメント用エンドポイントを使用します。自由形式のレビュー本文は、構造化された本文または安全に作成した一時ファイルを通じて送信します

リポジトリ監査モード

差分ではなく、現在のリポジトリの評価が目的の場合は、リポジトリ監査モードを使用します。

• マニフェスト、エントリーポイント、CI、テスト、スタックの手掛かりを一覧化します
• 重要な契約、モジュールの境界、状態の所有権、主要なテスト、運用経路に加えて、セキュリティ上のホットスポットを把握します
• リスクの高いモジュールから優先して調べます
• ファイル数ではなく、根本原因に基づいて指摘を重複排除します
• 確認済みの指摘、カバレッジの不足、推奨する次のアクションを分けて報告します。マージ可否の判断ではなく、優先度と監査対象範囲を報告します

出力ルール

• 報告する内容と省略する内容（確信度フィルター）については、references/core-review-policy.md を参照してください
• ローカル差分および PR の出力テンプレートについては、references/core-review-policy.md の「Output Format」セクションを参照してください
• リポジトリ監査レポートのテンプレートについては、references/repository-audit.md の「Report Skeleton」セクションを参照してください

リファレンスパック

• references/core-review-policy.md：根拠、重大度、判断、チェック結果、出力形式
• references/engineering-baseline.md：すべてのスタックに適用される意図、設計、正確性、テスト品質、互換性、運用のチェック項目
• references/repository-audit.md：リポジトリ全体の監査ワークフロー、ホットスポットの選定、レポートのひな形
• references/typescript-frontend.md：React／Next.js／Vite／ブラウザー UI のレビュー規則
• references/typescript-backend.md：Node／Bun／API／検証／DB／非同期処理のレビュー規則
• references/go.md：コンテキスト、エラー、並行処理、HTTP、リソース安全性に関する Go のレビュー規則
• references/rust.md：パニック境界、非同期処理のブロッキング、unsafe、ドキュメント、API 契約に関する Rust のレビュー規則
• references/python.md：検証、デシリアライズ、非同期処理、型安全性、コマンドインジェクションに関する Python のレビュー規則
• agents/code-reviewer.md：ユーザーが並列レビューまたは独立したレビューを依頼した場合に使用する、任意のサブエージェント用プロンプト
• evals/review-cases.md：動作の回帰シナリオ。このスキルの保守時に読み込み、通常のレビューでは読み込みません

詳細な規則は意図的にこれらのパックにまとめ、このファイルを小さく、読み込みコストを抑えています。