📝 한줄 요약
법 률·세무 워크스페이스를 만들다가 스킬 충돌 사건이 터졌고, 그 원인을 파고들다 결국 스킬과 워크스페이스 전체를 '분석→방법론→개선'의 순환 지식 체계로 재설계하게 됐습니다.
🎯 이런 분들께 도움돼요
워크스페이스를 여러 개 운영 중인데 스킬 관리가 어수선한 분
있는 스킬인데 몰라서 못 쓰고, 없는 스킬을 매번 처음부터 만드는 분
좋은 스킬을 발견해도 "내 워크스페이스에 어떻게 적용하지?"가 막히는 분
스킬·워크스페이스 설계 원칙을 체계적으로 쌓아두고 싶은 분
😫 문제 상황 (Before)
2주차 목표는 간단했습니다.
"법률 업무 전용 워크스페이스(LEGAL)와 세무 관리 워크스페이스(TAX)를 새로 만들자."
그런데 만들기 시작하자마자 두 가지 문제가 연달아 터졌습니다.
문제 1 — 스터디장이 workspace-standards v2를 추가로 공유해줬다
1주차에 gpters-cc-main을 공유받았고, 이번엔 workspace-standards v2가 새로 추가됐습니다. 앞서 받은 것과 함께 보니 워크스페이스 설계 철학 자체가 담긴 레퍼런스였습니다. 그냥 넘어가면 아까웠습니다.
문제 2 — 워크스페이스가 늘수록 스킬이 엉켜간다
최근 작업을 리뷰하다가 이런 메시지를 발견했습니다.
script-writer conflict: same skill found in .claude/skills and .gemini/skills
충돌이었습니다. 조사해보니 외부에서 설치한 스킬이 두 곳에 동시에 복사되어 있었습니다. 그리고 더 큰 문제를 발견했습니다 — 본업 워크스페이스에 22개 이상의 스킬이 있는데, 저도 그 목록과 기능을 정확히 몰랐습니다.
"만들고 넘어가면, 나중엔 뭐가 있는지도 모른다."
이 한 문장이 이번 주 작업의 방향을 완전히 바꿨습니다.
🛠️ 사용한 도구
도구: Claude Code
모델: Claude Sonnet 4.6
리서치: kkirikkiri (글로벌 설치 완료 — 전체 워크스페이스 사용 가능)
설계 방법론: automation-pipeline-design 풀 모드
🔧 작업 과정
1단계: 앞서 공유받은 것과 새로 공유받은 레퍼런스, 다시 같이 해부하다
gpters-cc-main(1주차 공유)과 workspace-standards v2(이번 주 추가 공유)를 나란히 놓고 함께 분석했습니다. 같이 보니 두 레퍼런스가 서로 다른 철학으로 설계되어 있어, 비교하면서 읽을수록 의미가 있었습니다.
workspace-standards v2 — 구조와 표준의 관점
핵심 발견 1 — 하네스 7-layer 구조
워크스페이스는 단순한 폴더 모음이 아니라 7개 층위로 구성된 통제 환경이라는 개념이었습니다.
┌─────────────────────────────────────────────────────┐
│ 워크스페이스 = 7-Layer 하네스 │
├─────────────────────────────────────────────────────┤
│ Layer 1 │ Instruction Surface │ CLAUDE.md │
│ │ │ 정체성·규칙 선언 │
├─────────────────────────────────────────────────────┤
│ Layer 2 │ Commands │ .claude/commands/ │
│ │ │ 호출 가능한 능력 │
├─────────────────────────────────────────────────────┤
│ Layer 3 │ Agents │ .claude/agents/ │
│ │ │ 역할 카드 │
├─────────────────────────────────────────────────────┤
│ Layer 4 │ Skills │ .claude/skills/ │
│ │ │ 트리거 기반 복합 기능 │
├─────────────────────────────────────────────────────┤
│ Layer 5 │ Hooks │ .claude/hooks/ │
│ │ │ 차단·유도 자동화 │
├─────────────────────────────────────────────────────┤
│ Layer 6 │ State │ _meta/, logs │
│ │ │ 작업 상태 추적 │
├─────────────────────────────────────────────────────┤
│ Layer 7 │ Memory │ memory/ │
│ │ │ 전문 지식 저장 │
└─────────────────────────────────────────────────────┘
※ 1주차까지는 Layer 1~2에만 집중했다
핵심 발견 2 — 하네스 강도 4단계
강도
특징
적합한 경우
basic
단일 에이전트 + 커맨드만
가벼운 단일 목적
runtime-ready
멀티 에이전트 team contract
협업이 필요한 작업
runtime-enforced
차단/유도 hooks 작동
안전이 중요한 작업
meta-harness
다른 워크스페이스를 만드는 WS
생성기·표준 관리
기존에 만든 워크스페이스들은 CLAUDE.md에 규칙만 선언한 "선언형"이었습니다. runtime-enforced는 hooks까지 작동해서 AI가 규칙을 어기려 하면 실제로 차단됩니다.
핵심 발견 3 — CLAUDE.md 12섹션 스키마
좋은 CLAUDE.md는 12개 섹션을 갖춘다는 표준이었습니다. 정체성(허용/금지), 핵심 원칙, 폴더 구조, 워크플로우, 커맨드 목록, Scale Modes(Lite 5분/Standard 30분/Full 1시간+), 트리거 경계 등. 이전에 만든 워크스페이스들은 이 중 일부가 빠져 있었습니다.
gpters-cc-main — 속도와 실용성의 관점
workspace-standards v2가 "구조를 어떻게 짤 것인가"에 집중한다면, gpters-cc-main은 "현장에서 빠르게 작동하게 만드는 법"에 집중했습니다.
One WS One Agent — 워크스페이스마다 전담 에이전트를 두고, 해당 도메인의 언어와 워크플로를 처음부터 이해하도록 설계
Pushy description 원칙 — 커맨드에 "언제 써야 하는가"와 "언제 쓰면 안 되는가" 두 가지를 모두 명시
User Profile 내장 — 사용자 배경·역할·선호 방식을 CLAUDE.md 고정 섹션에 유지
2단계: 두 레퍼런스 흡수 → LEGAL · TAX 생성
분석이 끝나고 두 워크스페이스를 만들었습니다.
┌─────────────────┐ ┌──────────────────┐ ┌────────────────┐
│ workspace- │ │ gpters-cc-main │ │ 본업 WS │
│ standards v2 │ │ (실용 설계) │ │ (운영 경험) │
│ │ │ │ │ │
│ • 7-layer 하네스 │ │ • One WS One │ │ • 4대 계약 │
│ • 강도 4단계 │ │ Agent │ │ • Tier 메모리 │
│ • 12섹션 스키마 │ │ • Pushy desc. │ │ • 세션 프로토콜 │
│ • Scale Modes │ │ • User Profile │ │ │
└────────┬────────┘ └────────┬─────────┘ └───────┬────────┘
│ │ │
└────────────────────┼──────────────────────┘
▼
┌───────────────────────────────────┐
│ AI-WORKSPACE-LEGAL / TAX 생성 │
│ (세 레퍼런스 강점 전부 통합) │
└───────────────────────────────────┘
AI-WORKSPACE-LEGAL (법률 전문)
법률 업무의 특성상 AI가 "알아서 작성"하면 안 됩니다. 계약서 조항 하나가 실제 법적 효력을 가지기 때문입니다.
runtime-enforced 강도 — "법적 조언 금지", "계약서 자동 완성 금지" hooks 차단
에이전트 아키타입: Research Agent(판례·법령 조사) + Writer Agent(계약서 초안)
4대 계약 + ASK 3단 룰
AI-WORKSPACE-TAX (세무 관리)
Scale Modes — Lite(빠른 세금 계산) / Standard(신고 준비) / Full(결산·기한후신고)
memory 파일 4개: entity_profile, tax_CORE(가산세), tax_calendar(월별 신고), policy_DB(절세)
커맨드 10개: /status-check, /urgent-fix, /vat-prep, /withholding, /corp-tax 등
항목
기존 WS
LEGAL / TAX
CLAUDE.md 설계
규칙 누적
12섹션 처음부터
하네스 강도
선언형
runtime-enforced / basic
AI 정체성
범용 어시스턴트
도메인 전문가로 선언
도메인 메모리
없거나 분산
구조화된 4개 파일
커맨드 설명
기능 나열
Pushy (트리거+경계+예시)
3단계: 스킬 충돌 사건 → 더 큰 문제를 발견하다
워크스페이스를 만들던 중 script-writer 충돌 메시지를 발견했습니다.
C:\Users\cskim\.claude\skills\script-writer\ ← 글로벌 스킬
C:\Users\cskim\.gemini\skills\script-writer\ ← 이게 왜 여기에?
내용을 비교해보니 두 파일이 완전히 동일했습니다. 해결은 간단했지만 이 사건이 더 큰 문제를 드러냈습니다.
"본업 워크스페이스에 스킬이 22개 이상 있는데, 내가 그 목록과 기능을 정확히 알고 있는가?"
4단계: 스킬 Tier 체계 + 네이밍 룰
전체 스킬 현황을 파악하고 체계를 잡았습니다.
┌──────────────────────────────────────────────────────────┐
│ 스킬 Tier 체계 │
├──────────────────────────────────────────────────────────┤
│ Tier 1 │ C:\Users\cskim\.claude\skills\ │
│ 글로벌 │ find-skills, script-writer, workspace-builder │
│ │ → 모든 워크스페이스에서 사용 가능 │
├──────────────────────────────────────────────────────────┤
│ Tier 2 │ F:\AI-WORKSPACE-1w-...\skills\ │
│ 본업 │ automation-pipeline, deep-research, kkirikkiri │
│ │ → 본업 워크스페이스에서만 사용 가능 │
├──────────────────────────────────────────────────────────┤
│ Tier 3 │ F:\AI-WORKSPACE-{이름}\.claude\skills\ │
│ WS전용 │ 해당 WS 특화 스킬 │
│ │ → 해당 워크스페이스에서만 사용 가능 │
└──────────────────────────────────────────────────────────┘
충돌 방지 네이밍 룰:
접두사
의미
예시
ext-
외부 마켓에서 설치한 스킬
ext-script-writer
ws-
특정 WS 전용 스킬
ws-tax-check
(없음)
직접 만든 본업 스킬
automation-pipeline-design
5단계: Skill Lifecycle System — 설계 + 구현
네이밍 룰을 만들다 보니 더 근본적인 문제가 보였습니다.
문제
현재 상태
있는 스킬인데 몰라서 못 씀
카탈로그 없음
어설프게 만든 스킬 방치
품질 점검 루틴 없음
업데이트 vs 새로 만들기 판단 못 함
기준 없음
스킬 조합 가능성 모름
시너지 기록 없음
중복·오래된 스킬 누적
정리 루틴 없음
이 5가지를 한 번에 해결하는 시스템을 설계하고 바로 구현했습니다.
새 작업 시작
│
▼
┌────────────────┐
│ /suggest-skills │ ← 로컬 카탈로그 탐색
└────────┬───────┘
있음 ↙ ↘ 없거나 품질 낮음
│ │
│ ▼
│ ┌───────────────┐
│ │ find-skills │ ← 외부 마켓 탐색
│ └───────┬───────┘
│ 있음 ↙ ↘ 없음
│ │ │
│ ▼ ▼
│ 레퍼런스 ┌────────────┐
│ 분석 │skill-creator│ ← Step 0: 레퍼런스 필수
│ └───────►│(Zero 출발 │
│ │ 완전 금지) │
│ └────────────┘
▼
스킬 실행 / 업그레이드
구현된 3종 커맨드:
/suggest-skills — 작업별 로컬 스킬 추천 + 시너지 조합 제안
/skill-audit — 주간 스킬 헬스체크 (미사용·중복·노후화 탐지)
/skill-upgrade — 기존 스킬 약점 분석 후 체계적 개선
그리고 기존 skill-creator에 Step 0을 추가했습니다.
Step 0: 레퍼런스 탐색 ( 항상 먼저)
1. 로컬 카탈로그 확인 → 겹치면 /skill-upgrade 권장
2. 워크스페이스 스킬 폴더 스캔
3. find-skills 외부 마켓 탐색
→ 모두 없을 때만 Step 1 (신규 제작) 진행
6단계: workspace-builder v4 — 이 모든 것을 처음부터 내장한다
"새 워크스페이스를 만드는 스킬에, 이 모든 게 처음부터 들어있어야 하지 않나?"
항목
v2
v4
도메인 조사
없음
kkirikkiri 멀티에이전트 자동 조사
하네스 강도
없음
4단계 추천 후 선택
스킬 추천
없음
SKILLS-CATALOG 스캔 자동 추천
임의
12섹션 스키마 완전 적용
Lifecycle
없음
suggest/audit/upgrade 3종 자동 포함
검토
없음
2회 게이트 (조사 후 + 파일 생성 직전)
kkirikkiri가 특정 워크스페이스에만 설치되어 있어서 --scope user로 글로벌 재설치했습니다. 이제 어떤 도메인 워크스페이스를 만들든 kkirikkiri 조사가 기본으로 들어갑니다.
7단계: 스킬 설계 방법론 — 분석한 스킬에서 원칙을 도출하다
여기까지 했을 때 하나의 의문이 생겼습니다.
"스터디장이 만든 스킬들이 왜 그렇게 잘 작동하는 건지 — 구조적으로 해부해본 적이 있나?"
kkirikkiri, vibe-sunsang, show-me-the-prd, insane-search, skillers-suda — 5개 스킬을 전부 열어서 메커니즘 단위로 해부했습니다.
kkirikkiri 해부 — 8개 메커니즘 중 핵심 3개
① 3-File 외부 상태 관리
Claude의 기억력을 믿지 않는 설계 철학이었습니다.
┌─────────────────────────────────────────────────────┐
│ 파이프라인 진행 중 상태 저장 │
├─────────────────────────────────────────────────────┤
│ TEAM_PLAN.md │ 팀 구성·전략 결정 │
│ │ → "누가 무엇을" 한 번만 기록, │
│ │ 이후 단계에서 Read │
├─────────────────────────────────────────────────────┤
│ TEAM_PROGRESS.md │ 에이전트 진행상황 (실시간 갱신) │
│ │ → 조율 효율 │
├─────────────────────────────────────────────────────┤
│ TEAM_FINDINGS.md │ 조사 결과 누적 │
│ │ → 최종 보고서 작성 시 참조 │
└─────────────────────────────────────────────────────┘
설계 철학: "클로드의 기억력을 믿지 마.
중요한 결정은 반드시 파일에 기록."
② Continuation Contract (연속 실행 계약)
AskUserQuestion 답변 받은 후 Claude가 "확인했어요~" 하고 멈추는 패턴을 막는 장치. "바로 다음 도구 호출 필수"를 명시 선언.
③ Leader = Opus 필수 하드룰
7개 팀원 원형 중 Leader만 Opus 강제. 품질 보장 최후 보루.
vibe-sunsang(바선생) 해부 — AI 활용 역량 측정 시스템
바선생의 핵심은 6개 기술 축 × 7레벨 × 0.5단위로 AI 활용 역량을 측정하는 구조였습니다.
6대 기술 차원:
코드
차원
한 줄 정의
DECOMP
작업 분해
복잡한 요청을 AI 처리 가능 단위로 나누는 능력
VERIFY
검증 전략
AI 출력물을 비판적으로 검토하는 능력
ORCH
오케스트레이션
도구·에이전트·워크플로우 조합 능력
FAIL
실패 대응
오류·한계·예상치 못한 결과 대처 능력
CTX
맥락 관리
배경·제약·목표를 AI에게 제공하는 능력
META
메타인지
자신의 AI 활용 패턴을 인식하고 조정하는 능력
바선생은 사용자의 AI 활용 유형을 4가지(Builder·Explorer·Designer·Operator)로 분류합니다. 이 유형은 Claude 워크스페이스와는 다른 개념으로, "내가 AI를 주로 어떻게 쓰는가"에 대한 분류입니다.
AI 활용 유형 분류 (Claude 워크스페이스와 별개 개념)
┌──────────────┬─────────────────────────────────────┐
│ Builder │ 코딩·만드는 작업 중심 → DECOMP+VERIFY 가중 │
│ Explorer │ 리서치·조사 중심 → FAIL+CTX+META 가중 │
│ Designer │ 기획·전략 중심 → CTX+META 가중 │
│ Operator │ 자동화·운영 중심 → ORCH+FAIL 가중 │
└──────────────┴─────────────────────────────────────┘
현재 측정 결과: L4.0 (Operator 유형)
L5 블로커: strategic_ratio 4.0% → 5.0% 목표
스킬 설계 방법론 문서 v1.1 완성
6개 스킬 분석을 통해 15개 설계 원칙(P1~P15)을 도출했습니다.
원칙
내용
출처 스킬
P11
Per-step Lazy Loading — Step별 참조 파일 로드
kkirikkiri
P12
기억 외부화 — 3-File 패턴
kkirikkiri
P13
Continuation Contract — 대화 후 즉시 다음 도구 호출
kkirikkiri
P14
서브에이전 트 위임 — 대용량 분석 컨텍스트 보호
vibe-sunsang
P15
멀티스킬 플러그인 아키텍처 — 책임별 서브스킬 분리
vibe-sunsang
8단계: WS 설계 방법론 — 스킬처럼 워크스페이스도 해부한다
스킬에 방법론 문서가 생기자 자연스럽게 이 질문이 따라왔습니다.
"워크스페이스도 똑같이 해부하면 어떨까? 각 WS의 강점을 정리해두면 새 워크스페이스 설계할 때 참조할 수 있지 않을까?"
4개 대상을 분석했습니다: workspace-standards v2, gpters-cc-main, 본업 워크스페이스, workspace-builder 스킬 자체.
워크스페이스 분석 → 방법론 → 스킬 개선 순환:
┌──────────────────────────────────────────────────────┐
│ 분석 → 방법론 → 개선 순환 │
└──────────────────────────────────────────────────────┘
[스킬 분석] [WS 분석]
skill-analyses/ ws-analyses/
┌─────────────┐ ┌─────────────┐
│ kkirikkiri │ │ ws-standards│
│ vibe-sunsang│ │ gpters-cc │
│ show-me-prd │ │ 본업 WS │
│ insane-srch │ │ ws-builder │
└──────┬──────┘ └──────┬──────┘
│ 원칙 도출 │ 원칙 도출
▼ ▼
13-skill-design- 14-ws-design-
methodology.md methodology.md
(P1~P15 원칙) (W1~W21 원칙)
│ │
└──────────────┬────────────────┘
│ 반영 여부 결정
▼
workspace-builder 스킬
(점진적 개선 반영)
4개 분석 소스별 최고 강점:
소스
가장 강한 카테고리
핵심 한 줄
workspace-standards v2
하네스 설계
7레이어 + 4단계 강도 = 구조의 표준
gpters-cc-main
편리성 + 속도
간결함이 최고의 하네스. 규칙보다 경계
본업 워크스페이스
규칙 신뢰성
사고가 만든 규칙은 이론보다 강하다
workspace-builder
자동화 + 확장성
설계를 자동화하면 품질이 일관해진다
카테고리별 최고 패턴 요약:
자동화 │ workspace-builder: WS 자동생성, 생성 후 검증, Lifecycle 내장
처리속도 │ workspace-standards: Scale Modes + 본업WS: Tier 로딩 분리
편리성 │ workspace-builder: 진입점 자동 판단 + 본업WS: ASK 3단 룰
하네스 │ workspace-standards: 7레이어 + 4단계 강도
지식유지 │ 본업WS: 5대 정본 + 9단계 세션 종료 프로토콜
규칙신뢰 │ 본업WS: 위반 사례 기반 ★★★ 규칙 승격 패턴
확장성 │ workspace-builder: 업그레이드 dry-run + A/B 모드
workspace-builder ↔ WS 방법론 쌍방향 정합
한 방향으로만 비교하면 절반입니다.
방향 A: 방법론 원칙이 스킬에 반영됐는가?
──────────────────────────────────────────
ws-analyses W1~W15 ──────────► workspace-builder
→ W7(학습 WS), W9(User Profile) 등 4개 미반영 발견
방향 B: 스킬의 설계 결정이 방법론에 기록됐는가?
──────────────────────────────────────────
workspace-builder ───────────► ws-analyses
→ kkirikkiri 연동, 동적 생성, 검증 체크리스트 등
6개가 원칙으로 미포착 → W16~W21로 새로 추가
✅ 결과 (After)
이번 주 완료한 것
항목
결과
workspace-standards v2 + gpters-cc-main 분석
7-layer, 12섹션, Pushy, Scale Modes 흡수
AI-WORKSPACE-LEGAL 생성
runtime-enforced, 법률 도메인 특화
AI-WORKSPACE-TAX 생성
12섹션 CLAUDE.md, 커맨드 10개, 메모리 4개
스킬 Tier 체계 + 네이밍 룰
Tier1/2/3, ext-/ws- 접두사
22개 스킬 + 품질점수·추천조합·개선메모
Skill Lifecycle 3종 구현
/suggest-skills + /skill-audit + /skill-upgrade
workspace-builder v4 완성
kkirikkiri 연동, Lifecycle 내장, 검증 체크리스트
kkirikkiri 해부 (8메커니즘)
P11~P13 원칙 도출
vibe-sunsang 해부 (7메커니즘)
6축×7레벨 완전 이해, P14~P15 도출
스킬 설계 방법론 v1.1
P1~P15 전체 원칙 + 레시피
WS 분석 4개
workspace-standards, gpters-cc-main, 본업, workspace-builder
WS 설계 방법론 v1.2
W1~W21 원칙 + 7카테고리 강점 매트릭스
쌍방향 정합
workspace-builder ↔ WS 방법론 완전 정합
Before vs After
항목
Before
After
스킬 설계
감 의존, Zero 출발
P1~P15 원칙 기반 설계
WS 설계
매번 새로 고민
W1~W21 원칙 + 레시피 선택
스킬 탐색
기억에 의존
/suggest-skills 커맨드
스킬 점검
없음
/skill-audit 주간 헬스체크
레퍼런스 흡수
임시방편
분석→방법론→원칙화 순환
하네스 강도
선언형 (규칙 나열)
4단계 선택 + 도메인 맞춤
신규 WS 생성
4문항 단순 인터뷰
kkirikkiri 조사 + 12섹션 자동 생성
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
1. "왜 잘 되는가"를 해부한다
좋은 스킬을 보면 "오, 잘 되네"로 끝내지 않고 "어떤 메커니즘 때문에 잘 되는가"를 파고들었습니다. kkirikkiri의 Continuation Contract, vibe-sunsang의 서브에이전트 위임 — 이름 붙이고 원칙화하는 순간 내 다른 스킬에 적용할 수 있게 됩니다.
2. 분석 인프라가 생기면 개선 속도가 올라간다
스킬/WS 방법론 문서가 없을 때는 "이걸 어떻게 개선할까"가 항상 제로베이스였습니다. 원칙이 문서에 쌓이면 "W8(린 WS)가 적용 안 됐네, 이 방향으로 개선하자"처럼 빠르게 결정할 수 있습니다.
3. 쌍방향 비교가 단방향 비교보다 훨씬 많이 나온다
"방법론이 스킬에 반영됐는가"만 확인하면 절반입니다. "스킬에 있는 설계 결정이 방법론에 기록됐는가"까지 확인해야 진짜 정합입니다. 역방향 비교에서 W16~W21이 새로 나왔습니다.
4. 충돌 사건을 시스템 점검 계기로
script-writer 충돌은 사소한 버그였지만 "왜 이 문제가 생겼나"를 파고들었더니 전체 스킬 관리 체계가 없다는 게 드러났습니다. 증상 제거보다 원인 탐색이 먼저입니다.
이렇게 하면 안 돼요
1. 만들고 끝 내기 — 스킬과 워크스페이스는 만드는 순간이 아니라 쌓이면서 자산이 됩니다. 만들 때부터 분석 인프라를 같이 구축하세요.
2. 하네스 강도를 항상 최강으로 — runtime-enforced는 hooks가 작동하면서 속도가 느려질 수 있습니다. 법률·세무처럼 안전이 중요한 도메인에만 적용하세요.
3. 외부 스킬 설치 후 중복 확인 안 하기 — 설치 도구는 예상치 못한 위치에 파일을 복사할 수 있습니다. 설치 후 다른 경로에 중복이 생겼는지 꼭 확인하세요.
🌍 다른 업무에 적용한다면?
팀 운영 WS — 팀마다 도메인 전문 워크스페이스를 runtime-ready 강도로 만들면, AI가 팀의 언어와 프로세스를 처음부터 이해하고 시작합니다.
스킬 공유 문화 — Tier 체계와 카탈로그가 있으면 팀 스킬을 어떤 프로젝트에서도 재사용할 수 있습니다.
방법론 누적 — 좋은 스킬을 발견할 때마다 메커니즘을 해부해 원칙으로 기록해두면, 시간이 갈수록 설계 속도가 빨라집니다.
📋 재사용 가능한 프롬프트
프롬프트 1: 레퍼런스 WS 흡수해서 새 WS 만들기
"[레퍼런스 경로]의 하네스 구조를 분석해줘. 내가 만들려는 [도메인] 워크스페이스에 맞게 강점을 흡수하고, 하네스 강도는 어떤 게 맞는지 판단해서 12섹션 CLAUDE.md로 만들어줘."
프롬프트 2: 스킬 메커니즘 해부
"[스킬명] SKILL.md를 읽고 핵심 메커니즘을 해부해줘. 각 메커니즘이 왜 그렇게 설계됐는지, 어떤 문제를 해결하는지, 우리 스킬에 적용할 수 있는 원칙이 뭔지 정리해줘."
프롬프트 3: 스킬 탐색 → 레퍼런스 분석 → 제작
"내가 [작업 설명] 스킬을 만들려고 해. 먼저 find-skills로 유사 스킬이 마켓에 있는지 찾고, 있으면 구조를 분석해서 강점을 정리해줘. 그 다음 skill-creator Step 0부터 시작해서 우리 도메인에 맞는 버전을 만들자."
프롬프트 4: WS 쌍방향 비교
"[스킬명]과 [방법론 문서]를 쌍방향으로 비교해줘. 방법론 원칙이 스킬에 반영됐는지 + 스킬의 설계 결정이 방법론에 원칙으로 기록됐는지 두 방향 모두 체크해줘."
프롬프트 5: workspace-builder로 새 WS 만들기
"workspace-builder 실행해줘. [도메인명] 전용 워크스페이스 만들고 싶어. 도메인 인터뷰부터 시작해줘."
22기 클코끝판왕 2주차 | 2026.06.03
