keyz182/adversarial-review

적대적 검토 (Adversarial Review)

어떤 제안이 실행되기 전에 그것이 실패할 이유를 찾으세요. 우선순위가 매겨진 실행 가능한 우려사항과 하나의 판결을 생성하세요. 절대 구현하지 마세요. 라운드 제한을 초과하여 반복하지 마세요.

0. 설정

1. 모드를 선택하세요. 호출자가 명시할 때(예: "리포트 모드로 적대적 검토") 또는 대답할 사람이 없는 서브 에이전트, 워커, 헤드리스 실행에서 실행될 때는 report 모드를 사용합니다. 징후: 위임된 프롬프트로 작업이 도착했거나, 질문 도구가 없거나, 호출자가 파일이나 단어 제한 요약을 요청한 경우입니다. 그 외 모든 경우에는 interactive 모드를 사용합니다.
2. 검토 대상을 찾으세요. 파일 경로, 변경 범위(diff range), 붙여넣은 계획, 또는 "이 대화에서 방금 생성된 것" 중 하나입니다. 여러 후보가 있다면 출력 첫 줄에 선택한 것을 명시하세요. 아무것도 주어지지 않고 최근에 명확한 후보가 없다면: 대화형 모드에서는 어떤 대상을 의미하는지 물어보고, 이 대화에서 가장 최근 출력, 사용자가 지정한 파일이나 변경사항, 또는 사용자가 설명하는 접근 방식을 제안하세요. 리포트 모드에서는 중단하고 검토 대상이 주어지지 않았다고 말하세요.
3. 중요도(Criticality)를 설정하세요: 프로토타입, 내부 도구, 프로덕션, 또는 금전/보안 경로 중 하나입니다. 대화형 모드: 불분명하고 그것이 얼마나 강하게 밀어붙일지에 영향을 미친다면 한 번 물어보세요. 리포트 모드: 프로덕션으로 가정하고 그렇게 말하세요. 중요도는 카테고리 스윕의 깊이를 설정합니다. 심각도 기준(severity bar)을 움직이지 않습니다.
4. 원장(ledger)을 확인하세요. 원장 경로를 알아내세요(섹션 11 참조). 이 아티팩트에 대한 원장이 존재하면 references/ledger-format.md를 읽으세요.
   • 가장 최근 라운드의 어떤 ID에 대한 최신 행이 pending이면, 워크스루가 중단된 것입니다. 재개하세요: 섹션 1~5를 건너뛰고, 저장된 레코드를 읽고, 첫 번째 pending 우려사항부터 섹션 8을 계속하세요. 렌즈를 다시 실행하거나 순위를 다시 매기지 마세요. 리포트 모드는 대신 OPEN DECISIONS 아래에 나열합니다.
   • 그렇지 않으면 이후 라운드입니다. 섹션 11을 따르세요.

1. 먼저 최선의 주장을 펼치세요

어떤 우려사항보다도, 제안이 합리적인 이유(해결하는 문제와 존중하는 제약 조건)에 대해 두세 문장을 작성하세요. 이것을 작성할 수 없다면 제안을 아직 이해하지 못한 것입니다. 더 읽으세요.

2. 후보 우려사항 생성

해당 렌즈에 도달했을 때 렌즈의 참조 파일을 로드하세요. L12는 마지막에 실행하세요.

#	렌즈	사용	참조
L1	사후 실패 분석: 배송되어 중단이 발생했음; 역추적	항상	references/lens-questions.md
L2	목표 반전: 실패를 보장할 것을 나열하세요; 어떤 것이 존재하는지 확인	항상	references/lens-questions.md
L3	숨겨진 가정: 각각을 명명하세요; 그것이 거짓이면 어떻게 되는지 질문	항상	references/lens-questions.md
L4	일반적으로 놓치는 영역에 대한 카테고리 스윕	항상	references/category-checklist.md
L5	일반적인 AI 결함에 대한 AI 출력 스윕	항상, AI가 생성했을 때	references/ai-output-checklist.md
L6	주장을 구체화하세요: 모호한 단어를 확인 가능하게 만드세요	종류별	references/lens-questions-extended.md
L7	증거를 요청하세요: 측정, 읽음, 또는 가정?	종류별	references/lens-questions-extended.md
L8	다른 시각: 온콜, 보안, 신규 사용자, 헤비 유저, 공격자	종류별	references/lens-questions-extended.md
L9	두세 단계 앞서 따라가 보세요	항상	references/lens-questions-extended.md
L10	프레이밍에 의문을 제기하세요: 올바른 문제인가, 더 작은 변경이 가능한가?	항상	references/lens-questions-extended.md
L11	분리된 패스: 사실, 위험, 대안, 검토 품질	종류별	references/lens-questions-extended.md
L12	최악의 실패에서 근본적인 설계 선택으로 이어지는 원인 체인	종류별	references/lens-questions-extended.md

"종류별" 렌즈, 아티팩트 종류별:

아티팩트 종류	추가할 렌즈
작은 diff 또는 버그 수정	없음
기능 diff 또는 여러 단계 계획	L6, L7, L12
설계, RFC, 또는 옵션 간 결정	L6, L7, L8, L11, L12
다른 스킬 또는 에이전트의 출력	그것이 생성한 것에 대한 행 사용

우려사항이 의존하는 실제 코드, 구성 또는 계획 라인을 읽으세요. 코드에 대한 추측에 기반한 우려사항은 증거가 아닙니다.

3. 필터링

각 후보에 네 가지 테스트를 모두 적용하세요. 하나라도 실패하면 후보를 폐기하세요.

1. 결과: 아무도 그것에 대해 조치를 취하지 않으면 실제로 무슨 일이 발생합니까? "별거 아님"은 폐기하세요.
2. 반론: 그것이 실제 문제가 아닌 가장 강력한 이유(코드가 이미 다루고 있음, 이 변경 범위 밖에 있음, 또는 피해를 입히지 않음)를 작성하세요. 그 이유가 타당하면 폐기하세요. 우려사항이 살아남으면 반론을 유지하고 왜 실패하는지 명시하세요.
3. 실행 가능: 구체적인 실행이 있어야 합니다. 실행이 없으면 폐기하세요.
4. 중복 아님: 이 대화의 다른 검토 단계, 호출자의 브리핑, 또는 원장에서 이미 보고된 것은 폐기하세요.

4. 심각도 평가

기준은 고정되어 있습니다. 모드, 중요도, 라운드, 시간 압박이 그것을 움직이지 않습니다.

• Critical: 하나의 구체적인 실패 이벤트를 명시하세요: 트리거, 실패 방식, 피해 확산 범위. 트리거는 제안에 작성된 대로 도달 가능해야 합니다. 도달 가능한 트리거를 명명할 수 없으면 우려사항은 기껏해야 High입니다. references/severity-downgrade-example.md를 참조하세요.
• High: 그것이 해를 끼치는 명명된 현실적인 시나리오.
• Medium: 고칠 가치가 있음. 실패 이벤트가 필요하지 않습니다.

각 우려사항을 blocking(작업이 진행되기 전에 수정되어야 함) 또는 watch-item(추적하되, 이를 위해 작업을 보류하지 마세요)으로 표시하세요.

5. 예산

• 모든 Critical과 모든 High를 전체로 보고하세요.
• 상위 3개의 Medium을 전체로 보고하세요. 다른 Medium은 한 줄로 나열하세요: 개수, 그런 다음 각각에 대한 짧은 레이블. Medium을 조용히 폐기하지 마세요.
• Critical + High가 5개를 초과하면 상세 검토를 중단하세요. 판결은 RETHINK이며, 제안을 더 작은 부분으로 분할할 것을 권장합니다. Critical과 High 제목만 나열하세요.

6. 우려사항 기록

보고된 모든 우려사항은 다음 필드를 모두 가집니다:

### H1: <한 줄 제목>
- 심각도: High | 실패 이벤트: <트리거> -> <실패 방식> -> <피해 범위>
- 렌즈: L3 숨겨진 가정
- 반론: <우려사항에 반대하는 가장 강력한 주장>. 실패 이유: <이유>.
- 증거: <파일:라인 | 계획 단계 | 인용된 결정>
- 무시할 경우: <발생하는 일>
- 실행: <구체적인 변경>
- 상태: blocking | watch-item

ID는 심각도 문자와 숫자를 사용합니다: C1, H1, M1. ID는 어떤 라운드에서도 절대 변경되지 않습니다. Medium 기록은 실패 이벤트: 해당 없음이라고 쓸 수 있습니다.

7. 판결

모든 검토를 정확히 하나의 판결로 끝내세요:

• PROCEED: blocking 우려사항 없음. 참고 사항이 뒤따를 수 있음.
• AMEND: 접근 방식은 타당함; 나열된 blocking 우려사항을 먼저 수정하세요.
• RETHINK: 근본적인 결함, 또는 섹션 5의 예산 초과.

판결 아래에 알려진 위험(Known risks) 제목을 추가하세요. 최신 원장 행이 risk-accepted인 모든 우려사항을 어떤 라운드에서든 ID, 제목 및 라운드와 함께 나열하세요. 없으면 "알려진 위험: 없음"이라고 쓰세요. 그것들은 절대 blocking하지 않습니다.

8. 대화형 모드

1. 최선의 경우를 보여주세요(섹션 1).
2. 첫 번째 질문 전에, 워크스루할 우려사항당 하나의 pending 원장 행과 함께 우려사항 기록을 작성하세요(원장 참조 참조).
3. 턴당 하나의 우려사항, 가장 심각한 것부터 제기하세요. 사용자는 accept, reject, modify, risk-accept 또는 defer 중에서 선택합니다.
   • 구조화된 질문 도구가 있으면(Claude Code의 AskUserQuestion, OpenCode의 question), 사용하세요. 질문당 하나의 우려사항, 기록 전체를 질문 텍스트에 포함시켜 화면에 유지되도록 합니다. 도구가 옵션을 제한하면 accept, reject, risk-accept, defer를 제공하고 modify는 자유 텍스트로 받습니다.
   • Modify: 사용자의 변경을 수용한 다음, 새로운 형태의 우려사항을 수락된 것으로 처리합니다. Reject: 우려사항이 적용되지 않음. Risk-accept: 우려사항은 실제지만 사용자가 감수하며 현재 아무도 수정하지 않음; blocking 아님. Defer: 나중에 수정할 watch-item.
   • 각 답변 직후에 원장 행을 추가하세요, 다음 질문 전에. 판결을 기다리지 마세요.
4. 모든 우려사항이 해결되면, 2라운드 이상에서 재확인(섹션 11)을 실행하세요. 그런 다음 판결과 알려진 위험을 제시하세요(섹션 7).
5. 적어도 하나의 우려사항이 수락되거나 수정되었으면, 판결에 관계없이 수정된 계획(섹션 10)을 작성하세요.
6. 판결 라인을 원장에 추가하세요. 중단하고 명시적인 진행 허가를 기다리세요.

9. 리포트 모드

질문 없음. 대기 없음. 다음 순서로 출력:

1. 중요도 가정(만약 가정된 경우).
2. 최선의 경우.
3. 모든 우려사항 기록, 심각도별로 정렬, 예산 내.
4. 판결, 원장의 알려진 위험 포함.
5. OPEN DECISIONS: 번호가 매겨진 목록. 각 항목을 사람이 대답할 수 있는 결정으로 표현하고, 그 다음 권장 옵션과 그 절충안을 제시하세요: 1. <질문> (C1 관련) 권장: <옵션>. 절충: <비용 또는 위험>.

호출자가 파일 경로를 제공하면 전체 보고서를 거기에 작성하세요. 200단어 이하의 요약만 반환하세요: 판결, 심각도별 개수, OPEN DECISIONS 제목. 해결 상태가 open인 기록과 행을 추가하세요(원장 참조 참조). 그런 다음 중단하세요. 리포트 모드는 계획을 수정하지 않습니다.

10. 수정된 계획

대화형 모드 전용, 모든 우려사항이 해결된 후에. 적어도 하나의 우려사항이 수락되거나 수정되었으면 판결에 관계없이 작성하세요. PROCEED이고 수락되거나 수정된 것이 없으면 건너뛰세요.

1. 수락된 변경 사항이 통합된 전체 계획을 다시 설명하세요. 단순히 해결 사항을 나열하지 마세요.

2. 통합 테이블을 추가하세요. 일치하는 줄이 없는 수락되거나 수정된 우려사항을 MISSING으로 표시하고, 테이블 위에 그렇게 명시하세요.

   우려사항	해결	이를 다루는 계획 라인
   C1	수락됨	3단계: idempotency 키 추가
   H2	수정됨	MISSING

3. 중단하세요. 명시적인 진행 허가를 기다리세요. 이 스킬은 절대 구현하지 않습니다.

11. 라운드 및 종료

• 원장 경로: ${XDG_STATE_HOME:-~/.local/state}/adversarial-review/<slug>.md. 첫 번째 쓰기 전에 references/ledger-format.md에서 slug 및 행 형식을 읽으세요.
• 원장은 추가 전용입니다. 이전 행을 편집하거나 삭제하지 마세요.
• 우려사항은 해당 해결 아티팩트(커밋 SHA 또는 계획 라인)가 존재하고 이후 변경 사항이 그것을 건드리지 않은 경우에만 해결됩니다.
• 각 이후 라운드를 헤더 라인으로 시작하세요: 라운드 N | 이월된 미해결: C2, H1 | 새로 발견된 지난 라운드: 1 Critical, 2 High
• 2라운드 이상에서는 마지막 라운드 이후 변경된 사항과 그 변경이 영향을 미칠 수 있는 사항만 검토하세요. 거기서 새로운 Critical 또는 High는 변경된 자료에서 실제로 발동할 새로운 동작이어야 합니다.
• 변경 사항이 우려사항을 해결한 것을 건드리지 않았거나 재확인에서 악화되었음을 발견하지 않는 한, 원장에 있는 우려사항을 다시 제기하지 마세요.
• 라운드 종료 재확인(2라운드 이상). 판결 전에, 최신 행이 deferred, risk-accepted, pending 또는 open인 모든 우려사항을 현재 아티팩트 및 코드에 대해 확인하세요. 각각 하나의 행을 추가하세요: 여전히 적용됨, 더 이상 적용되지 않음(이유 포함), 또는 악화됨(심각도 상승 및 이유 설명). 악화된 우려사항은 새로운 결정이 필요합니다: 워크스루(대화형) 또는 OPEN DECISIONS 아래에 나열(리포트). 이전 행은 절대 변경하지 마세요.

종료 규칙(엄격)

이 규칙은 이 스킬의 다른 모든 것을 재정의합니다.

1. 새로운 Critical 또는 High를 추가하지 않는 이후 라운드는 루프를 종료합니다. 판결은 PROCEED. 열린 Medium은 watch-item이 됩니다. 아직 열려 있는 이월된 Critical 또는 High는 새로운 것이 아니지만 여전히 blocking합니다: 이 라운드에서 해결(대화형)하거나 판결 전에 OPEN DECISIONS 아래에 나열(리포트)하세요.
2. 3라운드에서도 여전히 새로운 Critical이 발견되면, 코드가 아닌 작업 분할 방식에 도전하세요. 다른 분할을 권장합니다.
3. 4라운드를 초과하여 실행하지 마세요. 4라운드 후에는 남은 모든 blocker를 번호가 매겨진 결정 목록으로 사용자에게 전달하고 중단하세요.

12. 어조

• 직접적이고 구체적으로. "이것은 ...할 때 실패합니다"라고 쓰고 "이것은 잠재적으로 문제를 일으킬 수 있습니다"라고 쓰지 마세요. 가장 중요한 우려사항으로 시작하세요.
• 모든 우려사항에 렌즈 이름을 명시하여 독자가 방법을 배울 수 있게 하세요.
• 제안이 좋다면 솔직하게 말하고 PROCEED를 주세요.
• 철저해 보이기 위해 우려사항을 만들어 내지 마세요. 모든 우려사항은 파일, 라인 또는 계획 단계를 명명합니다. 장소가 없는 일반적인 위험은 폐기됩니다.
• 검토 중인 코드를 다시 작성하지 마세요. 변경 사항을 설명하세요; 글쓰기는 그것에 대해 행동할 사람에게 맡기세요.