실증 루프로 다시 읽는 skill-creator

Anthropic 공식 skill-creator는 "스킬을 만드는 스킬"이다. 흥미로운 점은 superpowers와 정반대 성격이라는 것 — Iron Law로 잠그는 대신 테스트 → 평가 → 개선 루프로 스킬을 진화시킨다. 같은 6기둥(ROLE · GOAL · FORBID · OUTPUT · EXAMPLE · CHECK)에 매핑하면 그 차이가 분명히 보인다.

01 · 두 가지 하네스 성격superpowers vs skill-creator

같은 마크다운 하네스라도 무게중심이 다르다. 내 규칙서가 어느 쪽인지를 먼저 정해야 한다.

둘은 적이 아니라 짝이다. superpowers는 한 스킬 안의 규칙을 잠그고, skill-creator는 그 스킬 자체를 더 잘 만들기 위해 돌린다. 하나가 "어떻게 매번 같이 답하게 할까", 다른 하나가 "그 규칙이 정말로 잘 작동하는지 어떻게 알까"에 답한다.

02 · 핵심 루프skill-creator의 6단계

SKILL.md 마지막에 같은 루프를 두 번 적어 둔다("Repeating one more time for emphasis"). 척추가 흐트러질 것을 안다는 신호.

03 · 6기둥 매핑skill-creator는 각 칸을 어떻게 채우는가

기둥	구문 장치	역할
1 · ROLE	description은 "pushy"하게 적어라 "Your job is to figure out where the user is in this process"	스킬은 호출되어야 호출된다 — 호출 자체가 1순위 과제. description에 트리거 문맥(키워드·시점·인접 상황)을 일부러 과하게 적어 undertrigger를 방어한다.
2 · GOAL	"Create skills that can be used a million times across many different prompts" "Explain the WHY behind everything"	단발 산출이 아니라 재사용 가능한 일반 규칙을 만드는 게 목표. 그래서 톤도 "MUST"가 아니라 "이게 왜 중요한지 모델에게 설명하라"가 척추.
3 · FORBID	"ALWAYS/NEVER 대문자 = yellow flag" "Don't make should-not-trigger queries obviously irrelevant" "Do NOT use /skill-test" "Don't force assertions onto subjective skills"	superpowers와 정반대 톤. 강한 금지 대신 잘못된 작법을 yellow flag로 표시. 단, eval 절차의 우회는 단호히 차단(NOT use /skill-test).
4 · OUTPUT	스킬 디렉토리 anatomy(SKILL.md / scripts/ / references/ / assets/) workspace 구조(iteration-N/eval-X/with_skill|without_skill) evals.json, eval_metadata.json, grading.json, benchmark.json, feedback.json grading.json 필드명: 정확히 text · passed · evidence	가장 두꺼운 칸. 산출물이 한 파일이 아니라 다중 파일 트리다 보니 파일명·경로·필드명까지 못 박는다. 뷰어가 정확한 필드명에 의존하기 때문.
5 · EXAMPLE	description "before/after"(밋밋 → pushy) commit message Input/Output 견본 eval query Bad/Good 짝(Q4 sales xlsx 시나리오) JSON 스키마 견본	모든 추상 규칙에 반드시 짝지은 견본이 붙는다. 특히 trigger eval query는 "리얼한 사용자 말투" 견본을 길게 적어 톤까지 학습시킨다.
6 · CHECK	5단계 실행 절차(Spawn → Draft assertions → Capture timing → Grade/aggregate/launch viewer → Read feedback) train/test 60·40 split (description optimizer) "분석가 패스"(non-discriminating assertion, flaky eval 식별) blind comparison(2 outputs to independent agent)	검수가 본체. 사람 리뷰(정성) + benchmark(정량) + 자동화 가능한 부분은 grader 스크립트로. 게이트 하나가 아니라 다층 검수 체계.

04 · 표준 프론트매터"pushy" description의 실제

skill-creator가 직접 보여주는 description 작법 변환. 같은 의미를 트리거 키워드로 두텁게 감싼다.

이게 1 ROLE의 핵심. "정확한 한 줄"보다 "조금 과한 한 줄"이 실전에서 더 잘 작동한다는 경험칙이 그대로 적혀 있다.

05 · OUTPUT 구조다중 파일·다중 폴더로 검수를 강제

skill-creator의 OUTPUT은 한 파일이 아니라 폴더 트리다. 구조 자체가 검수 절차를 강제한다.

# 스킬 자체의 anatomy
skill-name/
├── SKILL.md              ← required (YAML frontmatter + body)
├── scripts/              ← deterministic 코드
├── references/           ← 필요 시 로드되는 도큐
└── assets/               ← 출력에 들어가는 템플릿·아이콘·폰트

# eval workspace 구조 (sibling 디렉토리)
<skill-name>-workspace/
├── skill-snapshot/                   ← 기존 스킬 개선 시 baseline
├── iteration-1/
│   ├── eval-0-descriptive-name/
│   │   ├── with_skill/outputs/...
│   │   ├── without_skill/outputs/    ← 또는 old_skill/outputs/
│   │   ├── eval_metadata.json
│   │   ├── timing.json               ← total_tokens · duration_ms
│   │   └── grading.json              ← {text, passed, evidence}
│   ├── benchmark.json                ← 집계: pass_rate · time · tokens
│   ├── benchmark.md
│   └── feedback.json                 ← 사용자 리뷰 결과
└── iteration-2/                      ← 매 사이클마다 새 폴더
    └── ...

한 칸이라도 어긋나면 뷰어가 깨진다. 특히 grading.json의 text · passed · evidence 필드명은 "viewer depends on these exact field names"라고 명시 — 뷰어 코드와 데이터 계약이 잠겨 있다.

06 · CHECK 본체실증 루프 4겹 검수

skill-creator의 CHECK는 단순 체크리스트가 아니라 4겹 평가 체계다.

07 · 작법 철학"musty MUSTs" 대신 "WHY"

skill-creator가 가장 단호하게 적은 작법 원칙. superpowers의 Iron Law 톤과 정반대.

주의: 이건 "FORBID를 쓰지 말라"는 게 아니다. 가능하면 reframe해서 이유를 설명하라는 뜻. superpowers의 Iron Law도 사실 "왜 이게 절대인가"를 길게 설명한 뒤 박는다 — 둘은 같은 원칙의 다른 균형점이다.

08 · 핵심 패턴 5가지skill-creator에서 가져갈 것

• description은 일부러 과하게 적는다 Claude는 스킬을 undertrigger하는 경향이 있다. "use whenever ~ mentions X, Y, or Z, even if they don't explicitly ask" 같은 pushy 문장으로 트리거 키워드를 두텁게 감싼다. 정확한 한 줄보다 살짝 과한 한 줄이 실전에서 잘 작동한다.
• with-skill / baseline 짝 실행이 기본 단위 한 번에 하나만 돌리지 않는다. 같은 프롬프트를 스킬 있는 버전과 없는 버전(또는 이전 버전)으로 같은 턴에 동시 spawn해야 비교가 가능하다. 이게 "스킬이 정말 도움이 되는가"를 정량 측정하는 유일한 방법.
• OUTPUT은 파일 트리 + 정확한 필드명 산출물이 여러 파일이라면 폴더 구조와 JSON 필드명까지 못 박는다. grading.json의 필드명 하나가 어긋나면 viewer가 깨진다. 데이터 계약은 코드보다 엄격하게.
• 정량 + 정성 + 분석가 + 자동 루프 — 4겹 검수 사람 리뷰만, 또는 assertion만으로는 부족하다. 사람(톤) · 스크립트(정확성) · 분석가(non-discriminating 식별) · train/test 자동 루프(overfitting 방지) 4겹을 모두 둔다. 한 겹은 다른 겹이 못 보는 걸 본다.
• MUST 대신 WHY를 적는다 대문자 ALWAYS/NEVER가 yellow flag. 모델이 이유를 알면 견본 너머에도 적용하지만, 이유 없이 박힌 규칙은 그 견본에서만 작동한다. 단, "왜 이게 절대인지"를 길게 설명한 FORBID는 여전히 강하다.

09 · 빈칸 체크두 레퍼런스를 합쳐 본인 규칙서에 적용

같은 6기둥, 두 가지 무게중심. 본인 규칙서가 어느 쪽에 가까운지 정한 뒤 각 기둥의 강도를 조절한다.

기둥	superpowers 식 (잠근다)	skill-creator 식 (개선한다)
1 · ROLE	"Use when X, before Y" — 호출 조건 명시	"Pushy" — 인접 키워드까지 두텁게 감쌈
2 · GOAL	"Core principle:" 한 줄	"Million-times reusable" — 일반화 강조
3 · FORBID	Iron Law + Rationalization 표 4겹	"Yellow flag" 톤 + 명확한 절차 우회만 차단
4 · OUTPUT	한 파일 헤더 템플릿 + 저장 경로	다중 파일 트리 + 정확한 필드명 계약
5 · EXAMPLE	<Good>/<Bad> 짝 코드	before/after description, 리얼 말투 견본
6 · CHECK	다이아몬드 분기 + 게이트 통과 강제	정성·정량·분석가·자동 루프 4겹 검수

실습 연결: 2003-4-1-harness-writing-practice.md에서 본인 규칙서를 잠그고, 그 뒤에 skill-creator의 eval 루프를 가벼운 버전으로라도 한 번 돌려 본다 — 같은 프롬프트를 규칙서 있는 버전과 없는 버전으로 두 번 던지고 산출물을 옆에 놓고 비교한다. 한 번이라도 돌려 봐야 "이 규칙은 실제로 잠겼다"는 게 증거로 남는다.