03-실전

03. 실전 — 첫 스킬 만들기 30분 워크플로우

0~5분: 후보 고르기

다음 두 조건을 모두 만족하는 작업을 고른다.

1. 명령으로 1~2주 운영해 본 적이 있다 (검증된 프롬프트가 있다).
2. 자동 호출되면 좋을 작업이다 — 사용자가 매번 명령 이름을 떠올리지 않아도 됨.

전형적 후보: lint-fix, explain-code, pr-summary, migration-plan.

5~10분: 폴더 골격

mkdir -p .claude/skills/lint-fix
$EDITOR .claude/skills/lint-fix/SKILL.md

10~20분: SKILL.md 작성

frontmatter부터 description을 정확히. “Use when…” 형식을 권장:

---
name: lint-fix
description: |
  Fixes lint and type errors in TypeScript files.
  Use when the user mentions ESLint errors, TypeScript errors,
  or asks to clean up code style issues. Also use after editing
  TS/TSX files if eslint reports new violations.
allowed-tools: ["Read", "Edit", "Bash(pnpm lint*)", "Bash(pnpm typecheck*)"]
invocation: auto
---

본문 단계는 아주 구체적으로:

## 단계
1. `pnpm lint --format json` 실행, 결과를 분석.
2. 가장 많이 보고된 규칙 3개를 식별.
3. 각 파일을 Read로 열고 해당 규칙만 수정.
4. 수정 후 `pnpm lint`를 다시 돌려 0이 될 때까지 반복.
5. `pnpm typecheck`로 회귀 확인.

20~25분: 자동 호출 테스트

새 세션을 열고 description의 트리거 문구를 살짝 다른 표현으로 시도.

• “ESLint에서 빨간 줄이 잔뜩 떴어” → 호출되어야 함.
• “테스트 깨졌는데” → 호출되면 안 됨.

자동 호출이 잘못 발화하면 description을 좁힌다 (“only when…” 추가).

25~30분: 보조 파일 분리

본문이 200줄을 넘기면 일부를 옆 파일로 빼고 본문에서 가리킨다. 이게 토큰 절약의 정수.

## 보조 파일
- `eslint-rule-fixes.md` — 규칙별 자동 수정 패턴 카탈로그. 처음 보는 규칙이면 먼저 읽어라.