create-skill-test

create-skill-test 스킬 개요

create-skill-test는 dotnet/skills 저장소에서 에이전트 스킬용 eval.yaml 테스트 파일을 만들 때 쓰는 스캐폴딩 및 검증 보조 도구입니다. “테스트를 하나 써 달라”는 식의 일반 프롬프트가 아니라, 신뢰할 수 있는 출발점이 필요한 사람을 위한 도구입니다. 핵심 역할은 대상 스킬, 플러그인 이름, 시나리오 아이디어를 받아 컨벤션을 해치지 않는 테스트 구조로 바꾸고, 오버피팅 가능성이 낮은 fixtures, assertions, rubric을 갖추게 하는 데 있습니다.

create-skill-test 스킬은 이미 평가하려는 스킬이 무엇인지 알고 있고, 저장소 규칙에 맞는 테스트 파일을 빠르게 만들어야 하는 작성자에게 가장 잘 맞습니다. 반대로 테스트를 실행하거나, validator 실패를 디버깅하거나, 스킬 지침을 처음부터 쓰려는 경우에는 활용도가 낮습니다.

create-skill-test는 무엇을 위한 도구인가

새 eval 파일을 만들거나, 기존 파일에 시나리오를 더하거나, rubric이 특정 출력 하나에만 지나치게 맞춰져 있는지 점검할 때 create-skill-test 스킬을 사용하세요. 특히 create-skill-test for Skill Testing 워크플로처럼 테스트 설계의 품질이 YAML 형식만큼 중요한 경우에 유용합니다.

무엇을 피하게 해 주는가

가장 큰 장점은 깨지기 쉬운 eval을 피하는 것입니다. 예를 들면 필수 필드 누락, skill path 불일치, fixture 구성의 부실, 그리고 실제 동작이 아니라 특정 표현 하나만 보상하는 rubric 문구 같은 문제입니다. 대상 스킬이 발전해도 테스트가 계속 쓸모 있으려면 이런 부분을 피하는 것이 중요합니다.

대체하지 않는 것

이 도구는 skill-validator를 대체하지 않으며, SKILL.md 파일 편집도 도와주지 않습니다. 깨진 테스트 실행 원인을 진단하거나 validator 출력을 디버깅하려는 목적이라면 이 도구는 맞지 않습니다.

create-skill-test 스킬 사용 방법

설치하고 원본 스킬 열기

npx skills add dotnet/skills --skill create-skill-test로 create-skill-test를 설치하세요. 그다음에는 먼저 SKILL.md를 읽어야 합니다. 여기에는 워크플로, 입력 요구사항, 그리고 요청이 유효한지 여부를 가르는 경계가 들어 있기 때문입니다. 모델에 무언가를 생성시키기 전에 이 기준부터 확인해야 합니다.

올바른 테스트 브리프를 제공하기

좋은 create-skill-test install 요청은 단순히 “테스트를 만들어 줘”가 아닙니다. 스킬 이름, 플러그인 이름, 검증하려는 동작, 그리고 시나리오 제약을 함께 넣어야 합니다. 이 스킬은 plugins/<plugin>/skills/ 아래의 대상 skill 같은 입력을 기대하므로, 이름을 정확하게 적는 것이 중요합니다.

더 나은 브리프의 예시는 다음과 같습니다.

• Skill: foo-bar
• Plugin: dotnet-msbuild
• Goal: 에이전트가 유효한 요약을 생성하고 지원되지 않는 경로는 거부하는지 확인
• Scenario: 일부 맥락만 가진 초보 사용자
• Fixture need: 최소 입력 파일 1개와 엣지 케이스 파일 1개

이 정도면 create-skill-test usage 흐름이 단순한 템플릿이 아니라, 실제로 쓸 만한 eval을 만들 수 있는 구조를 확보하게 됩니다.

중요한 저장소 섹션을 읽기

먼저 SKILL.md를 보고, 그다음 README.md, AGENTS.md, metadata.json이 있는지 확인하세요. 또한 주변에 rules/, resources/, references/, scripts/ 폴더가 있으면 함께 살펴보는 것이 좋습니다. 이 저장소 스냅샷에서는 SKILL.md만 드러나 있으므로, skill 정의 자체가 가장 중요한 단일 기준 자료입니다.

시나리오와 rubric을 반복 개선하기

첫 초안을 만든 뒤에는 테스트가 정말 의도한 동작을 측정하는지 확인하세요. rubric이 결과가 아니라 표현만 보상한다면 더 엄격하게 고치고, 시나리오가 너무 넓다면 분리하세요. skill에 필요한 것이 하나의 정상 흐름뿐이라면, 불필요한 케이스를 억지로 늘리기보다 eval을 작고 명확하게 유지하는 편이 낫습니다.

create-skill-test 스킬 FAQ

create-skill-test는 dotnet/skills에만 쓰는 도구인가?

네. dotnet/skills 저장소의 컨벤션과 plugins/<plugin>/skills/ 레이아웃을 기준으로 설계되어 있습니다. 다른 곳에도 개념은 적용할 수 있지만, 저장소 구조와 검증 기대치가 비슷할 때 create-skill-test 가이드의 가치가 가장 큽니다.

일반 프롬프트 대신 이걸 써야 하나?

구조적 실수를 줄인 반복 가능한 eval 스캐폴드를 원한다면 create-skill-test를 쓰는 것이 맞습니다. 일반 프롬프트로도 테스트를 설명할 수는 있지만, 저장소별 컨벤션, fixture 배치, 오버피팅 점검에서는 대개 더 약합니다.

초보자도 쓰기 쉬운가?

대상 skill을 식별하고 시나리오를 쉬운 말로 설명할 수 있다면 그렇습니다. 하지만 plugin 이름, skill path, 테스트 대상 동작을 말할 수 없다면 초보자 친화적이지 않습니다. 이런 입력값들이 생성 결과를 직접 좌우하기 때문입니다.

언제 쓰지 말아야 하나?

테스트 실행, validator 오류 디버깅, 새 skill 작성에는 create-skill-test를 쓰지 마세요. 이들은 인접한 워크플로처럼 보이지만, 사용하는 도구도 다르고 성공 기준도 다릅니다.

create-skill-test 스킬 개선 방법

입력 범위를 더 좁히기

create-skill-test의 결과는 넓은 의도보다 구체적인 시나리오에서 훨씬 좋아집니다. “맥락이 부족할 때도 skill이 안전한 fallback을 반환하는지 테스트해 달라”는 요청은 “포괄적인 eval을 만들어 달라”보다 훨씬 강합니다. 무엇이 중요한 동작인지, 무엇을 과도하게 점수 주면 안 되는지 분명히 알려 주기 때문입니다.

YAML만이 아니라 rubric 품질까지 요청하기

구조만 요청하면 기술적으로는 유효하지만 여전히 오버피팅된 파일이 나올 수 있습니다. 성공으로 봐야 할 것, 실패로 처리해야 할 것, 그리고 부차적인 디테일이 무엇인지까지 말하세요. 이것이 create-skill-test for Skill Testing 결과를 가장 빠르게 끌어올리는 방법입니다.

생성 후 오버피팅 여부 확인하기

assertion이 하나의 표현, 고정된 순서, 특정 예시 문자열만 보상하고 있지 않은지 확인하세요. 물론 그 정도의 구체성이 정말 필요한 경우도 있습니다. 하지만 좋은 eval은 한 번의 실행에서 나온 정확한 문구가 아니라, skill이 유지해야 할 동작을 측정해야 합니다.

validator 피드백으로 다듬기

첫 출력이 validation에 실패했다면, 정확한 에러 메시지와 그 주변의 YAML 조각을 함께 다시 넣으세요. 전체 요청을 다시 설명하는 것보다, 이렇게 피드백을 주는 편이 보통 두 번째 결과를 훨씬 좋게 만듭니다.