Skill Create 코어5

/skill-create — 스킬 제조 공장

PO의 철학: "가져다 쓰지 마라. 분해하고, 결함 부분은 걸러내고, 검증된 부품만 가려내 조립하라. 발굴 자체가 실력이 아니라 — 발굴 + 검증 + 자기 자산화까지 가는 흐름이 실력이다."

필요한 Claude Code 스킬을 막연한 요청 한 줄에서 받아, 완성·검증된 SKILL.md로 출하하는 메타 스킬 — 스킬을 만드는 스킬.

⚠️ 제조 대상 한정 (V3.2): 이 스킬은 Claude Code 스킬 — ~/.claude/skills/{name}/SKILL.md 형태로 등재되어 슬래시 명령(/{name})으로 호출되는 절차·방법론 단위 — 만 제조한다. LLM 의존형 독립 에이전트(웹사이트·데몬·API 등 자체 실행체) 제조는 형제 공장 /llm-dependent-agent-create가 담당한다 (둘은 같은 9-Phase 방식·같은 "분해·검증 후 조립" 철학을 공유하며, 같은 자산이 스킬로 출하될 수도 에이전트로 재포장될 수도 있는 양방향 관계다).

이 스킬은 공개 저장소의 기존 스킬을 통째로 신뢰하지 않는다. 발굴물을 작업대에 올려 부품(Phase 블록·프롬프트·체크리스트) 단위로 검증하고, 안전하지 않은 부분을 걸러낸 뒤 검증된 부품만 적용한다. 그 위에 자체 작성을 얹어 조립하고, QC 출하검사를 통과한 것만 자산으로 등재한다. 출하 후에는 운영 루프가 돌면서 사용 통계·피드백을 Phase 1로 회귀시켜 다음 사이클을 시작한다.

공장 비유 (Manufacturing Metaphor)

원자재 입고   →  공개 저장소·OSS·사내 자산에서 부품 발굴
입고 검사     →  발굴물 5대 KPI 검증
안전성 진단   →  주작-sal-da 방식 위험도 감사 — 결함 부분 식별
해체·선별     →  부품 단위 분해 / 결함 부분 걸러내기 / 검증된 부품만 선별
부품 창고(BOM)→  검증 통과 부품 목록 (5분류: 🟢🟡🔴🏭🔵)
조립          →  검증 부품 + 자체 작성 결합 → SKILL.md
출하 검사     →  4단 QC (정적·동적·호출·외부 검증) + 별도 Verification Agent
출하          →  ~/.claude/skills/ 등재 + CLAUDE.md 기록
운영·개선     →  사용 통계·피드백 → Phase 1 회귀

핵심은 "부품 선별·조립·운영 루프" — 공급원에서 부품을 받되 결함은 걸러내고 검증된 부품만 가져다 조립하며, 출하 후에도 피드백을 다음 사이클로 환류시킨다.

Usage

/skill-create [만들고 싶은 스킬 설명]

# 예시
/skill-create PR 올라오면 자동 리뷰 코멘트 다는 스킬       # 단일 모드
/skill-create 회의록·기안문·검토보고서 3종 양식 자동화 묶음  # 배치 모드
/skill-create                                            # 대화 맥락에서 자동 도출

핵심 원칙 (8대 철칙)

1. 발굴물 무신뢰 — 공개 저장소·사내 자산도 통째로 가져다 쓰지 않는다. 반드시 분해·검증한다.
2. 부품 단위 선별 — 발굴물 전체가 아니라 검증된 부품(Phase 블록·프롬프트·체크리스트)만 추출한다.
3. 운용 충돌 0건 — 타협 불가 — PO 글로벌 헌법(한국어 출력·보안 가드·SAL/MBO 자동 감지)을 깨는 부품은 기능이 아무리 좋아도 적용 거부한다.
4. 10라운드 + α 문답 항상 강제 — 막연한 요청을 그대로 받지 않는다. 모드에 맞춰 묻고 답해 스펙을 외부로 끌어낸다.
5. MBO 승인 게이트 — Phase 2 PO 승인 없이 제조(Phase 3 이후) 시작 금지.
6. 자기검증 금지 — 제조한 스킬을 제조자가 검증하지 않는다. 별도 Verification Agent를 투입한다.
7. "파일 생성 ≠ 동작함" — ~/.claude/skills/에 SKILL.md가 있는 것만으로 완료가 아니다. 실제 슬래시 호출로 의도대로 작동해야 완료다.
8. 자산화·운영까지가 완료 — 만들고 끝이 아니다. 등재 + CLAUDE.md 기록 + 운영 루프 가동까지 해야 출하 완료다.

스킬 특화 4대 원칙 (V3.2 유지)

• 단일 책임 — 하나의 명확한 목적만. 여러 목적을 한 스킬에 욱여넣지 않는다.
• 자기완결 — 만든 스킬은 다른 스킬 참조 링크에 의존하지 않는다. 필요한 내용은 추려서 자기 폴더 안에 참조 자료로 둔다.
• 간결 — 500줄 이내 권장. 거대 스킬 금지.
• 구조 완비 — YAML frontmatter(description·user-invocable) + Phase 구조 + 사용 예시 + 금지사항 — 4요소.

공장 파이프라인 (Phase 0 → 9, V3.2)

Phase 0  시동       — 무슨 스킬을? + 모드(단일/배치)?
Phase 1  요구 발굴   — 모드별 10라운드 + α 문답 → 기획안 + 아키텍처 SVG
Phase 2  목표 정의   — MBO 목표서 → PO 승인 ⛔게이트
Phase 2.5 도메인 심층 리서치 — 4 트랙 광역 조사 → 1장 요약 → PO 게이트 ★V3.5 R15 신설
Phase 3  발굴       — 공개 저장소·OSS·사내 자산에서 부품 수집
Phase 4  분해·검증   — BOM 5분류 (🟢🟡🔴🏭🔵) ★공장의 심장
Phase 5  설계 검증   — 페르소나 토론 (정량 규모별 S/M/L)
Phase 6  조립·제조   — SKILL.md 작성 (검증 부품 + 자체 작성)
Phase 7  출하 검사   — 4단 QC + 별도 Verification Agent
Phase 8  자산화·출하 — 등재 + CLAUDE.md 헌법 기록 + 출하 보고서
Phase 9  운영·개선   — 사용 통계·피드백 → Phase 1 회귀 (루프) ★V3.2 신설

Phase별 1장 요약표 ★V3.5 후속 신설 (입력 / 작업 / 출력 / 완료 조건)

⛔ Phase 0·2의 PO 게이트는 자율 진행 금지 — 반드시 PO 답을 받고 다음으로.

작동 프로세스 — 사용자 접점 (Runtime Flow)

🗣️ = PO에게 묻고 멈추는 지점 · ⚙️ = 스킬 자율 실행

/skill-create [요청]  호출
     │
🗣️ 접점 1  Phase 0   "무엇을 + 어느 모드(단일/배치)" — 대상·모드 확보
     │
🗣️ 접점 2  Phase 1   모드별 10라운드 + α 문답 → 기획안 + 아키텍처 SVG   ★핵심 상호작용
     │
🗣️ 접점 3  Phase 2   MBO 목표서 제시 → PO 승인   ⛔필수 게이트
     │
🗣️ 접점 3.5  Phase 2.5  도메인 심층 리서치 4 트랙 → 1장 요약 → PO 게이트 ★R15 신설
     │
⚙️         Phase 3   발굴 (자율 — 후보 애매 시만 접점)
⚙️         Phase 4   분해·검증 → BOM 5분류 (자율)
⚙️         Phase 5   설계검증 페르소나 토론 (자율, 결과 보고)
⚙️         Phase 6   SKILL.md 조립 (자율)
⚙️         Phase 7   QC 4단 출하검사 (자율, 결과 보고)
     │
🗣️ 접점 4  Phase 8   출하 보고 + 헌법 등재
     │
⚙️         Phase 9   운영·개선 루프 (자율 — 피드백 누적 시 Phase 1 회귀 권고)

사용자 접점 4개

Phase 0. 시동 (Intake)

• 인자가 있으면 그것을 제조 대상으로 한다.
• 인자가 없으면 대화 맥락에서 "무슨 스킬을 원하는지 + 단일/배치 중 어느 모드인지" 도출한다.
• 도출 불가 시 PO에게 한 줄 질문으로 확인한다.

모드 판별 (V3.2 신설)

포털 모드(1c)는 스킬에 무관 — 포털형은 호스팅·인증·DB 인프라가 본질이라 스킬(메타 절차서) 단위에는 적용되지 않는다. 포털형 자산이 필요하면 /llm-dependent-agent-create로 가야 한다.

판별 불가 시 결정 트리 (Q1):

Q. 만들 스킬 수가 2개 이상이면서 카테고리·패턴이 공통인가?
    NO  → 단일 (Phase 1a)
    YES → 배치 (Phase 1b)

PO 강제 거부권: PO가 결정 트리 결과에 동의하지 않으면 출하 보고서에 mode_override: true + tree_recommended + po_decision + risk 명시.

첫 질문 (도출 불가 시)

"어떤 스킬을 만들고 싶으십니까? 막연하게 한 줄로 주셔도 됩니다 — 이후 10라운드 + α 문답으로 함께 충분히 기획하겠습니다. 그리고 다음 두 가지도 알려주세요: ① 제조 모드 — 단일(1개) / 배치(N개 묶음) ② 작업 폴더 — 스킬을 어느 폴더에 만들지 (보통 ~/.claude/skills/{name}/)"

작업 폴더 지정 ★V3.4 필수 절차

Phase 1 진입 전 PO에게 작업 폴더 위치를 반드시 물어 확정한다. 표준 위치는 ~/.claude/skills/{name}/이나 PO 명시 지정도 허용.

Phase 1. 요구 발굴 — 모드별 10라운드 + α 문답 (V3.5 — 10라운드 기본)

막연한 요청을 그대로 제조에 넣지 않는다. 모드에 맞춰 한 번에 한 질문씩 진행한다. (출처: SUNNY AI MAGIC 50 #01 10라운드 + α 문답 브레인스토밍 → V3.5에서 길이 절반으로 단축)

★ V3.5 핵심 원칙 — 질문은 AI가 한다 + 초보자 친화

1. 묻는 주체는 AI(스킬)이다. PO에게 항목 나열을 던져 일방적으로 답하라고 시키지 않는다. AI가 한 질문씩 던지고 → PO가 답하고 → 다음 질문.
2. 초보자도 답할 수 있는 질문이어야 한다. 기술 용어를 그대로 쓰지 말고 풀어쓴 뒤 예시 1~2개를 동반한다.
3. 객관식·예시형 우선. 가능하면 AskUserQuestion 도구로 2~4개 선택지 + "Other" 직접 입력 형태. 자유 서술은 정말 자유 답이 필요할 때만.
4. 10라운드 기본, 부족 시 추가. 종료 신호가 안 나오면 라운드를 늘려 보강한다.

질문 톤 예시:

Phase 1a — 단일 모드 (10라운드 기본)

첫 멘트: "지금부터 스킬 만들기 진행합니다. 한 번에 한 질문씩 드릴 거예요. 어려운 용어는 풀어서 묻고 예시도 함께 드릴 테니 편하게 답해 주세요."

10라운드 3구간 (10은 기준선 — 종료 신호가 안 나오면 추가 라운드로 보강)

Phase 1b — 배치 모드 (5라운드 공통 + 변주)

N개 스킬을 1개씩 돌리는 건 비현실적이므로 공통 + 변주 구조로 진행:

종료 신호 / 금지

• 종료 신호: 모드별 산출물(아래)이 모두 채워진 시점.
• 부족 신호 → 라운드 추가: 산출물 항목 중 비어 있는 게 있거나 PO 답변이 "잘 모르겠다"·"적당히"로 끝났으면 그 항목만 짚어 1~3 라운드 추가 질문. 10라운드 채웠다는 이유로 강제 종료 금지.
• 금지: 라운드 중간에 "바로 답 줘"로 건너뛰지 않는다 — 막연한 스펙으로 회귀한다.

Phase 1 산출물

아키텍처 SVG는 끊긴 흐름·고아 부품을 눈으로 드러낸다. 제작 전 필수.

Phase 2. 목표 정의 — MBO 목표서 + 승인 게이트

Phase 1 기획안을 MBO 목표서로 구조화하여 PO에게 제시한다. (출처: mbo-천상)

이 단계에서 스킬 규모(S/M/L)를 확정한다.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  스킬 제조 목표서 — {스킬명/카탈로그명}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

## 제조 대상
{Phase 1 기획안 요약}
제조 모드 : 단일 / 배치(N개)
스킬 규모 : {S / M / L}

## 죽이는 수작업 (Pain Point)
| 현재 (AS-IS) | 스킬 도입 후 (TO-BE) |

## 측정 지표 (KPI)
| 지표 | 목표값 | 측정 방법 |
( ※ 반드시 사용자 여정 KPI 1개 이상 포함 — "파일 생성"은 데이터 KPI일 뿐 )
( ※ "실제 슬래시 호출 시 의도대로 작동" 같은 호출 KPI 필수 )

## 제조 계획
| Phase | 작업 | 예상 결과 |

## 리스크
| 리스크 | 대응 |
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
이 목표를 승인하시겠습니까?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⛔ PO 승인 없이 Phase 2.5 이후 진행 절대 금지. PO가 수정 요청 시 목표서를 고쳐 재제시.

Phase 2.5 ★V3.5 R15 신설 — 도메인 심층 리서치 (Deep Domain Research)

PO 지적 회고 (2026-05-29): "AI가 어느 정도 상황 파악한 다음에 지구상에 있는 모든 관련된 것들을 조사하는 그 프로세스가 있어야만이 제대로 된 수준 높은 스킬이 나온다." → Phase 3은 "부품 발굴"이라 스킬 도메인 자체 광역 조사가 빠져 있었음. 형제 공장 R15와 동일 동기화.

왜 필요한가: Phase 1·2까지는 "PO 의도 파악". Phase 3은 "부품 단위 발굴". 그 사이에 "이 분야 자체에 어떤 깊이가 표준인가" 광역 리서치가 빠지면 표면적 스킬로 끝남.

2.5-1. 키워드 망 작성

Phase 1·2에서 도출된 도메인·문제·트리거 키워드를 영문·한국어 양쪽 정리 (핵심 35 + 보조 510 + 부정 2~3).

2.5-2. 4개 트랙 병렬 조사 (★핵심)

각 트랙은 WebSearch·WebFetch·Subagent 위탁 가능. 병렬 처리 권장.

2.5-3. 종합 — 1장 요약서

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Phase 2.5 도메인 심층 리서치 요약 — {스킬 도메인명}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

## 4 트랙 조사 ({S 8건 / M 20건 / L 40건+})

### ① 기존 스킬·솔루션 (N건)
- {이름} | URL | 강점 | 약점
### ② 학술·표준 (N건)
### ③ 사용자 워크플로우 (N건)
### ④ 실패 사례·교훈 (N건)

## 종합 발견
- 패턴 5건 · 차별점 후보 3건 · 함정 5건 · 적용 표준

## 영향 (Phase 3~6에 미칠 변경)
- BOM 부품 후보 · 4대 원칙 보강 · 헌법 제약
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2.5-4. PO 게이트 (1회)

• ✅ "이 정도 깊이면 OK" → Phase 3 진입
• 🔁 "트랙 N번 더 깊이" → 2.5-2 해당 트랙만 재실행
• ❌ "방향 잘못됨" → Phase 2 회귀

⛔ PO 게이트 통과 없이 Phase 3 진입 금지.

2.5-5. 규모별 강도

2.5-6. 자기검증 금지 적용

L 규모는 트랙별 Subagent에 제조 의도 비전달 + 종합은 별도 Verification Subagent.

2.5-7. 산출물

_design/phase_2.5_research_{YYYY-MM-DD}.md 작업 폴더 영구 보존. Phase 9 회귀 시 재활용.

2.5-8. 외부 도메인 리서치 ≠ Phase 3 부품 발굴

Phase 2.5 = 멀리·넓게 (도메인·솔루션·논문) / Phase 3 = 가까이·구체적 (Phase 블록·체크리스트·프롬프트). 같은 도구 다른 시야.

Phase 3. 발굴 — 공개 저장소·OSS·사내 자산 (전방위)

이미 잘 만들어진 것을 찾는다. 시간은 PO만이 만들 수 있는 부분에 쓴다. (출처: SUNNY AI MAGIC 50 #38 도구 발굴 / find-skills-기본)

발굴 출처 카탈로그 (V3.2 — 사내 자산 추가)

후보 0개 → Phase 4의 5대 KPI 채점·분해를 건너뛰고, BOM을 "전부 자체 작성"으로 확정한 뒤 Phase 6 진행.

Phase 4. 분해·검증 — "정밀 선별" ★공장의 심장

발굴물을 통째로 신뢰하지 않는다. 작업대에 올려 부품 단위로 검증하고, 결함은 걸러낸 뒤 검증된 부품만 선별한다.

4-1. 입고 검사 — 후보별 5대 KPI 채점

5개 중 4개 미만 → 후보 폐기 또는 fork. "운용 충돌 0건"은 어떤 경우에도 타협 불가.

4-2. 부품 단위 분해

후보를 통째로 채택하지 않는다. Phase 블록·프롬프트·체크리스트·설정 단위로 쪼개 각각을 분류한다.

4-3. 안전성 진단 (주작 방식) → 걸러내기

발굴물을 위험도·안전성 관점에서 감사 (주작-sal-da 방식). 다음은 발견 즉시 제거:

• eval()·exec()·검증 없는 shell 직접 실행
• 하드코딩된 시크릿·API 키·절대경로
• 사용자 보안 가드 위반 (예: 사용자가 지정한 보호 폴더 — 클라우드 드라이브·비밀번호 보관소 등 — 무단 접근, .env 노출 등)
• deprecated 라이브러리·API 의존
• 영어 강제 출력 등 한국어 운용 규칙 위반
• 1년 이상 미유지보수 코드

4-4. BOM 산출 — 5분류 (V3.2 보강) ★

📦 BOM — Bill of Materials (선별 부품 목록)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[🟢 정상 — 그대로 적용]
  • {부품명} ← {출처}:{경로} | 용도: ___

[🟡 재단 후 적용]
  • {부품명} ← {출처} | 재단 내용: ___

[🔴 걸러냄 — 적용 거부]
  • {부품명} ← {출처} | 사유: {보안위반/deprecated/충돌}

[🏭 자체 작성 필요]
  • {부품명} | 사유: 발굴물에 검증된 대체재 없음

[🔵 공통 인프라 — 배치 스킬이 공유] ★V3.2 신설
  • {부품명} | 적용 범위: {몇 개 스킬} | 횡단 관심사: {공통 프롬프트·검증 절차·산출물 양식}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔵 공통 인프라 부품의 예 (배치 모드 시):

• 공통 입력 검증 프롬프트
• 표준 산출물 양식 (예: HTML 보고서 구조)
• 공통 검증 체크리스트
• 카테고리 공통 사용 예시

배치 모드는 🔵가 반드시 채워진다. 단일 모드에서는 🔵 불가.

4-5. 이중 분류 규칙 (V3.2 신설 — 🔵 ∩ 🏭 교집합 처리)

한 부품이 여러 분류에 동시 해당할 수 있다. 다음 우선순위 규칙으로 단일 레이블 부여:

🟢/🟡  >  🔵  >  🏭  >  🔴

판정 절차:

1. 출처 우선 — 발굴물에서 가져온 것이면 🟢/🟡
2. 범위 우선 — 자체 작성이지만 N 스킬이 공유한다면 🔵 (배치 모드만)
3. 신규 작성 단독 사용 — 🏭
4. 결함 — 🔴 (다른 분류와 동시 적용 불가)

BOM 작성자는 한 부품을 두 분류에 동시 기입하지 않는다 — 단일 레이블만.

Phase 5. 설계 검증 — 자기완결 절차 (V3.4)

★ 자기완결 원칙 정의 (V3.5 R9 — 두 공장 동기화)

자기완결(Self-contained)이란: 본 스킬이 작동하는 동안 다음 3가지를 모두 만족하는 상태.

1. 외부 스킬 호출 금지 — /pro-persona-debate·/주작-sal-da·/review-evaluate 등 다른 user-invocable 스킬을 의무로 호출하지 않는다. 핵심 절차는 본문에 직접 내장.
2. 외부 AI(가족 외 LLM) 호출 금지 — codex CLI(GPT)·Gemini API·Grok 등 Claude 외 LLM을 의무 흐름에 두지 않는다. (단 Phase 7 외부 LLM 교차 검증은 선택적 외부 게이트로 제한, 미실시 폴백 명시)
3. 내장 Subagent로 검증 — 검증·평가는 Agent(subagent_type=..., model="sonnet") Cross Validator Subagent를 본 스킬이 직접 띄워 수행. 외부 스킬에 위임하지 않는다.

이 정의는 형제 공장 /llm-dependent-agent-create와 한 글자 변경 없이 동일 적용된다.

⚠️ V3.4 변경: V3.3까지 /pro-persona-debate + /주작-sal-da 외부 호출 의무였으나, 자기완결 원칙 적용으로 두 스킬의 핵심 절차를 본문에 내장. 외부 스킬·외부 AI(codex CLI 등) 호출 금지.

Phase 5 = 5A 검토·평가 + 5B 진단·해체. S 규모는 5A만, M·L은 둘 다.

규모 정량 판정 기준 (V3.2 명시 유지)

경계선 처리: 두 규모에 걸치면 높은 쪽. 배치 모드는 자동 L.

📋 Phase 5A. 검토·평가 (review-evaluate 핵심 내장)

5A-1. 평가 대상

Phase 1~4 산출물 — 📐 plan.md · 🗺️ 아키텍처 SVG · 📦 bom.md · (배치) 카탈로그

5A-2. 5기준 루브릭 (각 20점 = 100점)

5A-3. Round 루프 (최대 10회)

1. Cross Validator Subagent 호출 — Agent(subagent_type="general-purpose", model="sonnet", mode="auto")
2. 산출물 + 루브릭 + 사양 대조 지침 전달 (제조 의도 비공개)
3. 점수 + 개선 권고 반환
4. 100점 미달 시 권고 반영 → Round +1
5. 매 Round 별도 Cross Validator (자기검증 금지)
6. 100점 도달 또는 한도 도달 시 종료

5A-4. 사양-구현 대조

• Phase 1 기획안 KPI 누락 0
• Phase 2 MBO 측정 지표 누락 0
• 글로벌 헌법 (~/.claude/CLAUDE.md) 위반 0
• 스킬 4대 원칙 (단일 책임·자기완결·간결·구조 완비) 위반 0

🔬 Phase 5B. 진단·해체 (SAL Grid 핵심 절차 내장) ★V3.4 신설

review-evaluate(점수 매기기)와 다른 가치 — SKILL.md 부품을 단위로 해체하고 의존성·결함 지점을 카드별 진단. M 규모 이상 적용.

5B-1. 역방향 분해 — Grid 완성 (5단계)

[1] 구성요소 목록 파악     — BOM 부품 + SKILL.md Phase 블록 단위
[2] 진단 Area 확정          — 4~9개 선택 (구조·자기완결·간결·헌법·실행·문서·재사용 등)
[3] 구성요소 × Area 매트릭스 — 관련성 ≥ 0.6 셀만 유효 진단 단위
[4] 의존성 분석             — Stage 번호 (1, 2, 3...) + Stage 명칭
[5] SAL ID 확정             — S{stage}{AREA}{level} (예: S1SC1 = Stage1·자기완결·Level1)

5B-2. Stage별 카드 처리 (의존성 순)

각 카드 = 진단 → 개선안 → 개선 → 재진단 (한 카드에서 완결)

5B-3. Stage Gate (다음 Stage 진입 조건)

• 현재 Stage 모든 카드 Final Verdict 확정
• Fail 카드 0
• 다음 Stage 의존성 충족

5B-4. 자가 수렴 재진단 루프

Re-status가 Danger·Warning(미허용)이면 같은 카드에서 재개선 → 재진단 반복. Pass 수렴까지.

Phase 5 규모별 강도

Phase 5 외부 의존 명시적 배제 (V3.4)

❌ codex CLI 등 외부 AI 호출 (GPT/Gemini/Grok/Perplexity) ❌ /pro-persona-debate 호출 ❌ /주작-sal-da 호출 ✅ Claude Code 내장 Agent 도구만 사용

Phase 5 결과 → Phase 6 진입

진입 게이트 — 모두 통과해야 Phase 6 시작:

• 5A 100점 + 5B Stage Gate 통과
• 📐 스킬 기획안 모든 필수 항목 채워짐
• 📡 출력 대상 시스템 명세 확인 (V3.5 신설) — 외부 시스템(웹사이트·파일·DB·메신저·콘솔 등 — 스킬 결과가 PO 화면 밖으로 나가는 모든 경로)에 결과를 출력하는 스킬이면 명세 비어 있는지 점검. 비어 있으면 Phase 1로 회귀해 1~3 라운드 추가 질문으로 채운 뒤 재진입. 외부 출력 없는 순수 스킬(컨텍스트 안에서만 동작하는 절차·INSTRUCTION 등)은 면제
• 🤖 큐레이션·필터링형 선정 알고리즘 — 후보 다건 중 선택하는 스킬이면 알고리즘 명시 확인. 디폴트 "첫 후보"는 무작위 선택과 동일하므로 금지
• 한도 도달 시 → PO에게 점수·잔여 이슈 보고 → 진입 여부 결정

★V3.5 R9 — 게이트 재진입 한도 + 통과 판정 권자:

• 재진입 한도: Phase 1 회귀 → 추가 질문으로 명세 보강 → 게이트 재시도. 최대 3회 재진입. 3회 후에도 게이트 미통과 시 Phase 0 모드 재선언 (스킬 자체 재정의 필요).
• 통과 판정 권자: 게이트 4개 항목은 별도 Verification Subagent가 판정 (Agent(subagent_type="general-purpose", model="sonnet")로 띄움). 제조 SA가 자기 판정 금지 (자기검증 회귀). Subagent 판정 결과 + 외부 도구 출력(tools/verify_windows_adapter.ps1 등)을 합쳐 통과 여부 결정.
• 판정 결과 기록: Phase 8 출하 보고서의 "QC 결과" 항목에 gate_verification: pass/fail + gate_retries: N + verifier_invocations: M 명시.

검증 질문 예: "이 부품 조합이 KPI를 달성하는가? 거대 스킬이 되지 않는가? 자체 작성으로 대체할 부품은? 자기완결 원칙 위반 없는가? 외부 출력 명세가 채워졌는가?"

Phase 6. 조립·제조 — SKILL.md 작성

확정된 부품(BOM 🟢🟡🔵)과 자체 작성(🏭)을 결합해 ~/.claude/skills/{이름}/SKILL.md를 조립한다.

좋은 스킬 4대 조건 (V1.0부터 유지)

Phase 6 모드별 실행 순서 (V3.2 명시)

단일 모드 (1a):  SKILL.md 1개 작성 → Phase 7
배치 모드 (1b):  🔵 공통 인프라 부품 통합 → SKILL.md × N개 작성 → Phase 7

조립 원칙

• 🟢 정상 부품은 출처를 주석으로 명시하고 그대로 적용
• 🟡 재단 부품은 PO 톤·헌법에 맞춰 수정 후 적용
• 🏭 자체 부품은 신규 작성
• 🔵 공통 인프라는 배치 스킬들이 공유 (별도 참조 자료로 폴더에 동봉)
• 🔴 결함 부품 자리는 자체 작성으로 메운다 — 절대 걸러낸 것을 되살리지 않는다

SKILL.md 출하 형식 (스킬 특화)

---
description: "스킬의 한 줄 설명 + 호출 트리거 키워드 명시"
user-invocable: true
version: "1.0"
last_updated: "YYYY-MM-DD"
---

<!-- SKILL_NAME_SPEC_VERSION: V1.0 -->

# /skill-name — 한 줄 정체성

## 핵심 원칙 또는 철학

## Phase 구조 (또는 절차)
Phase 0 → 1 → 2 → ...

## 금지 사항 (안티 패턴)

## 필요 도구 (Tools Required)

Phase 7. 출하 검사 — QC 4단 (V3.2)

자기검증 금지. 제조에 참여하지 않은 별도 Verification Agent를 투입한다. (출처: SUNNY AI MAGIC 50 #28 / review-evaluate-코어1)

7-0. Verification Agent 소환 메커니즘 (V3.2 신설)

"별도 Verification Agent를 투입한다"는 선언만으로는 V1.0처럼 자기검증으로 회귀할 수 있다. 다음 메커니즘을 강제한다:

소환 절차 (4단계 — 모두 필수):

1. 별도 Agent 도구 호출 — Agent(subagent_type="...", model="sonnet", mode="auto")로 신규 Subagent를 띄운다.
2. 제조 컨텍스트 비전달 — Verification Subagent prompt에는 SKILL.md와 검증 기준만 전달. 제조 과정의 의도·근거·내부 결정 사항은 전달 금지.
3. 외부 검증 도구 사용 의무 — YAML frontmatter 검증·markdown lint·slash 호출 시뮬 등 외부 도구 결과를 함께 보고.
4. 호출 증거 기록 — Phase 8 출하 보고서의 "QC 결과" 항목에 verification_agent_invocations: N 카운트 + 호출 시각·duration 명시.

금지:

• ❌ 제조 Subagent에게 "이제 검증해라"라고 추가 지시
• ❌ 메인 Claude Code(SA)가 직접 검증 의견 작성
• ❌ Subagent 호출은 하지만 prompt에 제조 과정을 다 보여줘서 편향 유도

위반 시 효과: QC 결과 무효 처리, Phase 7 처음부터 재실행.

V3.4 자기완결: 외부 스킬(/review-evaluate·/pro-persona-debate·/주작-sal-da) 위임 금지. Cross Validator Subagent를 본 스킬이 직접 띄운다 (Phase 5-3 참조).

4단 QC

모든 규모에 공통 — 강도는 규모별 차등.

7-1. 정적 분석

• YAML frontmatter 유효성 (필수 필드 존재·문법 OK)
• Markdown 구조 (헤더 계층·표·코드 블록)
• Dead 링크 검사 (외부 URL·참조 파일 경로)
• 시크릿 누출 검사 (정규식 패턴)
• 500줄 초과 여부

7-2. 동적 검증

• 슬래시 호출 시뮬 — /{스킬명} 인식 여부
• 인자 처리 — Phase 0 인자 처리 로직 검증
• 외부 도구 의존 확인 — Skill/Agent/Bash 등 권한 매핑

7-3. 실제 호출 검증 ★"파일 생성 ≠ 동작함" 7번 철칙 실행

• 실제 슬래시 호출 1회 — 가벼운 시나리오로 의도대로 작동하는지
• 산출물 검증 — 기대한 형식·내용으로 출력되는지
• 금지: "파일이 ~/.claude/skills/에 있다"만으로 OK 처리

7-3+. ★ 출력 대상 시스템 실제 화면 확인 (V3.5 신설 — 형제 공장 회고 흡수)

"외부 시스템 출력" 정의 (V3.5 명확화) — 다음 중 하나라도 해당하면 외부 출력:

• 웹사이트·블로그·커뮤니티에 글/이미지/댓글 게시 (예: WAAT 사이트, 노션 페이지)
• 파일 시스템에 사용자가 직접 열어볼 결과 파일 생성 (예: SVG·PDF·PPTX·이미지·HTML 산출물)
• DB·시트에 사용자가 다시 읽을 행 INSERT (예: Supabase, Google Sheets)
• 메신저·이메일·SMS 전송 (예: Slack, 카톡봇, Gmail SMTP)
• CLI 콘솔에 사용자에게 보일 텍스트 출력 (단, 디버그 로그·진행 안내는 제외)

면제 — 다음만 하는 순수 스킬은 해당 없음:

• INSTRUCTION 텍스트를 컨텍스트에 주입만 하고 별도 파일·외부 호출 없는 스킬
• Claude Code 내부 상태(메모리·tasks·plan)만 조작하는 스킬

외부 출력에 해당하는 스킬은 그 시스템의 실제 사용자 화면을 사람 눈으로 확인하기 전까지 Verified 처리 금지.

• 자기 검증 금지의 구체 적용: 슬래시 호출 1회 통과 + 산출물 텍스트 확인만으로는 Verified 불가
• 검증 주체: 메인 SA 또는 제조 Subagent 금지 → PO 직접 또는 별도 Verification Agent
• 검증 화면: 출력 대상 시스템에서 일반 사용자가 보는 그대로의 화면
• 검증 항목 (최소): 텍스트 렌더링(마크다운 raw 노출 없음), 라벨·배지 의미 일치, 클릭 가능 요소 동작, 모바일/데스크톱 양쪽
• 회고 사유: claude-news-agent (형제 공장 사례)에서 자기검증 모두 통과 후에도 PO 브라우저에서 마크다운 raw 노출 + 라벨 오용 결함 발견

7-4. 외부 검증 (V3.2 신설, L 규모만)

• 도메인 전문가 리뷰 (필요 시 PO에 의뢰)
• 공개 저장소 검증 — 발굴한 부품의 라이선스·최신성 재확인
• 외부 표준 적합성 — 한국어 출력·보안 가드 등 헌법 통과

결함 발견 시

• /5times-debug-loop에 위임하여 박살 후 복귀
• 같은 결함 2라운드 연속 잔존 시 Phase 6로 회귀

출하 판정 (V3.2 — 회귀 깊이 결정 표)

✅ 합격 — review-evaluate 100점 + 사용자 여정 KPI 통과 + 4단 QC 통과 → Phase 8 출하
❌ 불합격 — 결함 잔존 → 회귀 깊이 결정 표 적용

Phase 8. 자산화·출하

만들고 끝이 아니다. 등재까지 해야 출하 완료다.

1. 등재 — ~/.claude/skills/{이름}/ 폴더에 SKILL.md 배치 + 자동 인식 확인
2. 자산 기록 — 스킬 레지스트리·인덱스에 1줄 등재
3. SAL Grid 반영 — SAL_Grid_Dev_Suite 프로젝트면 grid_records JSON 갱신
4. CLAUDE.md 헌법 등재 — ~/.claude/CLAUDE.md에 1줄 (V3.2 강조)
5. 운영 통계 인프라 가동 확인 (V3.2 신설) — Phase 9 회귀 트리거가 작동하려면 다음이 있어야 함:
   • 사용 횟수 추적 (수동 또는 자동)
   • 피드백 수집 경로 (이슈 트래커·README의 연락처 등)
   • 어느 하나라도 없으면 Phase 6 재조립으로 회귀 (본 스킬은 단일/배치 모드만 — 포털 제외. 따라서 형제 공장의 6a 본체 / 6b 플랫폼 / 6c 공통 인프라 3단 분해는 본 스킬에 없고, Phase 6 = 단일 SKILL.md 조립으로 일원화. 3단 분해 흐름이 필요하면 ~/.claude/skills/llm-dependent-agent-create/ SKILL.md 참조)
6. B 인프라 배포 어댑터 점검 (V3.5 신설 — 해당 시에만 적용) — 제조한 스킬이 standalone .py + .bat 형태로 PC 배포되는 경로를 가진다면 (예: 도구함 zip, 바탕화면 바로가기, 작업 스케줄러용 진입점), 형제 공장 /llm-dependent-agent-create SKILL.md의 "인프라 B Windows 어댑터 체크리스트" 7개 룰 + install_shortcut.ps1 사전 검증 모두 적용 (V3.5 R6 6개 룰 + R7 install_shortcut.ps1 자동 생성 + R8 .bat 한글 사전 검증). 순수 SKILL.md만으로 동작하는 스킬(Claude Code 컨텍스트 내부 전용 — 대다수의 경우)은 이 단계 면제:
   • .bat 한글 echo·주석 금지 (cmd cp949 디코딩 사고 회피)
   • 한글 경로 하드코딩 금지 → pushd "%~dp0"
   • timeout 대신 ping -n N 127.0.0.1 > nul
   • set PYTHONIOENCODING=utf-8 + set PYTHONUTF8=1 강제
   • chcp 65001 > nul (콘솔 표시용)
   • Python 스크립트는 sys.stdout.reconfigure(encoding="utf-8", errors="replace") 첫 줄
   • 검증: cmd /c "your.bat"을 cmd 환경에서 직접 실행 (PowerShell 통과로 cmd 통과를 보장 못 함)
   • 순수 SKILL.md만으로 동작하는 스킬은 면제 (Claude Code 컨텍스트에서만 동작)
7. 출하 보고서

🏭 스킬 출하 완료 — {스킬명/카탈로그명}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
제조 모드   : {단일/배치}
등재 위치   : ~/.claude/skills/{이름}/SKILL.md
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
BOM 요약    : 🟢적용 N · 🟡재단 N · 🔴걸러냄 N · 🏭자체작성 N · 🔵공통인프라 N
발굴 출처   : {목록 — 사내 자산 포함}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
QC 결과     : {S/M/L} — review-evaluate XX/100점
정적/동적/실호출/외부검증 : 통과/실패
사용자 여정 : {KPI} — 통과/실패
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
MBO 달성    : 목표 대비 달성/미달성
헌법 등재   : ~/.claude/CLAUDE.md 기록 완료
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
호출 방법   : /{스킬명} [인자]
운영 루프 가동 시점 : {Phase 9 진입 일자}

Phase 9. 운영·개선 — 피드백 루프 (V3.2 신설) ★

출하는 끝이 아니라 운영의 시작이다. Phase 9는 자율 루프 — 일상 운영 중 수집된 데이터가 다음 사이클의 Phase 1로 회귀한다.

9-1. 운영 모니터링

• 사용 횟수 — 스킬이 실제로 호출되는 빈도 (수동 기록 또는 슬래시 호출 로그)
• 이상 신호 — 호출 0회 / 같은 오류 반복 / 응답 시간 급증
• 사용자 여정 KPI — Phase 2에서 정의한 지표를 일상적으로 추적

9-2. 피드백 수집

• 이슈 트래커 — GitHub Issues 또는 README의 연락처
• 자동 수집 — 실패 패턴 로그
• PO 인터뷰 — 분기·반기 단위 정성 피드백

9-3. 개선 사이클 → Phase 1 회귀

피드백이 일정 수준 누적되면 다음 사이클을 트리거. 다음 정량 임계값 중 하나라도 충족 시:

자동 트리거 조건 (OR)

• 사용률 0 — 출하 후 30일간 호출 0회 (폐기/통합 검토)
• 반복 실패 — 같은 오류 ≥ 3회 (직전 7일)
• 피드백 누적 — "버그·개선요청" ≥ 3건 (직전 14일)
• PO 정기 점검 — 매월 1일 운영 KPI 리뷰 (강제)

트리거 발동 후 회귀 깊이 매핑:

9-4. 점진적 배포 (Canary)

L 규모 스킬은 다음 사이클 산출물을 한꺼번에 풀지 않는다:

• Canary — PO 본인이 1주 선행 사용 → 안정 확인
• Rollout — 팀 또는 공개 배포
• Rollback — 문제 발견 시 즉시 되돌릴 수 있는 경로 (이전 버전 폴더 백업)

운영 루프 종료 조건

스킬 폐기·교체·통합 시점까지 무한 루프. 폐기 시:

• CLAUDE.md 등재 갱신 ("폐기" 또는 "후속 스킬로 이관")
• 사용 로그 아카이브

/llm-dependent-agent-create와의 관계 (V3.2 — 양방향 명시, V3.5 후속 — 경계 표 강화)

/llm-dependent-agent-create는 형제 공장이다. 같은 9-Phase 방식·같은 분해·검증 후 조립 철학을 공유한다.

★ 두 공장 경계 — 어느 쪽으로 가야 하나? (V3.5 후속 신설)

어느 쪽으로 갈지 결정 (5초 가이드)

산출물이 "Claude Code 컨텍스트 안에서 절차·체크리스트·INSTRUCTION으로 동작"하는가?
├─ YES → /skill-create (이 공장)
│         ├─ 단일 스킬 1개 → Phase 1a 단일 모드
│         └─ N개 스킬 묶음 → Phase 1b 배치 모드
│         예: /code-review-기본, /diagram-기본, /review-evaluate-코어1
│
└─ NO → 외부 사용자가 직접 호출하는 서비스가 필요한가? → /llm-dependent-agent-create (형제 공장)
        ├─ 외부 호출자 1유형·1 호스팅 → 단일 모드 (1a)
        ├─ N개 묶음·각자 호스팅 → 배치 모드 (1b)
        └─ 1 호스팅 = N 에이전트 + 공통 인증·관리 → 포털 모드 (1c, 인프라 A 필수) ★V3.5 R9 명시
        예: 대규모 사내 에이전트 포털(N≥50, 포털 모드), 뉴스 요약 에이전트(단일 B), 카톡봇·Slack봇(단일 A)

양방향 변환 가능 — 같은 도메인 지식을 두 형태로 포장 가능:

• 스킬 → 에이전트: SKILL.md의 INSTRUCTION을 에이전트의 system_prompt로 재포장
• 에이전트 → 스킬: 에이전트 system_prompt를 SKILL.md로 추출 (개인 사용으로 축소)

대규모 사례: N개 도메인 스킬(스킬스/*/SKILL.md)이 동시에 N개 LLM 에이전트의 system_prompt로도 사용됨. 같은 자산 두 포장. (사내 에이전트 포털 운용 사례에서 확인)

역할 분담 한 줄:

• /skill-create = 도메인 지식의 마크다운화 (한 절차·체크리스트·INSTRUCTION을 SKILL.md로)
• /llm-dependent-agent-create = 그 마크다운을 LLM이 실행하는 에이전트로 패키징 (엔진 + UI/CLI + 인프라)

금지 사항 (안티 패턴 V3.2 — 10개)

❌ 절대 하지 말 것:

1. 통째 채택 — 발굴물을 분해 없이 그대로 가져다 쓰지 않는다 (Phase 4 필수).
2. 결함 적용 — 🔴 판정 부품을 "기능이 좋으니까"로 되살리지 않는다.
3. 운용 충돌 묵인 — 헌법 위반 부품을 글로벌에 들이지 않는다 (타협 불가).
4. 10라운드 + α 문답 생략 — "요청이 명확하다"는 자가 판단으로 Phase 1을 건너뛰지 않는다.
5. MBO 게이트 무시 — PO 승인 없이 제조 시작 금지.
6. 자기검증 — 제조자가 자기 스킬을 QC하지 않는다.
7. "파일 생성" 합격 처리 — ~/.claude/skills/에 파일이 있다는 것만으로 출하하지 않는다. 실제 호출로 검증.
8. 거대 스킬 + 외부 참조 의존 — 단일 책임 위반·자기완결 위반 금지. 500줄 권장 초과 시 분할 검토.
9. 모드 무선언 (V3.2) — 단일/배치 모드를 명시하지 않고 진행하지 않는다.
10. 운영 루프 단절 (V3.2) — Phase 9 진입 없이 "출하 완료"로 종결하지 않는다.

실행 체크리스트 (V3.2)

[ ] Phase 0  제조 대상 + 모드(단일/배치) 수령
[ ] Phase 1  모드별 10라운드 + α 문답 (1a/1b) → 기획안 + 아키텍처 SVG (+ 배치는 카탈로그)
[ ] Phase 2  MBO 목표서 → PO 승인 ⛔
[ ] Phase 3  발굴 후보 수집 (사내 자산 포함)
[ ] Phase 4  분해 → 5대 KPI → 부품 분류 → BOM 5분류 산출 (🔵 공통 인프라 포함)
[ ] Phase 5  설계 검증 (규모별 페르소나 토론 — 배치는 L 강제)
[ ] Phase 6  조립 → SKILL.md 작성 (검증 부품 + 자체 작성)
[ ] Phase 7  QC 4단 (정적·동적·실호출·외부검증) → 별도 Verification Agent
[ ] Phase 8  등재 + CLAUDE.md 기록 + 운영 통계 인프라 확인 + 출하 보고서
[ ] Phase 9  운영 루프 가동 (모니터링·피드백·회귀 트리거)

필요 도구 (Tools Required)

• AskUserQuestion (10라운드 + α 문답·승인)
• Read, Glob, Grep (발굴물 분해)
• WebSearch, WebFetch (전방위 발굴)
• Bash (npx skills find, OSS 검증)
• Write, Edit (조립·등재)
• Agent (Verification Agent·페르소나 토론 투입)
• Skill (/diagram-기본 아키텍처 SVG 생성만 위임. 검토·평가·진단·해체는 V3.4 자기완결 원칙으로 본 스킬이 직접 Cross Validator Subagent 호출)

동원 방법론 출처

• 10라운드 + α 문답법 (옛 명칭 "스무고개" — SUNNY AI MAGIC 50 #01 출처)
• 전문가 페르소나 토론 — #02 / pro-persona-debate-코어6
• MBO 목표 관리 — #12 / mbo-천상
• 발굴→검증→자산화 — #38 / find-skills-기본
• 자산화 4단계 사다리 — #18·#22
• QC 4종 출하검사 — #28 / review-evaluate-코어1 · pro-persona-debate-코어6 · 주작-sal-da · 5times-debug-loop
• 스킬 구조 4요소 — Claude Code 스킬 표준 구조 (YAML frontmatter·Phase·사용 예시·금지사항)
• 형제 공장 양방향 — /llm-dependent-agent-create V3.2 (2026-05-27 공통 영역 동기화)

이 스킬은 스킬 제조 공장이다. 발굴하고, 분해하고, 걸러내고, 적용하고, 검사하여 — 완성된 SKILL.md를 출하한다. 그리고 운영 루프로 다음 사이클을 시작한다.