이 리포지토리에 coder-eval 설정하기
목표: 사용자에게 즉시 실행 가능한 하나의 실제 태스크가 포함된 태스크 디렉토리를 남기는 것입니다. 빈 스캐폴드가 아닙니다. 태스크는 이 리포지토리가 실제로 제공하는 기능을 테스트해야 합니다.
사용자의 요청은 다음과 같습니다: $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에 따라 평가 트리를 찾으세요. 리포지토리에 이미 태스크가 있으면 목록을 보고하고 중단합니다: 태스크 파일 수와 위치, 실행 디렉토리 수, 실험(experiment) 존재 여부를 알려줍니다. 그런 다음 사용자에게 기존 항목을 대상으로 하는 스킬을 안내합니다 —
/coder-eval:lint-tasks— 이미 있는 태스크 검토/coder-eval:analyze— 완료된 실행 결과 분석
리포지토리에 태스크가 전혀 없거나, 사용자가 목록을 본 후 명시적으로 더 요청하는 경우에만 스캐폴딩합니다. 사용자가 무엇을 요청하든 기존 태스크 파일을 절대 덮어쓰지 말고, 옆에 함께 추가하세요.
태스크는 있지만 실험이 없는 리포지토리는 부분적으로 설정된 것이지 비어 있는 것이 아닙니다. 그 상태 그대로 보고하고 누락된 부분을 제안하세요. 아무것도 없는 것처럼 첫 번째 태스크를 스캐폴딩하지 마세요.
3단계 — 테스트 가능한 항목 스캔
다음 항목을 우선순위 순서대로 찾고, 쓰기 전에 찾은 내용을 보고하세요:
- Claude Code 스킬 —
.claude/skills/*/SKILL.md및**/skills/*/SKILL.md를 글로브(glob) 검색합니다. 스킬은 평가할 가치가 가장 높습니다. 트리거 여부가 실패할 때까지 보이지 않기 때문입니다. 찾으면 각각에 대해/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개의 후보를 보고하기보다 스캔 범위를 제한하고 어떤 하위 트리에 집중할지 질문하세요.
이 세 가지 범주에서 아무것도 찾지 못한 경우 명확히 말합니다. 그런 다음 대신 가장 작은 유용한 작업 — 리포지토리에 이미 있는 스크립트나 테스트 명령을 실행하고 그 출력을 확인하는 태스크 — 을 제안합니다. 아무것도 증명하지 못하는 빈 스위트를 스캐폴딩하지 마세요.
4단계 — 하나의 실제 태스크 스캐폴딩
2단계에서 확인한 트리에 작성합니다. 리포지토리에 태스크가 없으면 위치를 제안하고 물어보세요. 2단계의 "절대 덮어쓰지 않음" 규칙은 여전히 적용됩니다. 이 규칙이 존재하는 유일한 장소입니다.
3단계에서 찾은 내용을 기반으로 하나의 태스크를 작성합니다:
- CLI — CLI가 수행하는 작업을 요청하는 프롬프트와, 단순히 파일이 생성되었는지가 아니라 결과 파일의 내용을 확인하는 기준을 가진 태스크입니다.
- MCP 서버 — 특정 도구 하나를 실행하고 그 효과를 검증하는 태스크입니다.
- 스킬 —
/coder-eval:check-skill을 안내합니다. 활성화 스위트는 기능 태스크와 다른 형태이며, 해당 스킬이 이를 올바르게 구축합니다.
프롬프트는 지시하고, 기준은 검증합니다. 기준이 확인하는 내용을 프롬프트에서 반복하지 마세요. "파일에 X가 포함되어 있는지 확인하세요"라고 말하는 프롬프트는 능력이 아닌 읽기 이해력을 테스트합니다.
기준을 작성하기 전에 ${CLAUDE_PLUGIN_ROOT}/reference/task-rubric.md를 읽으세요. 태스크가 잘못된 이유로 통과될 수 있는지 확인하는 공유 체크리스트이며, 여기서 스캐폴딩하는 하나의 태스크는 이 리포지토리의 모든 이후 태스크가 참고할 예시가 됩니다. 따라서 나중에 수정하는 것보다 지금 올바르게 만드는 것이 더 가치 있습니다. 기준 유형과 해당 필드에 대해서는 ${CLAUDE_PLUGIN_ROOT}/reference/criteria.md를 읽으세요.
사용자가 더 많은 태스크를 원하면 /coder-eval:task를 사용하세요. 이는 자연어 브리프를 사용하는 동일한 작성 루프입니다.
5단계 — 환경 변수
선택한 에이전트가 필요한 변수(예: 기본 claude-code 에이전트의 경우 ANTHROPIC_API_KEY)를 .env.example 에 작성합니다 — 생성하거나 추가합니다.
.env는 절대 작성하지 마세요. 이미 실제 비밀이 포함되어 있을 수 있습니다. .env가 존재하지 않으면, 사용자에게 생성하도록 제안하기 전에 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 게이트로 전환한다는 점.