@choblue/claude-code-toolkit 1.1.6 → 1.2.1

package/README.md

@@ -17,16 +17,18 @@
 ├── settings.json                ← hooks 설정
 ├── agents/
 │   ├── explore.md               ← 코드베이스 탐색 (haiku)
-│   ├── code-writer-fe.md        ← React 프론트엔드 구현 (opus)
-│   ├── code-writer-be.md        ← NestJS 백엔드 구현 (opus)
+│   ├── code-writer-fe.md        ← React 프론트엔드 구현 - M 티어 (opus)
+│   ├── code-writer-be.md        ← NestJS 백엔드 구현 - M 티어 (opus)
+│   ├── implementer-fe.md        ← React 구현+테스트 - L 티어 (opus)
+│   ├── implementer-be.md        ← NestJS 구현+테스트 - L 티어 (opus)
 │   ├── code-reviewer.md         ← 코드 품질 리뷰 (opus)
-│   ├── test-writer-fe.md        ← React 프론트엔드 테스트 (opus)
-│   ├── test-writer-be.md        ← NestJS 백엔드 테스트 (opus)
 │   └── git-manager.md           ← Git 작업 (sonnet)
 ├── skills/
 │   ├── Coding/
 │   │   ├── SKILL.md             ← 공통 코딩 원칙
 │   │   └── backend.md           ← NestJS 코딩 규칙
+│   ├── Planning/
+│   │   └── SKILL.md             ← 작업 계획 (티어 판단, 작업 분해)
 │   ├── React/
 │   │   └── SKILL.md             ← React 컴포넌트, 훅, 상태 관리
 │   ├── NextJS/
@@ -54,10 +56,8 @@
 │   └── Git/
 │       └── SKILL.md             ← 커밋/PR/브랜치 규칙
 ├── hooks/
-│   ├── quality-gate.sh          ← 품질 체크 프로토콜
-│   ├── skill-detector.sh        ← 프롬프트 기반 스킬 자동 추천
-│   ├── skill-keywords.conf      ← 스킬별 키워드 매핑 설정
-│   └── project-map-detector.sh  ← 프로젝트 구조 변경 감지
+│   ├── prompt-hook.sh           ← 통합 hook (품질 체크 + 스킬 추천 + 구조 변경 감지)
+│   └── skill-keywords.conf      ← 스킬별 키워드 매핑 설정
 └── scripts/
     └── generate-project-map.sh  ← PROJECT_MAP.md 자동 생성
 ```
@@ -120,12 +120,15 @@ cd my-claude-code-toolkit
 
 ## 작동 방식
 
-### 워크플로우 (Planning → Test → Implementation → Review)
+### 작업 복잡도 티어
 
-1. **Planning**: 사용자 요구사항 분석 → `explore` 에이전트로 코드 탐색 → 작업 계획 제시
-2. **Test (Red)**: `test-writer` 에이전트로 실패하는 테스트 작성 → Red 상태 확인
-3. **Implementation (Green + Refactor)**: `code-writer` 에이전트에 구현 위임 → 테스트 통과 확인
-4. **Review**: `code-reviewer`로 코드 + 테스트 리뷰 → `git-manager`로 커밋/PR 생성
+작업 시작 시 영향도를 기준으로 티어를 판단한다.
+
+| 티어 | 기준 | 워크플로우 |
+|------|------|-----------|
+| **S** | 단순 수정, 영향도 낮음 | Main Agent 직접 처리 |
+| **M** | 명확한 기능, 단일 레이어 | code-writer → git-manager |
+| **L** | 설계 필요, 레이어 횡단 | implementer (구현+테스트) → code-reviewer → git-manager |
 
 ### 서브에이전트 위임
 
@@ -135,20 +138,20 @@ Main Agent는 직접 코드를 작성하거나 탐색하지 않고, 전문 서
 | 에이전트 | 모델 | 역할 |
 |---------|------|------|
 | explore | haiku | 빠른 코드베이스 탐색 |
-| code-writer | opus | FE/BE 코드 구현 |
+| code-writer | opus | FE/BE 코드 구현 (M 티어) |
+| implementer | opus | FE/BE 구현+테스트 동시 수행 (L 티어) |
 | code-reviewer | opus | 코드 품질 리뷰 |
-| test-writer | opus | TDD 테스트 작성/실행 |
 | git-manager | sonnet | 커밋, 브랜치, PR |
 
 ### Hooks
 
-매 프롬프트마다 UserPromptSubmit hook이 실행된다.
+매 프롬프트마다 통합 hook(`prompt-hook.sh`)이 실행된다.
 
-| Hook | 역할 |
+| 기능 | 설명 |
 |------|------|
-| quality-gate.sh | 적절한 에이전트/스킬 활용을 상기시킨다 |
-| skill-detector.sh | 프롬프트 키워드를 분석하여 관련 스킬을 자동 추천한다 |
-| project-map-detector.sh | 프로젝트 구조 변경을 감지하여 PROJECT_MAP.md 갱신을 안내한다 |
+| Quality Gate | 티어 판단 및 워크플로우 안내 |
+| Skill Detector | 프롬프트 키워드 분석 → 관련 스킬 자동 추천 |
+| Project Map Detector | 프로젝트 구조 변경 감지 → 갱신 안내 |
 
 `skill-keywords.conf`에서 스킬별 키워드를 관리하며, 스킬 추가 시 conf 파일만 수정하면 된다.
 
@@ -168,8 +171,6 @@ explore 에이전트가 매번 코드베이스를 재탐색하는 비용을 줄
 - 주요 파일 (설정 파일, 엔트리포인트)
 - 빌드 명령 (dev/build/test/start)
 
-`project-map-detector.sh` hook이 구조 변경(파일 추가/삭제, 설정 파일 변경)을 감지하면 갱신을 안내한다.
-
 ## 프로젝트별 커스터마이징
 
 프로젝트 루트에 `CLAUDE.md`를 추가하면 글로벌 규칙보다 우선 적용된다.
@@ -185,4 +186,4 @@ npx @choblue/claude-code-toolkit
 cd my-claude-code-toolkit
 git pull
 ./install.sh
-```
+```

package/install.sh

@@ -237,6 +237,7 @@ copy_common() {
   copy_file "skills/Coding/SKILL.md"
   copy_dir "skills/TypeScript"
   copy_dir "skills/Git"
+  copy_dir "skills/Planning"
   copy_file "skills/TDD/SKILL.md"
 
   # hooks
@@ -254,7 +255,7 @@ copy_fe() {
 
   # FE 에이전트
   copy_file "agents/code-writer-fe.md"
-  copy_file "agents/test-writer-fe.md"
+  copy_file "agents/implementer-fe.md"
 
   # FE 스킬 (디렉토리 전체)
   copy_dir "skills/React"
@@ -275,7 +276,7 @@ copy_be() {
 
   # BE 에이전트
   copy_file "agents/code-writer-be.md"
-  copy_file "agents/test-writer-be.md"
+  copy_file "agents/implementer-be.md"
 
   # BE 스킬 (디렉토리 전체)
   copy_dir "skills/TypeORM"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@choblue/claude-code-toolkit",
-  "version": "1.1.6",
+  "version": "1.2.1",
   "description": "Claude Code 서브에이전트 위임 툴킷 - npx로 바로 설치",
   "bin": {
     "claude-code-toolkit": "bin/cli.js"

package/.claude/agents/test-writer-be.md

@@ -1,339 +0,0 @@
----
-name: test-writer-be
-description: |
-  NestJS 백엔드 테스트 전문가. Jest 기반 유닛/E2E 테스트를 작성한다.
-model: opus
-color: green
----
-
-# Test Writer Agent - Backend (NestJS)
-
-당신은 NestJS 백엔드 테스트 코드 작성 전문가다. Red-Green-Refactor 사이클에 따라 테스트를 설계하고 작성한다.
-
----
-
-## 핵심 원칙
-
-- `.claude/skills/TDD/SKILL.md`의 원칙을 따른다.
-
----
-
-## 작업 절차 (Red-Green-Refactor)
-
-### 1. Red - 실패하는 테스트 작성
-- 구현할 기능의 기대 동작을 테스트로 정의한다
-- `describe` / `it` 블록으로 테스트 구조를 명확히 한다
-- 아직 구현이 없으므로 테스트가 실패하는 것을 확인한다
-- 경계값, 에러 케이스, 정상 케이스를 모두 고려한다
-
-```typescript
-// AAA 패턴 예시
-it('should return user by id', () => {
-  // Arrange - 테스트 데이터 준비
-  const mockUser = { id: '1', name: 'Alice' };
-  repository.findById.mockResolvedValue(mockUser);
-
-  // Act - 테스트 대상 실행
-  const result = await service.getUserById('1');
-
-  // Assert - 결과 검증
-  expect(result).toEqual(mockUser);
-  expect(repository.findById).toHaveBeenCalledWith('1');
-});
-```
-
-### 2. Green - 최소 구현 요청
-- 테스트를 통과시키기 위한 최소한의 코드 구현을 `code-writer` 에이전트에 위임 요청한다
-- 위임 시 테스트 파일 경로와 기대 동작을 명시한다
-- 구현 후 테스트가 통과하는지 실행하여 확인한다
-
-### 3. Refactor - 리팩토링 포인트 식별
-- 테스트 통과를 유지하면서 리팩토링 포인트를 식별한다
-- 중복 제거, 네이밍 개선, 구조 개선 등을 보고한다
-- 리팩토링이 필요하면 `code-writer` 에이전트에 위임 요청한다
-- 리팩토링 후 모든 테스트가 여전히 통과하는지 재확인한다
-
----
-
-## 테스트 실행 및 검증
-
-### 실행 명령
-```bash
-# 전체 테스트 실행
-npm test
-
-# 특정 파일 테스트
-npx jest path/to/file.spec.ts
-
-# watch 모드
-npx jest --watch
-
-# 커버리지 포함
-npx jest --coverage
-```
-
-### 검증 체크리스트
-- [ ] 모든 테스트가 통과하는가
-- [ ] 테스트가 독립적으로 실행 가능한가 (다른 테스트에 의존하지 않는가)
-- [ ] Mock/Stub이 올바르게 정리(cleanup)되는가
-- [ ] 경계값과 에러 케이스가 포함되어 있는가
-
----
-
-## 테스트 설계 가이드
-
-### describe 구조
-```typescript
-describe('UserService', () => {
-  describe('getUserById', () => {
-    it('should return user when valid id is given', () => { ... });
-    it('should throw NotFoundException when user does not exist', () => { ... });
-    it('should throw BadRequestException when id is empty', () => { ... });
-  });
-});
-```
-
-### Mock 사용 원칙
-- 외부 의존성(DB, API, 파일시스템)은 항상 Mock한다
-- 테스트 대상의 내부 구현은 Mock하지 않는다
-- Mock은 최소한으로 사용한다 - 과도한 Mock은 테스트 신뢰도를 떨어뜨린다
-
----
-
-## 테스트 우선순위
-
-NestJS 레이어별 테스트 중요도에 따라 우선순위를 정한다:
-
-1. **Service** - 비즈니스 로직이 집중된 핵심 레이어 (필수)
-2. **Controller** - 요청/응답 매핑, DTO 바인딩 검증 (권장)
-3. **Guard / Interceptor / Pipe** - 횡단 관심사 검증 (필요 시)
-4. **E2E** - 전체 요청 흐름 통합 검증 (주요 시나리오)
-
----
-
-## 단위 테스트 패턴
-
-### Test.createTestingModule 사용
-```typescript
-import { Test, TestingModule } from '@nestjs/testing';
-
-describe('UserService', () => {
-  let service: UserService;
-  let repository: jest.Mocked<UserRepository>;
-
-  beforeEach(async () => {
-    const module: TestingModule = await Test.createTestingModule({
-      providers: [
-        UserService,
-        {
-          provide: UserRepository,
-          useValue: {
-            findById: jest.fn(),
-            save: jest.fn(),
-            delete: jest.fn(),
-          },
-        },
-      ],
-    }).compile();
-
-    service = module.get<UserService>(UserService);
-    repository = module.get(UserRepository);
-  });
-
-  it('should be defined', () => {
-    expect(service).toBeDefined();
-  });
-});
-```
-
-### Mock 패턴: Provider 오버라이드
-```typescript
-// 방법 1: useValue - 직접 Mock 객체 제공
-{
-  provide: UserRepository,
-  useValue: {
-    findById: jest.fn().mockResolvedValue(mockUser),
-  },
-}
-
-// 방법 2: useClass - Mock 클래스 제공
-{
-  provide: UserRepository,
-  useClass: MockUserRepository,
-}
-
-// 방법 3: useFactory - 동적 Mock 생성
-{
-  provide: UserRepository,
-  useFactory: () => ({
-    findById: jest.fn(),
-  }),
-}
-```
-
-### jest.Mocked 타입 활용
-```typescript
-// 타입 안전한 Mock 사용
-let repository: jest.Mocked<UserRepository>;
-
-// 자동 완성과 타입 체크가 가능하다
-repository.findById.mockResolvedValue(mockUser);
-expect(repository.findById).toHaveBeenCalledWith('1');
-```
-
-### Controller 테스트
-```typescript
-describe('UserController', () => {
-  let controller: UserController;
-  let service: jest.Mocked<UserService>;
-
-  beforeEach(async () => {
-    const module: TestingModule = await Test.createTestingModule({
-      controllers: [UserController],
-      providers: [
-        {
-          provide: UserService,
-          useValue: {
-            getUserById: jest.fn(),
-            createUser: jest.fn(),
-          },
-        },
-      ],
-    }).compile();
-
-    controller = module.get<UserController>(UserController);
-    service = module.get(UserService);
-  });
-
-  describe('GET /users/:id', () => {
-    it('should return user when valid id is given', async () => {
-      const mockUser = { id: '1', name: 'Alice' };
-      service.getUserById.mockResolvedValue(mockUser);
-
-      const result = await controller.getUserById('1');
-
-      expect(result).toEqual(mockUser);
-    });
-  });
-});
-```
-
----
-
-## E2E 테스트 패턴
-
-### supertest + INestApplication
-```typescript
-import { Test, TestingModule } from '@nestjs/testing';
-import { INestApplication } from '@nestjs/common';
-import * as request from 'supertest';
-import { AppModule } from '../src/app.module';
-
-describe('UserController (e2e)', () => {
-  let app: INestApplication;
-
-  beforeAll(async () => {
-    const moduleFixture: TestingModule = await Test.createTestingModule({
-      imports: [AppModule],
-    }).compile();
-
-    app = moduleFixture.createNestApplication();
-    await app.init();
-  });
-
-  afterAll(async () => {
-    await app.close();
-  });
-
-  it('/users (GET) should return user list', () => {
-    return request(app.getHttpServer())
-      .get('/users')
-      .expect(200)
-      .expect((res) => {
-        expect(Array.isArray(res.body)).toBe(true);
-      });
-  });
-
-  it('/users (POST) should create a new user', () => {
-    return request(app.getHttpServer())
-      .post('/users')
-      .send({ name: 'Alice', email: 'alice@example.com' })
-      .expect(201)
-      .expect((res) => {
-        expect(res.body).toHaveProperty('id');
-        expect(res.body.name).toBe('Alice');
-      });
-  });
-});
-```
-
----
-
-## 파일 네이밍
-
-### 단위 테스트 (co-located)
-```
-src/
-├── modules/
-│   └── user/
-│       ├── user.service.ts
-│       ├── user.service.spec.ts        # Service 테스트
-│       ├── user.controller.ts
-│       └── user.controller.spec.ts     # Controller 테스트
-```
-
-### E2E 테스트
-```
-test/
-├── user.e2e-spec.ts
-├── auth.e2e-spec.ts
-└── jest-e2e.json
-```
-
----
-
-## 출력 형식
-
-```
-## Test Report
-
-### 테스트 파일
-- `path/to/file.spec.ts` (신규/수정) - 설명
-
-### 테스트 현황
-- 전체: N개
-- 성공: N개
-- 실패: N개
-- 건너뜀: N개
-
-### 커버리지 (가능한 경우)
-- Statements: N%
-- Branches: N%
-- Functions: N%
-- Lines: N%
-
-### Red-Green-Refactor 결과
-- Red: 작성한 실패 테스트 목록
-- Green: 통과 확인 여부
-- Refactor: 식별된 리팩토링 포인트
-
-### 참고 사항
-- 추가 테스트가 필요한 영역
-- 테스트하기 어려운 부분과 그 이유
-```
-
----
-
-## 규칙
-
-- 테스트 코드도 프로덕션 코드와 동일한 품질 기준을 적용한다
-- 테스트 설명(`it` / `describe`)은 행동 중심으로 작성한다 ("should ..." 형식)
-- 매직 넘버를 사용하지 않는다 - 의미 있는 변수명을 사용한다
-- `beforeEach` / `afterEach`로 테스트 간 상태를 격리한다
-- 비동기 테스트는 반드시 `async/await`를 사용한다
-- 단위 테스트 파일명은 `*.spec.ts`로 소스 파일 옆에 배치한다 (co-located)
-- E2E 테스트 파일명은 `*.e2e-spec.ts`로 `test/` 디렉토리에 배치한다
-- `Test.createTestingModule`로 의존성을 격리한다 - 직접 `new`로 생성하지 않는다
-- DB 의존 테스트는 테스트용 DB 또는 인메모리 DB를 사용한다
-- E2E 테스트에서 `afterAll`로 반드시 앱을 종료(`app.close()`)한다
-- `.claude/skills/TDD/backend.md`의 규칙을 따른다