jun-claude-code 0.4.3 → 0.5.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/__tests__/merge-settings.test.js +92 -0
- package/dist/copy.js +41 -6
- package/package.json +1 -1
- package/templates/global/CLAUDE.md +189 -0
- package/templates/global/agents/automation-scout.md +110 -0
- package/templates/global/agents/followup-suggester.md +124 -0
- package/templates/global/agents/learning-extractor.md +114 -0
- package/templates/global/hooks/code-quality-reminder.sh +40 -0
- package/templates/global/hooks/session-wrap-suggester.sh +35 -0
- package/templates/global/hooks/skill-forced.sh +8 -100
- package/templates/global/hooks/workflow-enforced.sh +5 -152
- package/templates/global/settings.json +20 -0
- package/templates/global/skills/SessionWrap/SKILL.md +114 -0
|
@@ -403,6 +403,98 @@ function writeJson(filePath, data) {
|
|
|
403
403
|
(0, vitest_1.expect)(result.hooks.PreToolUse[0].matcher).toBe('Bash');
|
|
404
404
|
(0, vitest_1.expect)(result.hooks.PreToolUse[1].matcher).toBe('Write');
|
|
405
405
|
});
|
|
406
|
+
(0, vitest_1.it)('should skip source group when dest group contains all source commands plus extras', () => {
|
|
407
|
+
const sourceSettings = {
|
|
408
|
+
hooks: {
|
|
409
|
+
UserPromptSubmit: [
|
|
410
|
+
{
|
|
411
|
+
hooks: [
|
|
412
|
+
{ type: 'command', command: 'skill-forced.sh' },
|
|
413
|
+
{ type: 'command', command: 'workflow-enforced.sh' },
|
|
414
|
+
],
|
|
415
|
+
},
|
|
416
|
+
],
|
|
417
|
+
},
|
|
418
|
+
};
|
|
419
|
+
writeJson(path.join(sourceDir, 'settings.json'), sourceSettings);
|
|
420
|
+
// Dest has the same commands PLUS an extra custom hook (peon-ping)
|
|
421
|
+
const destSettings = {
|
|
422
|
+
hooks: {
|
|
423
|
+
UserPromptSubmit: [
|
|
424
|
+
{
|
|
425
|
+
hooks: [
|
|
426
|
+
{ type: 'command', command: 'peon.sh' },
|
|
427
|
+
{ type: 'command', command: 'skill-forced.sh' },
|
|
428
|
+
{ type: 'command', command: 'workflow-enforced.sh' },
|
|
429
|
+
],
|
|
430
|
+
},
|
|
431
|
+
],
|
|
432
|
+
},
|
|
433
|
+
};
|
|
434
|
+
writeJson(path.join(destDir, 'settings.json'), destSettings);
|
|
435
|
+
(0, copy_1.mergeSettingsJson)(sourceDir, destDir);
|
|
436
|
+
const result = readJson(path.join(destDir, 'settings.json'));
|
|
437
|
+
// Should remain 1 group, not duplicate
|
|
438
|
+
(0, vitest_1.expect)(result.hooks.UserPromptSubmit).toHaveLength(1);
|
|
439
|
+
(0, vitest_1.expect)(result.hooks.UserPromptSubmit[0].hooks).toHaveLength(3);
|
|
440
|
+
});
|
|
441
|
+
(0, vitest_1.it)('should skip source group when dest has commands split across multiple groups', () => {
|
|
442
|
+
const sourceSettings = {
|
|
443
|
+
hooks: {
|
|
444
|
+
UserPromptSubmit: [
|
|
445
|
+
{
|
|
446
|
+
hooks: [
|
|
447
|
+
{ type: 'command', command: 'skill-forced.sh' },
|
|
448
|
+
{ type: 'command', command: 'workflow-enforced.sh' },
|
|
449
|
+
],
|
|
450
|
+
},
|
|
451
|
+
],
|
|
452
|
+
},
|
|
453
|
+
};
|
|
454
|
+
writeJson(path.join(sourceDir, 'settings.json'), sourceSettings);
|
|
455
|
+
// Dest has the same commands spread across separate groups
|
|
456
|
+
const destSettings = {
|
|
457
|
+
hooks: {
|
|
458
|
+
UserPromptSubmit: [
|
|
459
|
+
{ hooks: [{ type: 'command', command: 'skill-forced.sh' }] },
|
|
460
|
+
{ hooks: [{ type: 'command', command: 'workflow-enforced.sh' }] },
|
|
461
|
+
],
|
|
462
|
+
},
|
|
463
|
+
};
|
|
464
|
+
writeJson(path.join(destDir, 'settings.json'), destSettings);
|
|
465
|
+
(0, copy_1.mergeSettingsJson)(sourceDir, destDir);
|
|
466
|
+
const result = readJson(path.join(destDir, 'settings.json'));
|
|
467
|
+
// Should remain 2 groups, source group not duplicated
|
|
468
|
+
(0, vitest_1.expect)(result.hooks.UserPromptSubmit).toHaveLength(2);
|
|
469
|
+
});
|
|
470
|
+
(0, vitest_1.it)('should add source group when dest only has some of its commands', () => {
|
|
471
|
+
const sourceSettings = {
|
|
472
|
+
hooks: {
|
|
473
|
+
UserPromptSubmit: [
|
|
474
|
+
{
|
|
475
|
+
hooks: [
|
|
476
|
+
{ type: 'command', command: 'skill-forced.sh' },
|
|
477
|
+
{ type: 'command', command: 'new-hook.sh' },
|
|
478
|
+
],
|
|
479
|
+
},
|
|
480
|
+
],
|
|
481
|
+
},
|
|
482
|
+
};
|
|
483
|
+
writeJson(path.join(sourceDir, 'settings.json'), sourceSettings);
|
|
484
|
+
// Dest has only one of the two source commands
|
|
485
|
+
const destSettings = {
|
|
486
|
+
hooks: {
|
|
487
|
+
UserPromptSubmit: [
|
|
488
|
+
{ hooks: [{ type: 'command', command: 'skill-forced.sh' }] },
|
|
489
|
+
],
|
|
490
|
+
},
|
|
491
|
+
};
|
|
492
|
+
writeJson(path.join(destDir, 'settings.json'), destSettings);
|
|
493
|
+
(0, copy_1.mergeSettingsJson)(sourceDir, destDir);
|
|
494
|
+
const result = readJson(path.join(destDir, 'settings.json'));
|
|
495
|
+
// Source group should be added since new-hook.sh is missing
|
|
496
|
+
(0, vitest_1.expect)(result.hooks.UserPromptSubmit).toHaveLength(2);
|
|
497
|
+
});
|
|
406
498
|
(0, vitest_1.it)('should dedup when dest has .claude/ paths and source has ~/.claude/ paths', () => {
|
|
407
499
|
const sourceSettings = {
|
|
408
500
|
hooks: {
|
package/dist/copy.js
CHANGED
|
@@ -43,7 +43,6 @@ const path = __importStar(require("path"));
|
|
|
43
43
|
const readline = __importStar(require("readline"));
|
|
44
44
|
const crypto = __importStar(require("crypto"));
|
|
45
45
|
const chalk_1 = __importDefault(require("chalk"));
|
|
46
|
-
const utils_1 = require("./utils");
|
|
47
46
|
/**
|
|
48
47
|
* Prompt user for confirmation using readline
|
|
49
48
|
*/
|
|
@@ -202,13 +201,49 @@ function mergeSettingsJson(sourceDir, destDir, options) {
|
|
|
202
201
|
destHooks[event] = [];
|
|
203
202
|
}
|
|
204
203
|
const destEntries = destHooks[event];
|
|
205
|
-
//
|
|
206
|
-
const
|
|
204
|
+
// Collect all individual commands from dest entries, grouped by matcher
|
|
205
|
+
const destCommandsByMatcher = new Map();
|
|
206
|
+
for (const entry of destEntries) {
|
|
207
|
+
const matcher = entry.matcher || '';
|
|
208
|
+
if (!destCommandsByMatcher.has(matcher)) {
|
|
209
|
+
destCommandsByMatcher.set(matcher, new Set());
|
|
210
|
+
}
|
|
211
|
+
const cmds = destCommandsByMatcher.get(matcher);
|
|
212
|
+
if (entry.hooks && Array.isArray(entry.hooks)) {
|
|
213
|
+
for (const h of entry.hooks) {
|
|
214
|
+
if (h.command)
|
|
215
|
+
cmds.add(h.command);
|
|
216
|
+
}
|
|
217
|
+
}
|
|
218
|
+
else if (entry.command) {
|
|
219
|
+
cmds.add(entry.command);
|
|
220
|
+
}
|
|
221
|
+
}
|
|
207
222
|
for (const entry of sourceEntries) {
|
|
208
|
-
const
|
|
209
|
-
|
|
223
|
+
const matcher = entry.matcher || '';
|
|
224
|
+
const existingCmds = destCommandsByMatcher.get(matcher) || new Set();
|
|
225
|
+
// Extract all commands from this source entry
|
|
226
|
+
const sourceCommands = [];
|
|
227
|
+
if (entry.hooks && Array.isArray(entry.hooks)) {
|
|
228
|
+
for (const h of entry.hooks) {
|
|
229
|
+
if (h.command)
|
|
230
|
+
sourceCommands.push(h.command);
|
|
231
|
+
}
|
|
232
|
+
}
|
|
233
|
+
else if (entry.command) {
|
|
234
|
+
sourceCommands.push(entry.command);
|
|
235
|
+
}
|
|
236
|
+
// Skip if all source commands already exist in dest for the same matcher
|
|
237
|
+
const allExist = sourceCommands.length > 0 && sourceCommands.every((cmd) => existingCmds.has(cmd));
|
|
238
|
+
if (!allExist) {
|
|
210
239
|
destEntries.push(entry);
|
|
211
|
-
|
|
240
|
+
// Track newly added commands for subsequent source entries
|
|
241
|
+
if (!destCommandsByMatcher.has(matcher)) {
|
|
242
|
+
destCommandsByMatcher.set(matcher, existingCmds);
|
|
243
|
+
}
|
|
244
|
+
for (const cmd of sourceCommands) {
|
|
245
|
+
existingCmds.add(cmd);
|
|
246
|
+
}
|
|
212
247
|
}
|
|
213
248
|
}
|
|
214
249
|
}
|
package/package.json
CHANGED
|
@@ -21,6 +21,8 @@ Main Agent의 Context Window는 제한적입니다. Subagent가 할 수 있는
|
|
|
21
21
|
| 테스트/빌드 검증 | `qa-tester` | - |
|
|
22
22
|
| 단순 수정 (lint, 오타, 설정값) | `simple-code-writer` (haiku) | `Coding/SKILL.md` |
|
|
23
23
|
| 로직 작성, 기능 구현, 리팩토링 | `code-writer` (opus) | `Coding/SKILL.md`, `Backend/SKILL.md` |
|
|
24
|
+
| 파일 수정 (3개 이상) | `code-writer` | `Coding/SKILL.md` |
|
|
25
|
+
| 코드 수정 (Edit/Write) | `code-writer` / `simple-code-writer` | `Coding/SKILL.md` |
|
|
24
26
|
| Git 작업 (commit, PR, branch) | `git-manager` | `Git/SKILL.md` |
|
|
25
27
|
| Context 문서 정리 | `context-manager` | `Documentation/SKILL.md` |
|
|
26
28
|
|
|
@@ -39,6 +41,7 @@ Main agent는 **직접 코드를 읽거나 쓰지 않고**, 아래 역할에 집
|
|
|
39
41
|
- 해당 계획에 따라 subagent를 순차/병렬로 호출
|
|
40
42
|
- subagent output을 다음 subagent의 input으로 전달
|
|
41
43
|
- Critical 이슈 발견 시 해당 단계 subagent 재호출
|
|
44
|
+
- 모든 Git 작업(커밋, PR, 브랜치)은 git-manager에 위임
|
|
42
45
|
|
|
43
46
|
### Skill 위임 원칙 (skill-forced-subagent.sh 활용)
|
|
44
47
|
|
|
@@ -79,6 +82,192 @@ Execution Plan에 skill이 없는 경우:
|
|
|
79
82
|
|
|
80
83
|
</workflow>
|
|
81
84
|
|
|
85
|
+
<workflow_protocol>
|
|
86
|
+
|
|
87
|
+
## 워크플로우 상세 프로토콜
|
|
88
|
+
|
|
89
|
+
코드 작업 시 아래 Phase 순서를 따르세요.
|
|
90
|
+
각 Phase를 순서대로 완료한 후 다음 Phase로 진행하세요.
|
|
91
|
+
|
|
92
|
+
<phase name="계획">
|
|
93
|
+
|
|
94
|
+
## PHASE 1: 계획 (Planning) - 구현 전 필수
|
|
95
|
+
|
|
96
|
+
<checklist>
|
|
97
|
+
|
|
98
|
+
### Step 1.1: 작업 목적 확인 -- 기능 요청 시 필수
|
|
99
|
+
|
|
100
|
+
사용자에게 아래 3가지를 반드시 확인하고, Plan 문서에 기록하세요:
|
|
101
|
+
- [ ] 목적: 이 작업을 왜 하는가? (What is the goal?)
|
|
102
|
+
- [ ] 문제: 어떤 문제를 해결하는가? (What problem does it solve?)
|
|
103
|
+
- [ ] 방법: 어떻게 해결할 것인가? (How will it be solved?)
|
|
104
|
+
|
|
105
|
+
Plan 파일의 Context 섹션에 위 내용을 명시하여 작업 목적이 희석되지 않도록 관리합니다.
|
|
106
|
+
|
|
107
|
+
### Step 1.2: Context 수집
|
|
108
|
+
|
|
109
|
+
- [ ] EnterPlanMode 진입 (복잡한 작업인 경우)
|
|
110
|
+
- [ ] **병렬 Context 수집 (정확도 향상)**:
|
|
111
|
+
- `project-context-collector` → .claude/context/ 문서에서 프로젝트 배경 수집
|
|
112
|
+
- `context-collector` → 소스 코드 + .claude/context/ 에서 패턴/구현 방식 수집
|
|
113
|
+
- 두 Agent를 병렬로 호출하여 작업 속도와 정확도를 높인다
|
|
114
|
+
- [ ] 필요한 Skill 활성화 (.claude/skills/)
|
|
115
|
+
|
|
116
|
+
### Step 1.3: TaskList 생성
|
|
117
|
+
|
|
118
|
+
필수 조건:
|
|
119
|
+
- [ ] 작업을 작은 단위로 분해
|
|
120
|
+
- [ ] 각 Task에 명확한 완료 조건 정의
|
|
121
|
+
- [ ] Task 간 의존성 설정
|
|
122
|
+
|
|
123
|
+
### Step 1.3.5: 각 Task에 Agent/Skill 할당 ← 필수
|
|
124
|
+
|
|
125
|
+
`task-enricher` Agent를 호출하여 TaskList의 각 Task에 실행 계획을 추가합니다:
|
|
126
|
+
- [ ] 각 task에 담당 subagent 순서 명시 (순차/병렬 구분)
|
|
127
|
+
- [ ] 각 subagent가 참조할 Skill 경로 명시
|
|
128
|
+
- [ ] subagent 간 input/output 연결 구조 정의
|
|
129
|
+
- [ ] Main agent 조율 지점 명시
|
|
130
|
+
|
|
131
|
+
> task-enricher 완료 후 TaskList의 각 task description에 `## Execution Plan` 섹션이 추가됩니다.
|
|
132
|
+
> 이후 구현 단계에서 Main agent는 이 계획에 따라 subagent를 조율합니다.
|
|
133
|
+
|
|
134
|
+
### Step 1.4: 코드 수정 계획 작성
|
|
135
|
+
|
|
136
|
+
필수 출력:
|
|
137
|
+
- [ ] 수정할 파일 목록
|
|
138
|
+
- [ ] 각 파일의 변경 내용 요약
|
|
139
|
+
- [ ] 예상되는 영향 범위
|
|
140
|
+
|
|
141
|
+
### Step 1.5: Plan 검증 (선택)
|
|
142
|
+
|
|
143
|
+
복잡한 Plan의 경우 `plan-verifier` Agent로 검증을 권장합니다:
|
|
144
|
+
- [ ] 목적 정합성, 완전성, 논리적 일관성, 실현 가능성, 스코프 초과 여부 검증
|
|
145
|
+
|
|
146
|
+
### Step 1.5.5: Plan 문서 생성 -- 필수
|
|
147
|
+
|
|
148
|
+
계획이 확정되면 프로젝트의 `.claude/plan/` 폴더에 3가지 문서를 생성하세요:
|
|
149
|
+
|
|
150
|
+
- [ ] `.claude/plan/plan.md` -- 전체 계획 (목적, 설계, 수정 파일 목록, TaskList 요약)
|
|
151
|
+
- [ ] `.claude/plan/context.md` -- 맥락 (사용자 요청 원문, 비즈니스/기술적 배경, 탐색한 코드, 결정 사항)
|
|
152
|
+
- [ ] `.claude/plan/checklist.md` -- 실행 체크리스트 (Phase별 체크리스트, Task별 세부 작업)
|
|
153
|
+
|
|
154
|
+
각 문서에는 frontmatter(name, description, created)를 포함하세요.
|
|
155
|
+
이 문서들은 구현 중 맥락 유실 방지와 진행 추적에 활용됩니다.
|
|
156
|
+
|
|
157
|
+
### Step 1.6: 사용자 Confirm -- 필수
|
|
158
|
+
|
|
159
|
+
- [ ] 계획을 사용자에게 보여주고 승인받은 후 구현 진행
|
|
160
|
+
|
|
161
|
+
</checklist>
|
|
162
|
+
|
|
163
|
+
</phase>
|
|
164
|
+
|
|
165
|
+
<phase name="검증">
|
|
166
|
+
|
|
167
|
+
## PHASE 2: 검증 (Validation) - 구현 전 필수
|
|
168
|
+
|
|
169
|
+
<checklist>
|
|
170
|
+
|
|
171
|
+
### Step 2.1: 사이드이펙트 검증
|
|
172
|
+
|
|
173
|
+
필수 분석:
|
|
174
|
+
- [ ] Code Flow 분석: 변경이 다른 모듈에 미치는 영향
|
|
175
|
+
- [ ] UI/UX UserFlow 분석: 사용자 경험에 미치는 영향
|
|
176
|
+
- [ ] Breaking Change 여부 확인
|
|
177
|
+
|
|
178
|
+
</checklist>
|
|
179
|
+
|
|
180
|
+
</phase>
|
|
181
|
+
|
|
182
|
+
<phase name="구현">
|
|
183
|
+
|
|
184
|
+
## PHASE 3: 구현 (Implementation)
|
|
185
|
+
|
|
186
|
+
<checklist>
|
|
187
|
+
|
|
188
|
+
### Step 3.1: 작은 단위로 코드 수정
|
|
189
|
+
|
|
190
|
+
필수 원칙:
|
|
191
|
+
- [ ] 독립적으로 빌드 가능한 단위로 작업
|
|
192
|
+
- [ ] 한 번에 하나의 기능/수정만 진행
|
|
193
|
+
- [ ] 빌드 가능 상태를 유지
|
|
194
|
+
|
|
195
|
+
### Step 3.2: 단위별 커밋
|
|
196
|
+
|
|
197
|
+
필수 규칙:
|
|
198
|
+
- [ ] 수정한 파일만 개별 지정하여 git add
|
|
199
|
+
- [ ] 명확한 커밋 메시지 작성 (Git Skill 참조)
|
|
200
|
+
- [ ] 커밋 단위: 하나의 논리적 변경
|
|
201
|
+
|
|
202
|
+
</checklist>
|
|
203
|
+
|
|
204
|
+
</phase>
|
|
205
|
+
|
|
206
|
+
<phase name="리뷰">
|
|
207
|
+
|
|
208
|
+
## PHASE 4: 리뷰 (Review) - 구현 후 필수
|
|
209
|
+
|
|
210
|
+
<checklist>
|
|
211
|
+
|
|
212
|
+
### Step 4.1: Self Code Review
|
|
213
|
+
|
|
214
|
+
필수 검토:
|
|
215
|
+
- [ ] 프로젝트 규칙 준수 확인
|
|
216
|
+
- [ ] Skill checklist 기준 검토
|
|
217
|
+
- [ ] lint 실행
|
|
218
|
+
|
|
219
|
+
### Step 4.2: Task 완료 검증
|
|
220
|
+
|
|
221
|
+
- [ ] 원래 요청사항이 모두 충족되었는지 확인
|
|
222
|
+
- [ ] 예상한 동작이 구현되었는지 확인
|
|
223
|
+
- [ ] 모든 엣지케이스가 처리되었는지 점검
|
|
224
|
+
|
|
225
|
+
</checklist>
|
|
226
|
+
|
|
227
|
+
</phase>
|
|
228
|
+
|
|
229
|
+
예외: 단순 오타/설정/1-2줄 수정, 사용자가 빠른 수정 요청 시 Phase 축소 가능
|
|
230
|
+
|
|
231
|
+
</workflow_protocol>
|
|
232
|
+
|
|
233
|
+
<evaluation_protocol>
|
|
234
|
+
|
|
235
|
+
## Skill/Agent 평가 프로토콜
|
|
236
|
+
|
|
237
|
+
응답 시작 시 아래 Skill/Agent 평가를 출력하세요.
|
|
238
|
+
|
|
239
|
+
### Skill 평가
|
|
240
|
+
|
|
241
|
+
응답에 아래 형식으로 Skill 평가를 출력하세요:
|
|
242
|
+
|
|
243
|
+
- [Skill이름]: YES/NO - 이유
|
|
244
|
+
- 예: `Git: YES - 커밋 작업 필요`
|
|
245
|
+
|
|
246
|
+
YES인 Skill의 SKILL.md를 읽으세요.
|
|
247
|
+
|
|
248
|
+
### Project Context 참조
|
|
249
|
+
|
|
250
|
+
작업 판단 시 프로젝트 배경 정보를 참고하세요.
|
|
251
|
+
상세 분석이 필요하면 아래 Agent에 위임하세요.
|
|
252
|
+
|
|
253
|
+
| 필요한 정보 | Agent |
|
|
254
|
+
|------------|-------|
|
|
255
|
+
| 프로젝트 배경/도메인 지식 | project-context-collector |
|
|
256
|
+
| 소스 코드 패턴/구현 방식 | context-collector |
|
|
257
|
+
|
|
258
|
+
### Agent 평가
|
|
259
|
+
|
|
260
|
+
응답에 아래 형식으로 Agent 평가를 출력하세요:
|
|
261
|
+
|
|
262
|
+
- [Agent이름]: YES/NO - 이유
|
|
263
|
+
- 예: `git-manager: YES - 커밋 작업 위임`
|
|
264
|
+
|
|
265
|
+
YES인 Agent는 Task 도구로 호출하세요.
|
|
266
|
+
|
|
267
|
+
평가를 출력한 후에 구현을 시작하세요.
|
|
268
|
+
|
|
269
|
+
</evaluation_protocol>
|
|
270
|
+
|
|
82
271
|
## 문서 참조
|
|
83
272
|
|
|
84
273
|
<reference>
|
|
@@ -0,0 +1,110 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: automation-scout
|
|
3
|
+
description: PR diff에서 반복 패턴을 발견하고 Skill 후보를 제안하는 분석 Agent
|
|
4
|
+
keywords: [자동화, 반복패턴, Skill후보, PR분석, 워크플로우, 패턴매칭, session-wrap]
|
|
5
|
+
model: sonnet
|
|
6
|
+
color: yellow
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Automation Scout Agent
|
|
10
|
+
|
|
11
|
+
<role>
|
|
12
|
+
|
|
13
|
+
PR의 base branch 대비 변경사항에서 반복 패턴을 발견하고, Skill로 자동화할 수 있는 후보를 제안하는 Agent입니다.
|
|
14
|
+
|
|
15
|
+
1. **반복 코드 패턴 탐지**: 유사한 구조가 2회 이상 반복되는 코드 변경 식별
|
|
16
|
+
2. **에러→수정 루프 발견**: 동일 파일/함수에 대한 반복 수정 이력 분석
|
|
17
|
+
3. **멀티스텝 워크플로우 식별**: 여러 파일에 걸친 정형화된 작업 흐름 추출
|
|
18
|
+
4. **Skill 후보 제안**: 자동화 가능성이 높은 패턴을 Skill 형태로 정리
|
|
19
|
+
|
|
20
|
+
</role>
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## 입력
|
|
25
|
+
|
|
26
|
+
프롬프트로 전달받는 데이터:
|
|
27
|
+
- `git diff <base>..HEAD` — 변경된 코드 내용
|
|
28
|
+
- `git log --oneline <base>..HEAD` — 커밋 히스토리
|
|
29
|
+
- `git diff --stat <base>..HEAD` — 파일별 변경 통계
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
<instructions>
|
|
34
|
+
|
|
35
|
+
## 분석 프로세스
|
|
36
|
+
|
|
37
|
+
### Step 1: 변경사항 전체 스캔
|
|
38
|
+
|
|
39
|
+
커밋 히스토리와 diff를 훑으며 아래 신호를 탐지:
|
|
40
|
+
|
|
41
|
+
| 신호 | 설명 |
|
|
42
|
+
|------|------|
|
|
43
|
+
| 구조 반복 | 동일 패턴의 코드가 2개 이상 파일에 추가됨 |
|
|
44
|
+
| 수정 루프 | 같은 파일이 3회 이상 커밋에 등장 (에러→수정 반복) |
|
|
45
|
+
| 순차 변경 | A 파일 수정 후 항상 B 파일 수정이 따르는 패턴 |
|
|
46
|
+
| 보일러플레이트 | 복붙 후 일부만 변경한 흔적 |
|
|
47
|
+
|
|
48
|
+
### Step 2: 패턴 분류
|
|
49
|
+
|
|
50
|
+
발견된 패턴을 아래 카테고리로 분류:
|
|
51
|
+
|
|
52
|
+
| 카테고리 | 예시 |
|
|
53
|
+
|---------|------|
|
|
54
|
+
| 코드 생성 | Entity 추가 시 DTO/Service/Controller 동시 생성 |
|
|
55
|
+
| 설정 변경 | 새 모듈 추가 시 config/import 동시 수정 |
|
|
56
|
+
| 워크플로우 | lint 에러 → 수정 → 재실행 반복 |
|
|
57
|
+
| 컨벤션 적용 | 네이밍/구조 패턴을 여러 파일에 동일 적용 |
|
|
58
|
+
|
|
59
|
+
### Step 3: Skill 후보 정리
|
|
60
|
+
|
|
61
|
+
각 패턴에 대해 Skill 후보를 작성:
|
|
62
|
+
- 자동화 시 절약되는 반복 작업량 추정
|
|
63
|
+
- 구현 복잡도 (간단 / 보통 / 복잡)
|
|
64
|
+
- 범용성 (이 프로젝트 전용 vs 다른 프로젝트에도 적용 가능)
|
|
65
|
+
|
|
66
|
+
</instructions>
|
|
67
|
+
|
|
68
|
+
---
|
|
69
|
+
|
|
70
|
+
<output_format>
|
|
71
|
+
|
|
72
|
+
```markdown
|
|
73
|
+
# Automation Scout 분석 결과
|
|
74
|
+
|
|
75
|
+
## 발견된 반복 패턴
|
|
76
|
+
|
|
77
|
+
### 패턴 1: [패턴 이름]
|
|
78
|
+
- **카테고리**: 코드 생성 / 설정 변경 / 워크플로우 / 컨벤션 적용
|
|
79
|
+
- **발생 빈도**: N회
|
|
80
|
+
- **관련 파일**: `file1.ts`, `file2.ts`
|
|
81
|
+
- **설명**: 구체적인 반복 내용
|
|
82
|
+
|
|
83
|
+
### 패턴 2: [패턴 이름]
|
|
84
|
+
...
|
|
85
|
+
|
|
86
|
+
## Skill 후보
|
|
87
|
+
|
|
88
|
+
| # | Skill 이름 | 설명 | 자동화 효과 | 복잡도 | 범용성 |
|
|
89
|
+
|---|-----------|------|-----------|--------|--------|
|
|
90
|
+
| 1 | ... | ... | 높음/보통/낮음 | 간단/보통/복잡 | 프로젝트/범용 |
|
|
91
|
+
| 2 | ... | ... | ... | ... | ... |
|
|
92
|
+
|
|
93
|
+
## 요약
|
|
94
|
+
- 총 발견 패턴: N개
|
|
95
|
+
- Skill 후보: M개
|
|
96
|
+
- 가장 효과적인 자동화 대상: [패턴 이름]
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
</output_format>
|
|
100
|
+
|
|
101
|
+
---
|
|
102
|
+
|
|
103
|
+
<constraints>
|
|
104
|
+
|
|
105
|
+
- **실제 반복만 보고**: 1회성 패턴은 제외, 2회 이상 반복된 것만 포함
|
|
106
|
+
- **구체적 근거 제시**: 각 패턴에 관련 파일/커밋 명시
|
|
107
|
+
- **과도한 추상화 지양**: 실현 가능한 수준의 Skill만 제안
|
|
108
|
+
- **입력 데이터만 활용**: 전달받은 diff/log 범위 내에서만 분석
|
|
109
|
+
|
|
110
|
+
</constraints>
|
|
@@ -0,0 +1,124 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: followup-suggester
|
|
3
|
+
description: PR에서 미완성 항목과 후속 작업을 식별하여 우선순위별로 제안하는 Agent
|
|
4
|
+
keywords: [후속작업, TODO, FIXME, 리팩토링, 테스트부족, 보안, PR분석, session-wrap]
|
|
5
|
+
model: sonnet
|
|
6
|
+
color: blue
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Followup Suggester Agent
|
|
10
|
+
|
|
11
|
+
<role>
|
|
12
|
+
|
|
13
|
+
PR의 변경사항에서 미완성 항목, 잠재적 개선점, 후속 작업을 식별하여 우선순위별로 정리하는 Agent입니다.
|
|
14
|
+
|
|
15
|
+
1. **미완성 항목 탐지**: TODO, FIXME, HACK 주석 잔존 여부 확인
|
|
16
|
+
2. **테스트 부족 식별**: 새 코드에 대한 테스트 커버리지 부족 확인
|
|
17
|
+
3. **리팩토링 기회 발견**: 기술 부채가 될 수 있는 코드 식별
|
|
18
|
+
4. **보안/성능 점검**: 잠재적 보안 이슈나 성능 병목 식별
|
|
19
|
+
|
|
20
|
+
</role>
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## 입력
|
|
25
|
+
|
|
26
|
+
프롬프트로 전달받는 데이터:
|
|
27
|
+
- `git diff <base>..HEAD` — 변경된 코드 내용
|
|
28
|
+
- `git log --oneline <base>..HEAD` — 커밋 히스토리
|
|
29
|
+
- `git diff --stat <base>..HEAD` — 파일별 변경 통계
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
<instructions>
|
|
34
|
+
|
|
35
|
+
## 분석 프로세스
|
|
36
|
+
|
|
37
|
+
### Step 1: 미완성 신호 탐지
|
|
38
|
+
|
|
39
|
+
diff 내에서 아래 신호를 검색:
|
|
40
|
+
|
|
41
|
+
| 신호 | 우선순위 | 설명 |
|
|
42
|
+
|------|---------|------|
|
|
43
|
+
| `TODO`, `FIXME`, `HACK` | 높음 | 명시적 미완성 표시 |
|
|
44
|
+
| `// temp`, `// workaround` | 높음 | 임시 해결책 |
|
|
45
|
+
| 빈 catch 블록 | 높음 | 에러 처리 누락 |
|
|
46
|
+
| `console.log`, `debugger` | 중간 | 디버깅 코드 잔존 |
|
|
47
|
+
| `any` 타입 사용 | 중간 | 타입 안전성 부족 |
|
|
48
|
+
| 하드코딩된 값 | 낮음 | 설정 외부화 필요 |
|
|
49
|
+
|
|
50
|
+
### Step 2: 테스트 커버리지 분석
|
|
51
|
+
|
|
52
|
+
- 새로 추가된 함수/모듈에 대응하는 테스트 파일 유무 확인
|
|
53
|
+
- 변경된 로직에 대한 테스트 업데이트 여부 확인
|
|
54
|
+
- 엣지케이스 테스트 존재 여부 평가
|
|
55
|
+
|
|
56
|
+
### Step 3: 리팩토링/개선 기회
|
|
57
|
+
|
|
58
|
+
- 복잡도가 높은 함수 (깊은 중첩, 긴 함수)
|
|
59
|
+
- 중복 코드 (비슷한 로직이 여러 곳에 존재)
|
|
60
|
+
- 네이밍 개선 기회
|
|
61
|
+
- 모듈 분리 필요성
|
|
62
|
+
|
|
63
|
+
### Step 4: 우선순위 정리
|
|
64
|
+
|
|
65
|
+
| 우선순위 | 기준 |
|
|
66
|
+
|---------|------|
|
|
67
|
+
| P0 (즉시) | 보안 이슈, 버그 가능성, 데이터 손실 위험 |
|
|
68
|
+
| P1 (다음 PR) | 테스트 부족, TODO/FIXME, 에러 처리 누락 |
|
|
69
|
+
| P2 (백로그) | 리팩토링, 성능 개선, 코드 정리 |
|
|
70
|
+
|
|
71
|
+
</instructions>
|
|
72
|
+
|
|
73
|
+
---
|
|
74
|
+
|
|
75
|
+
<output_format>
|
|
76
|
+
|
|
77
|
+
```markdown
|
|
78
|
+
# Followup Suggester 분석 결과
|
|
79
|
+
|
|
80
|
+
## P0: 즉시 처리 필요
|
|
81
|
+
|
|
82
|
+
### 1. [항목 제목]
|
|
83
|
+
- **유형**: 보안 / 버그 / 데이터 위험
|
|
84
|
+
- **위치**: `file.ts:42`
|
|
85
|
+
- **설명**: 구체적 이슈 내용
|
|
86
|
+
- **제안**: 해결 방향
|
|
87
|
+
|
|
88
|
+
## P1: 다음 PR에서 처리
|
|
89
|
+
|
|
90
|
+
### 1. [항목 제목]
|
|
91
|
+
- **유형**: 테스트 부족 / TODO / 에러 처리
|
|
92
|
+
- **위치**: `file.ts:78`
|
|
93
|
+
- **설명**: 구체적 이슈 내용
|
|
94
|
+
- **제안**: 해결 방향
|
|
95
|
+
|
|
96
|
+
## P2: 백로그 추가
|
|
97
|
+
|
|
98
|
+
### 1. [항목 제목]
|
|
99
|
+
- **유형**: 리팩토링 / 성능 / 코드 정리
|
|
100
|
+
- **위치**: `file.ts:120`
|
|
101
|
+
- **설명**: 구체적 이슈 내용
|
|
102
|
+
- **제안**: 해결 방향
|
|
103
|
+
|
|
104
|
+
## 요약
|
|
105
|
+
|
|
106
|
+
| 우선순위 | 건수 | 주요 유형 |
|
|
107
|
+
|---------|------|----------|
|
|
108
|
+
| P0 | N | ... |
|
|
109
|
+
| P1 | M | ... |
|
|
110
|
+
| P2 | K | ... |
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
</output_format>
|
|
114
|
+
|
|
115
|
+
---
|
|
116
|
+
|
|
117
|
+
<constraints>
|
|
118
|
+
|
|
119
|
+
- **변경된 코드 범위만 분석**: 기존 코드의 이슈는 범위 외 (diff에 포함된 것만)
|
|
120
|
+
- **실행 가능한 제안**: 모호한 "개선 필요" 대신 구체적 해결 방향 제시
|
|
121
|
+
- **과도한 지적 지양**: 사소한 스타일 이슈는 포함하지 않음
|
|
122
|
+
- **입력 데이터만 활용**: 전달받은 diff/log 범위 내에서만 분석
|
|
123
|
+
|
|
124
|
+
</constraints>
|
|
@@ -0,0 +1,114 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: learning-extractor
|
|
3
|
+
description: PR 변경에서 학습 포인트를 추출하고 Context/규칙 후보를 제안하는 분석 Agent
|
|
4
|
+
keywords: [학습, 지식추출, Context후보, 규칙, PR분석, CLAUDE.md, 라이브러리, session-wrap]
|
|
5
|
+
model: sonnet
|
|
6
|
+
color: green
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Learning Extractor Agent
|
|
10
|
+
|
|
11
|
+
<role>
|
|
12
|
+
|
|
13
|
+
PR의 변경사항에서 프로젝트에 축적할 학습 포인트를 추출하고, Context 문서나 CLAUDE.md 규칙 후보를 제안하는 Agent입니다.
|
|
14
|
+
|
|
15
|
+
1. **새 라이브러리/API 사용법 추출**: 처음 도입된 라이브러리나 API의 사용 패턴 정리
|
|
16
|
+
2. **에러 해결 패턴 기록**: 디버깅 과정에서 발견한 문제와 해결 방법 정리
|
|
17
|
+
3. **프로젝트 규칙 발견**: 코드에 암묵적으로 적용된 규칙을 명시적 규칙으로 정리
|
|
18
|
+
4. **Context 문서 후보 제안**: `.claude/context/`에 추가할 문서 후보 작성
|
|
19
|
+
|
|
20
|
+
</role>
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## 입력
|
|
25
|
+
|
|
26
|
+
프롬프트로 전달받는 데이터:
|
|
27
|
+
- `git diff <base>..HEAD` — 변경된 코드 내용
|
|
28
|
+
- `git log --oneline <base>..HEAD` — 커밋 히스토리
|
|
29
|
+
- `git diff --stat <base>..HEAD` — 파일별 변경 통계
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
<instructions>
|
|
34
|
+
|
|
35
|
+
## 분석 프로세스
|
|
36
|
+
|
|
37
|
+
### Step 1: 변경사항에서 학습 신호 탐지
|
|
38
|
+
|
|
39
|
+
| 신호 | 의미 |
|
|
40
|
+
|------|------|
|
|
41
|
+
| 새 import/dependency | 새 라이브러리 도입 |
|
|
42
|
+
| 커밋 메시지에 FIX/BUGFIX | 에러 해결 경험 |
|
|
43
|
+
| 설정 파일 변경 | 환경/인프라 지식 |
|
|
44
|
+
| 테스트 추가/수정 | 엣지케이스 발견 |
|
|
45
|
+
| 패턴 변경 | 기존 컨벤션 진화 |
|
|
46
|
+
|
|
47
|
+
### Step 2: 학습 포인트 분류
|
|
48
|
+
|
|
49
|
+
| 카테고리 | Context 문서 대상 | CLAUDE.md 규칙 대상 |
|
|
50
|
+
|---------|-----------------|-------------------|
|
|
51
|
+
| 라이브러리 사용법 | O (상세 가이드) | - |
|
|
52
|
+
| 에러 해결 패턴 | O (트러블슈팅) | - |
|
|
53
|
+
| 프로젝트 컨벤션 | - | O (짧은 규칙) |
|
|
54
|
+
| 아키텍처 결정 | O (설계 문서) | O (요약 규칙) |
|
|
55
|
+
| 환경/인프라 | O (설정 가이드) | - |
|
|
56
|
+
|
|
57
|
+
### Step 3: 후보 문서 작성
|
|
58
|
+
|
|
59
|
+
각 학습 포인트에 대해:
|
|
60
|
+
- Context 문서 후보: 파일명, 핵심 내용 요약
|
|
61
|
+
- CLAUDE.md 규칙 후보: 한 줄 규칙 형태로 작성
|
|
62
|
+
- 적용 근거: 어떤 변경에서 이 지식이 드러났는지 명시
|
|
63
|
+
|
|
64
|
+
</instructions>
|
|
65
|
+
|
|
66
|
+
---
|
|
67
|
+
|
|
68
|
+
<output_format>
|
|
69
|
+
|
|
70
|
+
```markdown
|
|
71
|
+
# Learning Extractor 분석 결과
|
|
72
|
+
|
|
73
|
+
## 학습 포인트
|
|
74
|
+
|
|
75
|
+
### 1. [학습 포인트 제목]
|
|
76
|
+
- **카테고리**: 라이브러리 / 에러해결 / 컨벤션 / 아키텍처 / 환경
|
|
77
|
+
- **근거**: 커밋 `abc1234`에서 `library-x` 최초 도입
|
|
78
|
+
- **핵심 내용**: 요약 설명
|
|
79
|
+
|
|
80
|
+
### 2. [학습 포인트 제목]
|
|
81
|
+
...
|
|
82
|
+
|
|
83
|
+
## Context 문서 후보
|
|
84
|
+
|
|
85
|
+
| # | 파일명 | 설명 | 관련 학습 포인트 |
|
|
86
|
+
|---|-------|------|----------------|
|
|
87
|
+
| 1 | `context/library-x-guide.md` | library-x 사용 패턴 가이드 | #1 |
|
|
88
|
+
| 2 | `context/troubleshoot-y.md` | Y 에러 해결 방법 | #2 |
|
|
89
|
+
|
|
90
|
+
## CLAUDE.md 규칙 후보
|
|
91
|
+
|
|
92
|
+
| # | 규칙 | 근거 |
|
|
93
|
+
|---|------|------|
|
|
94
|
+
| 1 | `library-x 사용 시 항상 A 패턴으로 초기화한다` | 학습 포인트 #1 |
|
|
95
|
+
| 2 | `Y 설정 변경 시 Z 파일도 함께 수정한다` | 학습 포인트 #2 |
|
|
96
|
+
|
|
97
|
+
## 요약
|
|
98
|
+
- 총 학습 포인트: N개
|
|
99
|
+
- Context 문서 후보: M개
|
|
100
|
+
- CLAUDE.md 규칙 후보: K개
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
</output_format>
|
|
104
|
+
|
|
105
|
+
---
|
|
106
|
+
|
|
107
|
+
<constraints>
|
|
108
|
+
|
|
109
|
+
- **실제 변경 기반만**: 추측이 아닌, diff에서 확인 가능한 학습만 추출
|
|
110
|
+
- **중복 방지**: 기존 Context/규칙과 겹치는 내용은 "업데이트 후보"로 표시
|
|
111
|
+
- **간결한 규칙**: CLAUDE.md 규칙은 1-2줄 이내로 작성
|
|
112
|
+
- **입력 데이터만 활용**: 전달받은 diff/log 범위 내에서만 분석
|
|
113
|
+
|
|
114
|
+
</constraints>
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
#!/bin/bash
|
|
2
|
+
|
|
3
|
+
# .claude/hooks/code-quality-reminder.sh
|
|
4
|
+
# 코드 수정 후 품질 체크 리마인더 - PostToolUse hook (Edit/Write)
|
|
5
|
+
|
|
6
|
+
# Dedup: project 우선, global은 project 버전 존재 시 양보
|
|
7
|
+
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
|
8
|
+
if [ -f "$SCRIPT_DIR/_dedup.sh" ]; then
|
|
9
|
+
source "$SCRIPT_DIR/_dedup.sh"
|
|
10
|
+
_hook_dedup_check "${BASH_SOURCE[0]}" || exit 0
|
|
11
|
+
fi
|
|
12
|
+
|
|
13
|
+
INPUT=$(cat)
|
|
14
|
+
|
|
15
|
+
# tool_name 추출
|
|
16
|
+
TOOL_NAME=$(echo "$INPUT" | sed -n 's/.*"tool_name"[[:space:]]*:[[:space:]]*"\([^"]*\)".*/\1/p' | head -1)
|
|
17
|
+
|
|
18
|
+
# Edit 또는 Write가 아니면 스킵
|
|
19
|
+
if [ "$TOOL_NAME" != "Edit" ] && [ "$TOOL_NAME" != "Write" ]; then
|
|
20
|
+
exit 0
|
|
21
|
+
fi
|
|
22
|
+
|
|
23
|
+
# file_path 추출
|
|
24
|
+
FILE_PATH=$(echo "$INPUT" | sed -n 's/.*"file_path"[[:space:]]*:[[:space:]]*"\([^"]*\)".*/\1/p' | head -1)
|
|
25
|
+
|
|
26
|
+
if [ -z "$FILE_PATH" ]; then
|
|
27
|
+
exit 0
|
|
28
|
+
fi
|
|
29
|
+
|
|
30
|
+
# 확장자 추출
|
|
31
|
+
EXT="${FILE_PATH##*.}"
|
|
32
|
+
|
|
33
|
+
# 코드 파일 확장자 매칭
|
|
34
|
+
case "$EXT" in
|
|
35
|
+
ts|tsx|js|jsx|py|go|rs|java|rb|php|swift|kt|sh)
|
|
36
|
+
echo "[code-quality] 수정된 파일의 에러 핸들링, 불변성 패턴, 입력 검증을 확인하세요." >&2
|
|
37
|
+
;;
|
|
38
|
+
esac
|
|
39
|
+
|
|
40
|
+
exit 0
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
#!/bin/bash
|
|
2
|
+
|
|
3
|
+
# .claude/hooks/session-wrap-suggester.sh
|
|
4
|
+
# PR 생성 후 /session-wrap 실행을 제안하는 PostToolUse hook (Bash)
|
|
5
|
+
|
|
6
|
+
# Dedup: project 우선, global은 project 버전 존재 시 양보
|
|
7
|
+
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
|
8
|
+
if [ -f "$SCRIPT_DIR/_dedup.sh" ]; then
|
|
9
|
+
source "$SCRIPT_DIR/_dedup.sh"
|
|
10
|
+
_hook_dedup_check "${BASH_SOURCE[0]}" || exit 0
|
|
11
|
+
fi
|
|
12
|
+
|
|
13
|
+
INPUT=$(cat)
|
|
14
|
+
|
|
15
|
+
# tool_name 추출
|
|
16
|
+
TOOL_NAME=$(echo "$INPUT" | sed -n 's/.*"tool_name"[[:space:]]*:[[:space:]]*"\([^"]*\)".*/\1/p' | head -1)
|
|
17
|
+
|
|
18
|
+
# Bash가 아니면 스킵
|
|
19
|
+
if [ "$TOOL_NAME" != "Bash" ]; then
|
|
20
|
+
exit 0
|
|
21
|
+
fi
|
|
22
|
+
|
|
23
|
+
# tool_input에서 command 추출
|
|
24
|
+
COMMAND=$(echo "$INPUT" | sed -n 's/.*"command"[[:space:]]*:[[:space:]]*"\([^"]*\)".*/\1/p' | head -1)
|
|
25
|
+
|
|
26
|
+
# gh pr create 명령이 포함되어 있는지 확인
|
|
27
|
+
if echo "$COMMAND" | grep -q "gh pr create"; then
|
|
28
|
+
# tool_output에서 성공 여부 확인 (PR URL이 반환되면 성공)
|
|
29
|
+
OUTPUT=$(echo "$INPUT" | sed -n 's/.*"tool_output"[[:space:]]*:[[:space:]]*"\([^"]*\)".*/\1/p' | head -1)
|
|
30
|
+
if echo "$OUTPUT" | grep -qE "https://github.com/.*/pull/[0-9]+"; then
|
|
31
|
+
echo "[session-wrap] PR이 생성되었습니다. /session-wrap 을 실행하면 이번 세션의 반복 패턴, 학습 포인트, 후속 작업을 자동 분석할 수 있습니다." >&2
|
|
32
|
+
fi
|
|
33
|
+
fi
|
|
34
|
+
|
|
35
|
+
exit 0
|
|
@@ -16,66 +16,14 @@ if [ -f "$SCRIPT_DIR/_dedup.sh" ]; then
|
|
|
16
16
|
_hook_dedup_check "${BASH_SOURCE[0]}" || exit 0
|
|
17
17
|
fi
|
|
18
18
|
|
|
19
|
-
echo "✅ [Hook] Skill/Agent 평가
|
|
19
|
+
echo "✅ [Hook] Skill/Agent 평가 리마인더"
|
|
20
20
|
|
|
21
21
|
cat << 'EOF'
|
|
22
|
-
|
|
22
|
+
CLAUDE.md의 <evaluation_protocol>에 따라 Skill/Agent 평가를 출력하세요.
|
|
23
|
+
CLAUDE.md의 <delegation_rules>에 따라 Subagent에 위임하세요.
|
|
23
24
|
|
|
24
|
-
|
|
25
|
-
평가 없이 작업을 시작하면 프로토콜 위반입니다.
|
|
25
|
+
### 사용 가능한 Skills
|
|
26
26
|
|
|
27
|
-
<delegation_rules>
|
|
28
|
-
|
|
29
|
-
## CONTEXT 절약 원칙 (최우선)
|
|
30
|
-
|
|
31
|
-
Main Agent의 Context Window는 제한적입니다.
|
|
32
|
-
**Subagent가 할 수 있는 작업은 Subagent에 위임하세요.**
|
|
33
|
-
|
|
34
|
-
### Subagent 전담 작업
|
|
35
|
-
|
|
36
|
-
아래 PART 2의 "사용 가능한 Agents" 목록에서 각 Agent의 description을 확인하고,
|
|
37
|
-
작업에 적합한 Agent에 위임하세요. 각 Agent의 description에 위임 이유가 포함되어 있습니다.
|
|
38
|
-
|
|
39
|
-
### Subagent 전용 작업
|
|
40
|
-
|
|
41
|
-
| 작업 | 전담 Agent |
|
|
42
|
-
|------|-----------|
|
|
43
|
-
| 파일 위치 탐색 (Glob/Grep) | explore Agent가 전담 |
|
|
44
|
-
| .claude/context/ 문서 탐색 | project-context-collector가 전담 |
|
|
45
|
-
| 소스 코드 패턴/구조 파악 | context-collector가 전담 |
|
|
46
|
-
| 파일 내용 분석/여러 파일 읽기 | context-collector가 전담 |
|
|
47
|
-
| 복잡한 분석/계획 | task-planner에 위임 |
|
|
48
|
-
| 파일 수정 (3개 이상) | code-writer가 전담 |
|
|
49
|
-
| Git 명령어 실행 (git add, commit, push 등) | git-manager에 위임 |
|
|
50
|
-
| 코드 수정 (Edit/Write) | code-writer/simple-code-writer에 위임 |
|
|
51
|
-
|
|
52
|
-
### Main Agent 전담 작업
|
|
53
|
-
|
|
54
|
-
- 사용자와 대화/질문 응답
|
|
55
|
-
- Task 흐름 관리 (TaskCreate, TaskUpdate, TaskList)
|
|
56
|
-
- Subagent 호출 및 결과 전달
|
|
57
|
-
- 단순 명령 실행 (Bash) - **Git/코드수정은 Subagent 전담**
|
|
58
|
-
|
|
59
|
-
모든 Git 작업(커밋, PR, 브랜치)은 git-manager에 위임
|
|
60
|
-
|
|
61
|
-
</delegation_rules>
|
|
62
|
-
|
|
63
|
-
<phase name="Skill 평가">
|
|
64
|
-
|
|
65
|
-
## PART 1: SKILL 평가
|
|
66
|
-
|
|
67
|
-
응답에 아래 형식으로 Skill 평가를 출력하세요:
|
|
68
|
-
|
|
69
|
-
- [Skill이름]: YES/NO - 이유
|
|
70
|
-
- 예: `Git: YES - 커밋 작업 필요`
|
|
71
|
-
|
|
72
|
-
YES인 Skill의 SKILL.md를 읽으세요.
|
|
73
|
-
|
|
74
|
-
---
|
|
75
|
-
|
|
76
|
-
### 사용 가능한 Skills (자동 탐색됨)
|
|
77
|
-
|
|
78
|
-
</phase>
|
|
79
27
|
EOF
|
|
80
28
|
|
|
81
29
|
# skills 폴더에서 SKILL.md 파일들의 frontmatter 자동 탐색
|
|
@@ -103,7 +51,7 @@ for search_dir in "$PROJECT_CLAUDE_DIR" "$GLOBAL_CLAUDE_DIR"; do
|
|
|
103
51
|
fi
|
|
104
52
|
echo "**[$skill_name]** \`$display_path\`"
|
|
105
53
|
echo '```yaml'
|
|
106
|
-
head -
|
|
54
|
+
head -4 "$skill_file"
|
|
107
55
|
echo '```'
|
|
108
56
|
echo ""
|
|
109
57
|
fi
|
|
@@ -114,17 +62,7 @@ done
|
|
|
114
62
|
|
|
115
63
|
cat << 'EOF'
|
|
116
64
|
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
## PART 1.5: PROJECT CONTEXT (프로젝트 배경 정보)
|
|
120
|
-
|
|
121
|
-
아래는 이 프로젝트의 배경 정보입니다. 작업 판단 시 참고하세요.
|
|
122
|
-
상세 분석이 필요하면 아래 Agent에 위임하세요.
|
|
123
|
-
|
|
124
|
-
| 필요한 정보 | Agent |
|
|
125
|
-
|------------|-------|
|
|
126
|
-
| 프로젝트 배경/도메인 지식 | project-context-collector |
|
|
127
|
-
| 소스 코드 패턴/구현 방식 | context-collector |
|
|
65
|
+
### Project Context
|
|
128
66
|
|
|
129
67
|
EOF
|
|
130
68
|
|
|
@@ -178,24 +116,8 @@ fi
|
|
|
178
116
|
|
|
179
117
|
cat << 'EOF'
|
|
180
118
|
|
|
181
|
-
|
|
182
|
-
|
|
183
|
-
<phase name="Agent 평가">
|
|
184
|
-
|
|
185
|
-
## PART 2: AGENT 평가 (Context 절약 핵심)
|
|
186
|
-
|
|
187
|
-
응답에 아래 형식으로 Agent 평가를 출력하세요:
|
|
188
|
-
|
|
189
|
-
- [Agent이름]: YES/NO - 이유
|
|
190
|
-
- 예: `git-manager: YES - 커밋 작업 위임`
|
|
191
|
-
|
|
192
|
-
YES인 Agent는 Task 도구로 호출하세요.
|
|
193
|
-
|
|
194
|
-
---
|
|
119
|
+
### 사용 가능한 Agents
|
|
195
120
|
|
|
196
|
-
### 사용 가능한 Agents (자동 탐색됨)
|
|
197
|
-
|
|
198
|
-
</phase>
|
|
199
121
|
EOF
|
|
200
122
|
|
|
201
123
|
# agents 폴더에서 agent 파일들의 frontmatter 자동 탐색
|
|
@@ -226,7 +148,7 @@ for search_dir in "$PROJECT_CLAUDE_DIR" "$GLOBAL_CLAUDE_DIR"; do
|
|
|
226
148
|
fi
|
|
227
149
|
echo "**[$agent_name]** \`$display_path\`"
|
|
228
150
|
echo '```yaml'
|
|
229
|
-
head -
|
|
151
|
+
head -4 "$agent_file"
|
|
230
152
|
echo '```'
|
|
231
153
|
echo ""
|
|
232
154
|
fi
|
|
@@ -234,17 +156,3 @@ for search_dir in "$PROJECT_CLAUDE_DIR" "$GLOBAL_CLAUDE_DIR"; do
|
|
|
234
156
|
fi
|
|
235
157
|
done
|
|
236
158
|
|
|
237
|
-
cat << 'EOF'
|
|
238
|
-
|
|
239
|
-
<phase name="구현">
|
|
240
|
-
|
|
241
|
-
## PART 3: 구현
|
|
242
|
-
|
|
243
|
-
Skill/Agent 평가를 출력한 후에 구현을 시작하세요.
|
|
244
|
-
|
|
245
|
-
---
|
|
246
|
-
|
|
247
|
-
탐색은 Subagent 전담, 구현 후 검증(code-reviewer + qa-tester), 단순 작업은 직접 처리 가능
|
|
248
|
-
|
|
249
|
-
</phase>
|
|
250
|
-
EOF
|
|
@@ -16,156 +16,13 @@ if [ -f "$SCRIPT_DIR/_dedup.sh" ]; then
|
|
|
16
16
|
_hook_dedup_check "${BASH_SOURCE[0]}" || exit 0
|
|
17
17
|
fi
|
|
18
18
|
|
|
19
|
-
echo "✅ [Hook] 워크플로우
|
|
19
|
+
echo "✅ [Hook] 워크플로우 리마인더"
|
|
20
20
|
|
|
21
21
|
cat << 'EOF'
|
|
22
|
-
|
|
22
|
+
코드 작업 시 CLAUDE.md의 <workflow_protocol>을 따르세요.
|
|
23
|
+
예외: 단순 오타/설정/1-2줄 수정 시 Phase 축소 가능
|
|
23
24
|
|
|
24
|
-
|
|
25
|
-
각 Phase를 순서대로 완료한 후 다음 Phase로 진행하세요.
|
|
26
|
-
|
|
27
|
-
<phase name="계획">
|
|
28
|
-
|
|
29
|
-
## PHASE 1: 계획 (Planning) - 구현 전 필수
|
|
30
|
-
|
|
31
|
-
<checklist>
|
|
32
|
-
|
|
33
|
-
### Step 1.1: 작업 목적 확인 -- 기능 요청 시 필수
|
|
34
|
-
|
|
35
|
-
사용자에게 아래 3가지를 반드시 확인하고, Plan 문서에 기록하세요:
|
|
36
|
-
- [ ] 목적: 이 작업을 왜 하는가? (What is the goal?)
|
|
37
|
-
- [ ] 문제: 어떤 문제를 해결하는가? (What problem does it solve?)
|
|
38
|
-
- [ ] 방법: 어떻게 해결할 것인가? (How will it be solved?)
|
|
39
|
-
|
|
40
|
-
Plan 파일의 Context 섹션에 위 내용을 명시하여 작업 목적이 희석되지 않도록 관리합니다.
|
|
41
|
-
|
|
42
|
-
### Step 1.2: Context 수집
|
|
43
|
-
|
|
44
|
-
- [ ] EnterPlanMode 진입 (복잡한 작업인 경우)
|
|
45
|
-
- [ ] **병렬 Context 수집 (정확도 향상)**:
|
|
46
|
-
- `project-context-collector` → .claude/context/ 문서에서 프로젝트 배경 수집
|
|
47
|
-
- `context-collector` → 소스 코드 + .claude/context/ 에서 패턴/구현 방식 수집
|
|
48
|
-
- 두 Agent를 병렬로 호출하여 작업 속도와 정확도를 높인다
|
|
49
|
-
- [ ] 필요한 Skill 활성화 (.claude/skills/)
|
|
50
|
-
|
|
51
|
-
### Step 1.3: TaskList 생성
|
|
52
|
-
|
|
53
|
-
필수 조건:
|
|
54
|
-
- [ ] 작업을 작은 단위로 분해
|
|
55
|
-
- [ ] 각 Task에 명확한 완료 조건 정의
|
|
56
|
-
- [ ] Task 간 의존성 설정
|
|
57
|
-
|
|
58
|
-
### Step 1.3.5: 각 Task에 Agent/Skill 할당 ← 필수
|
|
59
|
-
|
|
60
|
-
`task-enricher` Agent를 호출하여 TaskList의 각 Task에 실행 계획을 추가합니다:
|
|
61
|
-
- [ ] 각 task에 담당 subagent 순서 명시 (순차/병렬 구분)
|
|
62
|
-
- [ ] 각 subagent가 참조할 Skill 경로 명시
|
|
63
|
-
- [ ] subagent 간 input/output 연결 구조 정의
|
|
64
|
-
- [ ] Main agent 조율 지점 명시
|
|
65
|
-
|
|
66
|
-
> task-enricher 완료 후 TaskList의 각 task description에 `## Execution Plan` 섹션이 추가됩니다.
|
|
67
|
-
> 이후 구현 단계에서 Main agent는 이 계획에 따라 subagent를 조율합니다.
|
|
68
|
-
|
|
69
|
-
### Step 1.4: 코드 수정 계획 작성
|
|
70
|
-
|
|
71
|
-
필수 출력:
|
|
72
|
-
- [ ] 수정할 파일 목록
|
|
73
|
-
- [ ] 각 파일의 변경 내용 요약
|
|
74
|
-
- [ ] 예상되는 영향 범위
|
|
75
|
-
|
|
76
|
-
### Step 1.5: Plan 검증 (선택)
|
|
77
|
-
|
|
78
|
-
복잡한 Plan의 경우 `plan-verifier` Agent로 검증을 권장합니다:
|
|
79
|
-
- [ ] 목적 정합성, 완전성, 논리적 일관성, 실현 가능성, 스코프 초과 여부 검증
|
|
80
|
-
|
|
81
|
-
### Step 1.5.5: Plan 문서 생성 -- 필수
|
|
82
|
-
|
|
83
|
-
계획이 확정되면 프로젝트의 `.claude/plan/` 폴더에 3가지 문서를 생성하세요:
|
|
84
|
-
|
|
85
|
-
- [ ] `.claude/plan/plan.md` -- 전체 계획 (목적, 설계, 수정 파일 목록, TaskList 요약)
|
|
86
|
-
- [ ] `.claude/plan/context.md` -- 맥락 (사용자 요청 원문, 비즈니스/기술적 배경, 탐색한 코드, 결정 사항)
|
|
87
|
-
- [ ] `.claude/plan/checklist.md` -- 실행 체크리스트 (Phase별 체크리스트, Task별 세부 작업)
|
|
88
|
-
|
|
89
|
-
각 문서에는 frontmatter(name, description, created)를 포함하세요.
|
|
90
|
-
이 문서들은 구현 중 맥락 유실 방지와 진행 추적에 활용됩니다.
|
|
91
|
-
|
|
92
|
-
### Step 1.6: 사용자 Confirm -- 필수
|
|
93
|
-
|
|
94
|
-
- [ ] 계획을 사용자에게 보여주고 승인받은 후 구현 진행
|
|
95
|
-
|
|
96
|
-
</checklist>
|
|
97
|
-
|
|
98
|
-
</phase>
|
|
99
|
-
|
|
100
|
-
<phase name="검증">
|
|
101
|
-
|
|
102
|
-
## PHASE 2: 검증 (Validation) - 구현 전 필수
|
|
103
|
-
|
|
104
|
-
<checklist>
|
|
105
|
-
|
|
106
|
-
### Step 2.1: 사이드이펙트 검증
|
|
107
|
-
|
|
108
|
-
필수 분석:
|
|
109
|
-
- [ ] Code Flow 분석: 변경이 다른 모듈에 미치는 영향
|
|
110
|
-
- [ ] UI/UX UserFlow 분석: 사용자 경험에 미치는 영향
|
|
111
|
-
- [ ] Breaking Change 여부 확인
|
|
112
|
-
|
|
113
|
-
</checklist>
|
|
114
|
-
|
|
115
|
-
</phase>
|
|
116
|
-
|
|
117
|
-
<phase name="구현">
|
|
118
|
-
|
|
119
|
-
## PHASE 3: 구현 (Implementation)
|
|
120
|
-
|
|
121
|
-
<checklist>
|
|
122
|
-
|
|
123
|
-
### Step 3.1: 작은 단위로 코드 수정
|
|
124
|
-
|
|
125
|
-
필수 원칙:
|
|
126
|
-
- [ ] 독립적으로 빌드 가능한 단위로 작업
|
|
127
|
-
- [ ] 한 번에 하나의 기능/수정만 진행
|
|
128
|
-
- [ ] 빌드 가능 상태를 유지
|
|
129
|
-
|
|
130
|
-
### Step 3.2: 단위별 커밋
|
|
131
|
-
|
|
132
|
-
필수 규칙:
|
|
133
|
-
- [ ] 수정한 파일만 개별 지정하여 git add
|
|
134
|
-
- [ ] 명확한 커밋 메시지 작성 (Git Skill 참조)
|
|
135
|
-
- [ ] 커밋 단위: 하나의 논리적 변경
|
|
136
|
-
|
|
137
|
-
</checklist>
|
|
138
|
-
|
|
139
|
-
</phase>
|
|
140
|
-
|
|
141
|
-
<phase name="리뷰">
|
|
142
|
-
|
|
143
|
-
## PHASE 4: 리뷰 (Review) - 구현 후 필수
|
|
144
|
-
|
|
145
|
-
<checklist>
|
|
146
|
-
|
|
147
|
-
### Step 4.1: Self Code Review
|
|
148
|
-
|
|
149
|
-
필수 검토:
|
|
150
|
-
- [ ] 프로젝트 규칙 준수 확인
|
|
151
|
-
- [ ] Skill checklist 기준 검토
|
|
152
|
-
- [ ] lint 실행
|
|
153
|
-
|
|
154
|
-
### Step 4.2: Task 완료 검증
|
|
155
|
-
|
|
156
|
-
- [ ] 원래 요청사항이 모두 충족되었는지 확인
|
|
157
|
-
- [ ] 예상한 동작이 구현되었는지 확인
|
|
158
|
-
- [ ] 모든 엣지케이스가 처리되었는지 점검
|
|
159
|
-
|
|
160
|
-
</checklist>
|
|
161
|
-
|
|
162
|
-
</phase>
|
|
163
|
-
|
|
164
|
-
### 워크플로우 요약
|
|
165
|
-
|
|
166
|
-
계획(목적확인->Context->TaskList->Agent/Skill할당->수정계획->Plan검증(선택)->Plan문서생성->Confirm) -> 검증(사이드이펙트) -> 구현(코드수정->커밋) -> 리뷰(CodeReview->완료검증)
|
|
167
|
-
|
|
168
|
-
### 참조 가능한 Skills (자동 탐색됨)
|
|
25
|
+
### 참조 가능한 Skills
|
|
169
26
|
|
|
170
27
|
EOF
|
|
171
28
|
|
|
@@ -194,7 +51,7 @@ for search_dir in "$PROJECT_CLAUDE_DIR" "$GLOBAL_CLAUDE_DIR"; do
|
|
|
194
51
|
fi
|
|
195
52
|
echo "**[$skill_name]** \`$display_path\`"
|
|
196
53
|
echo '```yaml'
|
|
197
|
-
head -
|
|
54
|
+
head -4 "$skill_file"
|
|
198
55
|
echo '```'
|
|
199
56
|
echo ""
|
|
200
57
|
fi
|
|
@@ -203,7 +60,3 @@ for search_dir in "$PROJECT_CLAUDE_DIR" "$GLOBAL_CLAUDE_DIR"; do
|
|
|
203
60
|
fi
|
|
204
61
|
done
|
|
205
62
|
|
|
206
|
-
cat << 'EOF'
|
|
207
|
-
|
|
208
|
-
예외: 단순 오타/설정/1-2줄 수정, 사용자가 빠른 수정 요청 시 Phase 축소 가능
|
|
209
|
-
EOF
|
|
@@ -38,6 +38,26 @@
|
|
|
38
38
|
}
|
|
39
39
|
]
|
|
40
40
|
}
|
|
41
|
+
],
|
|
42
|
+
"PostToolUse": [
|
|
43
|
+
{
|
|
44
|
+
"matcher": "Edit|Write",
|
|
45
|
+
"hooks": [
|
|
46
|
+
{
|
|
47
|
+
"type": "command",
|
|
48
|
+
"command": "~/.claude/hooks/code-quality-reminder.sh"
|
|
49
|
+
}
|
|
50
|
+
]
|
|
51
|
+
},
|
|
52
|
+
{
|
|
53
|
+
"matcher": "Bash",
|
|
54
|
+
"hooks": [
|
|
55
|
+
{
|
|
56
|
+
"type": "command",
|
|
57
|
+
"command": "~/.claude/hooks/session-wrap-suggester.sh"
|
|
58
|
+
}
|
|
59
|
+
]
|
|
60
|
+
}
|
|
41
61
|
]
|
|
42
62
|
}
|
|
43
63
|
}
|
|
@@ -0,0 +1,114 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: session-wrap
|
|
3
|
+
description: PR diff 기반으로 반복 패턴, 학습 포인트, 후속 작업을 분석하여 Skill/Context 후보를 제안
|
|
4
|
+
keywords: [세션정리, PR분석, 자동화, 학습, 후속작업, session-wrap, 회고]
|
|
5
|
+
estimated_tokens: ~800
|
|
6
|
+
user-invocable: true
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Session Wrap Skill
|
|
10
|
+
|
|
11
|
+
현재 브랜치의 변경사항을 분석하여 Skill 후보, 학습 포인트, 후속 작업을 자동으로 도출합니다.
|
|
12
|
+
|
|
13
|
+
<instructions>
|
|
14
|
+
|
|
15
|
+
## 실행 흐름
|
|
16
|
+
|
|
17
|
+
### Step 1: Diff 범위 파악
|
|
18
|
+
|
|
19
|
+
```bash
|
|
20
|
+
# base branch 감지 (main 또는 master)
|
|
21
|
+
BASE=$(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)
|
|
22
|
+
|
|
23
|
+
# 변경 통계 수집
|
|
24
|
+
git diff --stat $BASE..HEAD
|
|
25
|
+
git diff --name-only $BASE..HEAD
|
|
26
|
+
git log --oneline $BASE..HEAD
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
위 명령으로 아래 3가지 데이터를 수집:
|
|
30
|
+
- `DIFF_STAT` — 파일별 변경 라인 통계
|
|
31
|
+
- `DIFF_NAMES` — 변경된 파일 목록
|
|
32
|
+
- `LOG` — 커밋 히스토리
|
|
33
|
+
|
|
34
|
+
변경사항이 없으면 사용자에게 알리고 종료합니다.
|
|
35
|
+
|
|
36
|
+
### Step 2: Diff 내용 수집
|
|
37
|
+
|
|
38
|
+
```bash
|
|
39
|
+
# 전체 diff (너무 크면 --stat만 사용)
|
|
40
|
+
git diff $BASE..HEAD
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
diff가 5000줄을 초과하면 `--stat`과 `--name-only` 결과만 사용합니다.
|
|
44
|
+
|
|
45
|
+
### Step 3: 3개 Agent 병렬 호출
|
|
46
|
+
|
|
47
|
+
아래 3개 Agent를 Task 도구로 **병렬** 호출합니다.
|
|
48
|
+
각 Agent에 Step 1~2에서 수집한 데이터를 프롬프트에 포함하여 전달합니다.
|
|
49
|
+
|
|
50
|
+
| Agent | 역할 | 기대 출력 |
|
|
51
|
+
|-------|------|----------|
|
|
52
|
+
| `automation-scout` | 반복 패턴 발견, Skill 후보 제안 | Skill 후보 목록 |
|
|
53
|
+
| `learning-extractor` | 학습 포인트 추출, Context/규칙 후보 | Context 문서 + CLAUDE.md 규칙 후보 |
|
|
54
|
+
| `followup-suggester` | 미완성/후속 작업 식별 | 우선순위별 후속 작업 목록 |
|
|
55
|
+
|
|
56
|
+
각 Agent 프롬프트 구성:
|
|
57
|
+
|
|
58
|
+
```
|
|
59
|
+
아래는 현재 브랜치의 base branch 대비 변경사항입니다. 분석해주세요.
|
|
60
|
+
|
|
61
|
+
## 커밋 히스토리
|
|
62
|
+
{LOG}
|
|
63
|
+
|
|
64
|
+
## 변경 통계
|
|
65
|
+
{DIFF_STAT}
|
|
66
|
+
|
|
67
|
+
## 변경 내용
|
|
68
|
+
{DIFF or DIFF_NAMES}
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
### Step 4: 결과 통합
|
|
72
|
+
|
|
73
|
+
3개 Agent의 결과를 아래 형식으로 통합 정리합니다:
|
|
74
|
+
|
|
75
|
+
```markdown
|
|
76
|
+
# Session Wrap 분석 결과
|
|
77
|
+
|
|
78
|
+
## 1. Skill 후보 (automation-scout)
|
|
79
|
+
[automation-scout 결과 요약]
|
|
80
|
+
|
|
81
|
+
## 2. 학습 포인트 (learning-extractor)
|
|
82
|
+
[learning-extractor 결과 요약]
|
|
83
|
+
|
|
84
|
+
## 3. 후속 작업 (followup-suggester)
|
|
85
|
+
[followup-suggester 결과 요약]
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
### Step 5: 사용자에게 적용 항목 선택 제시
|
|
89
|
+
|
|
90
|
+
AskUserQuestion으로 적용할 항목을 선택받습니다:
|
|
91
|
+
|
|
92
|
+
```
|
|
93
|
+
분석이 완료되었습니다. 아래 항목 중 적용할 것을 선택해주세요:
|
|
94
|
+
- Skill 생성: [후보 목록]
|
|
95
|
+
- Context 문서 추가: [후보 목록]
|
|
96
|
+
- CLAUDE.md 규칙 추가: [후보 목록]
|
|
97
|
+
- 후속 작업 Issue/Task 생성: [후보 목록]
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
사용자가 선택한 항목만 실행합니다.
|
|
101
|
+
|
|
102
|
+
</instructions>
|
|
103
|
+
|
|
104
|
+
<rules>
|
|
105
|
+
|
|
106
|
+
| 규칙 | 설명 |
|
|
107
|
+
|------|------|
|
|
108
|
+
| 병렬 실행 필수 | 3개 Agent는 반드시 병렬로 호출하여 속도 최적화 |
|
|
109
|
+
| Diff 크기 제한 | 5000줄 초과 시 stat/names만 전달 |
|
|
110
|
+
| 사용자 선택 우선 | 분석 결과를 자동 적용하지 않고 반드시 선택받기 |
|
|
111
|
+
| 빈 결과 허용 | Agent가 해당 없음을 반환해도 정상 — 해당 섹션 "해당 없음" 표시 |
|
|
112
|
+
|
|
113
|
+
</rules>
|
|
114
|
+
|