ce-dogfood について
ce-dogfoodは開発・QA向けのテストスキルで、現在のブランチとベースとの差分を対象に検証します。ブラウザーでユーザーフローを確認し、小さな問題を修正してレポートに記録します。
主な機能
- 01ブランチ差分に基づくテスト範囲設定
- 02フロー分析とテストマトリクス作成
- 03agent-browserによるブラウザー操作
- 04小さな問題の修正と回帰テスト
- 05テストレポートの記録とコミット
活用シーン
- 01現在のブランチで追加されたフローの検証
- 02リリース前の画面変更の確認
- 03ブロッカーや人の判断事項の記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ everyinc/ compound-engineering-plugin --skill ce-dogfoodインストール後、Claude Code で/ce-dogfoodを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
agents/openai.yamlreferences/dogfood-report-template.mdphases.mdtest-matrix-taxonomy.mdscripts/packs-resolve.py詳細
Dogfood
アクティブなブランチをエンドツーエンドで実際に使い込み、真にリリース準備が整うまで、自律的にQAエンジニアとして作業してください。
目標: このブランチで導入された、ユーザーに見える変更をすべて、実際のブラウザーで一連の操作を通して確認し、正確性と、製品のペルソナにとっての使い心地を評価します。小さな不具合は修正し、回帰テストを実施してコミットします。完了条件: マトリクスのすべてのシナリオが Pass、Fixed、Skipped、または終端の Blocked 状態になっていること。プロジェクトの自動テストスイートを一度実行し、その結果を記録していること。そして、テンプレートに沿って仕上げたレポート <root>/dogfood-reports/<YYYY-MM-DD>-<branch-slug>-dogfood.md をコミットしていること。マトリクスがすべて成功でもテストスイートが失敗している場合は、準備完了ではなく未準備と判定して完了します。この実行の目的は、テストスイートを成功するまで追いかけることではありません。
これは差分を対象とした作業であり、アプリ全体を探索するものではありません。トランクとの差分に含まれる、このブランチで導入または変更されたものをテストします。
Phase 0(スコープ)を始める前に references/phases.md を読み、指示に従ってください。各フェーズの詳細はこのファイルに記載されています。以下のフェーズ一覧だけでは、正しく実行できません。
境界
- ブラウザーの操作には
agent-browserCLI のみを使用してください。mcp__claude-in-chrome__*などの Chrome MCP ツール、他のブラウザー MCP、または組み込みのブラウザー操作ツールは、プラットフォームで利用可能な場合も含め、絶対に使用しないでください。npx agent-browserではなく、直接バイナリを使用してください(直接バイナリは高速な Rust クライアントを使用します)。 - ブランチ名または空のターゲットでトランクを実際に使い込まないでください。差分が存在しないためです。PR ターゲットには必ずベースがあるため、ヘッドブランチ名が
mainでも常に差分を確認できます。 - 数値のターゲットは、分離とチェックアウトを通して PR の識別情報のまま扱ってください。ヘッド参照に置き換えないでください。その名前が
mainの場合もあります。 - ユーザーが使用中のプライマリチェックアウトを勝手に切り替えないでください。このスキルでは、分離を提案するかどうかだけを判断します。空のターゲットまたは現在のブランチがターゲットなら、すでにそのブランチにいるため提案しません。PR または別の名前付き参照がターゲットなら提案します。実際の処理と判定の報告は
ce-worktreeが行います。提案が断られた場合は、未コミットの変更に影響するなら事前に確認してから、対象をその場でチェックアウトしてください。 - スクリーンショットなどの一時的な成果物は OS の一時ディレクトリ(
mktemp -d "${TMPDIR:-/tmp}/ce-dogfood-XXXXXX")に保存し、リポジトリのルートには保存しないでください。レポートに埋め込むものだけ、そこからコピーしてください。 - 自動修正するのは、小規模で内容を十分理解しており、リスクが低いものに限ってください。アーキテクチャやスキーマの判断が必要な変更、製品の動作や UX の意図を変える変更、多数のファイルにまたがる変更、または複数の妥当な解決策が考えられる変更は、マトリクス項目を完了させるために実装せず、レポートの人間による判断が必要な項目に記載してください。
前提条件
ユーザーが実行できる呼び出し形式の表示: 前提条件を満たせない場合は、通常 /ce-setup と /ce-dogfood <original arguments> を使用します。ただし、アクティブなホストが Codex の場合、またはドル記号を先頭に付けたスキル呼び出し形式が明示的に文書化されている場合は、$ce-setup と $ce-dogfood <original arguments> を使用してください。oh-my-pi(omp)では、/skill:ce-setup と /skill:ce-dogfood <original arguments> を使用してください。各呼び出しだけをインラインコードで表示し、いずれか一方の形式のみを出力してください。
-
起動できるローカル開発サーバー(
bin/dev、rails server、npm run devなど)。 -
agent-browserがインストールされていること。確認方法:command -v agent-browser >/dev/null 2>&1 && echo "Ready" || echo "NOT INSTALLED"インストールされていない場合は作業を中止し、ユーザーに
agent-browserのインストールを案内してください。現在のインストール方法に対応するce-setup呼び出しを表示し、その後に再試行用のce-dogfood <original arguments>呼び出しを表示します。このワークフローはagent-browserなしでは実行できません。
アーティファクトルート
レポートは <root>/dogfood-reports/ に、ペルソナは <root>/personas/ に保存します。初めて <root>/ のパスを組み立てるときに <root> を解決します。読み取りと書き込みのどちらの場合も同様で、それより前に解決してはいけません。<root>/ のパスを組み立てない実行では、解決を省略します。
アーティファクトパスを組み立てる前に、CE アーティファクトルート <root> を解決してください。
- 読み取り:
docs_rootは<repo-root>/.compound-engineering/config.yamlのみから読み取ります(<repo-root>=git rev-parse --show-toplevel)。config.local.yamlから読み取ってはいけません。未設定の場合、従来どおり<root>はdocsです。 - 検証:値が設定されている場合、リポジトリ相対のディレクトリであり、実パス(シンボリックリンク解決後)がリポジトリ内に収まり、リポジトリルートでも
.git/配下でもないことを確認します。それ以外の場合は、docs_rootとその値を明記したエラーで停止します。docsにフォールバックしてはいけません。 - 使用:
<root>を唯一のアーティファクト保存先として使います。存在しない場合は作成し、このスキル固有のサブディレクトリを使って各パスを<root>/<subdir>として組み立てます。また、docsを併せて読み取ってはいけません。
委任
ce-dogfood はオーケストレーターです。動作を独自に再構築するのではなく、既存の CE スキルを優先してください。PR または名前付きブランチを対象にする場合は ce-worktree で分離し、根本原因がすぐには明らかでない場合は ce-debug に引き継ぎ、各修正を ce-commit でコミットし、再利用可能な教訓を ce-compound に記録します。
Compound Packs
リポジトリで宣言された Compound Packs がペルソナと判定基準を提供します。ユーザーについて記述するパックのルールは、フローをたどる際に演じるペルソナです。製品がどう見えるか、またはどう動作すべきかを定めるルールは、そのルールに該当する各シナリオを評価する基準です。矛盾があれば失敗とみなし、(pack: <id>, <path within the pack>) の引用を添えて修正ループに入ります。ブランチが意図的に生じさせた矛盾は、そのルールに関する人間の判断を要するものであり、修正対象ではありません。一般化できる判定は ce-compound を通じてパックに反映します。このスキルがパックを書き込むことはありません。パックの適用方法は references/phases.md で定義されています。
フェーズの順序
スコープ設定 -> 差分の分析 -> フローのマッピング -> マトリックスの導出 -> サーバーの起動 -> 実行 -> 修正ループ -> レポート。この順序は必ず守ります。マトリックスより先にフローモデルを作成し、ブラウザーでの作業より先にマトリックスを作成します。各フェーズの条件は references/phases.md に記載されています。この行からフェーズを再構成するのではなく、フェーズ 0(スコープ設定)の前に読みます。一度に 1 つのシナリオに取り組み、各ペルソナにとっての使い心地と正確さの両方を評価します。回帰テストが修正前に失敗し、修正後に成功するか、自動テストが有意義でなかった理由をレポートに記載するまでは、修正は完了していません。
チェックポイントであり、最終書き込みではありません。 マトリックスができたらすぐに references/dogfood-report-template.md からレポートを作成し、すべてのシナリオを Pending に設定します。各シナリオの判定後、および各修正のコミット後にレポートを更新します。<branch-slug> はブランチ名を小文字にし、スラッシュを含むすべての非英数字の連続を 1 つの - に置き換えたものです。<root>/dogfood-reports/*-<branch-slug>-dogfood.md の glob 検索で過去の実行を探します。タスクリストはセッション単位ですが、ディスク上のレポートが後続の実行やチームメイトによる再開時に使われます。そのため、中断した実行では、単なるマトリックスではなくテンプレートに沿ったチェックポイントを残す必要があります。
終了状態。 Blocked (needs human verify)(OAuth、実際のメール、決済、SMS など、外部とのやり取りが必要で、ヘッドレスでは実行できないステップ)と Blocked (human decision)(自律的に行うには修正の規模が大きすぎる場合)は、どちらも人の対応を待つ状態です。どちらの状態でも、そのシナリオを終了しますが、実行全体は終了しません。マトリックスの残りのシナリオを続け、現在の実行でも再開後でも、ブロックされたシナリオを黙って再登録してはいけません。各状態で人に連絡する方法は異なり、状態を設定するフェーズでその方法を指定します。