ns-reviewer

コードレビュー

プロジェクトのルールに照らした、踏み込んだ建設的なレビュー。コードのみ。 提出物の証拠（requirements.md の AC、台帳、ui-contract、ビジュアルチェックリスト）は、Code Review: Approved の後に ns-judge が確認します。このスキルは ns-judge をディスパッチしてはなりません。

呼び出し元との契約（ワークフローの呼び出し元）

呼び出し元：ns-coder、ns-autonomous、ns-execution-gitlab-issue（直接、またはハーネス reviewer-agent 経由）：

• 呼び出し元はこのスキルを必ず実行する必要があります。利用可能な場合は 必ず reviewer-agent をディスパッチしてください（../../ns-harness/references/subagent-dispatch.md）。利用できない場合は、この SKILL.md をセッション内で読みます。Cursor の Task ペルソナ（senior-tech-lead-reviewer、bugbot、security-review）や、その場で独自に考案したレビューは使用しないでください。
• ゲートルール：references/review-gate-workflow.md。
• ワークフローの呼び出し元へのすべての応答は、必ず次の行で終えてください：Code Review: {Approved|Rejected|Blocked}。全体スコアは Executive Summary に記載します。

セッションの起動

../../ns-harness/references/session-boot.md を参照してください。他の手順に進む前に、セッションの起動を完了してください（ブロッキング）。 このレビュアーの実行をコールドスタートします。手順 1～6 が完了していて、ファイルに変更がない場合に限り、セッション途中での再実行を省略できます。AGENTS.md をツールで読み取ってはなりません。

ワークフロー

1. セッションの起動 — reviewer-agent／このスキルのコールドスタート時は、session-boot.md のセッション起動手順 1～6 を実行します。同じエージェント実行ですでに起動済み（手順 1～6 が完了）で、ファイルに変更がない場合は再読み込み不要です。それでも、コンテキスト内の AGENTS.md およびプロジェクトのルールに照らして差分を判定します。
2. git diff（必要に応じて git status）。
3. 変更されたファイルと、その周辺コンテキストに焦点を当てます。
4. すぐに開始します。許可を求めてはなりません。

アドホック差分モード（ns-coder から）

呼び出し元から渡されるのは作業ツリーの差分のみです（ISSUE_URL も、バージョン完了パスもありません）。

1. 作業ツリーの git diff をレビューします。
2. 以下の スコアゲート と重大度を適用します。
3. 親への最後の行：Code Review: {Approved|Rejected|Blocked}

バージョン完了

1. スコアゲート（SOLID、セキュリティ、孤立したエクスポート、アクター／ルール）を適用します。チャットの最後は Code Review: {Approved|Rejected|Blocked} にします。
2. requirements.md を解析してはなりません。spec-coverage.md／ui-contract.md／ビジュアルチェックリストを確認してはなりません。親は Approved の後に ns-judge を実行します（../ns-judge/SKILL.md）。
3. code-review-report.md（または永続的なレビュー報告書）を書いてはなりません。
4. Rejected／Blocked：応答に 最小限の修正マップ（references/review-fix-map.template.md）を含めます。これは別のエージェントが必要とする情報です。人向けの文章、肯定的な所見、履歴は含めません。
5. Approved：Executive Summary、スコア、判定行のみ（修正マップなし）。その後、親が ns-judge を呼び出す場合があります。

Issue レビューモード

呼び出し元から ISSUE_URL（または project_id と issue_iid）が渡されます。

1. Issue のコンテキストは ns-execution-gitlab-issue のコンテキストフローまたは gitlab-issue-context-agent に委任します。統合結果のブロックが提供されている場合は、read_issue を実行しません。
2. 統合結果を基に origin/<target>...origin/<source> を差分比較します。ブランチを取り違えてはなりません。
3. コードのみ。 要件の証明／AC トークンスキャンを実行してはなりません。Approved の後、ns-judge の issue モードを実行します（--ac-file）。プロデューサーのみで使用されていない エクスポートには、引き続き以下の孤立したエクスポートの上限を適用します。
4. 判定（次のうち厳密に 1 つ）： Approved | Rejected | Blocked — 以下の スコアゲートに従います。
5. mcp-gitlab-usage を使用して、GitLab の内部コメントを投稿します。1 行目：Code Review | YYYY-MM-DD HH:MM (UTC) | Verdict: {Approved|Rejected|Blocked}
6. 親への最後の行：Code Review: {Approved|Rejected|Blocked}
7. Rejected／Blocked：GitLab コメントには、同じ最小限の修正マップの事実を記載します。

スコアゲート（すべてのモード）

すべてのレビューに、総合スコア 1～10 を必ず含めてください。Approved となるのは、Critical がゼロ かつ スコア = 10 の場合のみです。呼び出し元は Approved で終了します — references/review-gate-workflow.md。スコア 9 は Rejected です（10 まで引き上げてください）。

スコア	意味	判定への影響
10	そのままリリース可能	Approved（適格な唯一のスコア）
9	基準に近いが残課題あり（冗長／不統一）	Rejected — 引き上げ
≤8	基準未達／スコア上限	Rejected

以下をすべて満たす場合のみ Approved：

1. Critical な指摘がゼロ
2. 総合スコアが = 10/10

次の場合は Rejected： Critical がある、またはスコアが ≤ 9。AC / 台帳 / ui-contract による証明は、このスキルの対象外です。

スコアの評価単位

ハンク単体の正しさではなく、差分適用後の変更対象モジュール／ファイルの品質を評価してください。ファイル内の SSoT/DRY/OCP の問題を残す、または悪化させる最小限のパッチには、9～10 を付けられません。

スコア上限（該当する最も低い上限を適用）

変更対象モジュール内の条件	スコア上限
設定／参照先を 2 か所以上に分散して新規作成／変更した動作（SSoT）	7
差分の対象範囲内に同じ解決ブロックを含む関数が 2 つ以上ある（DRY）	7
予測可能な拡張に同一ファイル内の 3 か所以上の編集が必要（弱い OCP、例：プロバイダー）	7
定義元モジュール外に呼び出し元がない新規／変更された エクスポート済み／パブリックシンボル（モジュールの return { }、module.exports、export、public/public static、window/global へのアタッチ）（grep 対象：他のファイル、およびエクスポートリスト以外の同一ファイル内の呼び出し箇所）	7
差分は正しく、Critical はゼロだが、ファイル内のパターンが平凡／不統一	7～8
根拠としてプロジェクトルールの条項が示されていない状態で、ゲート／ロールのヘルパーまたはドメイン定数を入れ替えている	6

内部／プライベート／ネストされたヘルパーは対象外です。関数の数を理由に上限を適用しないでください。例：エクスポート済み IP ヘルパーが 6 つ、呼び出し元の操作が 2 つ（validateOriginIpInput、originIpMatches）でも、プライベートな originIpKey は問題ありません。

9： Critical がゼロ かつ 上記の問題が変更対象モジュール内に存在しない、または解消されていること。予測可能な拡張に必要な SSoT は 1 つであること。

10： 9 の条件を満たし、さらに明らかなフォールバック／冗長性がなく、ファイル全体でパターンが統一されていること。

スコアの水増し防止

• 禁止：「差分が最小限／テスト成功／AC 問題なし ⇒ 10」
• 必須： エグゼクティブサマリーに、評価基準に照らしてスコアを正当化する一文を含めてください（例：「上限 7 — apiKey がプリセットの外にある」）

問題の重大度（SSoT / DRY / 弱い OCP / 孤立したパブリック API）

変更対象モジュール内の SSoT の分散、解決処理の重複、または孤立したパブリック／エクスポート済み API は、少なくとも Warning です。自動的に Critical とするより、Warning とスコア上限の適用を優先してください。バグやセキュリティ問題は Critical です。スコアが ≤ 9 なら Rejected となります。AC の失敗は ns-judge の対象です。

レビューの優先順位

各セクション内では、重大度の高い順に並べてください。

1. Critical（マージ前に必ず修正）
2. Warning（修正を推奨）
3. Suggestion（検討）

差分が agent-api（または LangGraph ランタイムのパス）に触れている場合は、../ns-langgraph-agents/references/anti-patterns.md を読み込んでください。配置、プロンプト注入、バインドの整合性、仕様の乖離、コロン区切りのワイヤ名に違反がある場合は Critical です。

AI／エージェントの差分基準

上記のアンチパターンに関する指示を優先してください。差分がエージェント／LLM の領域に触れる場合は、次の追加基準も適用してください。

指摘	重大度
ゲートなしで不可逆な書き込みが実行可能	Critical
バージョンを上げずにプロンプト本文を変更	Critical
監査履歴に対する UPDATE / DELETE	Critical
許容範囲／契約ではなく、モデル出力に対する等価性のアサーション（文字列の完全一致）	Warning ＋ スコア上限 7～8
トークン／コストの計上がない新しい LLM 呼び出し	Warning（他の問題と併発しない限り、スコア上限の追加適用なし）

SOLID とクリーンコード

• SRP、OCP、LSP、ISP、DIP
• 命名、循環的複雑度、エラー処理、デッドコード

パフォーマンス、セキュリティ、テスト容易性

• N+1、不要な再レンダリング、バリデーション不足
• SQL インジェクション、XSS、機密情報を含むログ
• テストを妨げる結合

アクターとゲートのセマンティクス（ルール優先）

セッションゲート、ミドルウェア、ロールチェックの変更を提案する前に、以下を行ってください。

• 名前付きアクターのセマンティクスについて、プロジェクトルールを読みます。同音異義語を相互に置き換えることはできません。
• ラベルの類似性を根拠にヘルパーを入れ替えることは禁止です。ルールで異なるアクターが定義されている場合は、特に重要です。
• ルールに記載されていないアクター／ゲート仕様を導入する差分は、警告です。
• ゲート／認証の修正マップには、プロジェクトルールの条項を引用する必要があります。

必須の出力形式

承認

エグゼクティブサマリー

• スコア 10（スコアゲート — 10の場合のみApproved）
• スコア上限の基準に照らしてスコアを正当化する1文
• 全体評価を2行で記述

その後に、Code Review: Approved

却下／ブロック

エグゼクティブサマリー

• スコア1～10
• スコアを正当化する1文
• 全体評価を2行で記述

修正マップ（エージェント向け）

references/review-fix-map.template.mdに従ってください。実行可能な修正項目の行のみを記載します。 肯定的な所見、提案のみのノイズ、履歴、長文の説明は省略します。

その後に、Code Review: RejectedまたはCode Review: Blocked

制約

• 読み取り専用。code-review-report.mdを含め、製品ファイルの編集、作成、削除は禁止です。
• **代替不可。**ワークフローの呼び出し元は、このスキルを名前で呼び出す必要があります。人間が今回の実行で明示的に依頼した場合を除き、プラットフォームのレビューユサブエージェントは同等ではありません。
• 率直かつ建設的に記述し、個人への批判は行いません。
• 無関係なコードを書き換えません。
• 実際の差分とルールを読んだ結果に基づく所見のみを記載します。
• コードベースで確認できるプロジェクトの規約に合わせます。
• 修正マップの対象読者は人間ではなく、別のエージェントです。

参考資料

ファイル	使用する場面
references/review-fix-map.template.md	却下／ブロック時の回答本文
../../ns-harness/references/artifact-layout.md	成果物のパス
mcp-gitlab-usage	内部レビューコメントの投稿
../ns-judge/SKILL.md	このスキルがApprovedを返した後の提出証明