verify

Verify Feature

ホストに依存しないワークフローです。スキル名（verify）で呼び出します。Claude Code のスラッシュルーティング、YAML フックローダー、.claude/chain については、references/claude-code.md を参照してください。

ニュアンスを踏まえた採点（0～10 点）と改善案を提示する、専門エージェントを並列で使った包括的な検証です。

クイックスタート

verify authentication flow
verify --model=opus user profile feature
verify --scope=backend database migrations

引数の解決

代名詞のターゲット（this、them、the above）は会話から読み返し、1 行で通知してから使用します。Read("../../shared/rules/target-resolution.md") のインライン部分です。

SCOPE = "$ARGUMENTS"       # Full argument string, e.g., "authentication flow"
SCOPE_TOKEN = "$ARGUMENTS[0]"  # First token for flag detection (e.g., "--scope=backend")
# $ARGUMENTS[0], $ARGUMENTS[1] etc. for indexed access (CC 2.1.59)

# Model override detection (CC 2.1.72)
MODEL_OVERRIDE = None
for token in "$ARGUMENTS".split():
    if token.startswith("--model="):
        MODEL_OVERRIDE = token.split("=", 1)[1]  # "opus", "sonnet", "haiku", "fable"
        SCOPE = SCOPE.replace(token, "").strip()

# Streak gate detection (#2540) — consecutive-pass mode
STREAK_TARGET = None
for token in "$ARGUMENTS".split():
    if token.startswith("--streak="):
        STREAK_TARGET = int(token.split("=", 1)[1])  # N consecutive READY verdicts required (N >= 2)
        SCOPE = SCOPE.replace(token, "").strip()
# When set, apply the Streak Gate (see below). Full protocol: references/streak-gate.md

MODEL_OVERRIDE が設定されている場合は、すべての Agent() 呼び出しに model=MODEL_OVERRIDE として渡してください。CC 2.1.74 に従い、シンボリック名（opus、sonnet、haiku、および Agent ツールの一覧にあるハーネスでの fable。なお、fable は 2026-07-12 以降、プレミアム API の利用料金が発生します）または完全な ID（claude-opus-5-5）を指定できます。

Opus 5.5：エージェントはネイティブの適応型思考を使用します（MCP sequential-thinking は不要です）。Opus 5.5 自体の effort のデフォルトは medium で、Opus 5 の high より 1 段階低くなっています。また、CC 2.1.280 以降では、新たにリリースされたモデルはデフォルト設定で起動するため、検証には high または xhigh を渡してください。拡張された 128K 出力により、包括的な検証レポートを作成できます。

---

STEP 0：effort に応じた検証のスケーリング（CC 2.1.76）

/effort レベルに応じて、検証の深さを調整します。

Effort レベル	実行するフェーズ	エージェント数	出力
low	テストのみ実行 → 成功／失敗	エージェント 0 人	簡易チェック
medium	テスト + コード品質 + セキュリティ + API 準拠	エージェント 4 人	スコア + 主な問題
high（デフォルト）	8 フェーズすべて + ビジュアルキャプチャ	エージェント 6～7 人	完全なレポート + 評価
xhigh（Opus 5、CC 2.1.111 以降）	8 フェーズすべて + ファイル横断の追加パターンスイープ + 自己検証パス	エージェント 6～7 人	不確実性の注記付き完全レポート

オーバーライド： ユーザーによる明示的な選択（例：「完全な検証」）は、/effort による縮小設定より優先されます。

STEP 0a：AskUserQuestion でユーザーの意図を確認する

タスクを作成する前に、検証の範囲を明確にします。

AskUserQuestion(
  questions=[{
    "question": "What scope for this verification?",
    "header": "Scope",
    "options": [
      # multiSelect questions do not render previews (single-select only) — kept text-only
      {"label": "Full verification (Recommended)", "description": "All tests + security + code quality + visual + grades"},
      {"label": "Tests only", "description": "Run unit + integration + e2e tests"},
      {"label": "Security & code quality", "description": "Security audit (OWASP/CVE/secrets) + lint/types/complexity"},
      {"label": "Quick check", "description": "Just run tests, skip detailed analysis"}
    ],
    "multiSelect": true
  }]
)

回答に基づいて、ワークフローを調整します：

• 完全な検証：9 フェーズすべて（8 + 2.5）、ビジュアルキャプチャを含む並列エージェント 7 人
• テストのみ：フェーズ 2（セキュリティ）と 5（UI/UX 分析）をスキップ
• セキュリティとコード品質：security-auditor と code-quality-reviewer のエージェントを実行
• 簡易チェック：テストのみ実行し、評価と提案をスキップ（フェーズ 2 をスキップするため、Fan-out ルールの対象外）

---

STEP 0b：オーケストレーションモードを選択する

詳細を読み込むには、環境変数の確認ロジック、Agent Teams と Agent Tool の比較、モード選択ルールについて Read("references/orchestration-mode.md") を参照してください。

デフォルトは Workflow（スター型。workflows/verify-dispatch.js がフェーズ 2 を実行）です。検出結果について議論が必要な場合は Agent Teams（メッシュ型。検証エージェント同士で検出結果を共有）を、オーケストレーションモードのリファレンスに従い、Workflow ツールが利用できない場合はプレーンな Agent tool（スター型）を選択してください。

Fan-out ルール： 選択した範囲でフェーズ 2 を実行する場合、単一パスだけで代替することはできません。フェーズ 2 は Workflow 呼び出し、Agent Teams、または Agent tool を通じて実行します。いずれも検証エージェントを起動しない場合は、実行を BLOCKED として終了し、その理由を伝えてください。フェーズ 2 をスキップする範囲（effort が low、テストのみ、簡易チェック）は違反ではありません。

---

MCP プローブ + 再開

# memory is alwaysLoad in .mcp.json (CC 2.1.121+, #1541) — probe below kept as fallback for older CC:
ToolSearch(query="select:mcp__memory__search_nodes")
Write(".claude/chain/capabilities.json", { memory, timestamp })

Read(".claude/chain/state.json")  # resume if exists

引き継ぎファイル

検証完了後、結果を書き込みます。

Write(".claude/chain/verify-results.json", JSON.stringify({
  "phase": "verify", "skill": "verify",
  "timestamp": now(), "status": "completed",
  "outputs": {
    "tests_passed": N, "tests_failed": N,
    "coverage": "87%", "security_scan": "clean"
  }
}))

回帰モニター（CC 2.1.71）

必要に応じて、検証後のモニタリングをスケジュールします。

# Guard: Skip cron in headless/CI (CLAUDE_CODE_DISABLE_CRON)
# if env CLAUDE_CODE_DISABLE_CRON is set, run a single check instead
CronCreate(
  schedule="0 8 * * *",
  prompt="Daily regression check: npm test.
    If 7 consecutive passes → CronDelete.
    If failures → alert with details."
)

---

完了条件。 完了とは、選択したすべての評価項目について、今回のセッションで実行したコマンドに裏付けられたスコアがあり、レポートで VERIFIED と CLAIMED が区別されていることです。Read("../../shared/rules/long-run-protocol.md") に従ってください。ユーザーからの入力が不要なステップは続行し、ユーザーなしでは続行できない場合、または破壊的な操作の前にのみ停止して確認します。各サブエージェントの証拠を確認してから採用し、確認できなかったことには、どこを調べたかを添えて明記してください。

タスク管理

メインの検証タスクと、フェーズごとにサブタスクを1つ作成し、チェックが完了するまで採点をブロックします：Read("references/task-management.md")。

---

8フェーズのワークフロー

詳細を読み込むには、完全なフェーズの詳細、エージェントの起動定義、Agent Teams の代替手段、チームの終了処理について、Read("references/verification-phases.md")を実行してください。

フェーズ	アクティビティ	出力
1. コンテキスト収集	Git の差分、コミット履歴	変更の概要
2. 並列エージェントのディスパッチ	6つのエージェントが評価	0～10のスコア
2.5 ビジュアルキャプチャ	スクリーンショットのルート、AI ビジョン評価	ギャラリー＋ビジュアルスコア
3. テスト実行	バックエンド＋フロントエンドのテスト	カバレッジデータ
4. 詳細な採点	総合スコアの計算	評価（A～F）
5. 改善提案	労力と影響の分析	優先順位付きリスト
6. 代替案の比較	アプローチを比較（任意）	推奨案
7. メトリクスの追跡	傾向分析	履歴データ
8. レポートの作成	証拠アーティファクト＋gallery.html	最終レポート

フェーズ2のエージェント（クイックリファレンス）

エージェント	対象	出力
code-quality-reviewer	Lint、型、パターン	品質 0～10
security-auditor	OWASP、シークレット、CVE	セキュリティ 0～10
test-generator	カバレッジ、テスト品質	カバレッジ 0～10
backend-system-architect	API 設計、非同期処理	API 0～10
frontend-ui-developer	React 19、Zod、アクセシビリティ	UI 0～10
python-performance-engineer	レイテンシ、リソース、スケーリング	パフォーマンス 0～10

ディスパッチを独自に実装しないでください。まずフェーズ3のテスト実行（以下）をバックグラウンドで開始し、その後、実行ツールを実行してください：

Workflow(
  scriptPath="${CLAUDE_SKILL_DIR}/workflows/verify-dispatch.js",
  args={"effort": EFFORT, "scope": "<diff summary from Phase 1>", "rubric": <rubric.json>,
        "dimensions": DIMS, "modelOverride": MODEL_OVERRIDE}
)   # add "testEvidence": {"outcome", "exitCode", "summaryLine"} if assert-evidence.sh already ran
# DIMS from STEP 0a: Full -> all six ["security","quality","coverage","api","performance","ui"] (overrides effort);
#   "Security & code quality" -> ["security", "quality"]; Tests only / Quick check -> skip Phase 2

スクリプトが担うのは処理の仕組みであり、文章ではありません。 労力に応じた検証エージェント（セキュリティを最優先）を証拠スキーマとともに起動し、重大なブロッカーと低いスコアを反証者に送ります（high では1票、xhigh では3票、予定された投票数の過半数が必要で、各反証にはコマンドで裏付けられた証拠が必要です）。エージェント数の上限を12に適用し、reasonsを含むverdictCapを返します。立証できないものがあると上限は引き下げられます。対象項目が不明、評価基準がない、コマンドで裏付けられた証拠のないスコア、CLAIMED 項目、検証エージェントの停止などが該当します。testEvidenceがない場合は、capIfTestsPassとともにPENDING-TESTSを返します。以下のゲートを通過した後、終了コードが0で、少なくとも1つのテストが成功し失敗がないことを示すサマリーがある EVIDENCE に限り、上限はcapIfTestsPassとなります。それ以外は BLOCKED です。すべてのプロジェクトで、セキュリティが9.0未満の場合は BLOCKED です（オペレーターの決定、2026-09-25）。ポリシーによって他のしきい値を厳しくすることはできますが、緩めることはできません。フェーズ4の評価は上限の範囲内で行い、上限を超えてはなりません。

監視と部分的な結果（CC 2.1.98）

テスト出力をストリーミングするにはMonitorを使用してください。run_in_backgroundのリクエストが反映されない場合があるため、結果を無条件に待ってはいけません。

LOG = f"verification-output/{ts}/npmtest.log"   # named file: evidence lands here whether or not backgrounding is honoured
task = Bash(command=f"npm test > {LOG} 2>&1; echo EXIT=$? >> {LOG}", run_in_background=true)
if not task.id:                 # request ignored → the command ran inline and LOG is already complete
    pass                        # do NOT wait; there is no task to wait for
else:
    Monitor(pid=task.id)        # bounded: see the contract reference below; progress via `tail -n 5 {LOG}`
# The verdict gate is EXECUTABLE, not prose (#3263). Only outcome=EVIDENCE may be graded:
Bash(command=f"bash \"${{CLAUDE_SKILL_DIR}}/scripts/assert-evidence.sh\" {LOG} --task-id '{task.id or 'none'}'")
# exit 0 EVIDENCE   → grade from LOG's runner summary line
# exit 4 STILL-RUNNING → keep the bounded wait, re-run the gate
# exit 3 COULD-NOT-OBSERVE (0 bytes, no live process) or exit 1 NO-BANNER →
#   the Tests dimension has NO score; report `Tests: COULD-NOT-OBSERVE (assert-evidence exit N, bytes, pid_alive)`
#   and the verdict is BLOCKED. Never emit a grade from an empty run.

計測結果（#3263）：バックグラウンドで実行した3つのテストスイートは0バイトを書き込み、npm 自体のバナーも表示されませんでした。さらにスキルは、発生し得ない完了シグナルを約40分待ちました。空の実行は保留にせず、明確に報告する必要があります。契約と反証された仮説については、Read("references/background-task-contract.md")を実行してください。

パターンの完全なリファレンス（TaskOutputとの使い分け、終了条件ゲート、アンチパターン）：Read("../chain-patterns/references/monitor-patterns.md")。

Agent Teams または通常の Agent モードでの段階的な出力と部分的な結果については、Read("references/progressive-and-partial-results.md")を実行してください。

フェーズ 2.5：ビジュアルキャプチャ（新規 — フェーズ 2 と並行して実行）

詳細の読み込み：自動検出、ルートの検出、スクリーンショットのキャプチャ、AI によるビジョン評価については、Read("references/visual-capture.md") を参照してください。

概要：プロジェクトのフレームワークを自動検出し、開発サーバーを起動してルートを検出し、agent-browser で各ルートのスクリーンショットを撮影し、Claude のビジョン機能で評価します。画像を Base64 で埋め込んだ自己完結型の gallery.html を生成します。

出力：verification-output/{timestamp}/gallery.html — ブラウザーで開くと、AI による評価、スコア、注釈の差分とともにすべてのスクリーンショットを確認できます。

グレースフルデグラデーション：フロントエンドが検出されない場合やサーバーが起動しない場合は、警告を表示してビジュアルキャプチャをスキップします。検証が妨げられることはありません。

---

採点とスコアリング

評価項目、重み、グレードのしきい値、改善の優先順位については、Read("../quality-gates/references/unified-scoring-framework.md") を参照してください。verify 固有の拡張（Visual 評価項目）については、Read("references/quality-model.md") を参照してください。エージェントごとの採点基準については、Read("references/grading-rubric.md") を参照してください。

評価項目レベルのブロッカー（ork-rubric/1.0）

総合スコアは必要ですが、それだけでは十分ではありません。総合スコアが高くても、重大な評価項目の低スコアが平均化されてしまう可能性があります。フェーズ 4（詳細な採点）では、rubric.json から評価項目ごとのしきい値を読み込みます（スキーマ：../../shared/rubric.schema.json）。security の min_blocker は 9.0（固定、ハード）、それ以外のすべての評価項目の min_blocker は 3.0、compliance の min_pass は 6.0、compliance の min_pass は 6.0 です。

• 証拠の結果が COULD-NOT-OBSERVE または NO-BANNER（scripts/assert-evidence.sh による）となった評価項目には、スコアがありません。結果をそのまま報告してください。例：Tests: COULD-NOT-OBSERVE (assert-evidence exit 3, 0 bytes, no live pid)。判定は BLOCKED となります。欠落した評価項目を総合スコアに平均化してはいけません。
• min_blocker を下回る評価項目が一つでもあれば、総合スコアにかかわらず判定は BLOCKED です。明示的に報告してください：Security 3.2/10 (CRITICAL BLOCKER — below min_blocker 9.0)。
• min_pass を下回り（min_blocker 以上である）評価項目がある場合、判定は IMPROVEMENTS RECOMMENDED が上限となり、READY FOR MERGE にはできません。
• BLOCKED 判定では、基準を満たさなかった評価項目をすべて先に列挙し、それぞれについて解除に必要な修正を示します。
• プロジェクトの .claude/policies/verification-policy.json（Policy-as-Code を参照）では、これらのしきい値をより厳しくできます。ただし、ルーブリックのデフォルト値より緩くすることはできません。

しきい値の範囲と報告形式については、references/grading-rubric.md の「Dimension-Level Blockers」セクションを参照してください。

---

連続成功ゲート（連続パスモード）

一度の成功だけでは証明になりません。不安定なテストスイートや実行順に依存するテストスイートは、一度は成功しても次の実行では失敗することがあります。--streak=N を指定すると、verify は N 回連続で成功するまで READY FOR MERGE と判定しません。READY 以外の判定が出ると、カウントは 0 にリセットされます。カウントは .claude/chain/verify-streak.json にスコープごとに保存され、独立した実行間で維持されます。

• --streak=N（N ≥ 2。3 が妥当なデフォルト値です）。指定がない場合は、従来どおり単一実行で成功／失敗を判定します。目標値は .claude/policies/verification-policy.json（"streak_target"）から設定することもできます。フラグの指定が優先されます。
• ゲートは判定の上位に位置し、ブロッカーを緩和することはありません。連続成功回数に達するまで「完了」を保留するだけです。実行ごとに実際のテストを再実行します（成功結果はキャッシュされません。この独立性が重要です）。
• リセット規則：READY FOR MERGE 以外の判定（ブロッカーへの該当、テスト失敗、または IMPROVEMENTS RECOMMENDED）はすべてカウントを 0 にします。部分的な達成は認められません。
• 判定にはカウントが表示されます：STREAK 2/3 — one more green to merge、または streak reset to 0/3 (security 3.2 < 9.0)。
• これは、prd-to-goal の品質連続成功レシピ（#2539）が利用するネイティブの仕組みです。/goal ループと組み合わせてください。ただし、最初に台帳を rm してください。/goal はそのターンの verify を実行する前に until を読み取るため、古い met:true が残っていると実行回数が 0 のまま終了します（「Stale-ledger guard」については streak-gate.md を参照）。

プロトコルの全容 — 台帳のスキーマ、実行ループ、/goal との連携、cover の再利用については、Read("references/streak-gate.md") を参照してください。

---

エビデンスとテストの実行

詳細を読み込むには、Read("rules/evidence-collection.md") を参照してください。Git コマンド、テスト実行のパターン、メトリクスの追跡、検証後のフィードバックについて記載されています。

---

ポリシー・アズ・コード

設定の詳細を読み込むには、Read("references/policy-as-code.md") を参照してください。

検証ルールを .claude/policies/verification-policy.json で定義します。

{
  "thresholds": {
    "composite_minimum": 6.0,
    "security_minimum": 9.0,
    "coverage_minimum": 70
  },
  "blocking_rules": [
    {"dimension": "security", "below": 9.0, "action": "block"}
  ]
}

---

検証マニフェスト（VERIFIED と CLAIMED）

エージェントのスコア、ツールの要約、「X はクリーン／合格／修正済み」という文はすべて、リードが証明を再実行するまでは主張です。判定の前に検証マニフェストを作成し、重要な主張をすべて ✅ VERIFIED（リードが新たに実行。command · exit · key line を引用）、🟡 CLAIMED（エージェント／ツール／ドキュメントが主張し、再実行されていない）、⬜ UNCHECKED、⚪ WAIVED（理由を付して、ブロッキングではないものとして承認）、または 🔴 COULD-NOT-OBSERVE（エビデンスを得ようと試みたものの、何も観測されなかった。引用は assert-evidence.sh の行とし、この状態の重要な行がある場合、判定は単に上限が設けられるのではなく BLOCKED になります）と記します。レポートに転記されたエージェントの「PASS」も依然として CLAIMED です。VERIFIED とは、リード自身が実行したことを意味します。サブエージェントの数値（価格、モデル ID、件数）は、ソースと照合されるまでは CLAIMED です。

**判定ルール：**重要な主張が 🟡 CLAIMED または ⬜ UNCHECKED のまま残っている場合、✅ VERIFIED または ⚪ WAIVED になるまで、判定の上限は IMPROVEMENTS RECOMMENDED です（READY FOR MERGE にはなりません）。これはディメンションレベルのブロッカーにも重ねて適用されます（両方を解消する必要があります）。--streak=N の場合、ストリークはリセットされます。

主張の出所、作成手順、テンプレート、アンチパターン（ロンダリング、楽観的なマーク付け、省略）を含むプロトコル：Read("references/verification-manifest.md")。

到達性：合格に意味はあるか（REACHED と UNREACHED）

出所が示すのは誰が実行したかです。合格に意味があるかどうかまでは示しません。✅ VERIFIED · pytest · exit 0 · 214 passed とある行は誠実な記録でも、価値がない場合があります。スイートに合格しても、そのスイートが変更箇所に到達した証明にはならないためです。2026-07-19 にリリースされたバリデーターは完全に定義され、十分にテストされていましたが、呼び出し箇所から一度も呼び出されていませんでした。すべてのテストは、古いパスに対して合格しました。

差分が追加または変更するテストごとに、マニフェストには2つ目のマークを付けます。

マーク	意味
🟢 REACHED	変更がない場合はテストが失敗し、変更がある場合は合格することが実行によって示されています。両方のコマンドを引用します。
🟡 UNREACHED	テストは合格していますが、失敗するところが確認されたことはありません。エビデンスにはなりません。
⚪ WAIVED	1行の理由を付して、意図的に承認されています。

**判定ルール：**この差分で追加または変更されたテストが 🟡 UNREACHED の場合、証明が示されるか、その行が ⚪ WAIVED になるまで、判定の上限は IMPROVEMENTS RECOMMENDED です。これは出所による上限とディメンションブロッカーに重ねて適用されます。すべて解消する必要があります。--streak=N の場合、ストリークはリセットされます。

証明を安全にする2つの順序ルールがあり、どちらも実際に発生した損害に基づいています。変更を加える前にコミットする（git checkout -- は HEAD の状態に戻すため、未コミットの作業を変更すると、復元時に変更が失われます）。また、新しいユニットではなく呼び出し箇所を変更する（ユニットを変更しても、そのユニットのテストが機能することしか証明できず、呼び出し箇所が使われていない状態を見逃します）。

このスキルは変更を行いません。テストファイルの作成も、ソースの編集も行いません。証明は上流の implement または cover が作成し、ここで評価します。証明がない場合、その行は 🟡 UNREACHED となり、判定の上限が設けられます。

範囲、5段階の証明手順、変更が重要な証明となる条件、テンプレート、アンチパターン（カバレッジを証明と見なすこと、バッチ単位の証明、表面的な変更）を含むプロトコル：Read("references/reachability-proof.md")。

レポート形式

詳細を読み込むには、Read("references/report-template.md") を参照してください。概要：

# Feature Verification Report

**Composite Score: [N.N]/10** (Grade: [LETTER])

## Verdict
**[READY FOR MERGE | IMPROVEMENTS RECOMMENDED | BLOCKED]**

[--streak=N mode only: **STREAK [current]/[target]** — READY FOR MERGE requires the full target; any non-ready run resets to 0.]

## Verification Manifest
[✅ VERIFIED · 🟡 CLAIMED · ⬜ UNCHECKED · ⚪ WAIVED · 🔴 COULD-NOT-OBSERVE — any load-bearing 🟡/⬜ caps the verdict below READY FOR MERGE; any load-bearing 🔴 makes it BLOCKED]
[Reached: 🟢 REACHED · 🟡 UNREACHED · n/a — any 🟡 on a test this diff added/modified also caps the verdict]
| # | Load-bearing claim | Asserted by | Provenance | Reached | Evidence (cmd · exit · key line) |

完了の最終確認（最後のステップ）。 レポートの後、ユーザーが承認するまでは判定は「完了」ではありません。Read("../../shared/rules/done-signoff.md") を読み込み、3つのラベルを変更せずに、その質問を1つ尋ねてください："Accept done"、"Show me the evidence"、"Not satisfied"。BLOCKED の項目または FAIL があれば、先に示してください。"Show me the evidence" の場合は、指定されたチェックをその場で再実行し、もう一度尋ねてください。非対話型の実行（claude -p、Workflow のフェーズ）では質問を省略し、判定をデータとして返してください。

プッシュ通知（CC 2.1.110+）： 複雑な変更では、5分を超える検証の実行はよくあります。最終判定が出たら、PushNotification を呼び出してユーザーに通知してください。ユーザーはターミナルから離れている可能性があります。"Push when Claude decides" の設定を有効にした Remote Control が必要です。設定がないユーザーには、通知はエラーなく送信されません。

PushNotification(
  message=f"ork:verify complete — {verdict} · {score}/10 · {blockers_count} blockers",
  status="proactive"
)

---

参考資料

Read("references/<file>") を使って必要に応じて読み込みます。

ファイル	内容
verification-phases.md	8フェーズのワークフロー、エージェントの起動定義、Agent Teams モード
visual-capture.md	フェーズ 2.5：スクリーンショットのキャプチャ、AI による画像認識、ギャラリーの生成
quality-model.md	スコアリングの項目と重み（8項目に統合）
grading-rubric.md	エージェントごとのスコアリング基準
report-template.md	視覚的な証拠セクションを含む完全なレポート形式
verification-manifest.md	VERIFIED と CLAIMED の来歴台帳：状態、判定ルール、主張のソース、テンプレート、アンチパターン
reachability-proof.md	REACHED と UNREACHED：mutate→red→restore→green の証明、コミット優先と呼び出し箇所のルール、判定の上限、アンチパターン
alternative-comparison.md	アプローチ比較テンプレート
orchestration-mode.md	Agent Teams と Agent Tool
policy-as-code.md	検証ポリシーの設定
verification-checklist.md	事前チェックリスト
streak-gate.md	--streak=N 連続合格ゲート：台帳スキーマ、リセットルール、/goal の接続、カバレッジの再利用

ルール

Read("rules/<file>") を使って必要に応じて読み込みます。

ファイル	内容
scoring-rubric.md	複合スコア、評価、判定
evidence-collection.md	証拠の収集とテストのパターン

検証ゲート（横断的に適用）

Read("../../shared/rules/verification-gate.md") を読み込んでください。これは、すべてのスキルで完了を主張する際に適用される、最低5ステップのゲートです。これは必須です。新たな検証証拠なしに完了を主張してはいけません。

作成側のエージェントの所見も、証拠再生ゲートを満たす必要があります（機械的に検証可能な {file, line, quote} または {command, expected_output} 形式で、判定やスコアに含める前に再生すること）。Read("../../shared/rules/evidence-replay.md") を参照してください。

迎合防止プロトコル

Read("../../shared/rules/anti-sycophancy.md") を読み込み、すべての検証エージェントが、ことさらに同意することなく所見を直接報告するようにしてください。「問題ないはずです」は証拠ではありません。「テスト合格（終了コード 0、47/47）」は証拠です。

エージェントステータスプロトコル

すべての検証エージェントは、標準化されたプロトコルに従って報告しなければなりません。Read("../../shared/status-protocol.md") を参照してください。懸念事項がある場合に DONE と報告してはいけません。不確かな作業を黙って提出してはいけません。

---

エージェントの連携

SendMessage（エージェント間の所見）

セッションをまたぐ返信は親に届きます（CC 2.1.248）： サブエージェントが別のセッションに SendMessage を送信した場合、返信はサブエージェントではなく親セッションの会話に届きます。サブエージェントは送信後に作業を続け、親が返信を読みます。セッションをまたぐ SendMessage / ListAgents は、テレメトリが無効でも Bedrock、Vertex、Foundry で動作します（CC 2.1.248）。

セキュリティエージェントが重大な問題を見つけた場合は、他の検証エージェントと共有してください。

SendMessage(to="test-generator", message="Security: SQL injection in user_service.py:88 — add parameterized query test")
SendMessage(to="code-quality-reviewer", message="Security finding at user_service.py:88 — flag in review")

Skill Chain

検証後、すべてのゲートを通過した場合はコミットまで続けます。

TaskCreate(subject="Commit verified changes", activeForm="Committing")
TaskUpdate(taskId=commit_id, addBlockedBy=[verify_task_id])
# Then: commit

セッションの復旧（CC 2.1.108+）： アイドル状態が続いた後や中断後は、/recap を使用して、チェックポイントからの再開状態とともに会話のコンテキストを復元してください。CC 2.1.110 以降はデフォルトで有効です（テレメトリーが無効の場合も含みます）。

品質基準

以下をすべて満たしていれば完了です。

• 判定は READY FOR MERGE／IMPROVEMENTS RECOMMENDED／BLOCKED のいずれか一つとし、複合スコアと各次元のスコアをすべて明記します
• 影響の大きい「合格／問題なし／修正済み」という主張はすべて Verification Manifest に記載し、VERIFIED（担当者が再実行し、コマンド・終了コード・主要行を明記）、CLAIMED、UNCHECKED、または WAIVED のいずれかにします
• テストの証拠には、実際のランナーのサマリー行（コマンド、終了コード、合格数）を使用します。言い換えは不可です
• 差分で追加または変更されたすべてのテストに Reached マークを付けます。REACHED には失敗した実行と合格した実行の両方を記載します。成功のみの行は証拠ではなく UNREACHED です
• いずれかの次元が min_blocker を下回る場合、複合スコアにかかわらず BLOCKED と報告します
• READY FOR MERGE とできるのは、影響の大きい主張に CLAIMED／UNCHECKED が残っておらず、差分で追加されたテストに UNREACHED がなく（かつ --streak=N の場合は、連続成功の要件を満たしている）場合のみです
• assert-evidence.sh の結果が EVIDENCE でない証拠に基づいて、いずれの次元も VERIFIED と報告してはいけません。COULD-NOT-OBSERVE または NO-BANNER の実行結果は、報告書内でそのままの表記で記載し、黙って再評価してはいけません

成功チェックを信頼する前に

障害の有無にかかわらず同じ内容を出力するチェックは何も測定していませんが、それでも答えを返し、その答えは証拠のように見えます。paired-probe スキルはこの問題に対応するもので、モデルから呼び出せます（scripts/assert-evidence.sh は Tests 次元におけるその実例で、実行時に観測可能な証拠が得られなかった場合は判定を拒否します）。判定を左右する PASS が出るあらゆるチェックに適用できます。特に、検出結果ゼロを報告したスイープや、予期せず通過したゲートに有効です。チェックではなく、判定を拒否します。

関連スキル

• ork:implement - 検証を含む完全な実装
• ork:review-pr - PR 専用の検証
• testing-unit / testing-integration / testing-e2e - テスト実行のパターン
• ork:quality-gates - 品質ゲートのパターン
• browser-tools - ビジュアルキャプチャのためのブラウザー自動化

---