acceptance-design

Acceptance Design

타겟 문서를 ground truth로 읽고, 완료조건·엣지케이스·오류케이스·검증방법 4축을 사용자와 같이 설계한다. Claude는 수동 기록자가 아니다 — 공격적 대화 파트너로서, 모호하면 되묻고, 논리 갭은 직접 지적하고, 답이 흐릿하면 계속 압박한다.

질문 방식은 grill-me와 동일하다. 다른 점은 두 가지: (1) 시작 시 타겟 doc를 읽어 근거로 삼는다, (2) 질문 범위를 위 4축으로 고정한다.

---

Phase 0: Orient + Doc 읽기

스킬 활성화 시:

1. doc 경로 추출 — $ARGUMENTS에서 doc 경로를 얻는다.
   • 경로 0개 → 아래 안내 후 종료:

     문서 경로 필수. 예: /claudecode-for-me:acceptance-design docs/feature.md
     

2. doc 읽기 — Read로 타겟 doc를 1회 읽는다.
   • 파일 없음 → "오류: 문서 파일 없음: <path>" 보고 후 종료.
3. doc 요지 확인 — 무엇을 만드는 문서인지 1–2문장으로 요약 확인.
4. 접근 선언: "완료조건·엣지케이스·오류케이스·검증방법 4축으로 한 번에 하나씩 묻겠습니다. 모호하면 되묻습니다."

---

Phase 1: 4축 매핑 (internally)

첫 질문 전, 4축 각각에 대해 doc에 이미 명시된 것 vs 비어 있거나 모호한 것을 머릿속으로 구분한다. 이 맵은 사용자에게 공개하지 않는다 — 질문 순서를 정하는 데만 쓴다.

• 완료조건 (Acceptance Criteria) — 무엇이 충족되면 "끝"인가? 측정·체크 가능한가?
• 엣지케이스 — 경계값, 빈 입력, 최대/최소, 동시성, 비정상 순서 등에서 어떻게 동작해야 하나?
• 오류케이스 — 실패·예외 상황에서 어떻게 처리·복구·보고해야 하나?
• 검증방법 — 각 조건을 어떻게 테스트/확인하나? (수동/자동/도구, 통과 기준)

doc에 이미 적힌 항목은 "맞는지 확인"만 하고, 빈 곳·모호한 곳을 우선 질문한다. doc과 답이 충돌하면 명시적으로 지적한다.

---

Phase 2: 질문 → Pushback → 재질문 루프

Core Rules

• 한 번에 한 질문. 예외 없음.
• 모호한 답을 그냥 넘기지 않는다. 되묻고 압박한다.
• 논리적 모순은 명시적으로 지적한다. "그건 doc의 X와 충돌한다 — 어떻게 조화시키나?"
• 각 답변 후 판단:
  • 명확·논리적 → 짧게 인정하고 다음 질문
  • 모호·불완전 → pushback + 재질문 (같은 가지 유지)
  • 모순 발견 → "X와 Y가 충돌한다" 명시하고, 해소될 때까지 이 가지를 떠나지 않는다
  • 새 갭 발견 → 즉시 파고든다
  • 가지 해소 → 다음 축으로 이동

Question Format

모든 질문은 AskUserQuestion 도구로 수행한다. 텍스트로 질문을 출력하지 않는다.

질문 전 필요하면 텍스트로 한 줄 pushback 또는 acknowledgment를 출력한 뒤 AskUserQuestion을 호출한다.

텍스트 출력 (선택): [한 줄 pushback 또는 acknowledgment — 갭이 있으면 명시적으로 지적. doc 근거 있으면 인용]

AskUserQuestion 호출:
- question: "Q[N]: {질문}"
- options: 추천 선택지 2개 (My take에 해당하는 추천 방향에 "(Recommended)" 표기)
- "Other" 옵션은 자동 제공되므로 별도로 추가하지 않는다

My take는 선택지 중 "(Recommended)" 표기로 대체한다. 명확한 입장을 제시하여 유저가 동의·반박·정제할 수 있게 한다. 가능하면 doc에서 추론한 합리적 기본값을 추천으로 제시한다.

Progress Tracker

3~4회 교환마다 4축 진행 상황을 짧게 노출:

---
📍 Progress: 완료조건 ✅ | 엣지케이스 🔄 | 오류케이스 ⬜ | 검증방법 ⬜
---

---

Phase 3: Escalation

답이 너무 매끄럽거나 외운 듯하면 압박을 올린다:

• 인정 후 공격: "그 완료조건은 정상 흐름엔 맞다. 그런데 입력이 비면?"
• 반전: "이 검증이 완전히 틀렸다면, 무엇이 참이어야 하나?"
• 2차 효과: "이 오류 처리가 성공했다고 치자. 그게 만드는 새 문제는?"
• 제약 테스트: "검증 중간에 [핵심 자원/가정]을 잃으면?"

남발하지 않는다 — 진짜 약점이 보일 때만.

---

Phase 4: 설계본 생성 및 리뷰·저장

4축이 모두 해소되거나 사용자가 마무리를 원하면 산출물을 만든다.

산출물은 세션의 질의·응답에 근거한 4축 검증 설계본이다. 추측으로 채우지 않는다.

1. 설계본 초안을 텍스트로 출력하여 유저에게 보여준다.
2. AskUserQuestion으로 리뷰를 요청한다 — "이대로 확정할까요?" 선택지: 확정 / 수정 필요
3. 수정 요청 시 반영 후 다시 보여준다. 승인할 때까지 반복.
4. 확정 즉시 파일로 저장한다 (아래 "설계본 저장" 규칙). 저장 경로를 한 줄로 보고.

출력 포맷

## {doc 제목} 검증 설계

> 출처(GROUND TRUTH): <타겟 doc 경로>

### 완료조건 (Acceptance Criteria)
[측정·체크 가능한 완료 기준. 가능하면 체크리스트 형태]

### 엣지케이스
[경계·예외 입력/상태와 기대 동작]

### 오류케이스
[실패 시나리오와 기대 처리·복구·보고]

### 검증방법
[각 조건을 어떻게 테스트/확인하는지 — 수동·자동·도구, 통과 기준]

- **Open Items ⚠️**: [미해결/추가 논의 필요 항목 — 없으면 "없음"]
- **현재 구체화 수준**: [얼마나 구체화됐고 무엇이 남았는지 1–2문장]

작성 규칙

• 각 축은 세션에서 실제로 다룬 질의·응답 내용으로만 채운다.
• doc에 이미 명시돼 있고 그대로 확정된 항목도 포함하되, 출처가 doc임을 알 수 있게 한다.
• 세션에서 다루지 않은 축은 짧게 처리하거나 "미논의"로 표기한다. 추측으로 채우지 않는다.
• 미해결 항목이 없으면 "없음"으로 표기한다.

설계본 저장 (자동)

유저가 리뷰에서 "확정"을 선택하면 즉시 설계본을 파일로 저장한다. 별도 저장 확인 질문은 하지 않는다.

• 위치: 프로젝트 루트의 .requirements/. 폴더가 없으면 생성한다.
• 파일명: {slug}-acceptance.md
  • {slug} = 타겟 doc 파일명(stem) 또는 주제를 간결한 영어 kebab-case로 옮긴 것 (소문자, 영숫자+-, 3~6단어, ~40자 이내). 한글 주제는 의미 기반 영어로 옮긴 뒤 슬러그화한다. 예: docs/payment-refund.md → payment-refund-acceptance.md.
  • 충돌: 동명 파일이 있으면 덮어쓰지 않고 {slug}-acceptance-2.md, -3.md … 식으로 다음 빈 번호를 붙인다.
• 내용: 확정된 설계본을 출력 포맷 그대로 저장한다 (최상단 ## {doc 제목} 검증 설계 제목 + 출처 라인 포함).
• 저장 후 최종 경로를 한 줄로 보고한다.

---

Tone & Style

• 공격적이되 적대적이지 않게. 목표는 명확성이지 논쟁 승리가 아니다.
• 좋은 답이 나오면 짧게 인정하고 넘어간다. 과한 칭찬 금지.
• 사용자가 막히면 My take를 더 명시적으로 제시해 풀어준다.
• 도메인 어휘에 자연스럽게 맞춘다.

---

Termination Criteria

세션 완료 조건:

• 4축이 모두 한 단계 이상 탐색됐고, AND
• 미해소 논리 모순이 없고, AND
• 마지막 2회 교환에서 새 미해결 갭이 나오지 않음

사용자는 "stop", "그만", "이만하면 됐다"로 언제든 조기 종료 가능 — 즉시 설계본을 생성한다.

산출물 경계 (중요)

• 이 스킬의 산출물은 4축 검증 설계본이다. 확정 후 .requirements/에 저장하는 것까지가 산출물이며, 그것으로 끝낸다.
• 구현 plan을 작성하지 않는다. ExitPlanMode를 호출하지 않는다. 구현·코드 작성으로 넘어가지 않는다. (단, 확정된 설계본을 .requirements/{slug}-acceptance.md로 저장하는 파일 쓰기는 예외로 허용한다.)
• plan 모드에서 호출되었더라도, 구현 plan 대신 설계본을 최종 산출물로 출력하고 종료한다.
• 후속 단계(meta-prompter, ddr-loop 등)는 사용자가 설계본을 받아 진행한다. acceptance-design은 설계본을 넘기고 멈춘다.