스킬러들의 수다 — 4명의 전문가 관점이 수다 떨며 바이브코더의 아이디어를 동작하는 Codex 스킬로 변환한다. Use when the user asks to "스킬 만들어줘", "스킬러들의 수다", "수다", "Codex 스킬 만들어줘", "이 스킬 개선해줘", "skill builder", "make a skill", "create a skill", "build a skill", "improve this skill".
스킬러들의 수다 — 4명의 전문가 관점이 수다 떨며 바이브코더의 아이디어를 동작하는 Codex 스킬로 변환한다. Use when the user asks to "스킬 만들어줘", "스킬러들의 수다", "수다", "Codex 스킬 만들어줘", "이 스킬 개선해줘", "skill builder", "make a skill", "create a skill", "build a skill", "improve this skill".
스킬러들의 수다 (Codex)
4명의 전문가 관점으로 아이디어를 다각도로 분석하고, 그 결과로 바이브코더의 아이디어를 동작하는 Codex 스킬로 변환한다.
이 문서는 참고 자료가 아니라 실행 지시서다. 트리거되면 즉시 워크플로우를 시작한다.
이 스킬은 Codex 스킬을 만든다 — 결과물은 SKILL.md + 선택적 references/·scripts/·assets/다. Codex에는 commands/ 슬래시 커맨드 폴더도, agents/ 폴더도 없다. 진입은 항상 description 트리거로 이뤄진다.
아이디어를 캐낼 때 가정형 말고 과거 실제 행동을 묻는다(§1.3, Mom Test): "이 기능 쓰실래요?"(X) 대신 "지금은 이 문제를 어떻게 해결하세요?"(O). 표면·예의·회피 답을 결론으로 받지 말고 한 번 더 구체 탐침한다(§2a·§2b). 하지만 사용자가 이미 스스로 진단했거나 요청이 이미 충분히 구체적이면 더 캐묻지 말고 즉시 진행한다(§2c). 추론 가능한 건 묻지 않는다(§1.1) — 물어야 하면 "기본값 제시 + 확인" 형태로.
질문 렌더링 — §A 번호형 선택지 (Codex 전용)
Codex CLI에는 AskUserQuestion 같은 객관식 카드 UI가 없다. 모든 선택 질문은 shared/questioning-policy.md §A대로 채팅에 번호형 선택지 블록을 출력하고 다음 자유 텍스트 답변을 읽는다.
표준 블록 포맷:
예시 프리뷰 ← 구조를 보여줄 때만. 단순 선호 질문이면 생략.
[User] --1:N--> [Skill] (매번 인터뷰 결과로 새로 생성, 하드코딩 금지)
질문: <한 줄 질문>
1. <추천안> — 무엇인지, 왜 좋은지, 트레이드오프
2. <대안> — 무엇인지, 트레이드오프
3. 문장으로 직접 수정 요청
(여러 개 고를 수 있으면: "여러 개면 1,3처럼 적어주세요")
추천안은 항상 1번에 둔다.
"잘 모르겠어요"는 별도 선택지로 만들지 말고 "모르면 1번으로 진행하겠습니다"로 안내한다.
핵심 문제 발굴(Phase A 첫 턴)은 번호 블록 대신 열린 텍스트 질문으로. 단순 분류/설정 고르기일수록 번호 블록이 적합하다.
진입점 판단
사용자가 어디에 있는지 파악하고 거기서 시작한다.
상황
시작 지점
아이디어 없음
Phase A (아이디어 수집)
아이디어 있음 (요청에 포함)
Phase B (4 관점 분석)
대화에 이미 워크플로우가 있음 ("이걸 스킬로 만들어줘")
대화에서 추출 → Phase D (워크플로우 확인)
이미 SKILL.md 드래프트가 있음 ("이 스킬 개선해줘")
Phase F (eval 실행)
기존 스킬 분석 요청 ("이 스킬 분석/검토해줘")
스킬 분석 모드
사용자가 "eval 안 해도 돼, 그냥 바이브로 가자"라고 하면 eval을 스킵하고 대화형으로 진행한다.
워크플로우
Phase A: 아이디어 수집
만들고 싶은 스킬의 핵심 아이디어를 파악한다.
대화 컨텍스트 추출 먼저: 현재 대화에 이미 워크플로우가 있으면("이걸 스킬로 만들어줘") 대화 히스토리에서 답을 먼저 추출한다 — 사용된 도구, 단계 순서, 사용자가 한 수정, 입출력 형식. 빈 부분만 채우고 확인받는다.
요청에 아이디어가 포함됐으면 그대로 사용한다. 없으면 열린 텍스트 질문 하나로 묻는다(번호 블록 아님 — §A·§1.2):
어떤 스킬을 만들고 싶으세요? 한 문장으로 말해주세요.
(예: "유튜브 댓글을 분석해서 인사이트를 뽑아줘", "회의록을 요약하고 액션 아이템 뽑아줘")
아이디어가 모호하면(예: "좋은 스킬") 과거 행동 앵커로 1개 더 묻는다(§2b): "지금은 그걸 어떻게 하고 계세요?". 이미 구체적이면 바로 Phase B로(§2c).
Phase B: 4 관점 분석 + 토론
목표: 아이디어를 4 관점에서 다각도로 분석한다. 검증 다중성을 위해 인원수 4는 유지하되, 4명의 정의는 매번 사용자 아이디어의 도메인을 보고 동적 생성한다(references/personas.md).
기본 4 관점(도메인 미특정 시):
기획자 — 방향·범위·MVP: "누가 쓸 건데? 뭘 해결하는 거야?"
사용자 — UX·진입장벽: "나라면 이걸 어떻게 쓸까?"
전문가 — 기술 실현성·워크플로우: "이 분야는 이런 점을 조심해야 해"
검수자 — 엣지 케이스·실패: "이거 이 경우에도 돼?"
분석 실행 (Codex 방식): 기본은 메인 스레드에서 4 관점을 직접 종합한다 — 각 관점을 순서대로 적용해 아이디어를 분석한다(references/interview-guide.md §2-1의 4개 분석 항목 템플릿 사용). 사용자가 명시적으로 "전문가 팀 불러줘 / 병렬로 깊게 봐줘"라고 요청하고 환경이 sub-agent 위임을 지원할 때만, 최대 4개의 bounded sub-agent로 위임한다. 위임이 불가능하면 조용히 메인 스레드 종합으로 진행한다 — 존재하지 않는 도구를 가정하지 않는다.
의견 충돌은 반드시 노출한다. 충돌이 있으면 그 충돌 자체를 §A 번호 블록의 질문으로 만든다:
질문: 커맨드 분기가 필요할까요, 단일 스킬이 나을까요?
1. 단일 스킬 (추천) — Codex는 슬래시 커맨드가 없고 트리거가 자연스러움
2. 인수 기반 분기를 SKILL.md 안에서 처리 — 진입 경로가 여러 개일 때
3. 문장으로 직접 수정 요청
충돌이 없으면 합의 방향을 짧은 프리뷰(MVP 범위 / 핵심 워크플로우 / 컴포넌트 타입)로 보여주고 §A 블록으로 확인받는다. "다시 토론해줘"를 고르면 추가 정보를 받아 Phase B를 다시 실행한다.
Phase C: 상세 인터뷰 (0–2개, 필요시만)
팀 분석에서 자동 판단한 항목(purpose / input_type / output_type / trigger_keywords / domain / constraints)은 다시 묻지 않는다. 불확실한 것만 §A 번호 블록으로 최대 2개 묻는다. 충분히 파악됐으면 이 Phase를 스킵하고 Phase D로 간다(§2c).
단순 확인("혹시 이런 뜻인가요?")은 자연 대화로 처리한다 — 굳이 번호 블록을 강제하지 않는다.
Phase D: 워크플로우 설계 + 확인
팀 분석 + 사용자 답변으로 워크플로우를 설계한다. 6가지 단계 타입을 조합한다(references/workflow-step-types.md):
prompt — Codex가 추론하는 단계 (분석·요약·판단·창작)
script — 반복/일관성/API 작업용 Python/Bash
api_mcp — 외부 연동 (API > MCP/App > 직접 구현 우선순위)
rag — references/ 참조 검색
review — 검토 게이트 (api_mcp/rag 뒤에 반드시 포함)
generate — 최종 출력 (파일 생성, 보고서)
컴포넌트 타입 (Codex): 기본값은 스킬이다. 여러 스킬·자산·메타데이터·MCP 설정을 한 제품으로 묶어야 하면 플러그인 패키지(references/plugin-package-guide.md). 큰 표·스키마·예시는 레퍼런스로, 결정적 작업은 스크립트로 분리한다. Claude Code의 command/agent 컴포넌트는 Codex에 없으므로 제안하지 않는다(references/component-decision.md).
자유도(Degrees of Freedom) 식별: 고정 요소(워크플로우 구조·단계 순서·필수 검증)와 가변 요소(출력 언어·상세도·포맷)를 구분한다. 가변 요소가 있으면 SKILL.md에 기본값 + 변경 방법을 명시한다.
Eval 기준 정의: 검수자 관점의 엣지 케이스를 활용해 eval 시나리오를 정의한다. should-trigger 2–3개 + should-not-trigger 1–2개. 현실적이고 구체적인 프롬프트로 작성한다(파일 경로·약어·캐주얼 표현을 섞는다). 상세: references/eval-guide.md, 스키마: references/schemas.md.
Step D-1: 단계별 흐름 + eval 시나리오 목록을 보여준다.
Step D-2: §A 번호 블록으로 확인받는다 — 1. 이대로 진행 (추천) / 2. 수정할 부분 있어 / 3. 나중에 할게.
Phase E: 파일 생성
확인된 워크플로우를 실제 파일로 만든다. Codex 스킬 파일 구조:
skills/{skill-name}/
├── SKILL.md # 워크플로우 (간결하게, references로 분리)
├── scripts/ # script 타입 단계용
├── references/ # rag 타입 + 큰 문서
└── assets/ # 출력에 직접 쓰는 파일 (컨텍스트에 로드 안 함)
commands/·agents/ 폴더는 만들지 않는다 — Codex에 없는 컴포넌트다.
SKILL.md 생성 템플릿:
---
name: {skill-name}
description: This skill should be used when the user asks to "{trigger1}", "{trigger2}", "{trigger3}". {무엇을 하는지 + 왜}.
---# {Display Name}> {한 줄 설명}## 워크플로우### Step 1: {단계 이름}**타입**: {prompt/script/api_mcp/rag/review/generate}
{명령형 실행 지침}
## References / Scripts / Assets
- **`references/{file}.md`** — {설명}
## Settings (가변 요소가 있을 때만)
| 설정 | 기본값 | 변경 방법 |
경로는 $PLUGIN_ROOT 기준으로 작성한다 — 예: python3 $PLUGIN_ROOT/skills/{skill-name}/scripts/{file}.py. $PLUGIN_ROOT는 Codex가 플러그인 실행 시 플러그인 루트로 설정하는 환경 변수다.
Description 작성 (references/trigger-mechanism.md):
Pushy — 무엇을 하는지 + 구체적 트리거 상황을 함께. BAD: "코드 리뷰 도구" / GOOD: 트리거 문구 + "Make sure to use this skill whenever the user mentions code review."
명령형(imperative) — "Read the file. Validate the input." / "You should…" 금지.
description은 third-person — "This skill should be used when…".
Why 설명 우선 — ALWAYS/NEVER 대신 이유를. Codex는 이유를 이해하면 더 잘 따른다.
간결 — 본문은 핵심만, 상세는 references/로. 컨텍스트는 공공재다.
규율형(Discipline) 스킬이면 합리화 차단 장치 필수 — "X 전에 반드시 Y"를 강제하는 스킬이면 Iron Law + 합리화 차단표 + Red Flags + Spirit vs Letter 4종을 포함한다. 번역·포맷팅 같은 기법형엔 넣지 않는다(토큰 낭비). 판별·템플릿: references/writing-style-guide.md §6.
스크립트: Python 우선(크로스플랫폼). 에러는 stderr, 결과는 JSON stdout. 표준 라이브러리 우선, 런타임 pip install 금지. 템플릿: references/script-templates.md.
파일 덮어쓰기: 같은 이름 파일이 있으면 사용자에게 확인한다. 동의 없이 덮어쓰지 않는다.
