From vibe-recipe
/vr:recipe 호출 시 사용합니다. 비개발자도 답할 수 있는 제품 질문으로 사용자 요구사항을 상세화하고, 구현 전에 번호가 붙은 feature spec과 승인 가능한 작업 레시피를 준비합니다.
npx claudepluginhub pj4316/vibe-recipe --plugin vibe-recipeThis skill uses the workspace's default tool permissions.
자연어 요청을 구현 전에 번호가 붙은 feature spec으로 바꿀 때 사용합니다. 목표는 사용자가 기술 용어를 몰라도, 구현자가 바로 task를 나눌 수 있을 만큼 정확한 요구사항을 끌어내는 것입니다.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
자연어 요청을 구현 전에 번호가 붙은 feature spec으로 바꿀 때 사용합니다. 목표는 사용자가 기술 용어를 몰라도, 구현자가 바로 task를 나눌 수 있을 만큼 정확한 요구사항을 끌어내는 것입니다.
recipe는 코드를 구현하지 않습니다. 제품 행동, 사용자 흐름, 예외, 성공 기준, 검증 방법을 확정하고, 승인된 뒤 cook/dev가 구현할 수 있는 spec을 만듭니다.
recipe는 문서를 쓰기 전에 먼저 대화로 스펙을 좁힙니다. 목표는 사용자가 “맞아요, 제가 원한 건 그거예요”라고 말할 때까지 티키타카로 이해를 맞추는 것입니다.
각 라운드는 아래 흐름을 기본으로 합니다.
이 루프는 필요한 만큼 반복합니다. 사용자가 확인하기 전에는 “확정된 spec”처럼 밀어붙이지 않습니다.
resources/question-bank.md: 요구사항을 세분화할 때 쓰는 비개발자 친화 질문 은행입니다. 답이 부족하거나 기능 유형별 drill-down이 필요할 때 읽습니다.resources/spec-template.md: .agent/spec/active/NNNN-<slug>.md 생성 시 사용하는 고정 템플릿입니다. spec 파일을 만들 때 읽습니다.시작 전에 AGENTS.md의 Recipe Routing을 먼저 읽고, 요청이 정말 recipe 대상인지 확인합니다.
| 요청 | 처리 |
|---|---|
| 새 기능, 제품 동작 변경, scope 변경 | recipe에서 spec 작성 |
| 접근 방식, library, vendor, API 선택이 불명확함 | forage로 ADR 초안 작성 후 recipe |
| 장애, bug, failing test, 원인 불명 | fix로 root cause 분석 |
| 동작 변경 없는 구조 개선 | tidy로 refactor spec 또는 작업 |
| UI token, component pattern, visual drift 정리 | recipe로 design-system 정책 spec 작성, 코드 이관은 tidy |
| version, changelog, release 준비 | wrap |
| release gate, tag, push/deploy 전 점검 | serve |
요청이 다른 skill에 더 적합하면 이유를 짧게 설명하고 해당 skill로 라우팅합니다. 단, 사용자가 명시적으로 “이것을 spec으로 만들어줘”라고 요청하면 recipe가 follow-up spec을 작성할 수 있습니다.
작업을 시작하기 전에 kitchen harness가 준비되었는지 확인합니다.
kitchen/init을 먼저 안내합니다. 필요하면 그때 실제 파일 경로를 근거로 덧붙입니다.kitchen/heal을 먼저 안내합니다..agent/constitution.md와 .agent/spec/prd.md의 product scope를 벗어나는 요청이면 scope 변경으로 표시하고 사용자 확인을 받습니다..agent/commands.json의 test, e2e, verify 상태를 확인해 spec의 test plan에 반영합니다.Alignment Brief가 있으면 Goal, Audience, MVP, Non-goals, Success criteria, Domain terms, Assumptions, AI interpretation을 읽고 spec과 domain update 초안에 반영합니다.forage/research로 보냅니다.AGENTS.md의 Recipe Routing, constitution, PRD, design, architecture, domain, command profile, 관련 ADR을 읽습니다.Alignment Brief가 있으면 spec의 goal/non-goal/success criteria/domain draft로 매핑하고, 사용자에게 수정할 기회를 줍니다.resources/question-bank.md에서 기능 유형에 맞는 질문을 고릅니다..agent/wiki/domain.md와 비교해 충돌과 모호성을 먼저 해결합니다..agent/wiki/decisions/NNNN-<slug>.md proposed ADR 후보로 남깁니다.resources/spec-template.md를 기준으로 .agent/spec/active/NNNN-<slug>.md를 Status: Draft로 생성합니다.Approved로 바꾸지 않습니다. 승인 후에만 status를 Approved로 바꾸고 feat/NNNN-slug, fix/NNNN-slug, refactor/NNNN-slug branch를 준비합니다.같은 대화에 제품 brief나 이전 alignment 메모가 있으면 아래처럼 반영합니다.
| Alignment Brief | Recipe 반영 위치 |
|---|---|
Goal | spec 요약, 목표 |
Audience | spec 사용자 요구의 Actor |
MVP | spec 목표, 사용자 흐름, task 후보 |
Non-goals | spec 제외 범위 |
Success criteria | spec 수락 기준, 검증 계획 |
Domain terms | .agent/wiki/domain.md update 후보 |
Assumptions | spec 위험과 가정, domain dangerous assumption 후보 |
AI interpretation | spec 요약, open question, scope boundary |
Recommended next skill | routing 확인. 기술 선택이면 forage, 구현 가능하면 cook 준비 |
Alignment 메모는 사용자가 승인한 의도 정렬 결과일 수 있지만, spec approval을 대체하지 않습니다. recipe는 brief를 draft 입력으로 사용하고, 구현을 막는 빈칸이나 위험한 scope는 다시 확인합니다.
brief가 현재 .agent/constitution.md, .agent/spec/prd.md, .agent/spec/design.md, .agent/wiki/domain.md와 충돌하거나 오래된 전제에 기대면 그대로 반영하지 않습니다. 충돌은 spec의 위험과 가정 또는 열린 질문에 남기고, 제품 의도가 필요한 부분만 사용자에게 확인합니다.
recipe는 용어와 결정 정리를 vibe-recipe의 .agent 구조에 맞춰 수행합니다.
CONTEXT.md를 만들지 않습니다. source of truth는 .agent/wiki/domain.md입니다.Domain 업데이트에 적고 .agent/wiki/domain.md에 반영합니다.recipe는 구현 방식 자체를 깊게 조사하지 않습니다. 다만 spec 작성 중 명백한 제품/운영 결정이 확정되면 ADR 후보를 남길 수 있습니다.
ADR 후보는 아래 세 조건을 모두 만족할 때만 작성합니다.
대상 경로는 .agent/wiki/decisions/NNNN-<slug>.md이고, 상태는 Status: Proposed입니다. 기술 선택 조사나 vendor 비교가 필요하면 ADR을 직접 쓰지 말고 forage/research로 라우팅합니다.
질문은 비개발자도 답할 수 있는 제품 언어로 합니다.
cook, forage, taste가 기술 선택으로 다룹니다.좋은 질문 예시는 아래와 같습니다.
추천안을 제시할 때는 다음을 함께 남깁니다.
반드시 확인할 축:
.agent/wiki/domain.md와 충돌하나요?recipe는 spec 단계에서 최소한의 adversarial scenario를 먼저 작성합니다. 이 작업은 agent가 기본값을 추천하고, 사용자는 제품 결과만 확인합니다.
none으로 두되, 왜 관련 없는지 짧게 남깁니다.spec change, code fix, follow-up, not applicable 중 하나로 분류합니다.Draft로 유지합니다.Task 0을 실패 test 또는 executable acceptance check 작성으로 시작합니다.cook/dev가 하나씩 처리할 수 있게 작고 검증 가능한 단위로 나눕니다.test, e2e, verify command가 null이면 test plan에 blocked 또는 manual fallback을 명시합니다.Domain 업데이트에 명시하고 .agent/wiki/domain.md 반영 여부를 표시합니다.결정 기록에 경로와 Status: Proposed를 남깁니다.Red-team 시나리오에 남깁니다.Draft로 유지합니다.Approved로 바꾸기 전 다음을 모두 확인합니다.
e2e 또는 Playwright MCP 검증 계획이 있습니다.spec change, code fix, follow-up, not applicable 중 하나로 분류되어 있습니다.Task 0이 실패 test 또는 executable acceptance check 작성이고, 이후 task가 cook/dev에서 하나씩 처리 가능한 크기로 나뉘며 각 task에 check가 있습니다..agent/commands.json의 test, e2e, verify 상태가 test plan에 반영되어 있습니다.Alignment Brief가 있으면 현재 PRD/constitution/design/domain과 충돌하지 않거나 blocking open question으로 남아 있습니다..agent/wiki/decisions/에 proposed 상태로 남았거나 forage로 라우팅되었습니다.추천 commit:
docs(spec): add NNNN <title>
Refs: .agent/spec/active/NNNN-<slug>.md
cook, fix, tidy를 시작하지 않습니다. 단, 사용자가 emergency debug mode를 명시하면 예외입니다.Approved로 바꾸지 않습니다.