vibe

Vibe Skill

目的： このコードはリリースできる状態ですか？

ループ内の位置

運用ループの**6（受け入れを証明してビードを完了する）**における、スライス単位の品質ゲートです。スライスの変更を受け取り、複雑さ、アーキテクチャ、セキュリティ、意図との適合性についてPASS/WARN/FAILを出力します。Vibeは「このスライスはslice-validationの集計に加算できる状態ですか？」に答えます。これは、スライスで最初に失敗するテストの代わりではありません（テストは動作を証明し、Vibeはそこに至るコードを評価します）。

3つのステップ：

1. 複雑さの分析 — ホットスポットを見つける（radon、gocyclo）
2. バグ探しの監査 — 具体的なバグを体系的に調査する
3. Councilによる検証 — 複数モデルによる判断

---

クイックスタート

/vibe                                    # validates recent changes
/vibe recent                             # same as above
/vibe src/auth/                          # validates specific path
/vibe --quick recent                     # fast inline check, no agent spawning
/vibe --structured recent                # 6-phase verification report (build→types→lint→tests→security→diff)
/vibe --deep recent                      # 3 judges instead of 2
/vibe --sweep recent                     # deep audit: per-file explorers + council
/vibe --mixed recent                     # cross-vendor (Claude + Codex)
/vibe --preset=security-audit src/auth/  # security-focused review
/vibe --explorers=2 recent               # judges with explorer sub-agents
/vibe --debate recent                    # two-round adversarial review
/vibe --tier=quality recent              # use quality tier for council calls

---

実行手順

ステップ0：過去のレビューコンテキストを読み込む

レビューを始める前に、過去のコードレビューや既知のパターンから関連する知見を取得します。

if command -v ao &>/dev/null; then
    ao lookup --query "<target-scope> code review patterns" --limit 3 2>/dev/null || true
fi

取得した知識を適用する（結果が返された場合は必須）：

知見やパターンが返された場合、単に受動的なコンテキストとして読み込むだけにしてはいけません。返された項目ごとに、次の手順を実行します。

1. 確認します。この知見はレビュー対象のコードに当てはまりますか？（はい／いいえで回答）
2. はいの場合：レビューにknown_riskとして含めます。パターン、確認すべき点、コードにそのパターンが見られるかどうかを記載します。
3. 指摘に影響する場合は、レビュー出力でファイル名を引用して知見の出典を示します。

適用後、引用を記録します。

ao metrics cite "<learning-path>" --type applied 2>/dev/null || true

aoが利用できない場合、または結果が返されない場合は、何もせずにスキップします。

プロジェクトのレビュアー設定： .agents/reviewer-config.mdが存在する場合、その完全な設定（reviewers、plan_reviewers、skip_reviewers）が審査員の選定のためにcouncilへ渡されます。skills/council/SKILL.mdのステップ1bを参照してください。

Crankチェックポイントの検出

git diffで変更ファイルをスキャンする前に、crankチェックポイントが存在するか確認します。

if [ -f .agents/vibe-context/latest-crank-wave.json ]; then
    echo "Crank checkpoint found — using files_changed from checkpoint"
    FILES_CHANGED=$(jq -r '.files_changed[]' .agents/vibe-context/latest-crank-wave.json 2>/dev/null)
    WAVE_COUNT=$(jq -r '.wave' .agents/vibe-context/latest-crank-wave.json 2>/dev/null)
    echo "Wave $WAVE_COUNT checkpoint: $(echo "$FILES_CHANGED" | wc -l | tr -d ' ') files changed"
fi

crankチェックポイントが利用できる場合は、git diffで再検出する代わりに、そのfiles_changedリストを使用します。これにより、vibeがcrankの変更したファイルを正確に検証できます。

ステップ1：対象を決定する

対象が指定されている場合： その対象を直接使用します。

対象が指定されていない場合、または「recent」の場合： gitから自動検出します。

# Check recent commits
git diff --name-only HEAD~3 2>/dev/null | head -20

何も見つからない場合は、ユーザーに確認します。

事前確認：ファイルが見つからない場合： 「PASS（レビュー対象の変更なし）— 変更されたファイルは検出されませんでした。」をすぐに返します。 ファイルリストが空の場合は、エージェントを起動してはいけません。

ステップ1.5a：構造化検証パス（--structuredモード）

--structuredフラグが設定されている場合、councilフローの代わりに、6フェーズの機械的な検証パイプラインを実行します。PRゲートやCI統合に適した、機械可読な検証レポートを生成します。

フェーズ：Build → Types → Lint → Tests → Security → Diff Review。

完全なレポートテンプレートとフェーズごとのコマンドについては、references/verification-report.mdを読みます。各フェーズはフェイルファストです。Buildが失敗した場合は、残りのフェーズをスキップし、NOT READYを報告します。

すべてのフェーズが完了したら、構造化レポートを.agents/council/YYYY-MM-DD-verification-<target>.mdに書き込み、要約表をユーザーに出力します。

使用する場面： PR前のゲート、CI統合、判断ベースではなく機械的な合否判定が必要な場合。

ステップ1.5：高速パス（--quickモード）

--quickフラグが設定されている場合、重い前処理となるステップ2aから2eに加え、2.5と2fをスキップし、ステップ2.3、2.4、2g、ステップ3の後、ステップ4に進み、インラインcouncilを実行します。ドメイン別チェックリスト、コンパイル時の予防策の読み込み、テストピラミッドの棚卸し、インラインでの製品コンテキストは低コストで効果が高いため、クイックモードでも実行します。複雑さの分析（ステップ2）も低コストで有益なため、引き続き実行します。

理由： ステップ2.5と2a〜2fでは、主に複数の審査員に渡すcouncil用パケットの作成に使う前処理に30〜90秒かかります。--quickモード（単一のインラインエージェント）では、これらの入力にかかるコストに見合う価値はありません。一方、テストピラミッドと製品コンテキストの確認は、インラインレビューに引き続き有意義な影響を与えます。

ステップ 2：複雑度分析の実行

言語検出の事前チェック、言語ごとのアナライザーコマンド（radon/gocyclo）、スコアの解釈表が必要な場合は、references/complexity-analysis.md を読んでください。アナライザーを実行する前に、差分に含まれる言語で絞り込んでください。

ステップ 2.3：ドメイン固有チェックリストの読み込み

対象ファイル内のコードパターンを検出し、該当するドメイン固有チェックリストを standards/references/ から読み込みます。

トリガー	チェックリスト	検出方法
SQL/ORM コード	sql-safety-checklist.md	ファイルに SQL クエリ、ORM のインポート（database/sql、sqlalchemy、prisma、activerecord、gorm、knex）、または変更セット内のマイグレーションファイルが含まれる
LLM/AI コード	llm-trust-boundary-checklist.md	ファイルが anthropic、openai、google.generativeai をインポートするか、*llm*、*prompt*、*completion* のパターンに一致する
並行処理コード	race-condition-checklist.md	ファイルで goroutine、threading、asyncio、multiprocessing、sync.Mutex、concurrent.futures、または共有ファイル I/O パターンを使用している
Codex スキル	codex-skill.md	skills-codex/ 配下のファイル、または *codex*SKILL.md、convert.sh、skills-codex-overrides/、変換スクリプトに一致するファイル

該当するチェックリストごとに、Read ツールで読み込み、関連項目を context.domain_checklists として council packet に含めてください。複数のチェックリストを同時に読み込めます。

パターンに一致しない場合は、何も通知せずにスキップします。このステップは --quick モードとフルモードの両方で実行されます（ドメインチェックリストは読み込みコストが低く、価値が高いためです）。

ステップ 2.4～2f、2h、3～3.6（詳細チェックと事前審議の準備）： コンパイル済みの予防策、過去の指摘事項、事前審議の詳細分析チェック、製品コンテキスト、仕様の読み込み、抑制設定、事前検死との照合、モデルのコスト階層については、references/deep-checks.md を読んでください。--quick モード以外では自動的に読み込まれます。--quick モードでは、ステップ 2g に直接進んでください。

コンパイル済み予防策の入力： 利用可能な場合は .agents/pre-mortem-checks/ と .agents/planning-rules/ を読み込みます。これらのコンパイル済み成果物には、レビューに役立つ過去の指摘事項に基づく known_risks が含まれています。一致した指摘 ID を審議コンテキストに引き継ぎ、審査担当者が、再発見を防ぐフィードバックループが機能したかを評価できるようにしてください。

ステップ 2a：過去の指摘事項の確認

--quick の場合はスキップします。 .agents/findings/registry.jsonl から過去の指摘事項を読み込みます。

ステップ 2b：制約テスト

--quick の場合はスキップします。 .agents/constraints/ のコンパイル済み制約テストを実行します。

ステップ 2c：メタデータの確認

--quick の場合はスキップします。 ファイルのメタデータに一貫性があることを確認します。

ステップ 2.5：OL 検証

--quick の場合はスキップします。 組織の lint チェックを実行します。

ステップ 2d：ナレッジ検索

--quick の場合はスキップします。 ao lookup を使って、関連する過去の知見を検索します。

ステップ 2e：バグ調査または詳細監査

--quick の場合はスキップします。

パス A — 詳細監査（--deep または --sweep）：

完全な手順については references/deep-audit-protocol.md を読んでください。概要は次のとおりです。

1. 対象ファイルを行数に基づいて 3～5 個のバッチに分割します
2. 最大 8 つの Explore エージェントを並列に起動し、それぞれが各ファイルに対して必須の 8 カテゴリチェックリストを実施します
3. すべての探索結果を .agents/council/sweep-manifest.md の監査マニフェストに統合します
4. 監査マニフェストを審議パケットに含め、審査担当者が裁定モードに切り替わるようにします

理由： 汎用の審査担当者には満足バイアスがあり、実際の問題数にかかわらず、少数の指摘を見つけると調査を止めてしまいます。ファイルごとに探索担当者を割り当て、カテゴリ別チェックリストを使うことで、このバイアスを軽減し、審議で裁定する前に具体的な行単位の問題を明らかにできます。

パス B — 軽量バグ調査（デフォルト。--deep／--sweep なし）：

対象ファイルに対して、積極的なバグ調査監査を実施します。

ステップ 2f：Codex レビュー

--quick の場合はスキップします。 --mixed が指定され、Codex CLI が利用可能な場合は、並列レビューのために差分の先頭 2000 文字を Codex に送信します。Codex のコンテキスト予算内に収めるため、入力は 2000 文字までに制限します。

ステップ 3：製品コンテキスト

別個の judge-fanout ステップとして実行する --quick の場合はスキップします。 PRODUCT.md が存在し、ユーザーが明示的な --preset の上書きを指定していない場合、クイックモードでは単一エージェントによるレビュー内で DX の期待事項も読み込みます。クイック以外のモードでは、DX（開発者体験）judge を追加します：独立した judge が 2 つ、DX judge が 1 つ（合計 3 つの judge）。DX judge は、コードが製品で明示されているペルソナと価値提案に沿っているかを評価します。

ステップ 2g：テストピラミッドの一覧（必須）

完全な一覧作成手順が必要な場合は、references/test-pyramid-inventory.md を読みます。内容は、モジュールごとの L0～L3 カバレッジチェック、BF1～BF5 の境界チェック、weighted_score の計算式、満足度スコアの公開、council packet の test_pyramid JSON 形式、判定ルールです。--quick モードとフルモードの両方で実行します。ファイルの存在チェックは低コストです。L0～L1 は 1 倍、L2 は 3 倍、L3 以上は 5 倍の重み付けにします。L0～L1 のみで weighted_score < 0.3 の場合は WARN です。

ステップ 2g.1：シナリオ→テストのカバレッジ（スライスにシナリオがある場合は必須）

テストピラミッドの一覧（2g）では、テストが存在することと、その構成が適切であることをチェックします。スライスの各受け入れシナリオがテストに対応付けられているかはチェックしません。そのためのリーフゲートは scripts/check-bead-scenario-coverage.sh（C2、ag-9jle.4）です。このスクリプトは bead の ## Scenarios ブロック（または .feature ファイル）を解析し、@covered-by:<test-path> リンクがないシナリオがあると FAIL になります。つまり、カバレッジ率から逆方向に確認するのではなく、動作から順方向に確認します。

# When validating a tracked bead with a ## Scenarios block:
bash scripts/check-bead-scenario-coverage.sh --bead <bead-id> --json

# When validating a .feature directly:
bash scripts/check-bead-scenario-coverage.sh skills/<skill>/references/<name>.feature --json

ここでの FAIL は WARN ではなく、雰囲気による判定を防ぐブロッカーです。「テストが存在する」ことやカバレッジ率だけでは不十分です。すべてのシナリオで、対応するテストを宣言する必要があります。未カバーの各 Scenario: の直上に @covered-by:<test-path>（任意で ::<TestName>）を追加します。スライスにシナリオがない場合に限りスキップします（自由記述の受け入れ条件は、まずシナリオにする必要があります。ワークフローの契約を参照してください）。このチェックアウトで対応するテストを実行できる場合は、テストが存在するだけでなく実際に PASS することを求めるため、--run を優先してください。

ステップ 4：Council の検証を実行する

仕様が見つかった場合 — code-review プリセットを使用します：

/council --preset=code-review validate <target>

• error-paths：すべてのエラー処理経路をたどります。捕捉されていないものはありますか？何が黙って失敗しますか？
• api-surface：すべての公開インターフェースをレビューします。契約は明確ですか？破壊的変更はありますか？
• spec-compliance：実装を仕様と照合します。何が欠けていますか？何が仕様と異なりますか？

仕様の内容は council packet のコンテキストに挿入されるため、spec-compliance judge は実装と照合できます。

仕様が見つからない場合 — 独立した judge 2 つ（perspective なし）：

/council validate <target>

perspective ラベルなしの独立した judge が 2 つです。重要度の高いレビューでは、--deep を使って judge を 3 つにします。--quick（インラインの単一エージェントチェック）または --mixed（Codex とのクロスベンダー）で上書きできます。

Council に渡される情報：

• レビュー対象のファイル
• 複雑性のホットスポット（ステップ 2 の結果）
• Git diff のコンテキスト
• 仕様の内容（見つかった場合は context.spec 内）
• スイープマニフェスト（--deep または --sweep の場合は context.sweep_manifest 内 — judge は裁定モードに切り替わります。references/deep-audit-protocol.md を参照してください）

すべての council フラグはそのまま渡されます：--quick（インライン）、--mixed（クロスベンダー）、--preset=<name>（perspective を上書き）、--explorers=N、--debate（対立的な 2 ラウンド）、--tier=<name>（モデルのコスト階層：quality/balanced/budget）。Quick Start の例と /council のドキュメントを参照してください。

ステップ 4.5：自己採点禁止の不変条件（作成者 ≠ 検証者）

受け入れ判定を、成果物の作成者自身が採点してはなりません。作成時のコンテキストが出した判定には自己相関があり、バグを生んだのと同じ盲点が見逃されてしまいます。これが自己採点禁止の不変条件（ag-lmdx.4）です。evidenced->validated 遷移を保護する、信頼ドメインの独立性チェックです。

ルール： 判定者のコンテキストは作成者のコンテキストと異なる必要があります。検証は作成セッション内で実行してもかまいませんが、判定者は、作成時のコンテキストを持たないものとして振る舞う、コンテキストが分離された新規の ブラインドサブエージェント でなければなりません。作成者のコンテキストである author_id とは別に、judge_id（分離されたサブエージェントのコンテキスト）を記録してください。ステップ 4 で起動する評議会の判定者は、コンテキストが分離されたサブエージェントであればこの条件を満たします。作成エージェント自身によるインラインの自己レビューは条件を満たしません。

ブラインドサブエージェント判定者の起動（仕組み。作成セッション内で検証する場合は必須）：

コードを作成したセッション内で判定を行う場合、受け入れ判定者を新しいコンテキストのサブエージェントとして必ず起動してください。インラインで採点してはなりません。具体的な手順は次のとおりです。

1. Agent／Task ツールを使って判定者を起動します（ステップ 4 の評議会が使用するものと同じ、コンテキストが分離されたサブエージェントです）。サブエージェントが判定者であり、これを統括する作成エージェントは判定者ではありません。
2. ブラインド判定者に渡すのは、受け入れに必要な入力 のみ とします。作成時の会話、計画、推論は渡してはなりません。
   • 審査対象の 差分／成果物（変更されたファイルと git diff）。
   • 受け入れシナリオ（bead の ## Scenarios ブロックまたは .feature ファイル）、および関連する仕様、複雑さに関するホットスポット、ドメインチェックリスト。
   • 判定の契約（skills/council/schemas/verdict.json）。 作成時の記録、中間設計メモ、「これが正しいと思う理由」といった説明は渡さないでください。判定者は、作成時のコンテキストを持たないものとして振る舞います。
3. サブエージェントの PASS／WARN／FAIL を受け入れ判定として使用します。judge_id には分離されたサブエージェントのコンテキストを、author_id には作成時のコンテキストを設定し、ao turn verify が消費するターン入力に記録します（以下の「適用」を参照）。

これにより、同じセッション内での検証が信頼できるものになります。成果物を作成していないコンテキストが判定を行うため、作成者の盲点が見逃されません。

判定者のコンテキストが作成者のコンテキストと同じ場合（judge_id == author_id）、つまりブラインドサブエージェントを起動せず、作成エージェントが自己採点した場合は、PASS 判定の出力を拒否してください。代わりに、ブラインドサブエージェント判定者を通じて判定をやり直してください。

例外： --allow-self（デフォルトは OFF）を指定すると、インラインの代替手段に限り、この不変条件を免除できます（サブエージェントのランタイムが利用できない場合など）。これを使用した判定には自己採点の印が付き、後続の ao turn verify では独立検証済みではなく、免除扱いとして報告されます。

適用： ao turn verify <bead> は、ターン入力ファイルの author_id／judge_id から author_neq_validator 述語を評価します。--allow-self が渡されない限り、自己採点された判定では Evidenced-Turn DoD が失敗します。evidenced->validated ガードは、自己採点された判定を拒否します。

ステップ 5：評議会によるチェック

各判定者は、次の観点からレビューします。

観点	確認する内容
正確性	コードは主張どおりに動作しますか？
セキュリティ	インジェクション、認証の問題、シークレット
エッジケース	null の処理、境界条件、エラー
品質	デッドコード、重複、明瞭さ
複雑さ	循環的複雑度の高さ、深いネスト
アーキテクチャ	結合、抽象化、パターン

ステップ 6：判定を解釈する

評議会の判定：

評議会の判定	Vibe の結果	アクション
PASS	リリース可能	マージ／デプロイ
WARN	懸念事項をレビュー	対処するか、リスクを受け入れる
FAIL	準備未完了	問題を修正

ステップ 7：Vibe レポートを作成する

出力先： .agents/council/YYYY-MM-DD-vibe-<target>.md（date +%Y-%m-%d を使用）

完全な Vibe レポートの Markdown テンプレートについては、references/report-format.md をお読みください。レポートには、複雑度分析、評議会の判定表、共通の指摘事項・重大な指摘事項・参考情報、すべての指摘事項（--deep／--sweep の場合）、推奨事項、判断用チェックボックスが含まれます。

ステップ 8：ユーザーに報告する

ユーザーに次の内容を伝えます。

1. 複雑度が高い箇所（該当する場合）
2. 評議会の判定（PASS／WARN／FAIL）
3. 主な懸念事項
4. Vibe レポートの場所

ステップ 9：ラチェットの進捗を記録し、ステップ 9.5：調査結果をフライホイールに反映する

PASS／WARN／FAIL のラチェット記録ルール、失敗時の再試行における指摘事項の抽出形式、および .agents/findings/registry.jsonl の書き込み仕様（dedup_key、applicable_when の語彙、アトミックなリネームのルール）と、その後に実行する hooks/finding-compiler.sh については、必要に応じて references/post-verdict-actions.md をお読みください。

ステップ 10：テストビードをクリーンアップする

検証の完了後、古くなったテストビード（bd list --status=open | grep -iE "test bead|test quest"）を bd close でクローズして、ビードの汚染を防ぎます。bd を利用できない場合はスキップしてください。

---

ワークフローとの統合

/implement issue-123
    │
    ▼
(coding, quick lint/test as you go)
    │
    ▼
/vibe                      ← You are here
    │
    ├── Complexity analysis (find hotspots)
    ├── Bug hunt audit (find concrete bugs)
    └── Council validation (multi-model judgment)
    │
    ├── PASS → ship it
    ├── WARN → review, then ship or fix
    └── FAIL → fix, re-run /vibe

---

例

ユーザーの指示： 「最新の変更を簡単に検証してください。」

実行内容：

/vibe recent

最近の変更を検証する

/vibe recent

最近の変更の複雑度を分析してから、評議会がレビューします。

特定のディレクトリを検証する

/vibe src/auth/

auth ディレクトリの複雑度分析と評議会によるレビューを行います。

詳細なレビュー

/vibe --deep recent

複雑度分析と 3 人の判定者による詳細なレビューを行います。

ベンダー横断の合意形成

/vibe --mixed recent

複雑度分析と Claude および Codex の判定者によるレビューを行います。

追加の例（仕様準拠を含むセキュリティ監査、PRODUCT.md を使った開発者エクスペリエンスのコードレビュー、高速なインラインチェック）については、references/examples.md を参照してください。

---

トラブルシューティング

問題	原因	解決策
"COMPLEXITY SKIPPED: radon not installed"	Python の複雑度分析ツールがありません	pip install radon でインストールするか、複雑度分析をスキップします（評議会の実行は継続します）。
"COMPLEXITY SKIPPED: gocyclo not installed"	Go の複雑度分析ツールがありません	go install github.com/fzipp/gocyclo/cmd/gocyclo@latest でインストールするか、スキップします。
Vibe が PASS を返す一方で、制約テストが失敗する	評議会の LLM が機械的な違反を見逃しています	制約テストの結果は .agents/council/<timestamp>-vibe-*.md で確認してください。制約テストの失敗は評議会の PASS 判定より優先されます。違反を修正して再実行してください。
Codex のレビューがスキップされる	--mixed が指定されていない、Codex CLI が PATH にない、または未コミットの変更がない	Codex のレビューはオプトインです。有効にするには --mixed を指定してください。また、Codex CLI が PATH にあり、未コミットの変更が必要です。
"No modified files detected"	作業ツリーがクリーン、または最近のコミットがありません	変更を加えるか、対象パスを明示的に指定してください：/vibe src/auth/。
仕様準拠判定者が起動されない	beads／plans に仕様が見つかりません	コミットメッセージで bead ID を参照するか、.agents/plans/ に計画ドキュメントを作成してください。仕様がない場合、Vibe は独立した判定者 2 人を使用します（--deep の場合は 3 人）。

---

書き込み時の品質フック

hooks/write-time-quality.sh の PostToolUse フックは、Write／Edit ツールの呼び出し後に自動実行され、レビュー時ではなく編集時に一般的なアンチパターンを検出します。次の項目をチェックします。

• Go： エラーの未チェック、ライブラリコード内の fmt.Print
• Python： 裸の except:、eval／exec、公開関数の型ヒント不足
• Shell： set -euo pipefail の不足、変数の引用符不足

このフックは実行をブロックせず（常に 0 を返します）、警告を JSON で出力します。設計の全容については、references/write-time-quality.md を参照してください。

関連項目

• skills/council/SKILL.md — マルチモデル検証評議会
• skills/complexity/SKILL.md — 単独での複雑性分析
• skills/bug-hunt/SKILL.md — 予防的なコード監査とバグ調査
• .agents/specs/conflict-resolution-algorithm.md — エージェントの調査結果間の競合解決
• テスト — テスト生成とカバレッジ分析
• パフォーマンス — パフォーマンスのプロファイリングとベンチマーク

参考ドキュメント

• references/vibe.feature — 実行可能な仕様：評議会の判定（複雑性／アーキテクチャ／セキュリティ／意図との適合性）、CRITICAL の場合はブロック、verdict.json（soc-qk4b）
• references/complexity-analysis.md
• references/deep-checks.md
• references/post-verdict-actions.md
• references/test-pyramid-inventory.md
• references/verification-report.md
• references/write-time-quality.md
• references/deep-audit-protocol.md
• references/examples.md
• references/go-patterns.md
• references/go-standards.md
• references/json-standards.md
• references/markdown-standards.md
• references/patterns.md
• references/python-standards.md
• references/report-format.md
• references/rust-standards.md
• references/shell-standards.md
• references/typescript-standards.md
• references/vibe-coding.md
• references/vibe-suppressions.md
• references/test-pyramid-weighting.md
• references/yaml-standards.md