@tienne/gestalt 0.38.0 → 0.40.0

package/skills/review/SKILL.md

@@ -217,7 +217,7 @@ ges_execute {
 `ges_agent { action: "get", name: "humanize-monolith" }`로 에이전트 시스템 프롬프트를 가져온 뒤, 해당 관점에서 리포트를 윤문합니다. 이슈 내용(severity·file·line·message)은 수정하지 않고, 설명 문장의 어투만 자연스럽게 다듬습니다.
 
 humanize-monolith는 두 룰북을 함께 적용합니다.
-- **어투**: `../../role-agents/technical-writer/references/author-voice.md` — 제안형("~하는 게 좋을 것 같아요/어떨까요?"), 온기·물결·이모지(코멘트당 1개 안팎)는 보존하고, `c:`/`r:` 접두어·`[출처]` 태깅·"…권장." 체언 종지(Claude artifact)는 쓰지 않습니다.
+- **어투**: `../../role-agents/technical-writer/references/author-voice.md` — 제안형("~하는 게 좋을 것 같아요/어떨까요?"), 온기·물결·이모지(코멘트당 1개 안팎)는 보존하고, `[출처]` 태깅·"…권장." 체언 종지(Claude artifact)는 쓰지 않습니다. (파이프라인 리포트는 severity 섹션 구조라 `r:`/`c:`/`a:` 접두어를 붙이지 않습니다 — 접두어는 4.7단계 PR 인라인 코멘트에만 씁니다.)
 - **음차·AI-tell**: `../../role-agents/technical-writer/references/ai-tell-quick-rules.md` — 안 굳어진 음차("소스 오브 트루스" 등)는 한글 의역하되, 굳어진 화이트리스트(컴포넌트·토큰·렌더링·트레이드오프 등)는 그대로 둡니다.
 
 즉 리뷰 파이프라인 리포트도 인라인 코멘트와 동일하게 voice + 음차가 함께 처리됩니다.
@@ -264,14 +264,25 @@ gh pr view <target> --json number,headRefName,baseRefName,url 2>/dev/null
 **코멘트 본문 작성 (code-review-writer).** `ges_agent { action: "get", name: "code-review-writer" }`로 에이전트 시스템 프롬프트를 가져온 뒤, 그 관점에서 4단계 `mergedIssues`의 각 이슈를 인라인 코멘트 본문으로 작성합니다. 이슈의 `file`·`line`·`severity`는 그대로 두고, `message`·`suggestion`을 에이전트 voice로 다듬어 코멘트 본문을 만듭니다.
 
 - code-review-writer는 `author-voice.md`(제안형·온기·물결·이모지)와 `ai-tell-quick-rules.md`(음차 교정)를 이미 내장하므로 **별도 humanize-monolith 패스를 거치지 않습니다.**
-- 에이전트 룰에 따라 `c:`/`r:` 접두어, `[출처]` 태깅, "…권장." 체언 종지는 쓰지 않습니다. 이건 Claude artifact이지 실제 리뷰어 어투가 아닙니다.
-- severity는 본문 첫 줄에 `[critical]`처럼 대괄호 라벨로만 표기합니다.
+- 에이전트 룰에 따라 `[출처]` 태깅, "…권장." 체언 종지는 쓰지 않습니다. 이건 Claude artifact이지 실제 리뷰어 어투가 아닙니다.
+- **강제성은 `r:`/`c:`/`a:` 접두어로 표기합니다** (레포에 자체 리뷰 컨벤션이 없을 때의 기본값). 코멘트 본문 맨 앞에 severity에 따라 붙입니다 — `r:` 꼭 반영(critical/high), `c:` 웬만하면 반영(warning), `a:` 사소한 의견(suggestion). 접두어는 강제성 라벨이고 본문 어투는 그대로 제안형입니다.
+- **개행은 GitHub 렌더링 기준으로 조립합니다.** GitHub GFM은 한 줄 개행(`\n`)을 무시하고 같은 문단으로 이어 붙이므로, 줄을 실제로 나누려면 **빈 줄(`\n\n`)로 블록을 분리**해야 합니다. severity 라벨 → 문제 설명 → 제안 → 코드 스니펫을 각각 빈 줄로 띄우고, 여러 줄 코드는 fenced code block(` ```lang ``` `)으로 감쌉니다. 한 줄 개행으로 이어 붙이면 PR에서 한 덩어리로 뭉쳐 읽기 어렵습니다 (code-review-writer의 Output Format 개행 규칙과 동일).
 
-**게시 (gh api).** 작성한 코멘트를 한 번의 리뷰로 묶어 게시합니다. 이슈마다 개별 호출하지 않고 `comments` 배열로 모읍니다.
+**리뷰 이벤트 결정.** 코멘트 접두어의 조합으로 리뷰 전체의 `event`를 정합니다 (r/c/a → GitHub 리뷰 이벤트 대응).
+
+- 이슈 중 하나라도 `r:`(critical/high)가 있으면 → `REQUEST_CHANGES`
+- `r:`은 없고 `c:`(warning)만 있으면 → `COMMENT`
+- `a:`(suggestion)만 있거나 이슈가 없으면 → `APPROVE`
+
+이는 4단계 `overallApproved`(결함 심급 blocking 여부)와도 일치합니다 — blocking 이슈가 있으면 `r:`이 존재하므로 `REQUEST_CHANGES`가 됩니다. 단 `APPROVE`/`REQUEST_CHANGES`는 리뷰 상태를 바꾸는 행위이므로, 위 **"게시 확인"**에서 사용자 동의를 받은 뒤에만 게시합니다.
+
+> **본인 PR 예외**: GitHub는 PR 작성자 본인이 자기 PR을 `APPROVE`/`REQUEST_CHANGES`하는 걸 막습니다(422). `gh pr view --json author`와 `gh api user`로 작성자가 현재 사용자와 같은지 확인하고, 같으면 `event=COMMENT`로 폴백해 게시합니다 (접두어 r/c/a는 본문에 그대로 유지). 이때 사용자에게 "본인 PR이라 승인/변경요청 상태는 못 걸어서 코멘트로 남겼어요"라고 한 줄 알립니다.
+
+**게시 (gh api).** 작성한 코멘트를 한 번의 리뷰로 묶어 게시합니다. 이슈마다 개별 호출하지 않고 `comments` 배열로 모읍니다. `event`는 바로 위에서 결정한 값을 넣습니다.
 
 ```bash
 gh api repos/{owner}/{repo}/pulls/{number}/reviews \
-  -f event=COMMENT \
+  -f event=<REQUEST_CHANGES|COMMENT|APPROVE> \
   -f body="<요약 한 줄 — code-review-writer가 작성한 overall summary>" \
   --input <(jq -n '{ comments: [ { path: "...", line: 42, side: "RIGHT", body: "..." } ] }')
 ```