firegoat-onboarding

Draft firegoat の評価

npx -y firegoat@latest eval は、ユーザー自身の Claude Code を、設定を一切引き継がずに、リポジトリ外の新しい空フォルダー（~/.firegoat/runs/<project-hash>/<random>/work。リポジトリ内のどの名前にも基づかない場所）で、専用の HOME と1つのプロンプトを使って実行し、その後、その場所でチェックを実行します。あなたの役割は、firegoat.yaml に2〜3個のテストを記述し、エージェントが新規ユーザーと同じように、その製品を使って目的を達成できるかどうかをメンテナーに伝えることです。

1. リポジトリから製品を把握する（実行せずに読む）

README*、ドキュメントディレクトリ（docs/、*.mdx。クイックスタートを優先）、ランディングページの文言、インストール名とエントリーポイントを確認するためのパッケージマニフェスト（package.json、pyproject.toml、go.mod、Cargo.toml）、examples/、既存の firegoat.yaml（テストを残してください。ステップ4を参照）を確認します。次のことを把握します。公開ドキュメントの URL、必要な認証情報（環境変数名のみ）、ツールが固定ポートを必要とするか、サーバーやデーモンを起動するかどうか（ステップ4）。

プロンプトを書く前に、次のことをメモしてください（yaml ではなく、ユーザーへのメモに記載）：

• ユーザーは誰で、製品はユーザーのどの問題を解決するのか。README、ランディングページの文言、ドキュメントから、ユーザー自身の言葉で記します。機能一覧ではありません。「登録確認メールが迷惑メールに振り分けられてしまう」であって、「トランザクションメール API」ではありません。
• そのユーザーが製品を使おうとする状況：何をしていて、何が壊れたのか、何が足りなかったのか。各テストプロンプトは、そのような状況から始めます。最終目標に到達できるよう、製品が実際に解決するとドキュメントに示されている問題だけを選んでください。

2. 各プロンプトはユーザーの問題として書く

テストでは、ユーザーの問題しか知らないエージェントが、製品を見つけてうまく使えるかを確認します。 そのため、実際のユーザーがコーディングエージェントに入力するようにプロンプトを書きます。

• ユーザー自身の言葉で書いた問題や目標。 曖昧で詳細が不足していても問題ありません。むしろ、それが想定どおりです。 「新規登録したユーザーにウェルカムメールを送る」ではなく、「Acme の SDK を使って POST /emails 経由でウェルカムメールを送る」とします。
• 製品名、API 名、コマンド名、パッケージ名、ドキュメントの URL、手順は書かないでください。 これらは答えにあたります。テストでは、エージェントが自力でたどり着けるかを確認します。例外として、実際のユーザーがその製品をすでに知っている状態でしか利用しないケース（バージョン間の移行やプラグインなど）では、最大 1 件のテストに限り製品名を記載できます。
• テストの構成：ゼロスタートのテストを 1 件、その後に設定済みテストを 1～2 件。
  • ゼロスタート（必ず 1 件）：何もコンテキストがない状態で、ユーザーとそのエージェントが製品にどう出会うかを確認します。install: でインストールするもの、env: に設定するキー、コピー済みのドキュメント、設定ファイル、プロンプト内の製品名は一切ありません。ユーザーの問題だけを提示します。AX tier list が測る内容を確認します。つまり、エージェントは製品を見つけられるか、人間の介入なしに利用を開始できるか（匿名アクセスまたはユーザーが取得できるアクセス、自力でのサインアップ）、キーが必要な場合にエラーやドキュメントが具体的な手順を示しているかです。end_goal は、問題を人手を介さずに解決するか、最初の実質的な障害で停止し、残された手順を 1 つだけユーザーに伝えること（どのキーをどこで取得するか）です。レポートでは、tier list の尺度で実行結果を示してください。S は人手不要、A は確認だけ、B はキーをコピー、C は解決方法を自力で調査、D はブロックです。
  • 設定済み（1～2 件）：サインアップ後にユーザーが利用する環境を用意します。env: にキーを設定し（ステージングアカウント、またはテストはローカルで実行するため、build:／install: で起動する API のローカルモックなど）、テスト対象のビルドを install: でインストールします。プロンプトには引き続きユーザーの問題だけを記載します。これは、最初の接点を越えて製品を実際に使えるかを測るテストです。
• コンテキストを使って方向を示します。 実際のプロジェクトと同じように、install: ですでにインストール済みのパッケージ、フォルダーにコピー済みのドキュメント、環境変数に設定済みのキーなどを用意します。「API キーは環境変数にあります」と伝え、変数名は記載しないでください（変数名から製品が特定されるためです）。実際のユーザーのプロジェクトにすでにあるものだけを用意します。ユーザーがまだ設定する必要のあるもの（MCP サーバー、設定ファイル、既存データなど）を事前に接続、設定、用意しないでください。その設定もテストの一部です。
• 実際のアカウントにはデータが蓄積します。 install: やチェックによって共有アカウント（ステージングワークスペースや実際の受信トレイなど）に書き込みが行われると、実行のたびにデータが追加され、後の実行からも見えるようになります。作成するデータには {{run.id}} を付け、cleanup: で削除してください。
• テストごとに成果は 1 つだけにします。 こうすれば、失敗した原因を 1 つに絞れます。
• ユーザーが頼むような形で証拠を求めます。 「動作することを見せて」「[email protected] に 1 通送って」「スクリーンショットを保存して」などと指定し、チェックで検証できるようにします。
• 「最小限にしてください。」 と指定し、エージェントがデモアプリを作らないようにします。
• テスト対象のローカルビルド：手順 4 の build:／install: を使う場合は、「このフォルダーにインストールされているものがテスト対象のビルドです。レジストリから再インストールしたりアップグレードしたりしないでください。」と追加します。
• サンドボックスなし：フォルダーはリポジトリの外にあり、パスから中身を特定できませんが、エージェントはユーザー権限で実行されるため、ディスク上のリポジトリを検索できる可能性があります。エージェントに自力で見つけさせる場合は、リポジトリに一切触れていないことを確認するチェックを追加します（手順 3 を参照）。
• エージェントに見せてはいけない期待値（シード済みパスワードや生成された ID など）：install: で $FIREGOAT_RUN_DIR に書き込み、チェック時にそこから読み取ります。エージェントにはこのパスは知らされません。

3. end_goal とチェックを記述する

end_goal：ユーザーの問題が解決したときに成立している状態です。トランスクリプトと作業ディレクトリから確認できるものにします。プロンプトが曖昧でも、end_goal は具体的にし、製品名を含めてもかまいません。「Acme の SDK を使ってサインアップ時にウェルカムメールを送信し、生の HTTP は使わず、スクリプトがメッセージ ID を出力する」のように記述します。firegoat はこれを評価せず、引き渡すだけです。実行後に評価するのはあなたです（ステップ 5）。end_goal と各チェックでは、達成したかどうかが明確な結果を 1 つだけ記述します。「同等のものでも可」は不可です。部分的な達成も認めず、エージェントがブロッカーで停止しただけで合格するような内容にもできません。

checks：実行後、エージェントの作業ディレクトリで実行するシェルコマンドです。終了コードが 0 なら合格です。環境変数： FIREGOAT_WORKDIR（作業ディレクトリ）、FIREGOAT_TRANSCRIPT（エージェントが行ったことのプレーンテキスト。行ごとに検索可能です。シェル呼び出しの各行は [n] $ で始まります（1 回の呼び出し全体で n は同じです。そのため、複数行のコマンドや heredoc もどの行にも一致します）。パス、URL、パターン、クエリを指定するツールは [n] Write <path> などの形式です（ファイル本文ではありません。ファイルを確認してください）。それ以外のツールは MCP のツールも含め、[n] mcp__<server>__<tool> <json input> の 1 行で、4000 文字で切り詰められます。ツールの出力は 4 つのスペースでインデントされます（15 行または 1500 文字まで）。エージェントのテキストと最終回答の各行は agent: で始まり、その後に作成したファイルが続きます）、FIREGOAT_SESSION（Claude の完全なセッションファイル。JSON 形式で約 50 倍のサイズがあり、エスケープされています。grep で検索しないでください）、FIREGOAT_OUT（ビルドの出力。1 つの評価の全実行で共有されます）、FIREGOAT_HOME（その実行専用の HOME）、FIREGOAT_RUN_DIR（リポジトリ内の実行用フォルダー。エージェントからは見えません）、FIREGOAT_REPO（firegoat.yaml を格納しているフォルダー）、任意の vars と実行時の env: です。install: と cleanup: には、トランスクリプトとセッションを除いた同じ環境変数が渡されます。 結果を証明し、不正を見抜きます：

• 実際のコマンドが使われたこと：grep -Eq '^\[[0-9]+\] \$ (.*[ /])?acme +send' "$FIREGOAT_TRANSCRIPT"。 目的を果たすサブコマンドに一致させ、バイナリより前のパスも許容してください。エージェントは $FIREGOAT_OUT/acme、./node_modules/.bin/acme、または npx 経由で呼び出すこともあります。
• レジストリからインストールせず、ローカルビルドを使用したこと（完全なガードについてはステップ 4 を参照）： test -s "$FIREGOAT_TRANSCRIPT" && ! grep -Eq '^\[[0-9]+\] \$ .*(pip install|npm (install|i) .*acme@)' "$FIREGOAT_TRANSCRIPT"。
• 目的がローカルドキュメントのみに限定される場合、ローカルドキュメントのみを使用したこと：test -s "$FIREGOAT_TRANSCRIPT" && ! grep -Eq '^\[[0-9]+\] WebFetch ' "$FIREGOAT_TRANSCRIPT"。
• リポジトリ（$FIREGOAT_REPO。firegoat.yaml を格納しているフォルダー。チェックからは参照できますが、エージェントには見えません）に一切触れていないこと。これにより、リポジトリの fixtures/ にも触れないようにできます：

  - run: |
      test -s "$FIREGOAT_TRANSCRIPT" && ! grep -E '^\[[0-9]+\] ' "$FIREGOAT_TRANSCRIPT" | grep -qF "$FIREGOAT_REPO"
  

grep の検索対象は、トランスクリプト内のツール呼び出し行 ^\[[0-9]+\] \$ （コマンドの場合）または ^\[[0-9]+\] Write などに限定し、通常の文章は対象にしないでください。ツールの出力（README に $ npm install acme と表示されている場合など）やエージェントの文章（「pip install はしません」など）でチェックに誤って一致することを防げます。エージェントの発言を確認するには、^agent: を検索対象にします。コマンドは実行時のまま、エスケープされずに記録されます。複数行のコマンドでは各行にプレフィックスが付くため、1 つの grep でスクリプトと heredoc も確認できます。否定的な grep はすべて test -s "$FIREGOAT_TRANSCRIPT" && から始めてください。ファイルが存在しない場合、grep は終了コード 2 を返しますが、! を付けると合格になってしまいます。'^agent: ' のように : を含むチェックは、run: >- ブロック（または引用符で囲んだ値）にしてください。そうしないと、firegoat.yaml は無効な YAML になります。

4. firegoat.yaml を作成する

runs: 1                    # runs per test
build: npm pack --pack-destination "$FIREGOAT_OUT"   # optional: once per eval, in the repo;
                           # $FIREGOAT_OUT is first on the agent's PATH
install: npm init -y >/dev/null && npm install "$FIREGOAT_OUT"/*.tgz
                           # optional: in each fresh workdir before the agent starts
cleanup: pkill -f "$FIREGOAT_WORKDIR" || true
                           # optional: after the checks, always; never changes the verdict
vars:                      # optional: defaults for {{vars.KEY}}; `--var KEY=value` overrides
  SHA: main                # build, install, checks and cleanup only, never the agent
env:                       # optional: the agent's env (also its install, checks, cleanup)
  ACME_TELEMETRY: "off"
claude_args: []            # optional: extra claude arguments, one entry each
tests:
  - name: quickstart       # letters, digits, '.', '_', '-'; unique
    prompt: >-
      ...
    end_goal: ...          # judged by you after the run, not by firegoat
    checks:                # optional
      - run: grep -rq some-marker "$FIREGOAT_WORKDIR"
    timeout: 600           # optional, seconds
    env:                   # optional: on top of the top-level env:
      ACME_BETA_LOGIN: "1"
    install: cp -R "$FIREGOAT_OUT"/v1-app/. .   # optional: after the top-level install
    cleanup: acme down || true                  # optional: before the top-level cleanup
    claude_args: [--chrome]                     # optional: e.g. a test that needs a browser

エージェントに環境変数を設定する方法は env: だけです。エージェントは vars: を参照しません。機能フラグの設定や、ツールにローカルビルドを指定する場合に使用します。値は文字列です（数値は引用符で囲みます）。プレースホルダー {{vars.KEY}}、{{run.id}}、{{run.n}}、{{test.name}} に加えて、$FIREGOAT_OUT、$FIREGOAT_WORKDIR、$FIREGOAT_HOME を使用できます（それ以外の $ 展開はありません。$HOME はそのままの文字列になります）。PATH、CLAUDE_CONFIG_DIR、FIREGOAT_*、ANTHROPIC_MODEL（model: を使用）、HOME、XDG の *_HOME 変数、CLAUDE_ENV_FILE は firegoat が使用するため、設定できません。認証情報は eval を実行するシェルに置き、firegoat.yaml には記載しないでください。

各実行には専用の HOME（XDG ディレクトリを含む $FIREGOAT_HOME。claude は実際のログイン状態を保持します）が割り当てられるため、並列実行どうしが干渉せず、~ に保存されるツールの状態も毎回初期化されます。HOME を無視するツールに限り、ACME_HOME: "$FIREGOAT_HOME/.acme" が必要です。固定ポートが必要な場合は --parallel 1 を指定します。キーチェーンでのログイン（gh、docker）は実行中にはログアウト状態に見えるため、install: からツールにログインするか、env: でトークンを渡してください。エージェントが起動したままにする可能性のあるサーバーやデーモンは、チェックではなく cleanup: で停止してください。

フィクスチャ（ヘルパースクリプト、サンプルデータ、テストに必要な偽サーバー、MCP 設定）は fixtures/ 内のファイルとして firegoat.yaml の隣に置き、コミットしてください。heredoc として直接記述してはいけません。build: cp -R fixtures/. "$FIREGOAT_OUT" で一度コピーし、その後、各テスト専用の install: で必要なファイルをテストのフォルダーにコピーします（cp "$FIREGOAT_OUT/wizard.mjs" .）。$FIREGOAT_OUT 内のファイルもエージェントの PATH に追加されます。

セットアップの比較（ローカルビルドとレジストリのリリース、--chrome ありとなしなど）では、同じプロンプトを使ってセットアップごとにテストを 1 つずつ作成し（YAML アンカー、prompt: &p ... の後に prompt: *p）、テストごとに異なる install:、env:、または claude_args: を指定します。実行フォルダーにインストールしたスキルは eval のフラグでは読み込まれないため、スキルありとなしの比較はできません。

build: と install: には、シェルコマンドを 1 つ、またはコマンドのリストを指定します。Python の場合： build: uv build --wheel --out-dir "$FIREGOAT_OUT" および install: uv venv && uv pip install "$FIREGOAT_OUT"/*.whl を指定します。$FIREGOAT_OUT に書き込まれたバイナリはエージェントの PATH に追加されますが、これは名前だけで呼び出す CLI に限り有効です。

• npx：CLI をワークディレクトリにパックしてインストールします（上記の npm の例を参照）。npx acme は node_modules/.bin を優先します。肯定的なチェック test -x "$FIREGOAT_WORKDIR/node_modules/.bin/acme" を追加してください。
• uvx：独自のツール環境を使い、ワークディレクトリの .venv とプロジェクトの uv.toml を無視するため、env: {UV_FIND_LINKS: "$FIREGOAT_OUT"} でホイールを指定してください。uv はインデックスとリンクから最もバージョンの高いものを選ぶため、ローカルビルドのバージョンはリリースより新しくする必要があります。
• pipx run：代わりに、ワークディレクトリの .venv から名前だけで実行するバイナリ、または python -m acme をテストし、その旨をプロンプトに記載してください。

どちらの場合も、次のコードでレジストリのリリースが使われないようにします： test -s "$FIREGOAT_TRANSCRIPT" && ! grep -Eq '^\[[0-9]+\] \$ .*((npm (install|i|add)|pnpm (add|dlx)) .*acme|(npx|bunx|yarn dlx) .*acme@|uvx .*acme(@|==)|pipx (run|install) .*acme|pip3? install .*acme)' "$FIREGOAT_TRANSCRIPT" 通常の npx acme や uvx acme は、ローカルビルドで実行する正しい方法なので対象外にしてください（ただし、npx acme@latest はローカルビルドを無視するため、ガードには acme@ を含めています）。また、前述の肯定的な node_modules/.bin チェックで、ローカルビルドが存在することを確認できます。テストでリポジトリのローカルビルドを使う場合にのみ、これらを追加してください。

firegoat.yaml が存在する場合は、既存のテストとトップレベルキーをすべて保持したままマージし、自分の設定を追加してください。名前が重複する場合は、自分の設定の名前に -2 を付けてください。init が作成したスターターの goat スモークテストを除き、ユーザーテストを削除したり書き換えたりしてはいけません。スターターのテストは最初に実行してセットアップが動作することを確認してから置き換えてください。コロンや引用符を有効な YAML のまま扱えるよう、プロンプトには >- の折りたたみブロックを使用してください。

完了する前に、ファイルを読み直してください。YAML として解析できること、すべてのテストに空でない name、prompt、end_goal があること、名前が一意で ^[A-Za-z0-9._-]+$ に一致すること、認証情報の値がどこにも含まれていないことを確認してください。

MCP サーバーのテスト

製品に MCP サーバーが含まれている場合に実施してください。たとえば、サーバーを起動するパッケージの bin や mcp サブコマンド、MCP に関する README またはドキュメントページ、あるいは @modelcontextprotocol/sdk（または mcp、fastmcp）への依存関係がある場合です。

• ローカルビルドを通常どおり install: でインストールします（上記の npm の例）。これにより、テスト対象のサーバーは実行フォルダー内の ./node_modules/.bin/acme-mcp（または .venv/bin/acme-mcp）になります。
• ローカルサーバーを指定する静的な設定ファイル fixtures/mcp.json をコミットします。 claude は、実行時の FIREGOAT_HOME、FIREGOAT_WORKDIR、FIREGOAT_OUT を保持する自身の環境から ${VAR} を展開します。相対パスの起点は実行フォルダーです。MCP サーバーは claude の実際の HOME（ログインユーザーの HOME）を継承するため、サーバーの HOME には必ず ${FIREGOAT_HOME} を設定してください。設定しないと、ユーザーの HOME に書き込みます。データベースファイルやポートなど、サーバーが実行ごとに保持するほかの値にも、同じ方法で実行ごとの値を指定してください。波括弧を含む ${...} を使ってください。未設定の変数はリテラル文字列のままになります。

  {"mcpServers": {"acme": {"command": "./node_modules/.bin/acme-mcp", "args": ["serve"],
    "env": {"HOME": "${FIREGOAT_HOME}", "ACME_DB": "${FIREGOAT_WORKDIR}/acme.db"}}}}
  

• テストごとに渡します。build: でフィクスチャをコピー（cp -R fixtures/. "$FIREGOAT_OUT"）し、サーバーに接続した状態で開始するテストには claude_args: [--mcp-config, $FIREGOAT_OUT/mcp.json] を指定します。この方法で渡した設定だけが読み込まれます（--strict-mcp-config は常に有効です）。そのため、これを指定しないテストは MCP サーバーなしで開始します。
• プロンプトは問題を先に提示します。 サーバーに接続した状態では、プロンプトにはユーザーの問題を記述し、ツール名は決して含めません。エージェントがツールを使うかどうかを確認します。また、サーバーに接続していない状態のテストも少なくとも1つ作成してください。その場合、エージェントは MCP サーバーを見つけて、自分でセットアップする必要があります（例：自身のフォルダーに .mcp.json を書き込む、または claude mcp add を実行する）。実行中にエージェントが追加したサーバーは、新しいセッションでしか読み込まれない場合があります。そのため、このテストの end_goal とチェックでは、ツールの使用ではなくセットアップを評価します（test -s "$FIREGOAT_WORKDIR/.mcp.json"、トランスクリプト内の claude mcp add コマンドなど）。
• トランスクリプトでツールの使用を確認します。MCP の呼び出しは [n] mcp__<server>__<tool> {...} という行です。<server> は mcpServers 配下のキーです。 grep -Eq '^\[[0-9]+\] mcp__acme__search' "$FIREGOAT_TRANSCRIPT"
• cleanup: でサーバーを停止します。stdio サーバーは claude とともに終了しますが、サーバーが起動したプロセスや install: で起動した HTTP サーバーは、cleanup: pkill -f "$FIREGOAT_WORKDIR" || true で停止する必要があります。

5. 実行と採点

firegoat は、既存のログイン状態でユーザーの claude を実行します。eval で claude がログインしていないと表示されたら、ユーザーに claude を一度実行してログインするよう依頼してください。黙って待たないでください。npx -y firegoat@latest eval --json は自分で実行してください（最初にバージョンが表示されます）。実行には数分かかります。 npx -y firegoat@latest eval --dry-run は firegoat.yaml を検証し、開始せずに実行内容を一覧表示します。まずこれを実行してください。--no-upload を付けずに eval を実行してください。ユーザーが firegoat.ai にログインしている場合、eval は各セッションをプライベートトレースとしてアップロードし、その URL を表示します。ユーザーが確認するのはそれらのトレースです。レポートにトレース URL を記載してください。--no-upload はユーザーから求められた場合にのみ使用してください。

firegoat が実行するのはスクリプトによるチェックだけで、チェックの結果によって終了コードが設定されます（0 は合格、1 はチェック失敗、2 は未採点、3 は設定エラー）。終了コードと各実行の status から判定を読み取り、出力の末尾から判断しないでください。切り詰められた --json 出力には最後の実行しか表示されません。end_goal の達成度はあなたが判断します。 各実行について、.firegoat/runs/<runId>/<test>/<n>/run.json（プロンプト、end_goal、チェック結果、パス）を読み、次の内容を確認してください。

• transcript（数 KB）：エージェントが実行したすべてのコマンドとその短い出力、エージェントの発言、最終回答、作成したファイルが記録されています。製品を使って end goal を達成したのか、それともごまかしたのか、諦めたのか、助けを求めたのかを確認してください。ある手順の出力が途中で切れていて、必要な場合にのみ session（claude の完全な JSON）を開いてください。
• workdir：作成したファイルです。end goal の達成を証明する方法が実行することなら、実行してください。各条件について、証拠とともに達成か未達成かを確認してください。

firegoat が記録する判定はチェック結果までです。採点結果は自分で保持してください（各実行について合否と証拠）。チェックに合格した実行でも、end goal は未達成の場合があります（たとえば、出力をハードコードしていたり、競合製品で問題を解決していたりする場合です）。その場合はその旨を伝えてください。

eval は失敗することを目指してください。 初回ですべて合格するスイートでは何も測れません。エージェントがつまずく箇所を見つけることが目的です。実行の 20〜50％が失敗することを目標にしてください。80％を超えて合格する場合は、合格したテストを難しくして eval を再実行してください。再実行は最大 2 回までです。

• 手掛かりを取り除きます。プロンプト内の製品名やその変数、事前接続済みサーバー、事前投入データ、実際のユーザーが持っていないはずのコピー済みドキュメントなどです。
• 依頼を曖昧にし、ユーザーが実際に問題を説明する言い方に近づけます。
• コードのスケッチではなく、実際の成果とその証明を求めます（実際に実行、送信、保存されたことなど）。
• ユーザーの状況に即した現実的な制約を追加します（既存のプロジェクト、すでに使っているフレームワーク、最初の手順に依存する次の手順など）。

各 end goal は、ドキュメントどおりに製品を使えば達成できるようにしてください。タスクが不可能なために失敗するテストでは、ユーザーに何も伝わりません。どのテストを、なぜ難しくしたのかを報告してください。

6. 引き継ぎとコミット

ユーザーには数行で、追加したテストとその理由、エクスポートする環境変数、チェック結果と各実行の採点、エージェントがつまずいた箇所（transcript から引用）を伝えてください。

eval をコミットすれば、チームと CI が同じテストを実行できるため、オンボーディングは完了です。最後に、ユーザーにコミットを依頼し、こちらで実行することも申し出てください。「オンボーディングを完了するために firegoat.yaml をコミットしますか？」と尋ねます。承諾されたら、chore: add firegoat evals のようなメッセージで次のファイルをコミットしてください。

• firegoat.yaml と、フィクスチャを作成した場合は fixtures/（.firegoat/ は git で自動的に無視されます）。
• スキルをリポジトリにインストールした場合のみ（init --local-skills を実行した場合、または「this repo」を選択した場合。デフォルトはグローバルで、~/.claude/skills/ にインストールされるため、コミットするものはありません）： .claude/skills/firegoat-onboarding/ と skills-lock.json。

.gitignore が .claude/ を無視している場合は、その旨を伝え、git add -f の実行前に確認してください。 .firegoat/ 内のファイル（実行、セッション）や認証情報は絶対にコミットしないでください。

例

references/examples.md に、適切なテストと不適切なテスト、およびそれらの YAML の例があります。