このリポジトリに coder-eval をセットアップする
目標: ユーザーに、すぐに実行可能な 本物のタスク が1つ含まれたタスクディレクトリを提供すること。空のスキャフォールドではありません。タスクは、このリポジトリが実際に出荷する何かを実行するものでなければなりません。
ユーザーのリクエストは: $ARGUMENTS
ステップ 1 — 前提条件を確認する
coder-eval --version を実行します。このプラグインをインストールしてもCLIはインストールされないため、以降のすべてのステップでCLIが必要です。
CLIが不足している場合は、${CLAUDE_PLUGIN_ROOT}/reference/cli-setup.md に従います。インストールを提案し、実行前に確認を求め、その後 coder-eval --version で確認します。許可なくインストールせず、ユーザーが拒否した場合は続行しないでください。
上記の参照ファイルには、バージョンチェックのもう半分、つまりこのプロジェクトが特定のcoder-evalバージョンを固定しているかどうか、インストールされたバージョンが一致しない場合の対処方法についても記載されています。
ステップ 2 — このリポジトリが既に構成されているか確認する
このスキルは最初のスイートをスキャフォールドします。既にスイートがあるリポジトリに対して実行すると、既存のツリーの横に「最初のタスク」を作成して成功を報告するため、何かを作成する前に状況を確認します。
${CLAUDE_PLUGIN_ROOT}/reference/repo-layout.md に従って評価ツリーを見つけます。リポジトリに既にタスクがある場合は、その一覧を報告して停止します：タスクファイルの数と場所、実行ディレクトリの数、experimentsの有無。そして、既存のものに対して機能するスキルをユーザーに案内します —
/coder-eval:lint-tasks— 既存のタスクをレビューする/coder-eval:analyze— 完了した実行を読み取る
リポジトリにタスクが全くない場合、またはユーザーが一覧を見た後に明示的に追加を依頼した場合にのみスキャフォールドします。ユーザーが何を依頼しても、既存のタスクファイルを上書きしないでください。代わりに、その横に追加します。
タスクはあるがexperimentsがないリポジトリは、部分的に構成されているのであって、空ではありません。その旨をそのまま報告し、不足している部分を提案してください。何もないかのように最初のタスクをスキャフォールドしないでください。
ステップ 3 — テスト可能なものをスキャンする
以下のものを優先順位に従って探し、何かを作成する前に、見つけたものを報告してください：
- Claude Code スキル —
.claude/skills/*/SKILL.mdと**/skills/*/SKILL.mdをグロブします。スキルは評価する価値が最も高いものです。なぜなら、それらがトリガーするかどうかは、失敗するまで見えないからです。見つけた場合は、それぞれに対して/coder-eval:check-skillを推奨してください。これは専用のアクティベーションスイートであり、ここで手作りするものではありません。 - MCP サーバー —
.mcp.json、package.jsonまたはpyproject.toml内のmcpServersキー、またはサーバーのエントリポイント（ツールを登録するserver.py/index.ts）。公開されているツールをメモします。 - CLI エントリポイント —
pyproject.tomlの[project.scripts]、package.jsonのbinまたはscripts、または使用可能なターゲットを持つMakefile。
リポジトリが多数のスキルやパッケージディレクトリを持つモノレポの場合は、スキャンを制限し、50個の候補を報告するのではなく、どのサブツリーに焦点を当てるかを尋ねてください。
これらの3つのカテゴリで何も見つからなかった場合は、その旨を明確に伝えてください。そして、代わりに最も小さな有用なもの、つまりリポジトリが既に持つスクリプトやテストコマンドを実行し、その出力をチェックするタスクを提案してください。何も証明しない空のスイートをスキャフォールドするのではなく。
ステップ 4 — 本物のタスクを1つスキャフォールドする
ステップ2で解決したツリーに書き込みます。リポジトリにタスクがない場合は、場所を提案して確認を取ります。ステップ2の「決して上書きしない」ルールはここでも適用されます。このルールが存在する唯一の場所です。
ステップ3で見つけたものに基づいて、1つのタスクを書きます：
- CLI — CLIが行う何かを依頼するプロンプトと、ファイルが出現したことだけでなく、結果のファイルの内容をチェックする評価基準を持つタスク。
- MCP サーバー — 特定のツールを1つ実行し、その効果を検証するタスク。
- スキル — 代わりに
/coder-eval:check-skillを指します。アクティベーションスイートは機能タスクとは異なる形をしており、そのスキルが適切に構築します。
プロンプトは指示を与え、評価基準は検証します。評価基準がチェックする内容をプロンプトで言い換えないでください。「ファイルにXが含まれていることを確認してください」というプロンプトは、能力ではなく読解力をテストします。
評価基準を書く前に、${CLAUDE_PLUGIN_ROOT}/reference/task-rubric.md を読んでください。これは、タスクが誤った理由で合格する可能性があるかどうかの共有チェックリストです。ここでスキャフォールドする1つのタスクは、このリポジトリの後続のすべてのタスクがモデルとする例になるため、後で修正するよりも、最初に正しく作成する価値があります。評価基準のタイプとそのフィールドについては、${CLAUDE_PLUGIN_ROOT}/reference/criteria.md を読んでください。
この1つのタスクの後にユーザーがさらにタスクを希望する場合は、/coder-eval:task を使用してください。これは、自然言語の概要を使用した同じオーサリングループです。
ステップ 5 — 環境変数
選択されたエージェントが必要とする変数（例：デフォルトの claude-code エージェントの場合は ANTHROPIC_API_KEY）を .env.example に書き込みます。ファイルを作成するか、追記します。
.env を絶対に書き込まないでください。既に実際の秘密情報が含まれている可能性があります。.env が存在しない場合は、gitignore されているかどうかを確認してからユーザーに作成を提案し、gitignore されていない場合はその旨を伝えてください。
ステップ 6 — 検証
coder-eval plan <task-directory>/*.yaml を実行し、終了コード0になるまで繰り返します。これにより、実際のモデルを通してタスクスキーマが検証されるため、間違って推測したフィールド名があればここで明らかになります。plan はタスクファイルを引数に取ります。ベアのディレクトリ引数は即座に拒否されます（Expected a YAML task file but got a directory）。したがって、常に明示的なパスまたはグロブを渡してください。引数なしの coder-eval plan を提案しないでください。引数なしのディスカバリーは coder-eval ソースチェックアウトからのみ機能し、他の場所では終了コード1で終了します。
空のディレクトリやタスクのないディレクトリは、意味のある成功とはみなされません。plan がタスクを報告しなかった場合は、合格ではなくスキャフォールドの失敗として扱ってください。ベアディレクトリエラーは別の結果であることに注意してください。それはスキャフォールドが空であることではなく、間違った引数の形状を渡したことを意味します。
ステップ 7 — 報告
ユーザーに以下のことを伝えます：
- スキャンで何を見つけたか、そして何を最初に評価することを選んだか
- それを実行するための正確なコマンド：
coder-eval run <path>、および実際のトークンを消費し、ステップ5の認証情報が必要であるという注意事項 - リポジトリがスキルを出荷している場合、
/coder-eval:check-skillが次のステップであること - その後、
/coder-eval:analyzeで実行ディレクトリを読み取り、/coder-eval:ciでスイートを GitHub Actions のゲートに変えることができること