dogfood-cli

vigiles CLI をドッグフードする（エキスパートによる発見＋修正のファンアウト）

vigiles を自分自身や実際のプラグインに対して実行し、実際のバグを見つけて修正するための、繰り返し可能な方法です。報告するだけではありません。この方法で、2026-07 バッチではソースコードを追跡して確認したバグを 14 件発見し、修正しました。

使用する場面

• 「CLI をドッグフードする」「ソースを追跡してさらにバグを見つける」「vigiles 自体をエージェントに分担して監査させる」「audit/lint の誤検出を探す」。
• 既知のバグが 1 件だけの場合には使いません（そのまま修正してください）。リリース済みのコンシューマー向け機能にも使いません（これはコントリビューター専用の開発プロセスであり、.claude/ は公開されていません）。

ループ

fan out (parallel experts) → synthesize + VERIFY each finding → fix directly
   → regression test → build → targeted test → commit per theme → FULL SUITE → push

1. 異なる対象領域に分担する

複数のエージェント（Sonnet — 並行して読み取りやトレースを行うのに低コストで、各エージェントで統合する必要はありません）を起動し、互いの作業が重ならないよう、それぞれが 1 つの対象領域を担当します。成果が出ている対象領域の一覧は次のとおりです。

• compile / eject — ラウンドトリップの正確性、フロントマター／データの消失、整合性。
• audit / lint の誤検出 — 実際のプラグインが CLEAN のままであること（誤警報を出さない）；存在しないパス；誤って解釈された glob／引用符トークン；コメント内だけの一致。
• init / scaffold のエッジケース — package.json がない場合、設定駆動の harness、不正なフロントマター、--target、生成された CI ワークフロー、--test／--lint。
• config parse-don't-validate — .vigilesrc.json の重大度（"off"／0／1／2）、文字列または配列のキー、未知の値。
• CLI のエラー表示 UX — 未知のフラグ／harness では、わかりやすいメッセージを表示して終了コード 2 で終了し、Node のスタックトレースをそのまま表示しないこと。
• ハーネス間（CC + Codex）とブラウザー／ディスク間の一致 — scanFiles はバイト単位で scanPlugin と一致すること；Codex 形式のリポジトリが CC としてスキャンされないこと。

各エージェントには次のように伝えてください。バグを見つけたら、必ずソースコードを追跡して file:line と修正案を示してください。トレースのない指摘は手がかりであり、バグではありません。

2. 結果を統合し、自分で検証する

エージェントは過剰に報告します。何かに手を加える前に、それぞれの指摘を自分で再現してください（実際にビルドした CLI を一時的なフィクスチャ、またはベンダー管理下の test/dogfood/* プラグインに対して実行します）。再現しないものは破棄してください。正確な file:line を確認してください。

3. 直接修正する — 報告しない

再現可能でソースコードを追跡して確認できるバグには、課題報告は不要です。修正してください。修正方針が本当に曖昧な場合（複数の妥当な解釈がある、または創業者の判断を仰ぐべきアーキテクチャ上重要な変更である）に限り、課題を報告してください。「報告ではなく修正」が、このループにおける創業者の継続的な方針です。

修正ごとに、次の手順を実施します。

• 再現 → 修正 → 回帰テスト → npm run build → 対象を絞った vitest → コミット。
• 1 コミットにつき 1 つのテーマ。 Conventional Commit 形式の件名を使い、本文の最後には Co-Authored-By: Claude … トレーラーを付けます。セッション URL や生のモデル ID は絶対に含めないでください（公開リポジトリです。no-session-links／モデル ID ルールを参照）。
• 修正は高精度である必要があります。誤検出の修正によって、ひそかに見逃しが増えてはいけません（誤警報を減らす代わりに、本物を見逃さないでください）。
• アーキテクチャを守ってください。共有検出器の定義場所は 1 か所のみです（one-detector-no-drift）；core ⊄ adapter；src/core/** および非依存の検出器に CC 固有の記述を入れないでください。

苦労して身につけた規律（教訓）

• 共有ファイルを変更する修正は、順番に実施するかマージしてください（src/cli.ts、 src/scan-core.ts）。同じファイルを並行して編集すると競合します。順番に作業するか、 各エージェントに専用の git worktree（isolation: "worktree"）を割り当ててください。
• 完了を宣言する前に、必ずスイート全体を実行してください。 無関係なテストファイルにある厳密な アサーションは、全体実行でしか表面化しないことがあります。I2 の修正でインストールコマンドが 変更され、別の e2e ファイルにある厳密な正規表現が失敗しました。ファイル単位の実行はすべて成功 しましたが、全体の vitest run で検出できました。
• ソースを編集するたびに再ビルドしてください。e2e テストは dist/cli.js を実行するため、 古い dist/ のままでは、気づかないうちに古いコードをテストしてしまいます。
• パリティゲートに注意してください。 スキャン検出器を変更する場合は、 scanFiles ↔ scanPlugin のバイト単位の一致を維持してください（src/scan-files.test.ts）。 ディスク側にフィールドを追加するなら、ブラウザー側にも追加する必要があります。
• コミット前に Prettier と fmt:check を実行してください — Markdown のコードスパンの前後には スペースが必要です。CI では fmt:check が実行されます。
• カバレッジゲートは許可リスト方式です（vitest.config.ts の coverage.include）。この対象に 新しいファイルを追加する場合は、カバレッジ 100% が必要です。現時点では、scan/cli ファイルは 対象に含まれていません。

繰り返し発生する 2 種類のバグ — 見つけて、その種類を再発防止する

このリポジトリで発生したバグのほとんどは、次の 2 種類のいずれかです。1 つ見つけたら、類似例を GREP で探し、その種類のバグが再発しないようゲートを追加してください。

1. 外部コントラクトに関する未検証の想定

外部のものがどう動作するか確認せずに推測するコードです。CLI フラグの形式（skills の -s は カンマ区切りだと思われていましたが、実際はスペース区切りで、インストールが 1 で終了しました）、 ハーネスの frontmatter キー（skills が使うのは tools: ではなく allowed-tools です）、git の 動作（サブディレクトリでの git config origin は上位の親リポジトリまでたどります）、モジュールの 解決（vigiles は package.json がないと解決できません）、リンターの有効状態 （checkstyle の severity=ignore モジュールは無効です）などが該当します。

• 境界では検証せず、パースしてください。 コーディングの前に、実際のコントラクトを確認して ください — ツールの --help、node_modules 内の引数パーサー、git rev-parse、リンター独自の ステータス判定ロジックなどです。推測せず、確かめてください。
• ネットワークやバイナリの有無に左右される e2e だけでなく、コマンドや形式の「形状」を確認する UNIT アサーションを追加してください。 実際のコマンドを実行する e2e は、開発環境では （ネットワークがない／claude がない／リンターのバイナリがないため）スキップされるので、 信頼できるガードにはなりません。実行されるのは CI だけです。外部ツールと同じ方法で組み立てた コマンドをパースするユニットテスト（たとえば、setup-plan.test.ts にある -s のスペース区切り アサーション）なら、リグレッションをオフラインですぐに検出できます。

2. 不完全な修正 — パターンの一部の呼び出し箇所だけを修正

ある場所では修正したパターンが、別の場所では残っているケースです。audit／init は config.harness を反映していましたが、test／eval／generate harness は反映していませんでした。 E1 は ScanAgent.path を修正しましたが、frontmatter ファミリーの検出結果は修正していませんでした。 コメント除去は、ある検出器には追加されましたが、次の検出器には追加されていませんでした。

• パターンを 1 つ修正したら、すべての該当箇所をただちに GREP で探してください。
• 無効な状態を表現不可能にする — 単一の集約ポイントを設けてください。 すべての呼び出し元を 単一のヘルパー（例：resolveCommandHarness）経由にし、新しい呼び出し箇所から迂回できないように してください。また、古い経路が再び現れたら失敗するゲートテストを追加してください （cli-harness-resolution.test.ts は cli.ts が生の検出器を決して呼び出さないことをアサートします）。
• 生テキストをスキャンする検出器には、共通の危険があります（コメント／例／説明文の中まで一致 させてしまうこと）。共通のテキストコンテキスト用ヘルパーが存在し、複製するのではなく再利用 されていることを確認し、誤検出防止用のフィクスチャが引き続き成功するようにしてください。

このスキルの対象外

ブラインドエージェントのオンボーディング・ドッグフーディング（新しいエージェントが、GHA の OS マトリックスとサブスクリプション評価をまたいで、実際のリポジトリ上で npx vigiles init を 実行すること）は、別途ロードマップにある e2e です。このスキルにその OS マトリックスを組み込まないで ください。このスキルはリポジトリ内の検出と修正のループを扱い、もう一方は初回オンボーディングの 体験をエンドツーエンドで測定します。