@tienne/gestalt 0.30.0 → 0.31.0
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 +1 -1
- package/dist/skills/interview/SKILL.md +24 -1
- package/dist/skills/pr/SKILL.md +139 -0
- package/dist/skills/review/SKILL.md +43 -2
- package/package.json +1 -1
- package/skills/interview/SKILL.md +24 -1
- package/skills/pr/SKILL.md +139 -0
- package/skills/review/SKILL.md +43 -2
package/dist/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: interview
|
|
3
|
-
version: "1.
|
|
3
|
+
version: "1.2.0"
|
|
4
4
|
description: "Gestalt-driven interview to clarify project requirements"
|
|
5
5
|
triggers:
|
|
6
6
|
- "interview"
|
|
@@ -24,6 +24,29 @@ outputs:
|
|
|
24
24
|
|
|
25
25
|
This skill conducts a Gestalt psychology-driven interview to transform vague requirements into clear specifications.
|
|
26
26
|
|
|
27
|
+
## 0단계: 인텐트 라우팅 (인터뷰 시작 전)
|
|
28
|
+
|
|
29
|
+
인터뷰를 시작하기 전에 topic이 인터뷰 파이프라인에 적합한지 먼저 확인한다.
|
|
30
|
+
|
|
31
|
+
### PR 관련 키워드 감지
|
|
32
|
+
topic에 아래 키워드가 포함되면 `/pr` 스킬이 더 적합하다:
|
|
33
|
+
`PR`, `풀리퀘`, `풀 리퀘스트`, `pull request`, `PR 작성`, `PR 만들어`, `PR 써줘`, `PR 올려`
|
|
34
|
+
|
|
35
|
+
→ `ges_interview start`를 실행하지 않고 사용자에게 안내:
|
|
36
|
+
> "이 요청은 `/pr` 스킬이 더 적합합니다. PR 작성 전용 파이프라인(레포 규칙 탐색 → 미니 인터뷰 → diff 분석 → description 생성)으로 진행할까요?"
|
|
37
|
+
> 확인 시 `/pr` 스킬 즉시 실행.
|
|
38
|
+
|
|
39
|
+
### 코드 리뷰 관련 키워드 감지
|
|
40
|
+
topic에 아래 키워드가 포함되면 `/review` 스킬이 더 적합하다:
|
|
41
|
+
`코드리뷰`, `code review`, `리뷰해줘`, `리뷰 부탁`, `리뷰 요청`, `review`, `리뷰`
|
|
42
|
+
|
|
43
|
+
→ `ges_interview start`를 실행하지 않고 사용자에게 안내:
|
|
44
|
+
> "이 요청은 `/review` 스킬이 더 적합합니다. 코드 리뷰 전용 파이프라인(미니 인터뷰 → 기획 컨텍스트 분석 → 전문 리뷰어 검토)으로 진행할까요?"
|
|
45
|
+
> 확인 시 `/review` 스킬 즉시 실행.
|
|
46
|
+
|
|
47
|
+
### 라우팅 대상이 아닌 경우
|
|
48
|
+
위 키워드가 없으면 기존 인터뷰 파이프라인을 정상 진행한다.
|
|
49
|
+
|
|
27
50
|
## ⚠️ Critical Rule: Never Self-Answer
|
|
28
51
|
|
|
29
52
|
**You are the interviewer, not the interviewee.**
|
|
@@ -0,0 +1,139 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: pr
|
|
3
|
+
version: "1.0.0"
|
|
4
|
+
description: "PR 작성 전용 스킬. 레포 규칙을 먼저 탐색하고, 미니 인터뷰로 컨텍스트를 수집한 뒤 diff 기반 PR description을 생성하고 gh pr create로 제출한다."
|
|
5
|
+
triggers:
|
|
6
|
+
- "PR 작성"
|
|
7
|
+
- "PR 만들어"
|
|
8
|
+
- "PR 써줘"
|
|
9
|
+
- "PR 올려"
|
|
10
|
+
- "풀리퀘"
|
|
11
|
+
- "풀 리퀘스트"
|
|
12
|
+
- "pull request"
|
|
13
|
+
- "create PR"
|
|
14
|
+
inputs:
|
|
15
|
+
target:
|
|
16
|
+
type: string
|
|
17
|
+
required: false
|
|
18
|
+
description: "비교 기준 브랜치 (생략 시 현재 브랜치 vs main)"
|
|
19
|
+
repoRoot:
|
|
20
|
+
type: string
|
|
21
|
+
required: false
|
|
22
|
+
description: "Repository root (기본값: 현재 디렉토리)"
|
|
23
|
+
outputs:
|
|
24
|
+
- prIntent
|
|
25
|
+
- changeContext
|
|
26
|
+
- prDescription
|
|
27
|
+
- prUrl
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
# PR Skill
|
|
31
|
+
|
|
32
|
+
레포의 PR 규칙을 먼저 탐색하고, 미니 인터뷰로 컨텍스트를 수집한 뒤, diff를 분석해 레포 규칙에 맞는 PR description을 생성하고 `gh pr create`로 제출합니다.
|
|
33
|
+
|
|
34
|
+
## 사용 방법
|
|
35
|
+
|
|
36
|
+
```
|
|
37
|
+
/pr # 현재 브랜치 vs main
|
|
38
|
+
/pr feature/auth # 특정 브랜치
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
## 전제 조건
|
|
42
|
+
|
|
43
|
+
`repoRoot`가 주어지지 않으면 현재 작업 디렉토리를 절대 경로로 사용합니다.
|
|
44
|
+
`target`이 주어지지 않으면 현재 브랜치 vs `main`을 기준으로 삼습니다.
|
|
45
|
+
|
|
46
|
+
## Skill Instructions
|
|
47
|
+
|
|
48
|
+
### 0단계: 레포 규칙 탐색 (필수 — 스킵 불가)
|
|
49
|
+
|
|
50
|
+
PR을 작성하기 전에 레포의 PR 규칙을 반드시 먼저 탐색합니다. 아래 경로를 순서대로 확인하고, 발견한 규칙은 PR 작성에 반드시 적용합니다:
|
|
51
|
+
|
|
52
|
+
1. `.github/pull_request_template.md` / `.github/PULL_REQUEST_TEMPLATE.md`
|
|
53
|
+
2. `.github/PULL_REQUEST_TEMPLATE/*.md` (복수 템플릿이면 변경 유형에 맞는 것 선택)
|
|
54
|
+
3. `CONTRIBUTING.md` / `docs/contributing.md`
|
|
55
|
+
4. `CLAUDE.md` / `.claude/CLAUDE.md`
|
|
56
|
+
5. `.claude/rules/*.md`
|
|
57
|
+
6. `.github/CODEOWNERS`
|
|
58
|
+
|
|
59
|
+
**적용 우선순위**:
|
|
60
|
+
|
|
61
|
+
- **PR 템플릿 발견** → 해당 구조를 그대로 채웁니다. 임의 섹션 추가 금지. 다른 섹션 재구성 금지.
|
|
62
|
+
- **템플릿 없음 + CONTRIBUTING 있음** → CONTRIBUTING의 PR 규칙을 적용한 구조를 생성합니다.
|
|
63
|
+
- **둘 다 없음** → 표준 PR 포맷을 사용합니다:
|
|
64
|
+
```
|
|
65
|
+
## Summary
|
|
66
|
+
## Changes
|
|
67
|
+
## Test plan
|
|
68
|
+
## Related issues
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
탐색 결과는 `repoRules = { templatePath, templateContent, contributingRules, claudeRules }` 형태로 보관합니다.
|
|
72
|
+
|
|
73
|
+
### 1단계: 미니 인터뷰 (prIntent 수집)
|
|
74
|
+
|
|
75
|
+
본격 작성에 앞서 PR의 의도·특이사항·이슈 번호를 한 번에 가볍게 확인합니다. **세 질문을 단일 묶음으로 한 번에 제시**하고, 사용자의 한 번의 응답으로 처리합니다 (1턴 경량 인터뷰):
|
|
76
|
+
|
|
77
|
+
```
|
|
78
|
+
PR을 작성하기 전에 세 가지를 확인합니다. 없으면 Enter / "없음"으로 건너뛰어도 됩니다.
|
|
79
|
+
|
|
80
|
+
1. 이 PR의 주요 목적/의도는? (한 줄)
|
|
81
|
+
2. 리뷰어가 미리 알면 좋을 특이사항이 있나요?
|
|
82
|
+
3. 관련 이슈/티켓 번호가 있나요?
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
사용자 응답을 `prIntent = { purpose, notes, issueRef }` 형태로 보관합니다.
|
|
86
|
+
|
|
87
|
+
- 각 항목별로 빈 응답·`"없음"`은 해당 항목을 비워 둡니다.
|
|
88
|
+
- **전체 건너뛰기**: 사용자가 `"없음"` / `"스킵"` / `"바로 PR"` 등으로 (개별 질문이 아닌) 1단계 자체를 건너뛰겠다는 의사를 보이면, 1단계 전체를 건너뛰고 `prIntent`의 모든 항목을 비워 둔 채 2단계로 바로 진행합니다.
|
|
89
|
+
|
|
90
|
+
`prIntent`는 이후 단계에서 **Claude의 추론 컨텍스트로만** 활용합니다.
|
|
91
|
+
|
|
92
|
+
### 2단계: diff 수집
|
|
93
|
+
|
|
94
|
+
비교 기준(`target`) 대비 변경 내용을 수집합니다:
|
|
95
|
+
|
|
96
|
+
```bash
|
|
97
|
+
git log --oneline {target}..HEAD # 커밋 목록
|
|
98
|
+
git diff {target}...HEAD --stat # 변경 파일 통계
|
|
99
|
+
git diff {target}...HEAD # 실제 diff (핵심 변경만)
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
`changedFiles`와 커밋 목록을 수집합니다.
|
|
103
|
+
|
|
104
|
+
### 3단계: change-context-writer로 변경 분석
|
|
105
|
+
|
|
106
|
+
`ges_agent { action: "get", name: "change-context-writer" }`로 에이전트 시스템 프롬프트를 가져온 뒤, 해당 관점에서 diff를 분석해 변경 컨텍스트를 작성합니다.
|
|
107
|
+
|
|
108
|
+
1단계에서 수집한 `prIntent.purpose`·`prIntent.notes`가 비어 있지 않다면, diff 분석 입력에 함께 전달해 더 정확한 분석을 생성하도록 합니다.
|
|
109
|
+
|
|
110
|
+
분석 결과를 `changeContext`로 보관합니다.
|
|
111
|
+
|
|
112
|
+
### 4단계: PR description 생성
|
|
113
|
+
|
|
114
|
+
0단계의 `repoRules` 구조 + 3단계의 `changeContext` + 1단계의 `prIntent`를 합성해 PR description을 작성합니다.
|
|
115
|
+
|
|
116
|
+
- **PR 제목**: `CLAUDE.md`가 있으면 그 커밋 컨벤션을 따릅니다 (예: `type(scope): subject`).
|
|
117
|
+
- 생성된 description을 **사용자에게 미리보기로 먼저 표시**합니다.
|
|
118
|
+
|
|
119
|
+
### 5단계: gh pr create 확인 및 실행
|
|
120
|
+
|
|
121
|
+
사용자에게 확인합니다:
|
|
122
|
+
|
|
123
|
+
```
|
|
124
|
+
이 내용으로 PR을 생성할까요?
|
|
125
|
+
- 생성: 바로 생성
|
|
126
|
+
- 수정: 어떤 부분을 수정할지 알려주세요
|
|
127
|
+
- 취소: description 텍스트만 출력하고 종료
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
생성 시 heredoc 패턴으로 실행합니다:
|
|
131
|
+
|
|
132
|
+
```bash
|
|
133
|
+
gh pr create --title "..." --body "$(cat <<'EOF'
|
|
134
|
+
{description 내용}
|
|
135
|
+
EOF
|
|
136
|
+
)"
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
반환된 PR URL을 사용자에게 표시합니다 (`prUrl`).
|
|
@@ -21,6 +21,7 @@ inputs:
|
|
|
21
21
|
required: false
|
|
22
22
|
description: "Repository root (기본값: 현재 디렉토리)"
|
|
23
23
|
outputs:
|
|
24
|
+
- reviewIntent
|
|
24
25
|
- changeContext
|
|
25
26
|
- reviewReport
|
|
26
27
|
- verdict
|
|
@@ -53,6 +54,26 @@ execute 세션 없이 PR·브랜치·커밋의 변경사항을 직접 리뷰 파
|
|
|
53
54
|
`repoRoot`가 주어지지 않으면 현재 작업 디렉토리를 절대 경로로 사용합니다.
|
|
54
55
|
`target`이 주어지지 않으면 현재 브랜치 vs `main`을 기준으로 삼습니다.
|
|
55
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
|
+
|
|
56
77
|
### 1단계: 변경 파일 수집 (blast_radius)
|
|
57
78
|
|
|
58
79
|
`blast_radius`로 리뷰 대상의 변경 파일과 영향받는 파일을 수집합니다:
|
|
@@ -73,6 +94,8 @@ ges_code_graph {
|
|
|
73
94
|
|
|
74
95
|
`ges_agent { action: "get", name: "change-context-writer" }`로 에이전트 시스템 프롬프트를 가져온 뒤, 해당 관점에서 diff를 분석해 기획 컨텍스트 문서를 작성한다.
|
|
75
96
|
|
|
97
|
+
0단계에서 수집한 `reviewIntent.purpose`·`reviewIntent.background`가 `"(없음)"`이 아니라면, diff 분석 입력에 함께 전달해 더 정확한 기획 컨텍스트를 생성하도록 한다.
|
|
98
|
+
|
|
76
99
|
작성된 컨텍스트 문서를 **리뷰 결과보다 먼저** 사용자에게 표시한다.
|
|
77
100
|
|
|
78
101
|
### 2단계: 리뷰 시작 (review_start)
|
|
@@ -88,7 +111,15 @@ ges_execute {
|
|
|
88
111
|
```
|
|
89
112
|
|
|
90
113
|
응답의 `reviewSessionId`, `reviewStartContext.systemPrompt`, `reviewStartContext.matchContext`를 확보합니다.
|
|
91
|
-
`matchContext`를 참고해 이번 리뷰에 투입할 에이전트(보안·성능·품질 등)를 선택합니다.
|
|
114
|
+
`matchContext.matchingPrompt`를 참고해 이번 리뷰에 투입할 에이전트(보안·성능·품질 등)를 선택합니다.
|
|
115
|
+
|
|
116
|
+
0단계의 `reviewIntent.focusAreas`에 영역이 명시돼 있으면 해당 전문가를 **반드시 포함하고, 가장 먼저 제출**합니다:
|
|
117
|
+
- `"보안"` → security-reviewer 우선
|
|
118
|
+
- `"성능"` → performance-reviewer 우선
|
|
119
|
+
- `"품질"` → quality-reviewer 우선
|
|
120
|
+
- `"프론트엔드"` → frontend-reviewer 우선
|
|
121
|
+
|
|
122
|
+
`focusAreas`가 비어 있으면 기존 기본 순서(보안 → 성능 → 품질)를 유지합니다.
|
|
92
123
|
|
|
93
124
|
### 3단계: 에이전트별 리뷰 제출 (review_submit × 3)
|
|
94
125
|
|
|
@@ -166,7 +197,17 @@ ges_execute {
|
|
|
166
197
|
|
|
167
198
|
## 결과 표시
|
|
168
199
|
|
|
169
|
-
|
|
200
|
+
0단계의 `reviewIntent`에 `purpose` 또는 `focusAreas`가 하나라도 있으면, 전체 출력 최상단에 리뷰 컨텍스트 블록을 표시합니다 (둘 다 `"(없음)"`/빈 배열이면 블록 전체를 생략):
|
|
201
|
+
|
|
202
|
+
```
|
|
203
|
+
## 리뷰 컨텍스트
|
|
204
|
+
**목적**: {purpose 또는 "(없음)"}
|
|
205
|
+
**중점 영역**: {focusAreas 또는 "(없음)"}
|
|
206
|
+
|
|
207
|
+
---
|
|
208
|
+
```
|
|
209
|
+
|
|
210
|
+
그다음 기획 컨텍스트 문서(1.5단계)를 리뷰 리포트 앞에 먼저 표시한 뒤, 코드 리뷰 결과를 표시합니다.
|
|
170
211
|
|
|
171
212
|
```
|
|
172
213
|
{1.5단계 기획 컨텍스트 마크다운}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: interview
|
|
3
|
-
version: "1.
|
|
3
|
+
version: "1.2.0"
|
|
4
4
|
description: "Gestalt-driven interview to clarify project requirements"
|
|
5
5
|
triggers:
|
|
6
6
|
- "interview"
|
|
@@ -24,6 +24,29 @@ outputs:
|
|
|
24
24
|
|
|
25
25
|
This skill conducts a Gestalt psychology-driven interview to transform vague requirements into clear specifications.
|
|
26
26
|
|
|
27
|
+
## 0단계: 인텐트 라우팅 (인터뷰 시작 전)
|
|
28
|
+
|
|
29
|
+
인터뷰를 시작하기 전에 topic이 인터뷰 파이프라인에 적합한지 먼저 확인한다.
|
|
30
|
+
|
|
31
|
+
### PR 관련 키워드 감지
|
|
32
|
+
topic에 아래 키워드가 포함되면 `/pr` 스킬이 더 적합하다:
|
|
33
|
+
`PR`, `풀리퀘`, `풀 리퀘스트`, `pull request`, `PR 작성`, `PR 만들어`, `PR 써줘`, `PR 올려`
|
|
34
|
+
|
|
35
|
+
→ `ges_interview start`를 실행하지 않고 사용자에게 안내:
|
|
36
|
+
> "이 요청은 `/pr` 스킬이 더 적합합니다. PR 작성 전용 파이프라인(레포 규칙 탐색 → 미니 인터뷰 → diff 분석 → description 생성)으로 진행할까요?"
|
|
37
|
+
> 확인 시 `/pr` 스킬 즉시 실행.
|
|
38
|
+
|
|
39
|
+
### 코드 리뷰 관련 키워드 감지
|
|
40
|
+
topic에 아래 키워드가 포함되면 `/review` 스킬이 더 적합하다:
|
|
41
|
+
`코드리뷰`, `code review`, `리뷰해줘`, `리뷰 부탁`, `리뷰 요청`, `review`, `리뷰`
|
|
42
|
+
|
|
43
|
+
→ `ges_interview start`를 실행하지 않고 사용자에게 안내:
|
|
44
|
+
> "이 요청은 `/review` 스킬이 더 적합합니다. 코드 리뷰 전용 파이프라인(미니 인터뷰 → 기획 컨텍스트 분석 → 전문 리뷰어 검토)으로 진행할까요?"
|
|
45
|
+
> 확인 시 `/review` 스킬 즉시 실행.
|
|
46
|
+
|
|
47
|
+
### 라우팅 대상이 아닌 경우
|
|
48
|
+
위 키워드가 없으면 기존 인터뷰 파이프라인을 정상 진행한다.
|
|
49
|
+
|
|
27
50
|
## ⚠️ Critical Rule: Never Self-Answer
|
|
28
51
|
|
|
29
52
|
**You are the interviewer, not the interviewee.**
|
|
@@ -0,0 +1,139 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: pr
|
|
3
|
+
version: "1.0.0"
|
|
4
|
+
description: "PR 작성 전용 스킬. 레포 규칙을 먼저 탐색하고, 미니 인터뷰로 컨텍스트를 수집한 뒤 diff 기반 PR description을 생성하고 gh pr create로 제출한다."
|
|
5
|
+
triggers:
|
|
6
|
+
- "PR 작성"
|
|
7
|
+
- "PR 만들어"
|
|
8
|
+
- "PR 써줘"
|
|
9
|
+
- "PR 올려"
|
|
10
|
+
- "풀리퀘"
|
|
11
|
+
- "풀 리퀘스트"
|
|
12
|
+
- "pull request"
|
|
13
|
+
- "create PR"
|
|
14
|
+
inputs:
|
|
15
|
+
target:
|
|
16
|
+
type: string
|
|
17
|
+
required: false
|
|
18
|
+
description: "비교 기준 브랜치 (생략 시 현재 브랜치 vs main)"
|
|
19
|
+
repoRoot:
|
|
20
|
+
type: string
|
|
21
|
+
required: false
|
|
22
|
+
description: "Repository root (기본값: 현재 디렉토리)"
|
|
23
|
+
outputs:
|
|
24
|
+
- prIntent
|
|
25
|
+
- changeContext
|
|
26
|
+
- prDescription
|
|
27
|
+
- prUrl
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
# PR Skill
|
|
31
|
+
|
|
32
|
+
레포의 PR 규칙을 먼저 탐색하고, 미니 인터뷰로 컨텍스트를 수집한 뒤, diff를 분석해 레포 규칙에 맞는 PR description을 생성하고 `gh pr create`로 제출합니다.
|
|
33
|
+
|
|
34
|
+
## 사용 방법
|
|
35
|
+
|
|
36
|
+
```
|
|
37
|
+
/pr # 현재 브랜치 vs main
|
|
38
|
+
/pr feature/auth # 특정 브랜치
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
## 전제 조건
|
|
42
|
+
|
|
43
|
+
`repoRoot`가 주어지지 않으면 현재 작업 디렉토리를 절대 경로로 사용합니다.
|
|
44
|
+
`target`이 주어지지 않으면 현재 브랜치 vs `main`을 기준으로 삼습니다.
|
|
45
|
+
|
|
46
|
+
## Skill Instructions
|
|
47
|
+
|
|
48
|
+
### 0단계: 레포 규칙 탐색 (필수 — 스킵 불가)
|
|
49
|
+
|
|
50
|
+
PR을 작성하기 전에 레포의 PR 규칙을 반드시 먼저 탐색합니다. 아래 경로를 순서대로 확인하고, 발견한 규칙은 PR 작성에 반드시 적용합니다:
|
|
51
|
+
|
|
52
|
+
1. `.github/pull_request_template.md` / `.github/PULL_REQUEST_TEMPLATE.md`
|
|
53
|
+
2. `.github/PULL_REQUEST_TEMPLATE/*.md` (복수 템플릿이면 변경 유형에 맞는 것 선택)
|
|
54
|
+
3. `CONTRIBUTING.md` / `docs/contributing.md`
|
|
55
|
+
4. `CLAUDE.md` / `.claude/CLAUDE.md`
|
|
56
|
+
5. `.claude/rules/*.md`
|
|
57
|
+
6. `.github/CODEOWNERS`
|
|
58
|
+
|
|
59
|
+
**적용 우선순위**:
|
|
60
|
+
|
|
61
|
+
- **PR 템플릿 발견** → 해당 구조를 그대로 채웁니다. 임의 섹션 추가 금지. 다른 섹션 재구성 금지.
|
|
62
|
+
- **템플릿 없음 + CONTRIBUTING 있음** → CONTRIBUTING의 PR 규칙을 적용한 구조를 생성합니다.
|
|
63
|
+
- **둘 다 없음** → 표준 PR 포맷을 사용합니다:
|
|
64
|
+
```
|
|
65
|
+
## Summary
|
|
66
|
+
## Changes
|
|
67
|
+
## Test plan
|
|
68
|
+
## Related issues
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
탐색 결과는 `repoRules = { templatePath, templateContent, contributingRules, claudeRules }` 형태로 보관합니다.
|
|
72
|
+
|
|
73
|
+
### 1단계: 미니 인터뷰 (prIntent 수집)
|
|
74
|
+
|
|
75
|
+
본격 작성에 앞서 PR의 의도·특이사항·이슈 번호를 한 번에 가볍게 확인합니다. **세 질문을 단일 묶음으로 한 번에 제시**하고, 사용자의 한 번의 응답으로 처리합니다 (1턴 경량 인터뷰):
|
|
76
|
+
|
|
77
|
+
```
|
|
78
|
+
PR을 작성하기 전에 세 가지를 확인합니다. 없으면 Enter / "없음"으로 건너뛰어도 됩니다.
|
|
79
|
+
|
|
80
|
+
1. 이 PR의 주요 목적/의도는? (한 줄)
|
|
81
|
+
2. 리뷰어가 미리 알면 좋을 특이사항이 있나요?
|
|
82
|
+
3. 관련 이슈/티켓 번호가 있나요?
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
사용자 응답을 `prIntent = { purpose, notes, issueRef }` 형태로 보관합니다.
|
|
86
|
+
|
|
87
|
+
- 각 항목별로 빈 응답·`"없음"`은 해당 항목을 비워 둡니다.
|
|
88
|
+
- **전체 건너뛰기**: 사용자가 `"없음"` / `"스킵"` / `"바로 PR"` 등으로 (개별 질문이 아닌) 1단계 자체를 건너뛰겠다는 의사를 보이면, 1단계 전체를 건너뛰고 `prIntent`의 모든 항목을 비워 둔 채 2단계로 바로 진행합니다.
|
|
89
|
+
|
|
90
|
+
`prIntent`는 이후 단계에서 **Claude의 추론 컨텍스트로만** 활용합니다.
|
|
91
|
+
|
|
92
|
+
### 2단계: diff 수집
|
|
93
|
+
|
|
94
|
+
비교 기준(`target`) 대비 변경 내용을 수집합니다:
|
|
95
|
+
|
|
96
|
+
```bash
|
|
97
|
+
git log --oneline {target}..HEAD # 커밋 목록
|
|
98
|
+
git diff {target}...HEAD --stat # 변경 파일 통계
|
|
99
|
+
git diff {target}...HEAD # 실제 diff (핵심 변경만)
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
`changedFiles`와 커밋 목록을 수집합니다.
|
|
103
|
+
|
|
104
|
+
### 3단계: change-context-writer로 변경 분석
|
|
105
|
+
|
|
106
|
+
`ges_agent { action: "get", name: "change-context-writer" }`로 에이전트 시스템 프롬프트를 가져온 뒤, 해당 관점에서 diff를 분석해 변경 컨텍스트를 작성합니다.
|
|
107
|
+
|
|
108
|
+
1단계에서 수집한 `prIntent.purpose`·`prIntent.notes`가 비어 있지 않다면, diff 분석 입력에 함께 전달해 더 정확한 분석을 생성하도록 합니다.
|
|
109
|
+
|
|
110
|
+
분석 결과를 `changeContext`로 보관합니다.
|
|
111
|
+
|
|
112
|
+
### 4단계: PR description 생성
|
|
113
|
+
|
|
114
|
+
0단계의 `repoRules` 구조 + 3단계의 `changeContext` + 1단계의 `prIntent`를 합성해 PR description을 작성합니다.
|
|
115
|
+
|
|
116
|
+
- **PR 제목**: `CLAUDE.md`가 있으면 그 커밋 컨벤션을 따릅니다 (예: `type(scope): subject`).
|
|
117
|
+
- 생성된 description을 **사용자에게 미리보기로 먼저 표시**합니다.
|
|
118
|
+
|
|
119
|
+
### 5단계: gh pr create 확인 및 실행
|
|
120
|
+
|
|
121
|
+
사용자에게 확인합니다:
|
|
122
|
+
|
|
123
|
+
```
|
|
124
|
+
이 내용으로 PR을 생성할까요?
|
|
125
|
+
- 생성: 바로 생성
|
|
126
|
+
- 수정: 어떤 부분을 수정할지 알려주세요
|
|
127
|
+
- 취소: description 텍스트만 출력하고 종료
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
생성 시 heredoc 패턴으로 실행합니다:
|
|
131
|
+
|
|
132
|
+
```bash
|
|
133
|
+
gh pr create --title "..." --body "$(cat <<'EOF'
|
|
134
|
+
{description 내용}
|
|
135
|
+
EOF
|
|
136
|
+
)"
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
반환된 PR URL을 사용자에게 표시합니다 (`prUrl`).
|
package/skills/review/SKILL.md
CHANGED
|
@@ -21,6 +21,7 @@ inputs:
|
|
|
21
21
|
required: false
|
|
22
22
|
description: "Repository root (기본값: 현재 디렉토리)"
|
|
23
23
|
outputs:
|
|
24
|
+
- reviewIntent
|
|
24
25
|
- changeContext
|
|
25
26
|
- reviewReport
|
|
26
27
|
- verdict
|
|
@@ -53,6 +54,26 @@ execute 세션 없이 PR·브랜치·커밋의 변경사항을 직접 리뷰 파
|
|
|
53
54
|
`repoRoot`가 주어지지 않으면 현재 작업 디렉토리를 절대 경로로 사용합니다.
|
|
54
55
|
`target`이 주어지지 않으면 현재 브랜치 vs `main`을 기준으로 삼습니다.
|
|
55
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
|
+
|
|
56
77
|
### 1단계: 변경 파일 수집 (blast_radius)
|
|
57
78
|
|
|
58
79
|
`blast_radius`로 리뷰 대상의 변경 파일과 영향받는 파일을 수집합니다:
|
|
@@ -73,6 +94,8 @@ ges_code_graph {
|
|
|
73
94
|
|
|
74
95
|
`ges_agent { action: "get", name: "change-context-writer" }`로 에이전트 시스템 프롬프트를 가져온 뒤, 해당 관점에서 diff를 분석해 기획 컨텍스트 문서를 작성한다.
|
|
75
96
|
|
|
97
|
+
0단계에서 수집한 `reviewIntent.purpose`·`reviewIntent.background`가 `"(없음)"`이 아니라면, diff 분석 입력에 함께 전달해 더 정확한 기획 컨텍스트를 생성하도록 한다.
|
|
98
|
+
|
|
76
99
|
작성된 컨텍스트 문서를 **리뷰 결과보다 먼저** 사용자에게 표시한다.
|
|
77
100
|
|
|
78
101
|
### 2단계: 리뷰 시작 (review_start)
|
|
@@ -88,7 +111,15 @@ ges_execute {
|
|
|
88
111
|
```
|
|
89
112
|
|
|
90
113
|
응답의 `reviewSessionId`, `reviewStartContext.systemPrompt`, `reviewStartContext.matchContext`를 확보합니다.
|
|
91
|
-
`matchContext`를 참고해 이번 리뷰에 투입할 에이전트(보안·성능·품질 등)를 선택합니다.
|
|
114
|
+
`matchContext.matchingPrompt`를 참고해 이번 리뷰에 투입할 에이전트(보안·성능·품질 등)를 선택합니다.
|
|
115
|
+
|
|
116
|
+
0단계의 `reviewIntent.focusAreas`에 영역이 명시돼 있으면 해당 전문가를 **반드시 포함하고, 가장 먼저 제출**합니다:
|
|
117
|
+
- `"보안"` → security-reviewer 우선
|
|
118
|
+
- `"성능"` → performance-reviewer 우선
|
|
119
|
+
- `"품질"` → quality-reviewer 우선
|
|
120
|
+
- `"프론트엔드"` → frontend-reviewer 우선
|
|
121
|
+
|
|
122
|
+
`focusAreas`가 비어 있으면 기존 기본 순서(보안 → 성능 → 품질)를 유지합니다.
|
|
92
123
|
|
|
93
124
|
### 3단계: 에이전트별 리뷰 제출 (review_submit × 3)
|
|
94
125
|
|
|
@@ -166,7 +197,17 @@ ges_execute {
|
|
|
166
197
|
|
|
167
198
|
## 결과 표시
|
|
168
199
|
|
|
169
|
-
|
|
200
|
+
0단계의 `reviewIntent`에 `purpose` 또는 `focusAreas`가 하나라도 있으면, 전체 출력 최상단에 리뷰 컨텍스트 블록을 표시합니다 (둘 다 `"(없음)"`/빈 배열이면 블록 전체를 생략):
|
|
201
|
+
|
|
202
|
+
```
|
|
203
|
+
## 리뷰 컨텍스트
|
|
204
|
+
**목적**: {purpose 또는 "(없음)"}
|
|
205
|
+
**중점 영역**: {focusAreas 또는 "(없음)"}
|
|
206
|
+
|
|
207
|
+
---
|
|
208
|
+
```
|
|
209
|
+
|
|
210
|
+
그다음 기획 컨텍스트 문서(1.5단계)를 리뷰 리포트 앞에 먼저 표시한 뒤, 코드 리뷰 결과를 표시합니다.
|
|
170
211
|
|
|
171
212
|
```
|
|
172
213
|
{1.5단계 기획 컨텍스트 마크다운}
|