| 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. 컨텍스트 수집
- 관련 공식 문서를 확인한다.
- 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로 확인한다.
- 기존 스킬 패턴이 필요하면
~/.pi/agent/skills/, ~/.agents/skills/, 프로젝트의 .pi/skills/, .agents/skills/를 살펴본다.
- 사용자의 현재 대화에서 다음을 먼저 추출한다.
- 스킬이 가능하게 해야 하는 일
- 트리거되어야 하는 표현/상황
- 기대 산출물 형식
- 필요한 도구/의존성/권한
- 테스트 또는 eval이 필요한지
- 빈칸이 많으면
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 친화적 평가 루프
사용자가 평가를 원하거나 객관 결과가 중요한 스킬이면 아래를 적용한다.
evals/evals.json을 만든다.
- 시작은 2~3개 현실적인 프롬프트로 충분하다.
- 파일 변환, 코드 생성, 데이터 추출처럼 객관 검증 가능한 항목에는
assertions를 추가한다.
- 템플릿은
assets/evals-template.json을 참고한다.
- 작업 공간을 스킬 디렉터리의 sibling으로 둔다.
- 예:
~/.pi/agent/skills/<skill-name>-workspace/iteration-1/...
- 가능한 경우 Pi CLI로 with-skill / baseline을 비교한다.
pi --no-skills --skill /path/to/skill -p "<eval prompt>"
pi --no-skills -p "<same eval prompt>"
- 장시간 실행, TUI, 로그 추적이 필요하면
interactive_shell 스킬/도구 지침을 따른다.
- 독립 판단이 중요한 경우에만
subagent를 사용한다. subagent를 쓰면 먼저 subagent help로 인터페이스를 확인하고, 같은 eval의 with-skill/baseline을 가능하면 batch로 띄운다.
- 결과는 숫자보다 사용자 피드백을 우선한다. 단, 반복되는 실패는 스킬 본문이 아니라
scripts/나 references/로 구조화할 수 있는지 본다.
6. Description/trigger 개선
트리거 정확도를 개선할 때:
- 실제 사용자가 말할 법한 쿼리 10~20개를 만든다.
- should-trigger: 5~10개
- should-not-trigger: 5~10개
- 너무 쉬운 negative보다 비슷하지만 다른 작업인 near-miss를 포함한다.
- 각 쿼리에 대해 현재 description에서 어떤 키워드/상황이 부족한지 분석한다.
- 새 description은 1024자 이하로 유지하고, 다음을 포함한다.
- 스킬이 하는 일
- 반드시 써야 하는 상황
- 사용자의 자연어 표현/키워드
- 쓰지 말아야 할 가까운 상황은 본문 edge case에 둔다.
- 과적합하지 않는다. 특정 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까지 돌려볼까요?"
