| name | issue-audit |
| description | 이슈 스펙 대비 구현 완료 여부를 독립 감사인 관점에서 검증합니다. 이슈 감사, issue audit, 구현 검증, 크로스체크 시 사용합니다. |
개요
이슈 스펙(요구사항) 대비 구현을 독립 감사인 관점에서 검증합니다.
구현을 수행한 AI가 아닌 다른 모델이 실행하는 것을 전제로, 두 단계로 감사를 수행합니다.
- Phase 1 — 적합성 검증: 스펙 대비 구현 완료 여부를 항목별로 대조
- Phase 2 — 비판적 검증: 구현이 잘못되었을 수 있는 근거를 적극적으로 탐색
관련 skill
- issue-work (권장):
.ai/90_issues/ 의 스펙·계획·요약 파일을 감사 입력으로 활용합니다.
issue-work 계획의 마지막 고정 **Task N(교차모델 검증)**에서 이 스킬을 호출합니다 —
구현 모델과 다른 벤더 모델(Non-Anthropic 포함)로 사용자가 직접 수동 수행하며,
감사 결과는 issue-<번호>-summary.md의 모델 기록·Task별 결과에 반영합니다.
- ai-workspace (권장):
.ai/30_contract/, .ai/40_domain/ 문서를 비즈니스 검증에 참조합니다.
git-review와의 차이: git-review는 PR 단위 코드 품질 리뷰이고,
issue-audit는 이슈 단위 스펙 충족 + 비판적 검증입니다.
참조 문서
- 공통 규칙:
.ai/10_rules/context-loading.md — 있으면 따르며, 이미 적재되어 있으면 재로딩하지 않습니다.
- 스킬 고유 추가 참조:
.ai/90_issues/active/ 하위 전체 또는 .ai/90_issues/archive/issue-<번호>/ 전체
.ai/30_contract/index.md, .ai/40_domain/index.md — 도메인·계약 정합성 (index 먼저 → 관련 파일만 선택적으로)
.ai/50_adr/index.md — Phase 1 범위 검증 시 ADR과의 정합성 대조 (index 먼저 → 관련 ADR만 선택적으로)
.ai/60_codebase/index.md — 관련 기능의 호출 흐름
역할 원칙
이 스킬을 실행하는 AI는 독립 감사인입니다.
- 구현자의 의도를 선의로 해석하지 않는다.
- "동작하니까 괜찮다"가 아니라 "스펙에 명시된 대로인가"를 기준으로 판단한다.
- 스펙 자체의 모호함이나 누락도 발견 사항으로 보고한다.
입력
사용자로부터 아래 정보를 확인합니다.
| 항목 | 필수 | 설명 |
|---|
| 이슈 번호 | O | GitHub Issue 번호 또는 이슈 식별자 |
| 구현 브랜치 | △ | 미지정 시 현재 브랜치 사용 |
절차
0단계: 컨텍스트 수집
.ai/90_issues/active/issue-<번호>/ 또는 .ai/90_issues/archive/issue-<번호>/ 에서 스펙·계획·요약 파일을 읽는다.
- 파일이 없으면 GitHub Issue 본문을 직접 읽어 스펙으로 사용한다.
.ai/60_codebase/index.md에 내용이 있으면 참고하여 관련 기능의 호출 흐름을 빠르게 파악한다.
- 단, SSoT는 소스코드이므로 색인을 신뢰하지 않고 반드시 실제 코드를 확인한다.
- 감사 과정에서 색인과 실제 코드가 다른 부분을 발견하면, 감사 리포트에 "코드베이스 색인 갱신이 필요해 보입니다 (
/code-map)" 의견을 남긴다.
.ai/30_contract/index.md, .ai/40_domain/index.md, .ai/50_adr/index.md를 먼저 읽고 관련 문서만 선택적으로 확보한다 (있는 경우).
- 구현 브랜치의 변경 파일 목록과 diff를 확보한다.
Phase 1: 적합성 검증 (Compliance Check)
목적: 이슈 스펙에서 요구한 사항이 빠짐없이 구현되었는지 대조한다.
검증 항목
- 요구사항 대조 — 스펙의 각 요구사항에 대해 구현 충족 여부를 판정한다.
- 완료의 정의(DoD) 대조 — 스펙에 정의된 DoD 체크리스트 항목별 충족 여부를 판정한다.
- 범위 검증 — 스펙의 "비포함(Out)" 범위를 침범하지 않았는지, 또는 스펙에 없는 기능이 추가되지 않았는지 확인한다.
- 도메인/계약/ADR 정합성 —
.ai/30_contract/, .ai/40_domain/, .ai/50_adr/ 의 관련 문서가 있으면 구현이 이와 충돌하지 않는지 검증한다.
판정 기준
각 항목에 대해 아래 중 하나로 판정한다.
| 판정 | 의미 |
|---|
| PASS | 스펙 요구사항을 충족함 |
| FAIL | 스펙 요구사항을 충족하지 않음 |
| PARTIAL | 부분적으로 충족하나 불완전함 |
| N/A | 현재 변경 범위에서 판정 불가 |
Phase 2: 비판적 검증 (Critical Review)
목적: "이 구현이 왜 잘못되었을 수 있는가?"를 전제로 적극적으로 문제를 탐색한다.
검증 관점
- 엣지케이스 — 경계값, 빈 입력, 대용량, 동시성 등 비정상 상황에서의 동작
- 암묵적 가정 — 구현이 전제하고 있지만 스펙에 명시되지 않은 가정
- 부작용 — 변경이 기존 기능에 미칠 수 있는 영향 (회귀 가능성)
- 스펙 모호성 — 스펙 자체가 여러 해석을 허용하는 부분
- 누락된 검증 — 테스트가 부재하거나 불충분한 영역
위험도 분류
각 발견 사항에 대해 아래 중 하나로 분류한다.
| 위험도 | 의미 |
|---|
| HIGH | 장애·데이터 손실·보안 이슈로 이어질 수 있음 |
| MEDIUM | 기능 오작동 또는 사용성 저하 가능성 |
| LOW | 개선 권장 사항 또는 잠재적 기술 부채 |
| INFO | 참고 사항, 조치 불필요 |
3단계: 결과 기록
- 이 skill 디렉토리의
templates/issue-audit-report-template.md를 참조하여 감사 리포트를 작성한다.
- 리포트를
.ai/99_workspace/issue-<번호>-audit-report.md에 저장한다.
- 사용자에게 주요 발견 사항을 요약 보고한다.
- 감사에 사용한 모델은 "벤더, 모델명" 형식으로 기록한다 (예:
OpenAI, GPT-5.x / Google, Gemini 3.x). 이는 issue-work의 summary 모델 기록과 동일한 형식이며, 리포트 템플릿의 '감사 모델' 줄(#26)도 이 형식을 따른다.
출력 요약 형식
감사 완료 후 사용자에게 아래 형식으로 요약을 보고한다.
## Issue #<번호> 감사 결과 요약
### Phase 1: 적합성 검증
- PASS: N건 / FAIL: N건 / PARTIAL: N건
### Phase 2: 비판적 검증
- HIGH: N건 / MEDIUM: N건 / LOW: N건 / INFO: N건
### 주요 발견 사항
1. ...
2. ...
> 상세 리포트: .ai/99_workspace/issue-<번호>-audit-report.md