RulesとCustom reviewers

RulesかReviewerかを選ぶ

まずRulesで足りるかを確認します。Rulesは追加セッションを使いません。独立した合否判定と修正ループが必要な場合だけCustom reviewerにします。どちらも信頼できるrepository内の定義として管理し、最終判断はPull Requestで人間が行います。

Rules — 既存stepへ規律を追加する

rules newはstep名を検証し、同じdirectoryの最大番号に1を足したMarkdownを生成します。実行時は数値prefixの昇順で読み込まれ、prefixなしのfileは末尾です。

npx specrunner rules new code-review no-unverified-auth-claim
# => specrunner/rules/code-review/01-no-unverified-auth-claim.md

## やめてほしいこと

認証・認可の保証を、実装とtestの根拠なしに承認しない。

## こうしてほしいこと

境界条件と拒否経路を確認し、根拠のfile:lineをfindingへ含める。

## 例外

文言だけの変更で認証境界に触れない場合。

指定できるstep: request-review、design、spec-review、spec-fixer、test-case-gen、implementer、build-fixer、code-review、code-fixer、conformance、adr-gen

Custom reviewers — 独立した判定を追加する

定義fileはfilename順で読み込まれます。nameはfilenameのstemと一致させ、目的・観点・判定基準を空にしないでください。

npx specrunner reviewers new security-boundary
# => specrunner/reviewers/security-boundary.md

---
name: security-boundary
maxIterations: 2
model: claude-sonnet-4-6
paths:
  - src/auth/**
  - src/core/credentials/**
requestTypes:
  - new-feature
  - bug-fix
---

## 目的

認証情報と権限境界の退行を防ぐ。

## 観点

入力の信頼境界、credentialの保存先、拒否経路、testの根拠を確認する。

## 判定基準

境界違反または検証不能な保証があればneeds-fix。根拠をfile:lineで示す。

検証はjob開始前にまとめて行われます。 専用のreviewers validateコマンドはありません。runまたはjob startが全定義を読み込み、違反をまとめて表示し、state作成前に停止します。

Activation条件を狭める

条件はLLMではなくCLIが決定的に評価します。pathsはchanged fileのいずれか、requestTypesはrequest.mdのtypeと照合します。

pathsはrepository相対pathのfull matchです。**、*、?を使用できます。

実行・修正・再開の挙動

Custom reviewerはlocal runtimeで使用します。 現在のmanaged runtimeではcustom reviewerのagent IDを解決できず、並列custom reviewerも未対応です。定義を追加するjobはlocal runtimeで実行してください。

小さく導入する

1. 01
   1つのRulesから始める

   既存stepの不足なら、追加sessionを持たないRulesで効果を確認します。

2. 02
   Reviewerは1定義に絞る

   pathsとrequestTypesを狭くし、maxIterationsは2〜3から始めます。

3. 03
   信頼できる小さなrequestで実行する

   local runtimeでnpx specrunner run <slug>を実行し、activationとfindingsを確認します。

4. 04
   コストと収束を確認する

   npx specrunner job statsで追加session、iteration、時間を確認します。

5. 05
   Pull Requestで人間が判定する

   自動reviewの承認をmerge判断に置き換えず、差分と判定根拠を確認します。