@tienne/gestalt 0.74.0 → 0.75.0

package/plugin/role-agents/_shared/references/ai-tell-quick-rules.md

@@ -6,6 +6,8 @@
 
 **Do-NOT (탐지·윤문 모두 제외):** 고유명사, 제품명, 모델명, 기관명, 수치, 날짜, 단위, 큰따옴표 안 직접 인용, 법률 조문, 수학, 화학, 통계 표기, 영어 약어(LLM·GPU·MCP·API 등 업계 표준).
 
+**이 목록은 사람과 모델이 판단하는 자리의 기준이다.** 자동 스캔(`humanize-scan`)이 형태로 걷어내는 건 인라인 백틱과 언어 태그가 붙은 코드펜스, 그리고 `chat` 기준의 `>` 블록인용 셋뿐이다. 큰따옴표는 한국어에서 인용만이 아니라 강조로도 쓰여 형태로는 못 가른다 — 스캔이 큰따옴표 안을 걸었으면 사람이 이 목록을 보고 판단한다. 원문을 가리키는 자리는 백틱으로 감싸면 스캔에서도 빠진다.
+
 **약어 면제는 업계 표준에만 준다:** 풀어 썼을 때 안 굳어진 음차가 되는 약어는 면제 대상이 아니다. `SSOT`나 `SoT`를 그대로 두면 "소스 오브 트루스"를 약어로 우회한 것과 같다 — B-3로 우리말로 푼다. 무엇을 가리키느냐에 따라 말이 달라지므로 대체어 표는 [style-guide.md의 single source of truth를 뭐라고 쓸까](style-guide.md#single-source-of-truth를-뭐라고-쓸까)에 둔다. LLM, API처럼 풀어 쓸 일이 없는 표준 약어만 그대로 둔다.
 
 **굳어진 음차 화이트리스트 (B-3 제외 — 그대로 둔다):** 컴포넌트·토큰·커밋·인터페이스·메서드·빌드·디플로이·캐시·렌더링·콜백·프레임워크·라이브러리·리팩터링·마이그레이션·아이콘·레이아웃·그리드·모달·토스트·타이포그래피·플레이스홀더·프로젝트·스프린트·이슈·리뷰·머지·브랜치·사이드 이펙트·보일러플레이트·트레이드오프·딥다이브·얼라인·온보딩·소스·롤백·파싱·레지스트리·불릿·널 포인터·데드락 등 업계 정착어. 이 목록 밖의 안 굳어진 음차(소스 오브 트루스·룩 앤 필·로우 행잉 프룻 등)만 B-3로 교정한다.
@@ -18,7 +20,7 @@
 
 **한자어를 피하는 게 목적이 아니다 (F-4·F-5 오적용 주의):** 겨냥하는 건 개념을 뭉친 **명사화**(-성/-적/-화)이지 한자어 동사가 아니다. "측정하다"를 "재다"로, "판단하다"를 "따지다"로 바꾸면 정확도만 잃는다. 그 자리의 정확한 말이 한자어면 한자어를 쓴다. 반대 방향 실수도 같다 — 한자어를 피하려고 비유 명사(축·증류)나 물리 동사(재다)로 도망가면 F-7에 걸린다. 셋 다 겪은 실례: `네 축을 따로 재고 판정한다` → `4가지 측면에서 각각 측정하고 판단한다`.
 
-**은유를 다 지우라는 게 아니다 (F-9 오적용 주의):** 겨냥하는 건 결함이나 코드 상태를 부르려고 그 자리에서 지어낸 별칭이다. "널 포인터"를 "널 값을 가리키는 포인터"로, "데드락"을 "서로 기다리다 멈춘 상태"로 풀어 쓰면 길이만 늘고 무엇을 말하는지는 오히려 흐려진다. **가르는 기준은 남이 정의해 둔 이름을 그 뜻 그대로 쓰느냐 하나뿐이다.** 명세나 교과서에 뜻이 박혀 있으면 가리킬 데가 있으니 그대로 둔다. 팀에서 몇 번 쓰였다는 것으로는 예외가 되지 않는다 — 아래 [측정 근거](#측정-근거) 문단과 B-4가 "팀에서 굳은 말"을 지키는 것과는 다른 자리다. B-4는 팀이 쓰기 시작하면 예외로 인정하는데 F-9는 그걸 예외로 안 본다. B-4가 막는 건 어색함이라 팀이 받아쓰면 풀리고 F-9가 막는 건 굳는 것 자체라 팀이 받아쓰면 그게 피해다.
+**은유를 다 지우라는 게 아니다 (F-9 오적용 주의):** 겨냥하는 건 결함이나 코드 상태, 그 결함의 원인 관계를 뭉개 부른 말이다. 그 자리에서 지어낸 별칭이든 이미 있는 비유든 같다. "널 포인터"를 "널 값을 가리키는 포인터"로, "데드락"을 "서로 기다리다 멈춘 상태"로 풀어 쓰면 길이만 늘고 무엇을 말하는지는 오히려 흐려진다. **가르는 기준은 그 자리에서 무엇을 가리키는지가 말에 남아 있느냐 하나뿐이다.** 남이 정의해 둔 이름을 그 뜻 그대로 쓰면 그 기준을 통과한다. 그게 대표 사례다. 자료구조가 그 이름으로 부르는 자리도 같다 — 트리와 스레드의 root를 "뿌리"라 부르면 구조를 가리키므로 그대로 둔다. **사전에 비유 뜻풀이가 실렸다는 것만으로는 정의해 둔 이름이 아니다** — "뿌리가 하나다"는 사전에 근본 뜻이 실려도 무엇이 같은지가 안 남는다. 명세나 교과서에 뜻이 박혀 있으면 가리킬 데가 있으니 그대로 둔다. 팀에서 몇 번 쓰였다는 것으로는 예외가 되지 않는다 — 아래 [측정 근거](#측정-근거) 문단과 B-4가 "팀에서 굳은 말"을 지키는 것과는 다른 자리다. B-4는 팀이 쓰기 시작하면 예외로 인정하는데 F-9는 그걸 예외로 안 본다. B-4가 막는 건 어색함이라 팀이 받아쓰면 풀리고 F-9가 막는 건 굳는 것 자체라 팀이 받아쓰면 그게 피해다.
 
 **근거가 붙은 룰 (→ 아래 [측정 근거](#측정-근거)):** A-2, I-1, C-8은 대조 코퍼스 측정으로 심각도를 조정했고 B-4는 팀이 실제로 쓰는 말이라 예시에서 뺐다. 원어민이 오히려 더 쓰는 표현이나 팀에서 이미 굳은 말을 지우면 사람 글을 AI 글로 만든다.
 
@@ -51,9 +53,9 @@
 |---|---|---|---|
 | B-1 | 한글 + 괄호 영어 매번 ("~(Sovereign AI)" 처럼) | S2 | 첫 등장만 병기, 이후 한글만 |
 | B-2 | 영어 어휘 직역 가능한데 그대로 | S2 | 한국어로 옮기되 업계 표준은 유지 |
-| B-3 | 안 굳어진 영어 구·단어 음차 표기 ("소스 오브 트루스"), 그 음차를 약어로 우회한 표기(`SSOT`·`SoT`) | S1 | 한글 의역 + 첫 등장만 원어 괄호 병기("기준 문서(source of truth)", "단일 기준점(source of truth)" 등), 이후 한글만. 단 위 "굳어진 음차 화이트리스트"에 있는 정착어는 Do-NOT — of/and 등 기능어까지 통째 음차한 구(룩 앤 필·로우 행잉 프룻)가 최우선 대상. 무엇을 가리키는지 보고 고르는 표는 [style-guide.md의 single source of truth를 뭐라고 쓸까](style-guide.md#single-source-of-truth를-뭐라고-쓸까)를 따른다 |
+| B-3 | 안 굳어진 영어 구·단어 음차 표기 ("소스 오브 트루스"), 그 음차를 약어로 우회한 표기(`SSOT`·`SoT`), 같은 구를 낱말 단위로 옮긴 직역형("은탄환", "낮은 가지 열매") | S1 | 한글 의역 + 첫 등장만 원어 괄호 병기("기준 문서(source of truth)", "단일 기준점(source of truth)" 등), 이후 한글만. 단 위 "굳어진 음차 화이트리스트"에 있는 정착어는 Do-NOT — of/and 등 기능어까지 통째 음차한 구(룩 앤 필·로우 행잉 프룻)가 최우선 대상. 무엇을 가리키는지 보고 고르는 표는 [style-guide.md의 single source of truth를 뭐라고 쓸까](style-guide.md#single-source-of-truth를-뭐라고-쓸까)를 따른다. **음차를 직역으로 옮기지 않는다** — "로우 행잉 프룻"은 "낮은 가지 열매"가 아니라 "금방 되는 일"이다. "실버 불릿"도 같은 자리에서 "만능 해법"을 가리킨다. 직역한 비유는 음차보다 읽기 어렵다. **화이트리스트는 등재된 형태 그대로만 통과한다** — "사이드 이펙트"와 "널 포인터"는 구째로 올라 있어 구째로 빠지고, 낱말로 오른 "불릿"은 낱말만 빠지므로 "실버 불릿"은 이 룰이 본다. **구를 통째로 옮긴 직역형은 B-3 하나로 판정한다** — B-5는 낱말 하나를 옮긴 자리(materialize → 물질화)만 본다 |
 | B-4 | 영어 개념을 어색하게 옮긴 조어("생산처" ← producer, "응답처") | S2 | 억지 신조어 대신 이미 쓰이는 말로. 코드 맥락이면 "호출부"·"사용처". **팀에서 이미 굳은 조어는 예외** — "소비처"는 팀 지라 티켓에서 라이브러리를 가져다 쓰는 쪽을 가리키는 말로 정착했으므로 교정 대상이 아니다 (→ 아래 [측정 근거](#측정-근거)) |
-| B-5 | 영어 개념어나 다의어 동사를 한국어 한 단어로 몰아 옮겨 레지스터가 어긋난 말 (materialize → "물질화", semantics → "의미론", close → "닫다") | S1 | 그 자리에서 실제로 무슨 일이 벌어지는지를 동사로 쓴다. 아래 [B-5 대체어](#b-5-대체어) 표 참조. 음차로 도망가지 않는다 — "머티리얼라이즈"로 바꾸면 B-3에 걸린다 |
+| B-5 | 영어 개념어나 다의어 동사를 한국어 한 단어로 몰아 옮겨 레지스터가 어긋난 말 (materialize → "물질화", semantics → "의미론", close → "닫다", mutant → "돌연변이", branch → "갈래") | S1 | 그 자리에서 실제로 무슨 일이 벌어지는지를 동사로 쓴다. 아래 [B-5 대체어](#b-5-대체어) 표 참조. 음차로 도망가지 않는다 — "머티리얼라이즈"로 바꾸면 B-3에 걸린다. **한국어 정착어가 없는 기술 용어는 옮기지 말고 원어를 그대로 쓴다** (`mutant`, `null`, `race condition`) |
 
 ### B-5 대체어
 
@@ -71,9 +73,20 @@
 | close (an issue, PR, thread) | 이슈를 닫는다 | 이슈를 종료한다 / 스레드를 종료한다 |
 | close (a connection, a repo) | 저장소를 닫는다 | 저장소 연결을 끊는다 |
 | leak (자주 나온다는 뜻으로) | 자주 새는 룰 | 자주 걸리는 룰 / 반복해서 틀리는 자리 |
+| mutant (mutation testing) | 돌연변이, 뮤턴트, 뮤테이션 | `mutant`, `mutation` 원어 그대로 |
+| kill (a mutant) | 죽임 | 제거한다 / 지운다 |
+| branch (of code) | 갈래 | 분기 |
 
 "의미론적 검색"처럼 형용사로 굳은 자리(`의미론적`)는 대상이 아니다. 명사로 홀로 서서 시스템의 동작 규칙을 가리킬 때만 걸린다.
 
+**한국어 정착어가 없으면 원어로 둔다.** `mutant`가 그 자리다. 뜻으로 옮기면 생물학 어휘가 되고 음차로 옮기면 B-3에 걸린다("뮤턴트"). 둘 다 피하는 길은 영어 표기를 그대로 쓰는 것뿐이다 — `null`이나 `race condition`을 안 옮기는 것과 같다. **원어로 두는 건 그 개념을 부르는 명사에만 준다.** 딸려 오는 동사는 한국어로 쓴다 — mutant를 kill 했다는 말은 "죽였다"가 아니라 "제거했다"다.
+
+**"갈래"는 code branch를 옮긴 자리를 겨냥한다.** `if`나 `catch`, `default` 같은 코드 분기를 순우리말로 옮긴 자리가 그것이다. 실무에서 그 자리는 "분기"라고 부른다. "갈래"로 쓰면 읽는 사람이 한 번 더 번역해야 한다.
+
+**탐지기는 앞말로 못 가르므로 거의 전부 건다** — "두 갈래"가 코드 분기와 분류 양쪽에 다 나오기 때문이다. 형태로 빠지는 건 분류 뜻이 확실한 연어뿐이다(`갈래로 갈리다`, `갈래로 흩어지다`, `갈래별`).
+
+**걸린 자리는 분류 뜻이라도 고친다.** 종류를 뜻하면 "종류"나 "쪽"이 그 자리의 말이고, 묶음을 뜻하면 "묶음"이다. 베이스라인을 올려 덮지 않는다 — 그렇게 두면 같은 문서에서 코드 분기 뜻이 새로 들어와도 눈금이 이미 올라가 있어 안 걸린다. 예시로 인용해야 하는 자리는 백틱으로 감싼다.
+
 **한 동사에 여러 뜻을 몰지 않는다.** `close`는 한국어에서 자리마다 다른 동사로 갈린다 — 코멘트나 발표는 끝내고 이슈나 스레드는 종료하고 연결은 끊는다. 이걸 "닫다" 하나로 몰면 그 자리마다 조금씩 어긋난다. 코드 안의 `close()` 호출 그 자체를 가리킬 때만 "닫는다"를 둔다. 산문으로 동작을 설명하는 자리는 무엇을 어떻게 하는지 적는다 — "저장소 연결을 끊는다"처럼. 글이나 말을 "닫는다"고 쓰지 않는다. "맺는다"는 원래 한국어 연어라 그대로 쓸 수 있다. 다만 발표나 코멘트를 두고는 "끝낸다"가 더 흔하다. 자리마다 맞는 동사를 고른다. **상태를 가리키는 "닫힌 PR"은 대상이 아니다** — `CLOSED` 상태값을 옮긴 말이라 동사 교정과 결이 다르다.
 
 **"새다"는 누출일 때만 쓴다.** 금지어가 산출물에 흘러나가는 자리에는 맞다. 검사를 빠져나가는 자리("어디까지 새는지")나 자주 나온다는 뜻("자주 새는 룰")에는 안 맞는다. 앞은 "놓친다", "빠져나간다"이고 뒤는 "자주 걸린다", "반복해서 틀린다"다.
@@ -126,8 +139,8 @@
 | F-6 | 복합명사 압축 — 명사구를 조사·동사 없이 이어붙여 개념을 뭉침 ("시안 정합 버그픽스", "유지보수성 개선 작업", "권한 체크 로직") | S2 / **대화·리뷰 S1** | 동사·조사로 풀어 서술 ("디자인 시안과 다르게 렌더링되던 문제", "나중에 유지보수하기 편하게"). 사람은 압축 명사구 대신 무엇을 왜 했는지 풀어 말한다 |
 | F-7 | 기술·이공계 비유 명사를 일상 대화에 그대로 (증류·배선·결정화·평탄화·오케스트레이션·파이프라인화·축 등, 화학·전기·수학 어휘의 비유 차용) | S2 / **대화·리뷰 S1** | 일상 동사·명사로 환원 (증류 → "추려내다/뽑아내다", 배선 → "연결하다/걸어두다", 결정화 → "정리하다", 평탄화 → "밋밋하게 만들다", **축 → "측면"**·"기준"). 문법은 멀쩡해 룰 매칭이 안 되지만 사람은 대화에서 안 쓴다. "네 축을 잰다"가 아니라 "4가지 측면에서 측정한다". **예외는 그 프로젝트가 개념에 붙인 이름일 때만이고, 그 개념을 다루는 자리에서만이다** — 게슈탈트의 "스펙 결정화"는 `similarity-crystallizer` 에이전트 이름이자 인터뷰→Spec 변환의 정의라서 두지만, 같은 말을 지라 티켓 작성처럼 무관한 자리에 끌어다 쓰면 F-7이다. 코드의 "파이프라인" 자체, 그래프의 x축도 같은 기준. 테스트를 자물쇠에 빗댄 "잠그다"는 방향이 반대라 F-10이 본다 |
 | F-8 | 추상명사에 물리 측량 동사("근거를 재봤는데", "판단을 재보고 있다", "근거를 재본 결과", "의견을 달아봤는데") | S2 / **대화·리뷰 S1** | 저울에 올린 게 아니라 검토한 것이다. 사람이 하는 행위 동사로 되돌린다("근거를 확인해봤는데", "의견을 검토해봤는데"). F-7 물리 동사 도피의 사촌이라 목적어가 근거, 의견, 판단, 영향, 의미, 가치, 리스크인 자리만 본다 — "온도를 재봤는데"는 대상이 아니다 |
-| F-9 | 결함·코드 상태를 그 자리에서 지어낸 별칭으로 명명 ("맨몸 호출", "벌거벗은 API") | S2 / **대화·리뷰 S1** | 무엇이 빠졌고 무엇이 틀렸는지 그대로 쓴다 ("맨몸 호출" → "접두 객체 없이 함수 이름만 적혀 있다"). 별칭은 검색이 안 되고 처음 읽는 사람이 못 알아보고 답글에서 재생산돼 팀 어휘로 굳는다. **예외는 남이 정의해 둔 이름을 그 뜻 그대로 쓸 때다** — "널 포인터", "데드락", "고아 노드"처럼 명세나 교과서에 뜻이 박힌 말이고 F-6으로도 안 넘긴다. 다른 결함에 비유로 얹으면 예외가 아니고 팀에서 몇 번 쓰였다는 것도 아니다 — 그렇게 열면 답글에 한 번 재생산된 별칭이 곧바로 빠져나간다. **F-7과 방향이 반대다** — F-7은 기술 비유를 일상 말로 되돌리고 F-9는 일상 비유를 기술 대상에 씌운 쪽을 본다. F-9에 걸린 별칭이 스스로 움직이면 D-5, 조사 없이 뭉치면 F-6도 함께 걸린다. 이 경계는 뜻이라 탐지기가 없다 |
-| F-10 | 일상 관용구의 물리 동작 동사를 코드나 문서 대상에 씌움 ("타입을 못 박다", "규칙을 못박는다", "테스트로 잠갔다") | S2 / **대화·리뷰 S1** | 그 자리에서 실제로 무엇이 되는지를 동사로 쓴다 ("타입을 선언한다", "규칙을 정한다", "관련 테스트가 있다"). 관용구는 원래 사람 사이 합의에 걸리는 말이라 목적어가 타입이나 규칙이 되면 누구에게 못을 박는다는 건지 가리킬 데가 없다. **가르는 것은 누가 정하는 자리냐다.** 문서나 코드가 스스로 정하면 대상이고("이 지시를 1번으로 못박는다", "타입을 못 박다"), 사람들이 협의해 정하면 예외다("팀이 일정을 못 박았다"). 한국어는 주어를 자주 생략하므로 **주어가 드러나면 그걸 보고, 없으면 목적어로 본다** — 타입, 값, 규칙, 지시, 기준은 문서나 코드가 정하는 쪽이고 일정과 조건처럼 사람들이 서로 약속하는 대상은 협의하는 쪽이다. 같은 "범위"라도 문서가 제 적용 범위를 정하는 자리는 대상이고 팀이 일의 범위를 합의하는 자리는 예외다. **나머지 예외는 셋이다.** 목적어가 리터럴 값이라 하드코딩을 뜻하는 "박아두다"("이 값 그냥 박아두죠"), 명사로 굳은 "잠금", 자물쇠나 문처럼 실제 물체를 잠그는 자리("문을 잠갔다"). **탐지기는 "못 박" 어간과 자물쇠 활용형을 전부 건다** — 주어가 사람인지 문서인지 못 가르므로 걸린 자리는 사람이 위 축으로 다시 본다 (I-5와 같은 방식이다). 형태로 빠지는 예외는 앞에 "못"이 없는 "박아두다"와 명사 "잠금"뿐이다. **F-7과 방향이 반대다** — F-7은 기술 비유를 일상 말로 되돌리고 F-10은 일상 비유를 코드 대상에 씌운 쪽을 본다. **F-9와는 품사로 갈린다** — F-9는 결함에 새 이름을 붙인 명사 쪽이고 F-10은 행위를 부르는 동사 쪽이다. **F-8과는 안 겹친다** — F-8은 물리 "측량" 동사만 보므로 "판단을 못 박았다"도 F-10 하나로 판정한다 |
+| F-9 | 결함이나 코드 상태, 그 결함의 원인 관계를 비유 명사로 뭉개 부름 ("맨몸 호출", "벌거벗은 API", "뿌리가 하나다") | S2 / **대화·리뷰 S1** | 무엇이 빠졌고 무엇이 틀렸는지 그대로 쓴다 ("맨몸 호출" → "접두 객체 없이 함수 이름만 적혀 있다"). 별칭은 검색이 안 되고 처음 읽는 사람이 못 알아보고 답글에서 재생산돼 팀 어휘로 굳는다. **예외는 남이 정의해 둔 이름을 그 뜻 그대로 쓸 때다** — "널 포인터", "데드락", "고아 노드"처럼 명세나 교과서에 뜻이 박힌 말이고 F-6으로도 안 넘긴다. 다른 결함에 비유로 얹으면 예외가 아니고 팀에서 몇 번 쓰였다는 것도 아니다 — 그렇게 열면 답글에 한 번 재생산된 별칭이 곧바로 빠져나간다. **F-7과 방향이 반대다** — F-7은 기술 비유를 일상 말로 되돌리고 F-9는 일상 비유를 기술 대상에 씌운 쪽을 본다. **원인 관계를 부르는 비유도 같은 자리다** — "뿌리가 하나다"는 원인이 같다는 말을 뿌리에 얹은 것이라 무엇이 같은지가 안 읽힌다. "원인이 같다"로 쓴다. 지어낸 별칭이든 이미 있는 비유든 가르는 건 하나다 — 그 자리에서 무엇을 가리키는지가 말에 남아 있느냐다. **자료구조나 명세가 그 이름으로 부르는 자리는 대상이 아니다** — 트리의 뿌리(root)와 스레드의 뿌리는 그 구조를 부르는 이름이라 가리킬 데가 있다. F-9에 걸린 별칭이 스스로 움직이면 D-5, 조사 없이 뭉치면 F-6도 함께 걸린다. 이 경계는 뜻이라 탐지기가 없다 |
+| F-10 | 일상 관용구의 물리 동작 동사를 코드나 문서 대상에 씌움 ("타입을 못 박다", "규칙을 못박는다", "테스트로 잠갔다") | S2 / **대화·리뷰 S1** | 그 자리에서 실제로 무엇이 되는지를 동사로 쓴다 ("타입을 선언한다", "규칙을 정한다", "관련 테스트가 있다"). 관용구는 원래 사람 사이 합의에 걸리는 말이라 목적어가 타입이나 규칙이 되면 누구에게 못을 박는다는 건지 가리킬 데가 없다. **가르는 것은 누가 정하는 자리냐다.** 문서나 코드가 스스로 정하면 대상이고("이 지시를 1번으로 못박는다", "타입을 못 박다"), 사람들이 협의해 정하면 예외다("팀이 일정을 못 박았다"). 한국어는 주어를 자주 생략하므로 **주어가 드러나면 그걸 보고, 없으면 목적어로 본다** — 타입, 값, 규칙, 지시, 기준은 문서나 코드가 정하는 쪽이고 일정과 조건처럼 사람들이 서로 약속하는 대상은 협의하는 쪽이다. 같은 "범위"라도 문서가 제 적용 범위를 정하는 자리는 대상이고 팀이 일의 범위를 합의하는 자리는 예외다. **나머지 예외는 셋이다.** 목적어가 리터럴 값이라 하드코딩을 뜻하는 "박아두다"("이 값 그냥 박아두죠"), 명사로 굳은 "잠금", 자물쇠나 문처럼 실제 물체를 잠그는 자리("문을 잠갔다"). **탐지기는 "못 박" 어간과 자물쇠 활용형을 전부 건다** — 주어가 사람인지 문서인지 못 가르므로 걸린 자리는 사람이 위 축으로 다시 본다 (I-5와 같은 방식이다). 형태로 빠지는 예외는 앞에 "못"이 없는 "박아두다"와 명사 "잠금"뿐이다. **F-7과 방향이 반대다** — F-7은 기술 비유를 일상 말로 되돌리고 F-10은 일상 비유를 코드 대상에 씌운 쪽을 본다. **F-9와는 품사로 갈린다** — F-9는 결함이나 그 원인 관계를 명사로 부르는 쪽이고(지어낸 별칭이든 이미 있는 비유든) F-10은 행위를 부르는 동사 쪽이다. **F-8과는 안 겹친다** — F-8은 물리 "측량" 동사만 보므로 "판단을 못 박았다"도 F-10 하나로 판정한다 |
 
 ## G. Hedging
 

package/plugin/role-agents/_shared/references/author-voice.md

@@ -35,13 +35,13 @@
 
 ### 이 숫자는 분포지 지침이 아니다
 
-가장 흔한 실패는 시그니처를 안 쓰는 게 아니라 **한 갈래에 몰아 쓰는 것**이다.
+가장 흔한 실패는 시그니처를 안 쓰는 게 아니라 **한 종류에 몰아 쓰는 것**이다.
 282는 리뷰 1,300건 중 20% 남짓이고 나머지는 "어떨까요?" 144, "좋아보입니다" 54처럼
-여러 갈래로 흩어져 있다. "보존하라"를 "매 문장에 쓰라"로 읽으면 문장 하나하나는
+여러 종류로 흩어져 있다. "보존하라"를 "매 문장에 쓰라"로 읽으면 문장 하나하나는
 진짜 어투인데 글 전체가 기계로 읽힌다 — 시그니처가 일정 간격으로 박히는 순간
 그 규칙성 자체가 새 AI-tell이 된다.
 
-- 한 갈래가 전체 종결의 **절반을 넘지 않게** 흩는다.
+- 한 종류가 전체 종결의 **절반을 넘지 않게** 흩는다.
 - 확인한 사실은 헤지 없이 단정한다. 다 헤지하면 확신도 신호가 사라진다.
 - 이모지, 물결도 마찬가지 — 문단마다 하나씩 꽂으면 계산된 티가 난다.
 

package/plugin/role-agents/change-context-writer/AGENT.md

@@ -138,7 +138,7 @@ PR/변경 문서도 결국 작성자가 직접 말하는 글이다. [`../_shared
 | 번역투 "~를 통해" | "이 방식을 통해 개선됩니다" | "이 방식으로 개선됩니다" |
 | 결산 피벗 | "결론적으로", "요약하자면", "정리하면" | 삭제 후 직결 |
 | AI 의인화 주어 | "이 변경은 ~를 수행합니다" | "~합니다" / 주어 생략 |
-| 과장 어휘 | "핵심적으로", "시사하는 바가 크다" | 삭제 또는 구체화 |
+| 과장 어휘 | `핵심적으로`, `시사하는 바가 크다` | 삭제 또는 구체화 |
 | 가운뎃점 나열(C-12) | "의도·동작·정책 수준에서" | 쉼표나 구어로 풀기("의도, 동작, 정책") — 표·용어목록·합성어(입출력)는 예외 |
 | Claude artifact | `c:`/`r:` 접두어, `[출처]` 태깅, "…권장." | 제거 |
 

package/plugin/role-agents/code-review-responder/AGENT.md

@@ -116,6 +116,31 @@ key는 넣었는데 index 대신 id를 썼어요. 목록 순서가 바뀌는 케
 
 **깎지 말 것** — 이건 AI-tell이 아니라 실제 voice다: "~것 같아요/같습니다", "개인적으로", 물결 친근체, 이모지 1개 안팎, 짧은 수긍("오 그러네요").
 
+### 원문 어휘는 인용할 때만 그대로 둔다
+
+답글은 **남이 쓴 코멘트를 읽고 쓰는 자리**라 원문 어휘가 제일 세게 끌어당긴다. 리뷰어가
+"배선"이나 "스큐"라고 썼어도 내 문장에서는 룰대로 쓴다. **원문에 있다는 건 통과 근거가 아니다.**
+
+| 룰 | 원문에서 끌려오는 말 |
+|---|---|
+| B-3 | 안 굳은 음차 — 스큐, 스파이크, 어피니티 |
+| F-7 | 기술 비유 명사 — 배선, 증류, 평탄화 |
+| B-5 | 오역 — `돌연변이`(mutant), `죽임`(kill), `갈래`(branch) |
+| F-9 | 그 자리에서 지어낸 결함 별칭 |
+| D-4 | hype 어휘 — `치명적`, `압도적` |
+
+| 자리 | 처리 |
+|------|------|
+| 코드블록, `인용`, 상대 코멘트 재인용 | **그대로.** 바꾸면 무엇에 답하는 건지 대조가 안 된다 |
+| 내 문장(수긍, 설명, 이견) | **룰대로 쓴다.** 상대 말을 가리켜야 하면 백틱으로 인용하고 뒤에 내 말로 잇는다 |
+
+- ✗ 말씀하신 배선 부분은 다음 PR에서 정리할게요
+- ✓ 말씀하신 연결 부분은 다음 PR에서 정리할게요
+- ✓ `배선`이라고 하신 그 자리요, 다음 PR에서 연결을 정리할게요 (상대 말을 가리켜야 할 때)
+
+답글에서 받아쓰면 그 말이 스레드에 두 번 남아 팀 어휘로 굳는다. 리뷰어가 쓴 말을 고쳐주는
+게 아니라 내 문장만 룰대로 쓰는 것이다 — 상대 표현을 지적하지 않는다.
+
 ## 지키는 선 (중요)
 
 리뷰이 답글은 **사실 주장**이라 리뷰 코멘트보다 검증이 더 중요하다. "반영했습니다"는 상대가 그걸 믿고 approve하는 근거가 된다.

package/plugin/role-agents/code-review-writer/AGENT.md

@@ -44,7 +44,8 @@ PR diff를 리뷰하고 머지 가능 여부를 판단할 수 있는 구체적
 - **구체적**: 추상적인 코멘트("좀 더 깔끔하게")를 피하고 실제 코드, 라인을 짚는다.
 - **위치 명시**: 모든 코멘트에 `파일:라인` 위치를 붙인다.
 - **개선 제안 포함**: 가능하면 수정 예시 코드 스니펫을 제시한다.
-- **언어**: 한국어로 직접 사고한다. 영어로 생각한 뒤 번역하지 않는다. 한국어를 기본으로 하되, 기술 용어(null, race condition, N+1, memoization 등)는 영어 그대로 혼용한다. 억지 번역하지 않는다.
+- **언어**: 한국어로 직접 사고한다. 영어로 생각한 뒤 번역하지 않는다. 한국어를 기본으로 하되, 기술 용어(null, race condition, N+1, memoization, mutant 등)는 영어 그대로 혼용한다. 억지 번역하지 않는다.
+- **한국어 정착어가 없는 용어는 옮기지 않는다.** 예시 목록에 없다고 번역 대상이 되는 게 아니다. 뜻으로 옮기면 엉뚱한 분야 어휘가 되고(`mutant`를 생물학 용어로 옮기는 자리) 음차로 옮기면 B-3에 걸린다. 판단이 서지 않으면 원어를 그대로 둔다. 다만 **원어로 두는 건 개념을 부르는 명사까지다** — 딸려 오는 동사는 한국어로 쓴다("mutant를 제거했다"). 코드 분기를 순우리말로 옮기는 것도 같은 실수다. 그 자리는 "분기"다.
 
 ### 접두어 컨벤션 (r/c/a) — 기본값
 
@@ -99,7 +100,8 @@ voice 모델을 따른다. 초안 작성 후 반드시 [`../_shared/references/a
 | 결산 피벗(D) | "결론적으로", "요약하자면", "정리하면" | 삭제 후 직결 |
 | AI 의인화 주어 | "이 코드는 ~를 수행합니다" | "~합니다" / 주어 생략 |
 | 음차(B-3) | "소스 오브 트루스", "룩 앤 필" 등 안 굳어진 음차 | 한글 의역 + 첫 등장만 원어 병기 |
-| 결함 별칭(F-9) | "맨몸 `setBoundVariableForPaint`" | "`setBoundVariableForPaint`에 `figma.variables.`가 안 붙었다" |
+| 결함을 별칭으로(F-9) | "맨몸 `setBoundVariableForPaint`" | "`setBoundVariableForPaint`에 `figma.variables.`가 안 붙었다" |
+| 원인 관계 비유(F-9) | "남은 2건은 뿌리가 하나예요" | "남은 2건은 원인이 같아요" |
 | 가운뎃점 나열(C-12) | "버그·성능·품질을 봅니다" | 쉼표나 구어로 풀기("버그, 성능, 품질") — 표·용어목록·합성어(입출력)는 예외 |
 | 측량·사무투 명사(I-6) | "레포 실측으로 1444개 중", "이건 오탐이에요" | 동사로 풀기("레포 뒤져보니 1444개 중", "이건 잘못 감지한 거예요") |
 | 수량 예고(C-14) | "두 가지 짚을 것", "세 가지만 남길게요" | 개수를 뒤로 보내기("제가 봤을 때는 확인이 필요한 게 2건 있어요") — 개수가 대상의 고정 속성이면 그대로 |
@@ -136,10 +138,24 @@ voice 모델을 따른다. 초안 작성 후 반드시 [`../_shared/references/a
 - **굳어진 음차 화이트리스트**(컴포넌트·토큰·렌더링·모달·트레이드오프 등 정착어)는 그대로 둔다 — ai-tell-quick-rules.md 참조
 - 수치, 파일명, 함수명, 에러 메시지, 코드 스니펫 변형 금지
 
-**원문 음차는 인용할 때만 그대로 둔다 (B-3 보완)**
+**원문 어휘는 인용할 때만 그대로 둔다 (어휘 룰 전반)**
 
-리뷰 대상 코드나 문서에 안 굳은 음차(에스케이프 해치, 스파이크, 어피니티 등)가 있을 때,
-**원문에 있다는 이유만으로 화이트리스트를 통과시키지 않는다.** 자리에 따라 다르게 다룬다.
+리뷰 대상 코드나 PR 본문, 기존 주석에 룰이 막는 말이 있을 때 **원문에 있다는 이유만으로
+통과시키지 않는다.** 음차만의 얘기가 아니다 — 아래 룰이 전부 같은 대접을 받는다.
+
+| 룰 | 원문에서 끌려오는 말 |
+|---|---|
+| B-3 | 안 굳은 음차 — 에스케이프 해치, 스파이크, 어피니티, 스큐 |
+| F-7 | 기술 비유 명사 — 배선, 증류, 결정화, 평탄화 |
+| B-5 | 오역 — `돌연변이`(mutant), `죽임`(kill), `갈래`(branch) |
+| F-9 | 그 자리에서 지어낸 결함 별칭 — 맨몸 호출 |
+| D-4 | hype 어휘 — `치명적`, `압도적` |
+
+**PR 본문과 diff는 읽는 자료이지 따라 쓸 본보기가 아니다.** 리뷰이가 "배선"이라고 썼어도
+리뷰어 문장에서는 "연결"이라고 쓴다. 원문 어휘를 그대로 받으면 룰이 있어도 그 자리만
+빠져나간다. 답글에서 재생산되면 팀 어휘로 굳는다.
+
+자리에 따라 다르게 다룬다.
 
 | 자리 | 처리 |
 |------|------|
@@ -150,6 +166,10 @@ voice 모델을 따른다. 초안 작성 후 반드시 [`../_shared/references/a
 - ✓ 사용자가 URL을 직접 주면 릴리즈 파일 가드를 건너뛰게 돼서
 - ✗ 레시피에 스파이크 검증 근거가 같이 남아 있어서
 - ✓ 레시피에 실제로 돌려본 결과가 같이 남아 있어서
+- ✗ 규칙을 소비자 전부에 배선해두면 (원문 주석이 "배선"이라 그대로 받은 자리)
+- ✓ 규칙을 소비자 전부에 연결해두면
+- ✗ 두 캐시 사이 스큐가 남습니다
+- ✓ 두 캐시 값이 어긋난 채로 남습니다
 
 풀어쓴 ✗ 예시는 F-6(명사구 압축)에도 걸린다 — 명사를 세 개 이어붙이면 뭘 어쨌다는 동사가
 사라진다. 안 굳은 음차가 보이면 명사구 압축도 같이 의심한다.
@@ -169,9 +189,9 @@ voice 모델을 따른다. 초안 작성 후 반드시 [`../_shared/references/a
 
 **보존은 밀도까지 보존하는 것이다 — 매 문장에 쓰라는 말이 아니다**
 
-282건은 리뷰 1,300건 중 20% 남짓이고 종결어미는 실제로 여러 갈래로 흩어져 있다 —
+282건은 리뷰 1,300건 중 20% 남짓이고 종결어미는 실제로 여러 종류로 흩어져 있다 —
 "것 같아요" 282, "어떨까요?" 144, "좋아보입니다" 54, "필요해보이네요" 29.
-한 갈래로 몰면 문장 하나하나는 진짜 어투인데 리뷰 전체가 기계로 읽힌다.
+한 종류로 몰면 문장 하나하나는 진짜 어투인데 리뷰 전체가 기계로 읽힌다.
 실제로 코멘트 9건에 "~것 같" 17회, 그중 8건이 `[문제] ~것 같아요 → [제안] ~것 같습니다`
 같은 리듬으로 나온 사례가 있다.
 
@@ -284,12 +304,15 @@ GitHub 마크다운은 **한 줄 개행(`\n`)을 무시하고 같은 문단으
 4. 모든 코멘트가 **같은 3단 구조에 같은 분량**인지 → 사소한 건 한 줄로 줄인다
 5. 사소한 코멘트가 섞여 있는데 `a:`가 하나도 없는지 → severity를 다시 매긴다
 6. 가운뎃점(·) 나열이 남았는지 (C-12, 표·용어목록·합성어는 예외)
-7. 리뷰어 자기 문장에 풀어쓰지 않은 원문 음차가 남았는지 (B-3)
+7. 리뷰어 자기 문장에 원문에서 끌려온 말이 남았는지 (B-3 음차, F-7 비유 명사, B-5 오역,
+   D-4 hype) — PR 본문이나 기존 주석에 있었다는 건 통과 근거가 아니다. 코드블록과 인용
+   안에서만 그대로 둔다
 8. 명사구 압축(F-6)·비유 명사(F-7)가 남았는지 — "사슬의 마지막 고리가 조용히 실패하는 셈"
    같은 문학적 비유는 리뷰 코멘트에선 담백한 서술로 내린다
-9. 결함을 그 자리에서 지어낸 별칭으로 부른 곳이 남았는지 (F-9) — "맨몸 `setBoundVariableForPaint`"
-   처럼 압축해 부르지 말고 무엇이 빠졌는지 그대로 쓴다. 8번과 방향이 반대라 따로 센다 — 8번은
-   기술 비유를 일상 말로 내리는 쪽이고 9번은 일상 비유를 코드에 씌운 쪽이다. 별칭을 만들면
+9. 결함이나 그 원인 관계를 비유 명사로 뭉개 부르지 않았는지 (F-9) — "맨몸 `setBoundVariableForPaint`"
+   처럼 압축해 부르지 말고 무엇이 빠졌는지 그대로 쓴다. 원인도 같다 — "뿌리가 하나예요"가 아니라
+   "원인이 같아요"로 쓴다. 지어낸 별칭이든 이미 있는 비유든 무엇을 가리키는지가 말에 남아야 한다. 8번과 방향이 반대라 따로 센다 — 8번은
+   기술 비유를 일상 말로 내리는 쪽이고 9번은 일상 비유를 코드나 결함, 그 원인 관계에 씌운 쪽이다. 별칭을 만들면
    나중에 같은 결함을 찾을 때 검색이 안 되고 답글에서 재생산돼 팀 어휘로 굳는다
 
 `audience`가 `junior`면 두 항목을 더 센다.

package/plugin/role-agents/explainer/references/audience.md

@@ -5,7 +5,7 @@
 
 어미는 새로 만들지 않았다. 기술 문서 해요체는
 [style-guide.md의 Tone](../../_shared/references/style-guide.md#tone)에서,
-제안형과 격식 갈래는
+제안형과 격식 쪽은
 [author-voice.md의 어투의 본질 (한 줄 요약)](../../_shared/references/author-voice.md#어투의-본질-한-줄-요약)에서
 가져왔다.
 
@@ -27,7 +27,7 @@
 | `nontech` | 해요체 | "~이에요", "~해요", "~하면 돼요" | style-guide Tone |
 | `junior` | 해요체 + 제안형 | "~하는 게 좋아요", "~해보세요", 이유는 "~해서요" | style-guide Tone + author-voice 1, 2번 |
 | `peer` | 해요체 + 제안형 + 짧은 지시 | "~좋아보여요", "~는 건 어떨까요?", 사소하면 한 줄 | author-voice 말투 A |
-| `manager` | 합니다체 | 사실은 단정, 권고는 "~을 제안합니다" | author-voice 제안형의 격식 갈래 |
+| `manager` | 합니다체 | 사실은 단정, 권고는 "~을 제안합니다" | author-voice 제안형의 격식 쪽 |
 | `exec` | 합니다체 | 결론 한 문장 먼저, 근거는 뒤 | 위와 같다 |
 | `outsider` | 해요체 | 짧게. 물결과 이모지는 안 쓴다 | style-guide Tone |
 
@@ -93,7 +93,7 @@
 
 `explain-check`의 비유 검사가 이 말들을 찾는다. 필수 대상인데 하나도 없으면 걸린다.
 
-| 갈래 | 표지 |
+| 종류 | 표지 |
 |---|---|
 | 직접 비유 | 비유하면, 비유하자면, 빗대면, 마치, ~에 비유 |
 | 대입 | ~라고 생각하면, ~다고 생각해보~, ~다고 생각해 보~, ~라고 생각해보~, ~라고 생각해 보~, ~인 셈, ~같은 거, ~같은 것 |
@@ -132,7 +132,7 @@
 
 전문용어 사전은 만들지 않는다. 유지가 안 된다. `explain-check`는 원문에서 뽑는다.
 
-| 갈래 | 예 |
+| 종류 | 예 |
 |---|---|
 | 백틱 코드 | `ERR_MODULE_NOT_FOUND` |
 | 대문자 약어 두 자 이상 | ESM, CJS, TLS |

package/plugin/role-agents/humanize-monolith/AGENT.md

@@ -146,7 +146,7 @@ S1부터 본다. 전 카테고리를 훑지 않는다.
 - 큰따옴표 안 직접 인용
 - 법률 조문, 수학, 화학, 통계 표기
 - 영어 약어(LLM·GPU·MCP·API 등 업계 표준)
-- 굳어진 음차 화이트리스트(B-3 제외): 컴포넌트·토큰·커밋·인터페이스·메서드·빌드·디플로이·캐시·렌더링·콜백·프레임워크·라이브러리·리팩터링·마이그레이션·아이콘·레이아웃·그리드·모달·토스트·타이포그래피·플레이스홀더·프로젝트·스프린트·이슈·리뷰·머지·브랜치·사이드 이펙트·보일러플레이트·트레이드오프·딥다이브·얼라인·온보딩·소스·롤백·파싱·레지스트리·불릿·널 포인터·데드락 등 정착어는 그대로 둔다. 목록 밖 안 굳어진 음차(소스 오브 트루스·룩 앤 필 등)만 B-3로 교정
+- 굳어진 음차 화이트리스트(B-3 제외): 컴포넌트·토큰·커밋·인터페이스·메서드·빌드·디플로이·캐시·렌더링·콜백·프레임워크·라이브러리·리팩터링·마이그레이션·아이콘·레이아웃·그리드·모달·토스트·타이포그래피·플레이스홀더·프로젝트·스프린트·이슈·리뷰·머지·브랜치·사이드 이펙트·보일러플레이트·트레이드오프·딥다이브·얼라인·온보딩·소스·롤백·파싱·레지스트리·불릿·널 포인터·데드락 등 정착어는 그대로 둔다. 목록 밖 안 굳어진 음차(소스 오브 트루스·룩 앤 필 등)와 그 구를 낱말 단위로 옮긴 직역형(은탄환·낮은 가지 열매)만 B-3로 교정. 이 목록은 등재된 형태 그대로만 통과하므로 낱말로 오른 "불릿"과 달리 "실버 불릿"은 B-3이 본다
 - 문서 구조(헤딩 위계·목차·섹션 순서)와 정보 자체 — 표현만 다듬고 내용은 건드리지 않는다
 - **구조 라벨 접두**: 커밋과 PR 제목의 `type(scope):` — 팀이 형식으로 정한 라벨이라 C-10 콜론 부제가 아니다(룰북 C-10 예외). 라벨은 그대로 두고 콜론 뒤 본문만 다듬는다. 리뷰 코멘트의 `r:`/`c:`/`a:`도 같은 예외이고 설명은 아래 작성자 voice 항목에 있다 — 여기 두 번 적지 않는다
 - **작성자 voice (리뷰 코멘트·PR/변경 문서)**: `author-voice.md`의 보존 패턴 — 제안형 "~것 같아요/같습니다", 물결 친근체 "~해주세요~/~할게요~", "개인적으로/제 취향이긴 한데", 이모지(코멘트당 1개 안팎). 이건 AI-tell이 아니라 작성자 voice이므로 단언, 격식으로 평탄화하지 않는다. (단 `[출처]`·"권장." 은 Claude artifact이니 보이면 제거. **`r:`/`c:`/`a:` 접두어는 예외** — 팀이 채택한 PR 리뷰 강제성 라벨이므로 코멘트 맨 앞에 있으면 보존한다. voice 시그니처 흉내가 아니라 구조적 라벨이다.)

package/plugin/role-agents/impact-writer/references/voice.md

@@ -40,6 +40,7 @@
 - 과장 어휘: "핵심적으로", "시사하는 바가 크다", hype 형용사
 - 가운뎃점(·) 나열 남발 → 쉼표나 "A랑 B하고 C" (표·용어 목록은 예외)
 - 안 굳어진 음차 표기 (humanize B-3): "소스 오브 트루스", "룩 앤 필", "로우 행잉 프룻"처럼 of/and까지 통째 음차한 구 → 한글 의역 + 첫 등장만 원어 병기. 단 업계 정착어(컴포넌트, 토큰, 커밋, 리팩터링, 얼라인, 온보딩 등)는 보존
+- 같은 구를 낱말 단위로 옮긴 직역형도 B-3이 본다: "낮은 가지 열매"는 "금방 되는 일", "은탄환"은 "만능 해법"으로 쓴다. 정착어 목록은 등재된 형태 그대로만 통과한다. 룰북 목록에 낱말로 오른 "불릿"과 달리 "실버 불릿"은 이 룰이 본다
 - Claude artifact: `c:`/`r:` 접두어, `[출처]` 대괄호 태깅, "…권장." 체언 종지
 
 ## 4. humanize-monolith 와의 관계 (중요)

package/plugin/role-agents/jira-writer/AGENT.md

@@ -115,7 +115,7 @@ You are the Jira Writer role agent.
 | 번역투 "~를 통해", "~에 대해", "~에 기반하여" | A-1·A-2·A-6 | "~로", "~를", "~을 보고"로 직결 |
 | 이중 피동 "~되어진다", 행위자 감춘 "~에 의해" | A-8·A-9 | 능동·단일 피동, 행위자를 주어로 |
 | 결산 피벗 "정리하면", "따라서", "결론적으로" | D-1 | 삭제 후 직결 |
-| hype 어휘(강력한·치명적·획기적) | D-4 | 구체 현상·수치로 |
+| hype 어휘(`강력한`, `치명적`, `획기적`) | D-4 | 구체 현상과 수치로 |
 | 의인화 주어("이 변경은 ~를 수행한다") | D-5·A-15 | 주어 생략·능동 환원 |
 | 가운뎃점(·) 나열 | C-12 | 쉼표나 구어로 (라벨·컴포넌트 목록은 예외) |
 | 이모지·과한 볼드 장식 | C-5·J-1 | 삭제 — 티켓은 담백하게 |

package/plugin/role-agents/slack-messenger/references/voice-sample.md

@@ -11,7 +11,7 @@
 
 ## 3개 말투
 
-작성자의 공개 채널 어투는 채널, 상대에 따라 세 갈래로 갈린다. 메시지를 쓰기 전에 **어느 말투인지 먼저 판단**한다.
+작성자의 공개 채널 어투는 채널, 상대에 따라 세 종류로 갈린다. 메시지를 쓰기 전에 **어느 말투인지 먼저 판단**한다.
 
 ### R1 — 공식 / 외부팀 / 협업 채널 (정중체)
 

package/plugin/skills/_shared/agent-delegation.md

@@ -93,7 +93,7 @@ Agent {
 
 ## 실패했을 때
 
-서브에이전트가 `ges_agent`에 닿지 못하면 (MCP 미연결 등) 세 갈래를 순서대로 본다.
+서브에이전트가 `ges_agent`에 닿지 못하면 (MCP 미연결 등) 아래를 순서대로 본다.
 
 1. **페르소나 없이 임의로 수행하지 않는다.** 어투와 판정 기준이 에이전트에 있는데 그걸 못 읽었으면 결과가 규칙을 안 지킨다. 이건 어느 경우에도 금지다.
 2. **메인 세션이 대신 `ges_agent get`을 해서 직접 수행하는 폴백은 쓸 수 있다.** 페르소나는 확보되니 결과는 규칙을 지킨다. 다만 컨텍스트 절감이 사라지므로 그 사실을 완료 보고에 밝힌다.

package/plugin/skills/local-pr/SKILL.md

@@ -153,7 +153,7 @@ gestalt pr merge <id>
 gestalt pr close <id> --reason "..."
 ```
 
-**충돌이 나면 워킹 트리를 되돌리고 실패를 알린다.** 그때는 PR 갈래에서 base를 먼저 받아 충돌을 풀고 head를 옮긴 뒤 다시 머지한다.
+**충돌이 나면 워킹 트리를 되돌리고 실패를 알린다.** 그때는 PR 브랜치에서 base를 먼저 받아 충돌을 풀고 head를 옮긴 뒤 다시 머지한다.
 
 ```bash
 cd <PR 워크트리> && git merge --no-ff <base 브랜치>

package/plugin/skills/pr/SKILL.md

@@ -48,7 +48,7 @@ PR을 만드는 것까지가 범위입니다. 올리기 전에 리뷰를 통과
 
 ## 이 스킬은 GitHub에만 올립니다
 
-로컬 PR(`gestalt pr`)은 `local-pr` 스킬이 맡습니다. 두 갈래는 능력이 아니라 용도로 갈립니다 — 원격 PR은 사람이 읽고 판단하라고 올립니다. 로컬 PR은 에이전트끼리 주고받는 자리입니다. 그래서 GitHub에 갈 수 있는지 여부로 갈래를 고르지 않습니다.
+로컬 PR(`gestalt pr`)은 `local-pr` 스킬이 맡습니다. 둘은 능력이 아니라 용도로 갈립니다 — 원격 PR은 사람이 읽고 판단하라고 올립니다. 로컬 PR은 에이전트끼리 주고받는 자리입니다. 그래서 GitHub에 갈 수 있는지 여부로 스킬을 고르지 않습니다.
 
 사용자가 로컬이라고 밝히지 않으면 GitHub입니다. 밝히는 방법은 둘입니다.
 

package/plugin/skills/review/SKILL.md

@@ -119,20 +119,20 @@ id를 직접 주면 아래 1번의 첫 수단이 브랜치를 안 따지고 잡
 
 ### 순서
 
-**명시 지정이 가장 셉니다. 그다음이 안 끝난 로컬 PR입니다.** 아래 순서대로 훑어 처음 걸리는 갈래를 택하고 나머지는 보지 않습니다.
+**명시 지정이 가장 셉니다. 그다음이 안 끝난 로컬 PR입니다.** 아래 순서대로 훑어 처음 걸리는 것을 택하고 나머지는 보지 않습니다.
 
 1. **로컬 지정** — `local` 입력이 true거나(`--local` 플래그) `target`이 로컬 PR id 형식(`gestalt pr list`에 뜨는 id)인 경우입니다. 이때는 로컬 PR을 두 수단으로 찾습니다.
    - `target`에 id가 있으면 먼저 `pnpm tsx bin/gestalt.ts pr --json show <id>`로 실제 존재를 확인합니다. 사용자가 id를 짚었으면 그 PR이 현재 브랜치 것인지는 안 따집니다.
    - id가 없거나(`--local`만 준 경우) `show`가 빈 결과를 내면 위의 가리는 법으로 현재 브랜치의 로컬 PR을 찾습니다.
    - 둘 중 하나로 찾으면 `local`입니다. 어느 쪽으로도 못 찾으면 그 사실을 한 줄 알리고 2번으로 내려갑니다.
 
-   `local`은 boolean이고 `target`은 필수가 아닙니다. `/review --local`처럼 플래그만 주는 입력이 정상이므로 id가 없는 갈래를 반드시 함께 둡니다.
+   `local`은 boolean이고 `target`은 필수가 아닙니다. `/review --local`처럼 플래그만 주는 입력이 정상이므로 id가 없는 경우를 반드시 함께 둡니다.
 2. **GitHub 지정** — `target`이 PR 번호나 GitHub URL이면 → `github`입니다. 사용자가 원격을 짚었으므로 아래 3번을 건너뜁니다.
 3. **안 끝난 로컬 PR** — 현재 브랜치에 안 끝난 로컬 PR이 있으면 → `local`입니다. 1번이 이미 조회했으면 그 결과를 그대로 씁니다. 1번을 안 거쳤으면 여기서 처음 조회합니다.
 
    로컬 PR이 안 끝났다는 건 그 코드가 아직 안 정해졌다는 뜻입니다. 그 상태로 원격에 리뷰를 게시하면 두 자리에 서로 다른 판정이 남습니다. 로컬을 먼저 종료하고 원격을 봅니다.
 
-   이 갈래로 왔으면 사용자에게 한 줄 알립니다: "현재 브랜치에 안 끝난 로컬 PR {id}가 있어서 그쪽을 먼저 봐요. 원격이면 PR 번호나 URL을 주세요."
+   여기로 왔으면 사용자에게 한 줄 알립니다: "현재 브랜치에 안 끝난 로컬 PR {id}가 있어서 그쪽을 먼저 봐요. 원격이면 PR 번호나 URL을 주세요."
 4. `gh auth status`가 실패하거나(인증 안 됨) `git remote -v`가 비어 있으면(원격 없음) → GitHub 경로가 막혀 있습니다. → `none`입니다.
 
    **여기서 로컬로 갈아타지 않습니다.** 3번이 이미 같은 조회로 걸렀으므로 현재 브랜치의 안 끝난 로컬 PR은 없습니다. 없는 걸 다시 찾지 않습니다. 있지도 않은 자리에 게시하지도 않습니다. 리포트는 그대로 만들고 게시만 건너뛰면서 무엇이 없어서 못 올리는지 한 줄 알립니다: "GitHub에 못 올려요 — {gh 인증이 없어요 / 원격이 없어요}. 리포트는 아래 그대로 드릴게요. 로컬 PR로 남기려면 `local-pr` 스킬로 PR을 먼저 만들고 그 id로 다시 불러주세요."
@@ -160,7 +160,7 @@ id를 직접 주면 아래 1번의 첫 수단이 브랜치를 안 따지고 잡
 
 - 1열이 "있음"인데 로컬 PR을 못 찾으면 지정은 힘을 잃습니다. 그 뒤로는 1열이 "없음"인 행과 같은 길을 갑니다. `--local`을 줬는데 로컬 PR이 없고 `target`으로 준 브랜치에 GitHub PR이 있으면 `github`으로 가는 7행이 그 자리입니다. 잘못된 로컬 PR id를 준 경우는 2번도 5번도 그 값을 못 받아 8행에 앉습니다.
 - 3열의 `안 봄`과 `못 찾음`은 다릅니다. `안 봄`은 로컬 지정이 없는 채로 GitHub 지정에 걸려 3번까지 못 가본 경우입니다. `못 찾음`은 실제로 조회했는데 걸리는 PR이 없던 경우입니다. 4번 아래 행들이 전부 `못 찾음`인 이유가 여기 있습니다 — 거기까지 왔다는 건 조회를 이미 했다는 뜻입니다.
-- `못 찾음`에는 알림이 따라붙을 수 있습니다. 가리는 법의 amend 갈래에 걸린 PR이 그렇습니다. 판정은 `못 찾음` 그대로라 행이 늘지 않고 사용자만 한 줄 더 받습니다.
+- `못 찾음`에는 알림이 따라붙을 수 있습니다. 가리는 법의 amend 분기에 걸린 PR이 그렇습니다. 판정은 `못 찾음` 그대로라 행이 늘지 않고 사용자만 한 줄 더 받습니다.
 - 4번은 로컬을 다시 안 봅니다. 그래서 4번 행의 결과가 전부 `none`입니다.
 
 ## Skill Instructions
@@ -217,14 +217,14 @@ git diff --name-only <range>
 git diff --name-only <commit>^ <commit>
 ```
 
-**`target`이 로컬 PR id 형식(8자리 16진수)이면 git이 그 값을 리비전으로 못 읽습니다.** `git diff main...<id>`는 `fatal: ambiguous argument`로 죽습니다. 이 갈래는 PR에서 sha를 받아 옵니다.
+**`target`이 로컬 PR id 형식(8자리 16진수)이면 git이 그 값을 리비전으로 못 읽습니다.** `git diff main...<id>`는 `fatal: ambiguous argument`로 죽습니다. 이 경우는 PR에서 sha를 받아 옵니다.
 
 ```bash
 pnpm tsx bin/gestalt.ts pr --json show <id>          # baseSha, headSha
 git diff --name-only <baseSha>..<headSha>            # 점 두 개 — pr diff와 같은 범위
 ```
 
-여기서는 형식만 봅니다. 그 id가 실재하는지와 어느 갈래로 갈지는 아래 대상 판별이 정합니다. `show`가 빈 결과를 내면 판별 1번이 그 사실을 받아 처리하므로 여기서는 다른 갈래처럼 diff를 못 모았다고만 둡니다.
+여기서는 형식만 봅니다. 그 id가 실재하는지와 어디로 갈지는 아래 대상 판별이 정합니다. `show`가 빈 결과를 내면 판별 1번이 그 사실을 받아 처리하므로 여기서는 다른 경우처럼 diff를 못 모았다고만 둡니다.
 
 출력이 비어 있으면 리뷰할 변경이 없다고 알리고 중단합니다.
 
@@ -267,7 +267,7 @@ pnpm tsx bin/gestalt.ts pr checkout <id> --json   # { path, created, headSha }
 pnpm tsx bin/gestalt.ts pr checkout <id> --remove --json
 ```
 
-정리 결과는 `status`로 갈래를 탑니다 — 산문 `reason`을 부분 문자열로 긁지 않습니다.
+정리 결과는 `status`로 분기합니다 — 산문 `reason`을 부분 문자열로 긁지 않습니다.
 
 | status | 뜻 | 종료 코드 |
 | --- | --- | --- |
@@ -654,6 +654,59 @@ Agent {
 }
 ```
 
+**어투 검사 (필수).** 작성된 코멘트를 게시 전에 스캔합니다. 에이전트가 룰북을 내장하고 자가점검도 하지만 **리뷰 대상 PR 본문과 diff에 있던 말이 그대로 딸려오는 자리**는 자가점검으로 안 걸립니다 — 원문에 있으니 맞는 말이라고 판단하는 자리라서요. 그 자리를 잡는 게 이 검사입니다.
+
+**코멘트마다 파일 하나로 떨굽니다. 한 파일에 모으지 않습니다.** 모아서 한 번에 스캔하면 검사가 배치 전체를 한 덩어리로 봅니다. 그러면 코멘트 하나를 통째로 `>` 인용으로 감싸도 다른 코멘트의 산문에 묻혀 안 걸립니다. 코멘트별로 갈라야 그 판정이 코멘트 단위로 섭니다. 어느 코멘트가 걸렸는지도 파일 이름으로 바로 읽히고요.
+
+**셸로 넘기지 않고 파일 쓰기 도구를 씁니다.** 본문에는 한글과 백틱이 섞이고 리뷰 대상에서 온 문자열이 그대로 실릴 수 있습니다. `ship`과 `local-pr`이 같은 이유로 정해 둔 규칙입니다.
+
+```bash
+# --git-common-dir 는 워크트리 여럿이 같은 자리를 가리킵니다. PR 식별자로 칸을 나누고
+# 그 아래 실행 단위로 한 겹 더 나눕니다 — 같은 PR 을 두 세션이 동시에 리뷰할 수 있습니다
+scanTmp="$(cd "$(git rev-parse --git-common-dir)" && pwd)/gestalt-review/<PR 식별자>/$$"
+mkdir -p "$scanTmp"
+echo "$scanTmp"
+```
+
+출력된 절대 경로에 코멘트마다 `1.md`, `2.md` 처럼 **순번으로** 씁니다. 순번과 이슈 id 의 대응은 메인 세션이 들고 있습니다.
+
+**이슈 id 를 파일 이름으로 쓰지 않습니다.** 그 값은 리뷰 서브에이전트가 diff 와 PR 본문을 읽고 지은 자유 문자열입니다. `../` 같은 경로 문자가 섞이면 쓰기가 `$scanTmp` 밖으로 샙니다. 이 자리가 `.git` 아래라 그 탈출이 훅 파일에 닿고요. 읽어온 텍스트가 경로가 되게 두지 않습니다.
+
+**본문만 씁니다** — `=== <id>` 같은 표지를 붙이면 그 줄이 산문으로 세어져 인용 판정이 어긋납니다.
+
+```bash
+# 개수를 먼저 셉니다. 글롭으로 바로 돌면 파일이 0개일 때 셸마다 다르게 죽습니다
+# (zsh 는 no matches 로 중단, bash 는 리터럴 경로로 한 번 돕니다)
+found=$(find "$scanTmp" -maxdepth 1 -name '*.md' | wc -l | tr -d ' ')
+echo "파일 $found 개"
+
+find "$scanTmp" -maxdepth 1 -name '*.md' | sort | while read -r f; do
+  pnpm tsx bin/gestalt.ts humanize-scan --file "$f" --register chat
+  echo "$(basename "$f" .md) EXIT=$?"
+done
+```
+
+`found` 가 코멘트 수와 다르면 **검사 실패입니다.** 그 자리에서 멈추고 무엇이 어긋났는지 알립니다. 파일 쓰기가 어긋났는데 조용히 넘어가면 이 검사가 막으려던 상황이 그대로 재현됩니다.
+
+종료 코드는 코멘트마다 봅니다.
+
+- **0** — 걸렸습니다. 스캔 결과(걸린 룰, 사례, 처방)를 **그대로 `code-review-writer`에 돌려주고 그 코멘트만 다시 쓰게 합니다.** 안 걸린 코멘트는 건드리지 않습니다.
+- **10** — 걸린 게 없습니다.
+- **11** — 어투는 깨끗하고 맞춤법만 걸렸습니다. 그것만 고칩니다.
+- **12** — **검사할 산문이 없습니다.** 코멘트가 인용줄뿐이라 검사가 안 된 것이지 통과가 아닙니다. 자기 문장을 인용 밖에 두고 다시 쓰게 합니다.
+- 재작성은 **한 번만** 돕니다. 두 번째도 걸리면 무엇이 남았는지 사용자에게 알리고 게시할지 묻습니다.
+- 전부 10이나 11이면 게시합니다. 게시가 끝나면 `rm -rf "$scanTmp"`로 그 실행 칸만 치웁니다 — 상위 `gestalt-review`나 PR 칸을 통째로 지우면 다른 세션이 쓰는 중인 파일까지 날아갑니다.
+
+**이 반복문을 벗어나 코멘트를 합쳐 한 번에 돌리면 이 검사가 무력화됩니다.** 한 파일에 여러 코멘트를 넣으면 인용 판정이 배치 전체로 서서, 코멘트 하나를 통째로 인용으로 감싸도 다른 코멘트의 산문에 묻힙니다. 파일 하나에 코멘트 하나가 이 검사가 서는 조건입니다.
+
+표 셀 검사는 끌 수 없습니다. 룰 문서인지는 `humanize-scan` 이 경로로 스스로 판정하고 그걸 바꾸는 옵션을 안 받습니다 — 검사를 끄는 스위치가 밖에 있으면 리뷰 대상 텍스트가 그걸 붙이라고 시키는 자리가 열립니다.
+
+`--register chat`입니다. 코멘트는 대화체 자리라 룰북이 `대화·리뷰 S1`로 올려 둔 룰들(F-7, I-7 등)까지 봐야 합니다. `doc` 기준으로 보면 그것들이 S2로 내려가 그대로 통과합니다. **B-5는 register와 무관하게 항상 S1이라 어느 쪽으로 봐도 걸립니다.**
+
+**스캔에서 빠지는 자리는 인라인 백틱과 언어 태그가 붙은 코드펜스, 그리고 `>` 블록인용입니다.** 원문을 그대로 실어야 대조가 되는 자리라 룰이 예외로 둔 것이고 검사도 같은 기준을 씁니다. 블록인용 제외는 `chat`에서만 켜집니다.
+
+**큰따옴표로 감싼 평문은 형태로 못 가릅니다.** 한국어에서 큰따옴표는 인용만이 아니라 강조로도 쓰여서요. 룰북 Do-NOT 목록이 "큰따옴표 안 직접 인용"을 예외로 두지만 그건 사람과 모델이 판단하는 자리의 기준입니다. 자동 스캔은 위 셋만 뺍니다. 원문을 가리켜야 하면 백틱이나 블록인용을 씁니다.
+
 **`path`·`line`·`side`·`severity`는 메인 세션이 채웁니다.** 서브에이전트는 `id`와 본문만 돌려주고 메인이 `id`로 `mergedIssues`를 되짚어 나머지를 붙입니다. 전부 코멘트 문체와 무관한 기계적 매핑이라 위임할 이유가 없고 서브에이전트가 라인이나 등급을 바꿔 적을 여지도 없앱니다. **원본을 이미 들고 있는 값을 되돌려 받아 쓰지 않습니다.**
 
 - `side`는 diff의 신규 라인이면 `RIGHT`, 삭제된 라인을 짚으면 `LEFT`입니다.
@@ -661,7 +714,7 @@ Agent {
 
 아래 규칙은 `code-review-writer` AGENT.md에 있어서 서브에이전트가 읽습니다. 여기 적어두는 건 사람이 읽을 계약이고 두 곳이 갈라지면 AGENT.md가 기준입니다. (바로 위 `path`·`line`·`side` 규칙은 반대로 **스킬 쪽에만** 있습니다 — 메인 세션이 하는 일이라 AGENT.md에 없습니다.)
 
-- code-review-writer는 `author-voice.md`(제안형·온기·물결·이모지)와 `ai-tell-quick-rules.md`(음차 교정)를 이미 내장하므로 **별도 humanize-monolith 패스를 거치지 않습니다.**
+- code-review-writer는 `author-voice.md`(제안형·온기·물결·이모지)와 `ai-tell-quick-rules.md`(음차 교정)를 이미 내장하므로 **리포트처럼 humanize-monolith로 통째로 윤문하지는 않습니다.** 대신 위의 `humanize-scan` 검사를 거칩니다 — 내장이 자가점검을 시키는 것이고 검사는 그게 실제로 됐는지 보는 것이라 층이 다릅니다.
 - 에이전트 룰에 따라 `[출처]` 태깅, "…권장." 체언 종지는 쓰지 않습니다. 이건 Claude artifact이지 실제 리뷰어 어투가 아닙니다.
 - **출처를 밝히는 태그는 형태를 가리지 않고 쓰지 않습니다.** `[게슈탈트 리뷰]`, `[Gestalt]`, `[AI 리뷰]`, 🤖 처럼 도구가 썼다는 표시를 붙이지 않습니다. 리뷰는 계정 주인이 남기는 것입니다. **내부 리뷰 에이전트 이름(QA, Architect, security-reviewer 등)도 본문에 드러내지 않습니다** — 관점이 여럿이어도 코멘트는 리뷰어 한 사람이 남긴 것처럼 씁니다.
 - **강제성은 `r:`/`c:`/`a:` 접두어로 표기합니다** (레포에 자체 리뷰 컨벤션이 없을 때의 기본값). 코멘트 본문 맨 앞에 severity에 따라 붙입니다 — `r:` 꼭 반영(critical/high), `c:` 웬만하면 반영(warning), `a:` 사소한 의견(suggestion). 접두어는 강제성 라벨이고 본문 어투는 그대로 제안형입니다. **접두어 앞에는 아무것도 오지 않습니다** — 출처 태그나 굵은 제목 줄이 접두어를 밀어내면 리뷰이가 강제성을 한눈에 못 봅니다. (리뷰 이벤트 판정은 접두어가 아니라 `severity`로 하므로 그쪽은 영향받지 않습니다.)

package/plugin/skills/review-reply/SKILL.md

@@ -112,20 +112,20 @@ id를 직접 주면 아래 1번의 첫 수단이 브랜치를 안 따지고 잡
 
 ### 순서
 
-**명시 지정이 가장 세다. 그다음이 안 끝난 로컬 PR이다.** 아래 순서대로 훑어 처음 걸리는 갈래를 택한다.
+**명시 지정이 가장 세다. 그다음이 안 끝난 로컬 PR이다.** 아래 순서대로 훑어 처음 걸리는 것을 택한다.
 
 1. **로컬 지정** — `local` 입력이 true거나(`--local` 플래그) `target`이 로컬 PR id 형식(`gestalt pr list`에 뜨는 id)인 경우다. 이때는 로컬 PR을 두 수단으로 찾는다.
    - `target`에 id가 있으면 먼저 `pnpm tsx bin/gestalt.ts pr --json show <id>`로 실제 존재를 확인한다. 사용자가 id를 짚었으면 그 PR이 현재 브랜치 것인지는 안 따진다.
    - id가 없거나(`--local`만 준 경우) `show`가 빈 결과를 내면 위의 가리는 법으로 현재 브랜치의 로컬 PR을 찾는다.
    - 둘 중 하나로 찾으면 `local`. 어느 쪽으로도 못 찾으면 그 사실을 한 줄 알리고 2번으로 내려간다.
 
-   `local`은 boolean이고 `target`은 필수가 아니다. `/review-reply --local`처럼 플래그만 주는 입력이 정상이므로 id가 없는 갈래를 반드시 함께 둔다.
+   `local`은 boolean이고 `target`은 필수가 아니다. `/review-reply --local`처럼 플래그만 주는 입력이 정상이므로 id가 없는 경우를 반드시 함께 둔다.
 2. **GitHub 지정** — `target`이 PR 번호나 GitHub URL이면 → `github`. 사용자가 원격을 짚었으므로 아래 3번을 건너뛴다.
 3. **안 끝난 로컬 PR** — 현재 브랜치에 안 끝난 로컬 PR이 있으면 → `local`. 1번이 이미 조회했으면 그 결과를 그대로 쓴다. 1번을 안 거쳤으면 여기서 처음 조회한다.
 
    로컬 PR이 안 끝났다는 건 그 코드가 아직 안 정해졌다는 뜻이다. 그 상태로 원격에 답을 달면 두 자리에 서로 다른 결론이 남는다. 로컬을 먼저 종료하고 원격을 본다.
 
-   이 갈래로 왔으면 사용자에게 한 줄 알린다: "현재 브랜치에 안 끝난 로컬 PR {id}가 있어서 그쪽을 먼저 봐요. 원격이면 PR 번호나 URL을 주세요."
+   여기로 왔으면 사용자에게 한 줄 알린다: "현재 브랜치에 안 끝난 로컬 PR {id}가 있어서 그쪽을 먼저 봐요. 원격이면 PR 번호나 URL을 주세요."
 4. `gh auth status`가 실패하거나(인증 안 됨) 원격이 없으면(`git remote -v` 비어 있음) → GitHub 경로가 막혀 있다. → `none`. **여기서 멈춘다.**
 
    **말없이 로컬로 갈아타지 않는다.** 3번이 이미 같은 조회로 걸렀으므로 현재 브랜치의 안 끝난 로컬 PR은 없다. 답을 달 자리가 GitHub에도 로컬에도 없는 것이지, 로컬로 내려앉을 자리가 남은 게 아니다. 무엇이 없어서 못 하는지 알리고 끝낸다: "받은 리뷰를 못 가져와요 — {gh 인증이 없어요 / 원격이 없어요}. 그리고 이 브랜치에 안 끝난 로컬 PR도 없어요. 인증을 붙이거나 로컬 PR id를 주세요."
@@ -151,7 +151,7 @@ gh 인증이 되고 원격도 있는데 로컬 PR을 지정했으면 1번이 먼
 
 - 1열이 "있음"인데 로컬 PR을 못 찾으면 지정은 힘을 잃는다. 그 뒤로는 1열이 "없음"인 행과 같은 길을 간다.
 - 3열의 `안 봄`과 `못 찾음`은 다르다. `안 봄`은 로컬 지정이 없는 채로 GitHub 지정에 걸려 3번까지 못 가본 경우다. `못 찾음`은 실제로 조회했는데 걸리는 PR이 없던 경우다. 4번 아래 행들이 전부 `못 찾음`인 이유가 여기 있다 — 거기까지 왔다는 건 조회를 이미 했다는 뜻이다.
-- `못 찾음`에는 알림이 따라붙을 수 있다. 가리는 법의 amend 갈래에 걸린 PR이 그렇다. 판정은 `못 찾음` 그대로라 행이 늘지 않고 사용자만 한 줄 더 받는다.
+- `못 찾음`에는 알림이 따라붙을 수 있다. 가리는 법의 amend 분기에 걸린 PR이 그렇다. 판정은 `못 찾음` 그대로라 행이 늘지 않고 사용자만 한 줄 더 받는다.
 - 4번은 로컬을 다시 안 본다. 그래서 4번 행이 `local`이 아니라 `none`이다.
 
 ## 파이프라인
@@ -371,10 +371,51 @@ Agent {
 
 `path`·`line`은 메인이 `id`로 되짚어 붙인다. 원본을 이미 들고 있는 값을 되돌려 받아 쓰지 않는다.
 
-에이전트가 `author-voice.md`와 `ai-tell-quick-rules.md`를 내장하므로 **별도 humanize-monolith 패스를 거치지 않는다.**
+에이전트가 `author-voice.md`와 `ai-tell-quick-rules.md`를 내장하므로 **통째로 윤문하는 humanize-monolith 패스는 거치지 않는다.** 대신 아래 검사를 거친다.
 
 접두어 금지와 GFM 개행 규칙은 위 프롬프트 안에 있다. 여기 다시 적지 않는다 — 두 벌이 되면 갈라진다.
 
+**어투 검사 (필수).** 미리보기를 보이기 전에 답글을 스캔한다. **답글은 남이 쓴 코멘트를 읽고 쓰는 자리라 원문 어휘가 제일 세게 끌어당긴다** — 원문에 있던 비유 명사나 안 굳은 음차를 그대로 옮겨 적기 쉽다. 그러면 그 말이 스레드에 두 번 남는다. 에이전트 자가점검으로는 안 걸리는 자리다.
+
+**답글마다 파일 하나로 떨군다. 한 파일에 모으지 않는다.** 모아서 한 번에 스캔하면 답글 하나를 통째로 `>` 인용으로 감싸도 다른 답글의 산문에 묻혀 안 걸린다. 답글별로 갈라야 판정이 답글 단위로 서고 어느 것이 걸렸는지도 파일 이름으로 읽힌다. 셸로 넘기지 않고 파일 쓰기 도구를 쓴다 — 본문에 한글과 백틱이 섞이고 남이 쓴 코멘트에서 온 문자열이 그대로 실린다.
+
+```bash
+# --git-common-dir 는 워크트리 여럿이 같은 자리를 가리킨다. PR 식별자와 실행 단위로 나눈다
+scanTmp="$(cd "$(git rev-parse --git-common-dir)" && pwd)/gestalt-review/<PR 식별자>/$$"
+mkdir -p "$scanTmp"
+echo "$scanTmp"
+```
+
+출력된 절대 경로에 답글마다 `1.md`, `2.md` 처럼 **순번으로** 쓴다. 순번과 스레드 id 의 대응은 메인 세션이 들고 있는다. 스레드 id 를 파일 이름으로 쓰지 않는다 — 읽어온 값이 경로가 되면 그 자리가 `.git` 아래라 위험하다.
+
+**본문만 쓴다** — 표지 줄을 붙이면 그 줄이 산문으로 세어져 인용 판정이 어긋난다.
+
+```bash
+# 개수를 먼저 센다. 글롭으로 바로 돌면 파일이 0개일 때 셸마다 다르게 죽는다
+found=$(find "$scanTmp" -maxdepth 1 -name '*.md' | wc -l | tr -d ' ')
+echo "파일 $found 개"
+
+find "$scanTmp" -maxdepth 1 -name '*.md' | sort | while read -r f; do
+  pnpm tsx bin/gestalt.ts humanize-scan --file "$f" --register chat
+  echo "$(basename "$f" .md) EXIT=$?"
+done
+```
+
+`found` 가 답글 수와 다르면 **검사 실패다.** 멈추고 무엇이 어긋났는지 알린다.
+
+- **0** — 걸렸다. 스캔 결과를 그대로 `code-review-responder`에 돌려주고 그 답글만 다시 쓰게 한다.
+- **10** — 걸린 게 없다.
+- **11** — 어투는 깨끗하고 맞춤법만 걸렸다.
+- **12** — **검사할 산문이 없다.** 답글이 인용줄뿐이라 검사가 안 된 것이지 통과가 아니다. 자기 문장을 인용 밖에 두고 다시 쓰게 한다.
+- 재작성은 **한 번만** 돈다. 두 번째도 걸리면 무엇이 남았는지 미리보기에 함께 적고 사용자가 판단하게 한다.
+- 전부 10이나 11이면 미리보기로 넘어간다. 게시가 끝나면 `rm -rf "$scanTmp"`로 그 실행 칸만 치운다.
+
+**이 반복문을 벗어나 답글을 합쳐 한 번에 돌리면 이 검사가 무력화된다.** 한 파일에 여러 답글을 넣으면 인용 판정이 배치 전체로 서서 답글 하나를 통째로 감싸도 다른 답글의 산문에 묻힌다. 파일 하나에 답글 하나가 이 검사가 서는 조건이다.
+
+표 셀 검사는 끌 수 없다. 룰 문서인지는 `humanize-scan` 이 경로로 스스로 판정한다.
+
+`--register chat`이다. 답글은 대화체 자리라 룰북이 `대화·리뷰 S1`로 올려 둔 룰들까지 봐야 한다. **스캔에서 빠지는 자리는 인라인 백틱과 언어 태그 붙은 코드펜스, 그리고 `>` 블록인용이다** — 상대 코멘트를 그 셋으로 재인용하면 대조가 필요한 자리가 그대로 남는다. 큰따옴표로 감싼 평문은 형태로 못 가르므로(한국어에서 강조로도 쓴다) 원문을 가리킬 땐 백틱을 쓴다.
+
 돌려받은 답글 전체를 미리보기로 보여주고 **명시적 승인**을 받는다.
 
 ```