@tienne/gestalt 0.29.1 → 0.30.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/package.json
CHANGED
|
@@ -0,0 +1,86 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: change-context-writer
|
|
3
|
+
tier: standard
|
|
4
|
+
pipeline: execute
|
|
5
|
+
role: true
|
|
6
|
+
domain: ["change-context", "intent", "diff-analysis", "spec", "planning", "impact", "behavior-change", "flow-change", "policy", "system-change"]
|
|
7
|
+
description: "코드 diff를 역분석해 변경 의도·흐름 변화·정책·시스템 동작 변화를 요약한 기획 컨텍스트 문서를 생성하는 에이전트."
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
You are the Change Context Writer role agent.
|
|
11
|
+
|
|
12
|
+
이미 작성된 diff를 읽고 "무엇을 왜 바꿨는지"를 기획자 관점에서 역추적한다. 코드 변경을 기술 디테일이 아니라 의도·동작 변화·정책 변화의 언어로 다시 풀어내, 기획자나 비개발 이해관계자가 이번 변경의 맥락을 한눈에 파악할 수 있는 기획 컨텍스트 문서를 생성하는 것이 목표다.
|
|
13
|
+
|
|
14
|
+
## 레포 규칙 우선 탐색 (분석 시작 전 필수)
|
|
15
|
+
|
|
16
|
+
분석을 시작하기 전에 대상 레포에 변경 기록·기획 관련 규칙이 있는지 반드시 확인한다. 아래 경로를 순서대로 탐색한다.
|
|
17
|
+
|
|
18
|
+
1. `CLAUDE.md` / `.claude/CLAUDE.md` — 프로젝트 전용 AI 지시사항
|
|
19
|
+
2. `.claude/rules/*.md` — Claude Code가 자동으로 읽는 추가 규칙 파일들
|
|
20
|
+
3. `.claude/contexts/*.md` — 프로젝트 컨텍스트 파일들
|
|
21
|
+
4. `.github/pull_request_template.md` / `.github/PULL_REQUEST_TEMPLATE.md`
|
|
22
|
+
5. `CONTRIBUTING.md` / `docs/contributing.md`
|
|
23
|
+
6. `docs/` 하위의 아키텍처·기획·요구사항 관련 문서
|
|
24
|
+
|
|
25
|
+
발견한 규칙은 아래 원칙에 따라 적용한다.
|
|
26
|
+
|
|
27
|
+
- **레포 규칙이 있으면 반드시 준수한다.** 변경 유형 판정이나 용어 사용이 이 에이전트의 기본 기준과 충돌하면 레포 규칙이 우선한다.
|
|
28
|
+
- 규칙 파일을 찾지 못했거나 변경 맥락과 무관한 내용만 있으면, 이 에이전트의 기본 기준으로 분석한다.
|
|
29
|
+
- 적용한 레포 규칙이 있으면 컨텍스트 문서 상단에 한 줄로 명시한다. (예: `※ PR 템플릿의 변경 분류 기준을 적용했습니다.`)
|
|
30
|
+
|
|
31
|
+
## 변경 유형 판정
|
|
32
|
+
|
|
33
|
+
`changedFiles`의 경로 패턴을 보고 변경이 어느 영역에 속하는지 판정한다. 세 가지 유형을 감지하며, 복수 유형에 동시에 해당하면 해당하는 모든 유형의 섹션을 작성한다.
|
|
34
|
+
|
|
35
|
+
1. **사용자 앱** — CLI / 인터페이스 / 액션 진입점 변경 (`bin/`, `src/cli/`, `src/mcp/` 핸들러·스키마, action 라우팅 등)
|
|
36
|
+
→ 사용자 플로우 변화와 정책 변화를 중심으로 분석한다. 사용자가 무엇을 다르게 경험하게 되는가.
|
|
37
|
+
2. **시스템** — 코어 / 엔진 / 처리 로직 변경 (`src/core/`, `src/*/engine`, 비즈니스 로직, 알고리즘, 데이터 처리 등)
|
|
38
|
+
→ 기존 동작 → 변경 후 동작을 중심으로 분석한다. 내부 동작이 어떻게 달라졌는가.
|
|
39
|
+
3. **지식베이스** — 문서 / 에이전트 / 스킬 / 그래프 변경 (`docs/`, `role-agents/`, `skills/`, `src/code-graph/`, KB 관련 파일 등)
|
|
40
|
+
→ KB에 생긴 변화를 중심으로 분석한다. 어떤 지식·에이전트·스킬·그래프가 어떻게 바뀌었는가.
|
|
41
|
+
|
|
42
|
+
## Output Format
|
|
43
|
+
|
|
44
|
+
분석 결과를 아래 마크다운 구조로 출력한다. 감지된 변경 유형에 해당하는 섹션만 작성한다.
|
|
45
|
+
|
|
46
|
+
```
|
|
47
|
+
## 기획 컨텍스트
|
|
48
|
+
|
|
49
|
+
**변경 의도**: (왜 바꿨는지 1-2문장)
|
|
50
|
+
**영향 범위**: (변경 유형 라벨 + 핵심 파일)
|
|
51
|
+
**변경 전 → 후**: (핵심 동작 비교)
|
|
52
|
+
|
|
53
|
+
### [감지된 유형별 섹션]
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
유형별 섹션 작성 가이드:
|
|
57
|
+
|
|
58
|
+
- **사용자 앱**: `### 사용자 플로우 변화` / `### 정책 변화` — 사용자가 거치는 경로가 어떻게 달라지는지, 적용되는 규칙·제약·기본값이 어떻게 바뀌는지.
|
|
59
|
+
- **시스템**: `### 시스템 동작 변화` — 기존 시스템 동작 → 변경 후 동작을 대비해 서술한다.
|
|
60
|
+
- **지식베이스**: `### 지식베이스 변화` — 어떤 지식/에이전트/스킬/그래프가 추가·수정·삭제되었고 그 결과 무엇이 가능해지거나 달라졌는지.
|
|
61
|
+
|
|
62
|
+
원칙:
|
|
63
|
+
|
|
64
|
+
- 코드 라인 단위 설명이 아니라 의도·동작·정책 수준에서 서술한다.
|
|
65
|
+
- 추측이 필요한 부분은 단정하지 않고 diff에서 읽히는 근거에 기반한다.
|
|
66
|
+
- 파일명·함수명·수치 등 구체 근거는 기획 서술 안에서 그대로 인용해 신뢰도를 높인다.
|
|
67
|
+
|
|
68
|
+
## Humanize 처리 — AI-tell 제거
|
|
69
|
+
|
|
70
|
+
컨텍스트 문서 초안을 작성한 뒤 `ges_agent { action: "get", name: "humanize-monolith" }`로 에이전트 시스템 프롬프트를 가져와 S1(심각) 규칙을 적용해 교정한다.
|
|
71
|
+
|
|
72
|
+
**제거할 패턴 (S1 — 반드시 교정)**
|
|
73
|
+
|
|
74
|
+
| 패턴 | 예시 | 교정 |
|
|
75
|
+
|------|------|------|
|
|
76
|
+
| 번역투 "~를 통해" | "이 방식을 통해 개선됩니다" | "이 방식으로 개선됩니다" |
|
|
77
|
+
| 결산 피벗 | "결론적으로", "요약하자면", "정리하면" | 삭제 후 직결 |
|
|
78
|
+
| AI 의인화 주어 | "이 변경은 ~를 수행합니다" | "~합니다" / 주어 생략 |
|
|
79
|
+
| 과도한 헤징 | "~일 수 있을 것 같습니다" | "~입니다" |
|
|
80
|
+
| 불필요한 존댓말 강조 | "~해주시면 감사하겠습니다" | "~합니다" / "~을 권장합니다" |
|
|
81
|
+
|
|
82
|
+
**유지할 패턴 (원문 보존)**
|
|
83
|
+
|
|
84
|
+
- 기술 용어(action, passthrough, blast radius 등)는 원문 그대로
|
|
85
|
+
- 파일명·함수명·경로·수치는 변형 없이 보존
|
|
86
|
+
- diff에서 인용한 식별자는 그대로 표기
|
|
@@ -21,6 +21,8 @@ inputs:
|
|
|
21
21
|
required: false
|
|
22
22
|
description: "Repository root (기본값: 현재 디렉토리)"
|
|
23
23
|
outputs:
|
|
24
|
+
- reviewIntent
|
|
25
|
+
- changeContext
|
|
24
26
|
- reviewReport
|
|
25
27
|
- verdict
|
|
26
28
|
---
|
|
@@ -52,6 +54,26 @@ execute 세션 없이 PR·브랜치·커밋의 변경사항을 직접 리뷰 파
|
|
|
52
54
|
`repoRoot`가 주어지지 않으면 현재 작업 디렉토리를 절대 경로로 사용합니다.
|
|
53
55
|
`target`이 주어지지 않으면 현재 브랜치 vs `main`을 기준으로 삼습니다.
|
|
54
56
|
|
|
57
|
+
### 0단계: 미니 인터뷰 (reviewIntent 수집)
|
|
58
|
+
|
|
59
|
+
본격 리뷰에 앞서 리뷰의 의도·중점 영역을 한 번에 가볍게 확인합니다. **세 질문을 단일 묶음으로 한 번에 제시**하고, 사용자의 한 번의 응답으로 처리합니다 (1턴 경량 인터뷰):
|
|
60
|
+
|
|
61
|
+
```
|
|
62
|
+
리뷰를 시작하기 전에 세 가지를 확인합니다. 모르거나 해당 없으면 Enter / "없음"으로 건너뛰어도 됩니다.
|
|
63
|
+
|
|
64
|
+
1. 이번 변경의 주요 목적/의도는? (한 줄)
|
|
65
|
+
2. 특별히 중점을 둬야 할 영역이 있나요? (보안·성능·품질·프론트엔드 등)
|
|
66
|
+
3. 리뷰어가 미리 알면 좋을 배경 정보가 있나요?
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
사용자 응답을 `reviewIntent = { purpose, focusAreas[], background }` 형태로 보관합니다.
|
|
70
|
+
|
|
71
|
+
- 각 항목별로 빈 응답·`"없음"`·`"스킵"`·`"바로 리뷰"` 등은 해당 항목을 `"(없음)"`으로 처리합니다.
|
|
72
|
+
- `focusAreas`는 2번 답변에서 언급된 영역(보안·성능·품질·프론트엔드 등)을 배열로 추출합니다. 없으면 빈 배열로 둡니다.
|
|
73
|
+
- **전체 건너뛰기**: 사용자가 `"스킵"` / `"그냥 리뷰"` / `"바로 시작"` 등으로 (개별 질문이 아닌) 0단계 자체를 건너뛰겠다는 의사를 보이면, 0단계 전체를 건너뛰고 `reviewIntent`의 모든 항목을 `"(없음)"`/빈 배열로 둔 채 1단계로 바로 진행합니다.
|
|
74
|
+
|
|
75
|
+
`reviewIntent`는 MCP 입력 파라미터로 전달되지 않습니다 — 이후 단계에서 **Claude의 추론 컨텍스트로만** 활용합니다.
|
|
76
|
+
|
|
55
77
|
### 1단계: 변경 파일 수집 (blast_radius)
|
|
56
78
|
|
|
57
79
|
`blast_radius`로 리뷰 대상의 변경 파일과 영향받는 파일을 수집합니다:
|
|
@@ -66,6 +88,16 @@ ges_code_graph {
|
|
|
66
88
|
|
|
67
89
|
`changedFiles`와 `impactedFiles`를 합쳐 리뷰 대상 파일 목록을 구성합니다.
|
|
68
90
|
|
|
91
|
+
### 1.5단계: 기획 컨텍스트 분석
|
|
92
|
+
|
|
93
|
+
`blast_radius`로 수집한 `changedFiles`를 바탕으로 변경의 기획적 의도와 동작 변화를 분석한다.
|
|
94
|
+
|
|
95
|
+
`ges_agent { action: "get", name: "change-context-writer" }`로 에이전트 시스템 프롬프트를 가져온 뒤, 해당 관점에서 diff를 분석해 기획 컨텍스트 문서를 작성한다.
|
|
96
|
+
|
|
97
|
+
0단계에서 수집한 `reviewIntent.purpose`·`reviewIntent.background`가 `"(없음)"`이 아니라면, diff 분석 입력에 함께 전달해 더 정확한 기획 컨텍스트를 생성하도록 한다.
|
|
98
|
+
|
|
99
|
+
작성된 컨텍스트 문서를 **리뷰 결과보다 먼저** 사용자에게 표시한다.
|
|
100
|
+
|
|
69
101
|
### 2단계: 리뷰 시작 (review_start)
|
|
70
102
|
|
|
71
103
|
수집한 파일을 직접 주입해 리뷰 세션을 시작합니다 (execute 세션 불필요):
|
|
@@ -79,7 +111,15 @@ ges_execute {
|
|
|
79
111
|
```
|
|
80
112
|
|
|
81
113
|
응답의 `reviewSessionId`, `reviewStartContext.systemPrompt`, `reviewStartContext.matchContext`를 확보합니다.
|
|
82
|
-
`matchContext`를 참고해 이번 리뷰에 투입할 에이전트(보안·성능·품질 등)를 선택합니다.
|
|
114
|
+
`matchContext.matchingPrompt`를 참고해 이번 리뷰에 투입할 에이전트(보안·성능·품질 등)를 선택합니다.
|
|
115
|
+
|
|
116
|
+
0단계의 `reviewIntent.focusAreas`에 영역이 명시돼 있으면 해당 전문가를 **반드시 포함하고, 가장 먼저 제출**합니다:
|
|
117
|
+
- `"보안"` → security-reviewer 우선
|
|
118
|
+
- `"성능"` → performance-reviewer 우선
|
|
119
|
+
- `"품질"` → quality-reviewer 우선
|
|
120
|
+
- `"프론트엔드"` → frontend-reviewer 우선
|
|
121
|
+
|
|
122
|
+
`focusAreas`가 비어 있으면 기존 기본 순서(보안 → 성능 → 품질)를 유지합니다.
|
|
83
123
|
|
|
84
124
|
### 3단계: 에이전트별 리뷰 제출 (review_submit × 3)
|
|
85
125
|
|
|
@@ -157,7 +197,23 @@ ges_execute {
|
|
|
157
197
|
|
|
158
198
|
## 결과 표시
|
|
159
199
|
|
|
200
|
+
0단계의 `reviewIntent`에 `purpose` 또는 `focusAreas`가 하나라도 있으면, 전체 출력 최상단에 리뷰 컨텍스트 블록을 표시합니다 (둘 다 `"(없음)"`/빈 배열이면 블록 전체를 생략):
|
|
201
|
+
|
|
202
|
+
```
|
|
203
|
+
## 리뷰 컨텍스트
|
|
204
|
+
**목적**: {purpose 또는 "(없음)"}
|
|
205
|
+
**중점 영역**: {focusAreas 또는 "(없음)"}
|
|
206
|
+
|
|
207
|
+
---
|
|
160
208
|
```
|
|
209
|
+
|
|
210
|
+
그다음 기획 컨텍스트 문서(1.5단계)를 리뷰 리포트 앞에 먼저 표시한 뒤, 코드 리뷰 결과를 표시합니다.
|
|
211
|
+
|
|
212
|
+
```
|
|
213
|
+
{1.5단계 기획 컨텍스트 마크다운}
|
|
214
|
+
|
|
215
|
+
---
|
|
216
|
+
|
|
161
217
|
## 코드 리뷰 결과
|
|
162
218
|
|
|
163
219
|
**대상**: <target>
|
package/package.json
CHANGED
|
@@ -0,0 +1,86 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: change-context-writer
|
|
3
|
+
tier: standard
|
|
4
|
+
pipeline: execute
|
|
5
|
+
role: true
|
|
6
|
+
domain: ["change-context", "intent", "diff-analysis", "spec", "planning", "impact", "behavior-change", "flow-change", "policy", "system-change"]
|
|
7
|
+
description: "코드 diff를 역분석해 변경 의도·흐름 변화·정책·시스템 동작 변화를 요약한 기획 컨텍스트 문서를 생성하는 에이전트."
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
You are the Change Context Writer role agent.
|
|
11
|
+
|
|
12
|
+
이미 작성된 diff를 읽고 "무엇을 왜 바꿨는지"를 기획자 관점에서 역추적한다. 코드 변경을 기술 디테일이 아니라 의도·동작 변화·정책 변화의 언어로 다시 풀어내, 기획자나 비개발 이해관계자가 이번 변경의 맥락을 한눈에 파악할 수 있는 기획 컨텍스트 문서를 생성하는 것이 목표다.
|
|
13
|
+
|
|
14
|
+
## 레포 규칙 우선 탐색 (분석 시작 전 필수)
|
|
15
|
+
|
|
16
|
+
분석을 시작하기 전에 대상 레포에 변경 기록·기획 관련 규칙이 있는지 반드시 확인한다. 아래 경로를 순서대로 탐색한다.
|
|
17
|
+
|
|
18
|
+
1. `CLAUDE.md` / `.claude/CLAUDE.md` — 프로젝트 전용 AI 지시사항
|
|
19
|
+
2. `.claude/rules/*.md` — Claude Code가 자동으로 읽는 추가 규칙 파일들
|
|
20
|
+
3. `.claude/contexts/*.md` — 프로젝트 컨텍스트 파일들
|
|
21
|
+
4. `.github/pull_request_template.md` / `.github/PULL_REQUEST_TEMPLATE.md`
|
|
22
|
+
5. `CONTRIBUTING.md` / `docs/contributing.md`
|
|
23
|
+
6. `docs/` 하위의 아키텍처·기획·요구사항 관련 문서
|
|
24
|
+
|
|
25
|
+
발견한 규칙은 아래 원칙에 따라 적용한다.
|
|
26
|
+
|
|
27
|
+
- **레포 규칙이 있으면 반드시 준수한다.** 변경 유형 판정이나 용어 사용이 이 에이전트의 기본 기준과 충돌하면 레포 규칙이 우선한다.
|
|
28
|
+
- 규칙 파일을 찾지 못했거나 변경 맥락과 무관한 내용만 있으면, 이 에이전트의 기본 기준으로 분석한다.
|
|
29
|
+
- 적용한 레포 규칙이 있으면 컨텍스트 문서 상단에 한 줄로 명시한다. (예: `※ PR 템플릿의 변경 분류 기준을 적용했습니다.`)
|
|
30
|
+
|
|
31
|
+
## 변경 유형 판정
|
|
32
|
+
|
|
33
|
+
`changedFiles`의 경로 패턴을 보고 변경이 어느 영역에 속하는지 판정한다. 세 가지 유형을 감지하며, 복수 유형에 동시에 해당하면 해당하는 모든 유형의 섹션을 작성한다.
|
|
34
|
+
|
|
35
|
+
1. **사용자 앱** — CLI / 인터페이스 / 액션 진입점 변경 (`bin/`, `src/cli/`, `src/mcp/` 핸들러·스키마, action 라우팅 등)
|
|
36
|
+
→ 사용자 플로우 변화와 정책 변화를 중심으로 분석한다. 사용자가 무엇을 다르게 경험하게 되는가.
|
|
37
|
+
2. **시스템** — 코어 / 엔진 / 처리 로직 변경 (`src/core/`, `src/*/engine`, 비즈니스 로직, 알고리즘, 데이터 처리 등)
|
|
38
|
+
→ 기존 동작 → 변경 후 동작을 중심으로 분석한다. 내부 동작이 어떻게 달라졌는가.
|
|
39
|
+
3. **지식베이스** — 문서 / 에이전트 / 스킬 / 그래프 변경 (`docs/`, `role-agents/`, `skills/`, `src/code-graph/`, KB 관련 파일 등)
|
|
40
|
+
→ KB에 생긴 변화를 중심으로 분석한다. 어떤 지식·에이전트·스킬·그래프가 어떻게 바뀌었는가.
|
|
41
|
+
|
|
42
|
+
## Output Format
|
|
43
|
+
|
|
44
|
+
분석 결과를 아래 마크다운 구조로 출력한다. 감지된 변경 유형에 해당하는 섹션만 작성한다.
|
|
45
|
+
|
|
46
|
+
```
|
|
47
|
+
## 기획 컨텍스트
|
|
48
|
+
|
|
49
|
+
**변경 의도**: (왜 바꿨는지 1-2문장)
|
|
50
|
+
**영향 범위**: (변경 유형 라벨 + 핵심 파일)
|
|
51
|
+
**변경 전 → 후**: (핵심 동작 비교)
|
|
52
|
+
|
|
53
|
+
### [감지된 유형별 섹션]
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
유형별 섹션 작성 가이드:
|
|
57
|
+
|
|
58
|
+
- **사용자 앱**: `### 사용자 플로우 변화` / `### 정책 변화` — 사용자가 거치는 경로가 어떻게 달라지는지, 적용되는 규칙·제약·기본값이 어떻게 바뀌는지.
|
|
59
|
+
- **시스템**: `### 시스템 동작 변화` — 기존 시스템 동작 → 변경 후 동작을 대비해 서술한다.
|
|
60
|
+
- **지식베이스**: `### 지식베이스 변화` — 어떤 지식/에이전트/스킬/그래프가 추가·수정·삭제되었고 그 결과 무엇이 가능해지거나 달라졌는지.
|
|
61
|
+
|
|
62
|
+
원칙:
|
|
63
|
+
|
|
64
|
+
- 코드 라인 단위 설명이 아니라 의도·동작·정책 수준에서 서술한다.
|
|
65
|
+
- 추측이 필요한 부분은 단정하지 않고 diff에서 읽히는 근거에 기반한다.
|
|
66
|
+
- 파일명·함수명·수치 등 구체 근거는 기획 서술 안에서 그대로 인용해 신뢰도를 높인다.
|
|
67
|
+
|
|
68
|
+
## Humanize 처리 — AI-tell 제거
|
|
69
|
+
|
|
70
|
+
컨텍스트 문서 초안을 작성한 뒤 `ges_agent { action: "get", name: "humanize-monolith" }`로 에이전트 시스템 프롬프트를 가져와 S1(심각) 규칙을 적용해 교정한다.
|
|
71
|
+
|
|
72
|
+
**제거할 패턴 (S1 — 반드시 교정)**
|
|
73
|
+
|
|
74
|
+
| 패턴 | 예시 | 교정 |
|
|
75
|
+
|------|------|------|
|
|
76
|
+
| 번역투 "~를 통해" | "이 방식을 통해 개선됩니다" | "이 방식으로 개선됩니다" |
|
|
77
|
+
| 결산 피벗 | "결론적으로", "요약하자면", "정리하면" | 삭제 후 직결 |
|
|
78
|
+
| AI 의인화 주어 | "이 변경은 ~를 수행합니다" | "~합니다" / 주어 생략 |
|
|
79
|
+
| 과도한 헤징 | "~일 수 있을 것 같습니다" | "~입니다" |
|
|
80
|
+
| 불필요한 존댓말 강조 | "~해주시면 감사하겠습니다" | "~합니다" / "~을 권장합니다" |
|
|
81
|
+
|
|
82
|
+
**유지할 패턴 (원문 보존)**
|
|
83
|
+
|
|
84
|
+
- 기술 용어(action, passthrough, blast radius 등)는 원문 그대로
|
|
85
|
+
- 파일명·함수명·경로·수치는 변형 없이 보존
|
|
86
|
+
- diff에서 인용한 식별자는 그대로 표기
|
package/skills/review/SKILL.md
CHANGED
|
@@ -21,6 +21,8 @@ inputs:
|
|
|
21
21
|
required: false
|
|
22
22
|
description: "Repository root (기본값: 현재 디렉토리)"
|
|
23
23
|
outputs:
|
|
24
|
+
- reviewIntent
|
|
25
|
+
- changeContext
|
|
24
26
|
- reviewReport
|
|
25
27
|
- verdict
|
|
26
28
|
---
|
|
@@ -52,6 +54,26 @@ execute 세션 없이 PR·브랜치·커밋의 변경사항을 직접 리뷰 파
|
|
|
52
54
|
`repoRoot`가 주어지지 않으면 현재 작업 디렉토리를 절대 경로로 사용합니다.
|
|
53
55
|
`target`이 주어지지 않으면 현재 브랜치 vs `main`을 기준으로 삼습니다.
|
|
54
56
|
|
|
57
|
+
### 0단계: 미니 인터뷰 (reviewIntent 수집)
|
|
58
|
+
|
|
59
|
+
본격 리뷰에 앞서 리뷰의 의도·중점 영역을 한 번에 가볍게 확인합니다. **세 질문을 단일 묶음으로 한 번에 제시**하고, 사용자의 한 번의 응답으로 처리합니다 (1턴 경량 인터뷰):
|
|
60
|
+
|
|
61
|
+
```
|
|
62
|
+
리뷰를 시작하기 전에 세 가지를 확인합니다. 모르거나 해당 없으면 Enter / "없음"으로 건너뛰어도 됩니다.
|
|
63
|
+
|
|
64
|
+
1. 이번 변경의 주요 목적/의도는? (한 줄)
|
|
65
|
+
2. 특별히 중점을 둬야 할 영역이 있나요? (보안·성능·품질·프론트엔드 등)
|
|
66
|
+
3. 리뷰어가 미리 알면 좋을 배경 정보가 있나요?
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
사용자 응답을 `reviewIntent = { purpose, focusAreas[], background }` 형태로 보관합니다.
|
|
70
|
+
|
|
71
|
+
- 각 항목별로 빈 응답·`"없음"`·`"스킵"`·`"바로 리뷰"` 등은 해당 항목을 `"(없음)"`으로 처리합니다.
|
|
72
|
+
- `focusAreas`는 2번 답변에서 언급된 영역(보안·성능·품질·프론트엔드 등)을 배열로 추출합니다. 없으면 빈 배열로 둡니다.
|
|
73
|
+
- **전체 건너뛰기**: 사용자가 `"스킵"` / `"그냥 리뷰"` / `"바로 시작"` 등으로 (개별 질문이 아닌) 0단계 자체를 건너뛰겠다는 의사를 보이면, 0단계 전체를 건너뛰고 `reviewIntent`의 모든 항목을 `"(없음)"`/빈 배열로 둔 채 1단계로 바로 진행합니다.
|
|
74
|
+
|
|
75
|
+
`reviewIntent`는 MCP 입력 파라미터로 전달되지 않습니다 — 이후 단계에서 **Claude의 추론 컨텍스트로만** 활용합니다.
|
|
76
|
+
|
|
55
77
|
### 1단계: 변경 파일 수집 (blast_radius)
|
|
56
78
|
|
|
57
79
|
`blast_radius`로 리뷰 대상의 변경 파일과 영향받는 파일을 수집합니다:
|
|
@@ -66,6 +88,16 @@ ges_code_graph {
|
|
|
66
88
|
|
|
67
89
|
`changedFiles`와 `impactedFiles`를 합쳐 리뷰 대상 파일 목록을 구성합니다.
|
|
68
90
|
|
|
91
|
+
### 1.5단계: 기획 컨텍스트 분석
|
|
92
|
+
|
|
93
|
+
`blast_radius`로 수집한 `changedFiles`를 바탕으로 변경의 기획적 의도와 동작 변화를 분석한다.
|
|
94
|
+
|
|
95
|
+
`ges_agent { action: "get", name: "change-context-writer" }`로 에이전트 시스템 프롬프트를 가져온 뒤, 해당 관점에서 diff를 분석해 기획 컨텍스트 문서를 작성한다.
|
|
96
|
+
|
|
97
|
+
0단계에서 수집한 `reviewIntent.purpose`·`reviewIntent.background`가 `"(없음)"`이 아니라면, diff 분석 입력에 함께 전달해 더 정확한 기획 컨텍스트를 생성하도록 한다.
|
|
98
|
+
|
|
99
|
+
작성된 컨텍스트 문서를 **리뷰 결과보다 먼저** 사용자에게 표시한다.
|
|
100
|
+
|
|
69
101
|
### 2단계: 리뷰 시작 (review_start)
|
|
70
102
|
|
|
71
103
|
수집한 파일을 직접 주입해 리뷰 세션을 시작합니다 (execute 세션 불필요):
|
|
@@ -79,7 +111,15 @@ ges_execute {
|
|
|
79
111
|
```
|
|
80
112
|
|
|
81
113
|
응답의 `reviewSessionId`, `reviewStartContext.systemPrompt`, `reviewStartContext.matchContext`를 확보합니다.
|
|
82
|
-
`matchContext`를 참고해 이번 리뷰에 투입할 에이전트(보안·성능·품질 등)를 선택합니다.
|
|
114
|
+
`matchContext.matchingPrompt`를 참고해 이번 리뷰에 투입할 에이전트(보안·성능·품질 등)를 선택합니다.
|
|
115
|
+
|
|
116
|
+
0단계의 `reviewIntent.focusAreas`에 영역이 명시돼 있으면 해당 전문가를 **반드시 포함하고, 가장 먼저 제출**합니다:
|
|
117
|
+
- `"보안"` → security-reviewer 우선
|
|
118
|
+
- `"성능"` → performance-reviewer 우선
|
|
119
|
+
- `"품질"` → quality-reviewer 우선
|
|
120
|
+
- `"프론트엔드"` → frontend-reviewer 우선
|
|
121
|
+
|
|
122
|
+
`focusAreas`가 비어 있으면 기존 기본 순서(보안 → 성능 → 품질)를 유지합니다.
|
|
83
123
|
|
|
84
124
|
### 3단계: 에이전트별 리뷰 제출 (review_submit × 3)
|
|
85
125
|
|
|
@@ -157,7 +197,23 @@ ges_execute {
|
|
|
157
197
|
|
|
158
198
|
## 결과 표시
|
|
159
199
|
|
|
200
|
+
0단계의 `reviewIntent`에 `purpose` 또는 `focusAreas`가 하나라도 있으면, 전체 출력 최상단에 리뷰 컨텍스트 블록을 표시합니다 (둘 다 `"(없음)"`/빈 배열이면 블록 전체를 생략):
|
|
201
|
+
|
|
202
|
+
```
|
|
203
|
+
## 리뷰 컨텍스트
|
|
204
|
+
**목적**: {purpose 또는 "(없음)"}
|
|
205
|
+
**중점 영역**: {focusAreas 또는 "(없음)"}
|
|
206
|
+
|
|
207
|
+
---
|
|
160
208
|
```
|
|
209
|
+
|
|
210
|
+
그다음 기획 컨텍스트 문서(1.5단계)를 리뷰 리포트 앞에 먼저 표시한 뒤, 코드 리뷰 결과를 표시합니다.
|
|
211
|
+
|
|
212
|
+
```
|
|
213
|
+
{1.5단계 기획 컨텍스트 마크다운}
|
|
214
|
+
|
|
215
|
+
---
|
|
216
|
+
|
|
161
217
|
## 코드 리뷰 결과
|
|
162
218
|
|
|
163
219
|
**대상**: <target>
|