acceptancelisted

# Acceptance Skill — story/epic 제품 검수 MVP `/acceptance` 는 PR 하나의 코드 리뷰가 아니라 제품 단위 완료 여부를 확인하는 검수 skill 이다. MVP 에서는 story / epic 검수만 다룬다. > 🔴 **분기 규칙 SSOT** — `product-acceptance` 결론(`PASS` / `FAIL` / `ESCALATE`) → 다음 행동은 [`acceptance-routing.md`](acceptance-routing.md) 가 본 skill 의 단일 진본이다. 본 파일은 입력 정형화와 진행 절차만 담는다. 용어·공개 진입점·분기 표현을 수정하거나 리뷰할 때만 [`terms.md`](../../docs/plugin/terms.md) 를 확인한다. > `/impl-loop` 는 story/epic 마감 task 의 머지 *전* 에 같은 `product-acceptance` agent 로 inline 검수를 돈다 — 그 경로의 결론→다음(gap 수정 루프 포함)은 [`impl-loop-routing.md` 마감 acceptance 분기](../impl-loop/impl-loop-routing.md#마감-acceptance-분기) 가 소유하고, 본 skill 의 prompt 규약(아래 Story/Epic Acceptance 호출 형식)만 재사용한다. ## Inputs 메인이 사용자에게 받거나 직접 확인해야 할 입력: - 검수 단위: `story` 또는 `epic` - story issue 또는 epic issue - PRD/stories path - 구현 PR 목록 - 있으면 테스트 결과, smoke 결과, 화면/API/CLI 동작 증거 - 이전 acceptance gap 이 있으면 그 결과와 재검수 대상 입력이 부족하면 추측으로 검수하지 않고 사용자에게 어떤 경로/PR/issue 가 필요한지 묻는다. ## 비대상 - 새 spec 작성 또는 PRD 변경 → `/spec` - 설계 산출물 작성/수정 → `/design` - 구현 자체 → `/impl` - GitHub issue 초안/등록 → `/to-issue` - release readiness, 배포, migration, full E2E 검증 → MVP 범위 밖. 후속 release/product acceptance 고도화에서 다룬다. Lite `/impl` 단발 작업은 불필요하게 `/acceptance` 로 강제하지 않는다. 파일/symbol이 명확한 작은 수정은 기존 test + pr-reviewer + CI gate 로 끝날 수 있다. ## Story Acceptance story 단위는 가볍게 돈다. 핵심은 AC / PR / test evidence 연결이다. 호출: ``` Agent(subagent_type="product-acceptance", prompt=""" mode: STORY_ACCEPTANCE 검수 단위: <story issue 또는 stories.md story> 기준 문서: - <PRD