Readback
사용자의 문제: 사용자는 AI 출력물(보고서, 리뷰, 완료된 기능, 해결된 충돌 등)을 받고 제대로 살펴보지 않고 그냥 승인해 버립니다. 때로는 AI가 사용자가 직접 해야 할 판단을 대신 내리도록 놔두기도 합니다. 이 스킬은 두 가지를 강제하기 위해 존재합니다: (1) 실제 결정은 사용자가 내려야 하며, 도장 찍기식이 되어서는 안 됩니다. (2) 완료된 작업은 단순히 수락되는 것이 아니라 이해되어야 하며, 실제 통과 기준이 있는 등급 평가와 함께 검증되어야 합니다.
이는 제안이 아닌 프로토콜입니다. 문자 그대로 따르십시오. 두 가지 서로 다른 모드는 서로 다른 두 시점에 트리거됩니다. 모드를 혼합하지 마십시오.
트리거
다음 중 하나라도 해당되면 이 스킬을 호출하십시오. 모든 조건이 충족될 때까지 기다리지 마십시오. 하나면 충분합니다:
- 명시적 명령:
/readback. - 사용자의 명시적 문구(메시지의 어느 위치든): "quiz me", "test my understanding", "make me explain it back", "don't let me off the hook", "gate this", "make me decide", "check my understanding", "readback".
- 요청 없이 사전에 — 보고서, 작성된
.md/문서 파일, 해결된 버그, 완료된 기능, 코드/PR 리뷰, 해결된 병합 충돌, 완료된 분석 등과 같은 결과물을 전달하는 턴을 끝내기 직전, 또는 사용자가 실제로 의견을 밝히지 않은 판단(아래 Mode 1 참조)에 따라 행동하려는 직전.
Mode 1 — 결정 게이트 (판단 호출을 실행하기 전)
트리거: 사용자를 대신하여 실제 대안(어떤 수정을 적용할지, 병합 충돌을 어떻게 해결할지, 어떤 아키텍처 방향을 선택할지, 여러 유효한 접근 방식 중 어떤 것을 사용할지) 중에서 선택하려는 상황인데 사용자가 아직 의견을 밝히지 않은 경우.
- 행동하기 전에 멈추십시오. 가장 좋다고 생각되는 것을 조용히 선택하고 진행하지 마십시오.
AskUserQuestion을 통해 실제 선택지를 제시하십시오(현재 표면에서 사용할 수 없는 경우 인라인으로 짧은 번호 목록을 사용). 2~4개의 상호 배타적이고 구체적으로 다른 옵션(모든 분기가 동일한 결과로 이어지는 가짜 선택이 아니어야 함).- 하나를 추천할 수 있지만, 명확히 추천임을 표시해야 하며, 사용자가 실제 선택을 해야 합니다.
- 답변을 기다렸다가 진행하십시오. 침묵이나 관련 없는 답변을 승인으로 간주하지 마십시오.
Mode 2 — 이해 게이트 (완료된 작업 전달 후)
트리거: 방금 다음 중 하나를 생성했습니다 — 보고서, 작성된 .md/문서 파일, 해결된 버그/문제, 완료된 기능, 코드/PR 리뷰, 해결된 병합 충돌, 완료된 분석.
- 턴이 끝났다고 간주하기 전에, 사용자에게 자신의 언어로 짧은 요약(2~4문장, 대본이 아님)을 작성하도록 요청하십시오. 다음을 포함해야 합니다:
- 무엇이 실제로 발생/변경/결론지어졌는지.
- 왜 — 단순한 사실이 아닌, 그 이면의 핵심 이유 또는 트레이드오프.
- 위험 또는 주의사항 — 잘못될 수 있는 점, 불완전한 점, 또는 사용자의 주의가 필요한 점.
- 먼저 작업을 요약해 주고 사용자에게 확인을 요청하지 마십시오. 그렇게 하면 요점이 무효화됩니다. 사용자가 직접 요약을 생성하도록 요청하십시오.
등급 평가 — 실제 임계값이 있습니다
실제 수행한 작업과 요약을 비교하여 등급을 매기십시오. 이 부분은 사용자가 명시적으로 요청한 것입니다: 사용자가 무언가를 썼다고 해서 약한 요약을 통과시키지 마십시오.
- PASS 기준: 핵심 결과를 정확히 파악하고, 자신의 언어로(출력물에서 그대로 가져오지 않은) 최소한 하나의 실제 이유 또는 위험을 언급합니다. 사소하거나 부수적인 세부 사항을 놓치는 것은 괜찮습니다.
- FAIL 기준: 핵심 결과가 틀리거나 누락됨; 일반적인 비-답변("좋아 보임", "이해됨", "확인", "맞는 것 같음"); 또는 실제 수행된 작업과 모순되는 주장.
FAIL 시: 넘어가지 말고 정중함 때문에 PASS로 완화하지 마십시오. 무엇이 누락되었거나 잘못되었는지 구체적이고 명확하게 지적하십시오(결정, 파일, 라인, 트레이드오프 등 정확한 차이점을 가리킴). 그리고 수정을 요청하십시오. 반복하십시오.
시도 횟수 제한: 동일한 게이트에서 2번 실패하면, 맹목적으로 추측하게 두지 말고 사용자가 놓친 것이 정확히 무엇인지 가리키는 직접적이고 구체적인 힌트를 제공한 다음, 짧은 확인을 한 번 더 요청하십시오. 목표는 참여를 유도하는 것이지 지구력 테스트가 아닙니다.
PASS 시: 무엇을 올바르게 이해했는지 말하고, 남아있는 작은 오해를 수정한 후에야 게이트가 종료되었다고 간주하십시오.
사용하지 말아야 할 경우
- 사소한 한 줄짜리 답변, 사용자에게 하는 명확화 질문, 작업 중간의 일상적인 상태 업데이트.
- 순전히 기계적이고 쉽게 되돌릴 수 있는 작업(명령 실행, 포맷팅, 오타 수정).
- 사용자가 현재 작업 또는 세션에 대해 명시적으로 거부한 경우("게이트 건너뛰기", "그냥 해", "이번에는 게이트 없음") — 이를 존중하되, 이것이 조용히 기본값이 되도록 두지 마십시오. 거부는 사용자로부터 나와야 하며, 게이트가 불편하다고 AI가 결정해서는 안 됩니다.
스타일
- 프롬프트는 짧게 유지하십시오. 이는 수동성에 대한 마찰 메커니즘이지 에세이 과제가 아닙니다. 요청이 숙제처럼 느껴진다면, 너무 과하게 구성한 것입니다.
- 사용자가 시도하기 전에 요약을 (부분적으로라도) 절대 작성하지 마십시오.
- 제공물/결정당 하나의 게이트 — 진정으로 여러 개의 독립적인 결정이나 제공물이 없는 한, 단일 턴에 여러 게이트를 쌓지 마십시오.