skill-creator

name	skill-creator
description	Pi 스킬을 생성·수정하거나 SKILL.md, description·트리거, progressive disclosure, eval을 설계·검증할 때 사용한다.

skill-creator

Pi 환경에서 Agent Skills 표준을 따르는 스킬을 만들고, 작게 검증하고, 피드백으로 반복 개선한다. Anthropic의 skill-creator에서 가져온 핵심 루프(의도 파악 → 초안 → 테스트 프롬프트 → 평가 → 개선)를 Pi 도구와 로컬 스킬 구조에 맞게 적용한다.

핵심 원칙

• Pi 우선: Claude Code 전용 명령, claude -p, Anthropic eval viewer 스크립트를 전제로 하지 않는다. Pi CLI, read/write/edit/bash, 필요 시 subagent, ask_user_question, todo_write를 사용한다.
• 표준 준수, Pi 동작 우선: SKILL.md는 Agent Skills 표준의 YAML frontmatter + Markdown 본문을 따른다. 단 Pi는 표준 일부를 의도적으로 완화한다(아래 "Pi vs 표준" 참고). 충돌 시 Pi 동작을 따른다.
• Progressive disclosure: 항상 들어가는 description은 정확하고 트리거 친화적으로, 본문은 500줄 미만을 목표로, 긴 자료는 references/, 반복 가능한 작업은 scripts/, 템플릿은 assets/에 둔다.
• 검증 가능한 산출물: 새 스킬에는 최소한 자체 검증 체크리스트와 현실적인 테스트 프롬프트를 남긴다. 객관 검증이 가능한 스킬이면 evals/evals.json도 만든다.
• 놀라움 금지: 사용자가 기대하지 않은 권한 상승, 데이터 유출, 위험한 자동화, 악성 행위 보조 스킬은 만들지 않는다.

Pi vs 표준 (자주 헷갈리는 지점)

• 이름과 디렉터리명이 달라도 Pi는 경고만 한다(표준은 일치 요구). 여러 하네스가 공유하는 스킬 디렉터리에서는 일부러 다르게 두는 것이 합리적일 수 있다.
• description이 없으면 Pi는 스킬을 아예 로딩하지 않는다. 다른 위반은 대부분 warning만 내고 로딩은 된다.
• 같은 이름 스킬이 여러 위치에 있으면 먼저 발견된 것만 사용되고 나머지는 warning이 뜬다.

언제 어떤 작업을 하나

사용자가 스킬을 만들고 싶다
  ├─ 의도/트리거/출력 형식이 충분히 명확함 → 초안 작성
  ├─ 일부만 명확함 → 대화 기록에서 추출 후 빈칸만 질문
  └─ 모호함 → ask_user_question으로 목적, 트리거, 산출물, 평가 필요 여부를 한 번에 확인

사용자가 기존 스킬을 고치고 싶다
  ├─ 경로 제공됨 → 해당 SKILL.md와 주변 resources 읽기
  └─ 경로 없음 → 후보 검색 후 확인

사용자가 스킬 성능/트리거를 개선하고 싶다
  ├─ 현재 description 분석
  ├─ should-trigger / should-not-trigger 쿼리 작성
  └─ 필요하면 Pi CLI 또는 subagent로 소규모 eval 실행

Workflow

1. 컨텍스트 수집

1. 관련 공식 문서를 확인한다.
   • Pi 스킬 문서: /usr/local/lib/node_modules/@earendil-works/pi-coding-agent/docs/skills.md
   • 필요 시 Pi 사용법: /usr/local/lib/node_modules/@earendil-works/pi-coding-agent/docs/usage.md, README.md
   • Agent Skills 표준: https://agentskills.io/specification
   • 패키지 경로가 바뀌었을 수 있다면 npm root -g로 확인한다.
2. 기존 스킬 패턴이 필요하면 ~/.pi/agent/skills/, ~/.agents/skills/, 프로젝트의 .pi/skills/, .agents/skills/를 살펴본다.
3. 사용자의 현재 대화에서 다음을 먼저 추출한다.
   • 스킬이 가능하게 해야 하는 일
   • 트리거되어야 하는 표현/상황
   • 기대 산출물 형식
   • 필요한 도구/의존성/권한
   • 테스트 또는 eval이 필요한지
4. 빈칸이 많으면 ask_user_question으로 한 번에 묻는다. 단, 이미 충분히 명확하면 묻지 말고 진행한다.

2. 위치와 이름 결정

로딩 위치(Pi가 자동 스캔):

• 전역(Pi 전용): ~/.pi/agent/skills/
• 전역(cross-harness 공유): ~/.agents/skills/
• 프로젝트(Pi 전용): <repo>/.pi/skills/
• 프로젝트(cross-harness): <repo>/.agents/skills/ — cwd부터 git 루트(또는 fs 루트)까지 상향 탐색
• 패키지: package.json의 pi.skills 또는 패키지 내 skills/
• 설정/명령행: .pi/settings.json의 "skills" 배열, pi --skill <path>(반복 가능, --no-skills와도 합산)

탐색 디테일:

• ~/.pi/agent/skills/, .pi/skills/에서는 루트의 단일 .md 파일도 스킬로 인식된다(디렉터리 없이 한 파일짜리 스킬 가능).
• ~/.agents/skills/, .agents/skills/에서는 루트의 .md는 무시되고 SKILL.md가 있는 디렉터리만 인식된다.
• 동일 이름이 여러 위치에 있으면 first-found wins. 충돌 시 워닝이 뜨므로 신규 스킬 이름은 미리 rg --files -g 'SKILL.md' ~/.pi/agent/skills ~/.agents/skills .pi/skills .agents/skills 2>/dev/null 정도로 확인.

다른 하네스(Claude Code, Codex)의 스킬을 가져와 쓰려면 .pi/settings.json(또는 ~/.pi/settings.json)에 추가:

{ "skills": ["~/.claude/skills", "~/.codex/skills"] }

이름 규칙(Pi 적용분):

• 1~64자, 소문자 영문/숫자/하이픈만 사용한다.
• 앞뒤 하이픈, 연속 하이픈은 금지한다.
• 디렉터리명과 name을 동일하게 두는 것을 권장한다(Agent Skills 표준 요구). 단 Pi는 강제하지 않으므로, cross-harness 공유 디렉터리에서 의도적으로 다르게 두어도 로딩된다.
• 예: ship, systematic-debugging, airtable-reporting

3. 설계 초안

복잡한 스킬이면 작성 전에 짧게 설계를 보여준다.

스킬 설계안:
- 이름/위치: ...
- 트리거: ...
- 핵심 workflow: ...
- resources: scripts/... references/... assets/...
- 검증 방법: ...

간단한 스킬이면 설계 문단을 내부 체크리스트로 처리하고 바로 초안을 작성해도 된다.

4. SKILL.md 작성 패턴

프론트매터(최소):

---
name: my-skill
description: 무엇을 하고 언제 사용해야 하는지 구체적으로 쓴다. 사용자의 실제 표현과 관련 키워드를 포함한다.
---

Pi가 인식하는 선택 필드:

필드	용도
license	라이선스 이름 또는 번들된 파일 참조
compatibility	환경 요구사항(최대 500자)
metadata	자유 key-value(에이전트가 무시해도 됨)
allowed-tools	공백 구분 사전 승인 툴 목록(experimental)
disable-model-invocation	true면 시스템 프롬프트에서 숨김. 자동 트리거 금지, /skill:name으로만 호출 가능

자동 트리거가 위험하거나 사용자 명시 호출만 허용해야 하는 스킬(파괴적 동작, 외부 전송, 비용 큰 작업)은 disable-model-invocation: true로 두는 것을 검토한다.

argument-hint 같은 Claude Code 전용 필드는 Pi가 인식하지 않으므로 넣지 않는다. 알려지지 않은 필드는 Pi가 조용히 무시한다.

본문 권장 구조:

# my-skill

한 문단 요약.

## 핵심 원칙
- 왜 이 절차가 중요한지 설명한다.

## Workflow
### 1. ...
### 2. ...

## Tool guidance
- 어떤 상황에서 어떤 Pi 도구를 쓸지 적는다.

## Output format
사용자가 기대하는 최종 응답/파일 형식을 명시한다.

## Validation
완료 전에 확인할 명령과 체크리스트를 적는다.

## Edge cases
흔한 실패/예외와 대응을 적는다.

작성 팁:

• description에는 "무엇"과 "언제"를 모두 넣는다. 자동 트리거는 이 필드에 크게 의존한다. 빠지면 Pi는 스킬 자체를 로딩하지 않는다.
• 모델이 따라야 하는 행동은 명령형으로 쓰되, 무조건적인 MUST 남발보다 이유를 설명한다.
• 대형 레퍼런스는 본문에 붙이지 말고 references/로 분리한 뒤 언제 읽어야 하는지 명시한다.
• 반복적·결정적 검증은 scripts/로 옮겨 매번 재발명하지 않게 한다.
• 상대 경로는 스킬 루트 기준으로 쓴다. 예: references/checklist.md, scripts/validate_skill.py. 절대경로(/Users/...)는 다른 사용자/머신에서 깨지므로 피한다.

/skill:name 강제 호출

Pi에서 사용자는 /skill:<name> 슬래시 명령으로 스킬을 명시 호출할 수 있다. 명령 뒤 인자는 User: <args> 형태로 스킬 본문 끝에 append된다.

/skill:my-skill input.pdf --pages 1-3

• 트리거 description이 약하거나 모호한 도메인이면 본문에 "확실하지 않으면 /skill:<name>으로 호출하세요" 같은 안내를 둔다.
• disable-model-invocation: true인 스킬은 이 경로로만 호출된다.
• 사용자가 끄고 싶다면 설정의 enableSkillCommands: false로 비활성화 가능.

5. Pi 친화적 평가 루프

사용자가 평가를 원하거나 객관 결과가 중요한 스킬이면 아래를 적용한다.

1. evals/evals.json을 만든다.
   • 시작은 2~3개 현실적인 프롬프트로 충분하다.
   • 파일 변환, 코드 생성, 데이터 추출처럼 객관 검증 가능한 항목에는 assertions를 추가한다.
   • 템플릿은 assets/evals-template.json을 참고한다.
2. 작업 공간을 스킬 디렉터리의 sibling으로 둔다.
   • 예: ~/.pi/agent/skills/<skill-name>-workspace/iteration-1/...
3. 가능한 경우 Pi CLI로 with-skill / baseline을 비교한다.

# with skill
pi --no-skills --skill /path/to/skill -p "<eval prompt>"

# baseline
pi --no-skills -p "<same eval prompt>"

4. 장시간 실행, TUI, 로그 추적이 필요하면 interactive_shell 스킬/도구 지침을 따른다.
5. 독립 판단이 중요한 경우에만 subagent를 사용한다. subagent를 쓰면 먼저 subagent help로 인터페이스를 확인하고, 같은 eval의 with-skill/baseline을 가능하면 batch로 띄운다.
6. 결과는 숫자보다 사용자 피드백을 우선한다. 단, 반복되는 실패는 스킬 본문이 아니라 scripts/나 references/로 구조화할 수 있는지 본다.

6. Description/trigger 개선

트리거 정확도를 개선할 때:

1. 실제 사용자가 말할 법한 쿼리 10~20개를 만든다.
   • should-trigger: 5~10개
   • should-not-trigger: 5~10개
   • 너무 쉬운 negative보다 비슷하지만 다른 작업인 near-miss를 포함한다.
2. 각 쿼리에 대해 현재 description에서 어떤 키워드/상황이 부족한지 분석한다.
3. 새 description은 1024자 이하로 유지하고, 다음을 포함한다.
   • 스킬이 하는 일
   • 반드시 써야 하는 상황
   • 사용자의 자연어 표현/키워드
   • 쓰지 말아야 할 가까운 상황은 본문 edge case에 둔다.
4. 과적합하지 않는다. 특정 eval 문장을 그대로 나열하지 말고 일반화한다.

7. 검증

스킬 작성/수정 후 반드시 아래를 확인한다.

python3 ~/.pi/agent/skills/skill-creator/scripts/validate_skill.py /path/to/skill

검증 스크립트는 다음을 본다(요약):

• 필수: SKILL.md 존재, frontmatter 형식, name/description 유무, name 글자 규칙, 길이 제한
• 경고: name과 디렉터리명 불일치(Pi 허용, 표준 위반), description이 너무 짧음, 500줄 초과, 본문 내 깨진 상대 경로 참조, 절대 경로 사용, allowed-tools 형식, 알려지지 않은 frontmatter 필드

추가 사람 검토:

• 본문이 너무 길면 references/로 분리했는가
• 스킬이 위험한 행동을 암묵적으로 지시하지 않는가
• 새 스킬을 글로벌에 추가했다면 사용자가 /reload 또는 새 세션을 시작해야 한다는 점을 안내했는가
• 격리 테스트가 필요하면 pi --no-skills --skill /path/to/skill -p "<쿼리>"로 재현 가능한지 확인
• 최종 보고에 생성/수정 파일과 검증 결과 포함

Output format

최종 응답은 짧게:

완료했습니다.
- 생성/수정: `path/to/SKILL.md`, ...
- 검증: `python3 .../validate_skill.py ...` 통과
- 참고: Pi 스킬 문서 / Agent Skills 표준 기준 반영

사용자에게 다음 행동이 필요하면 한 줄로만 묻는다. 예: "트리거 eval까지 돌려볼까요?"