jun-claude-code 0.0.12 → 0.0.13

package/templates/global/skills/Backend/SKILL.md

@@ -7,6 +7,8 @@ estimated_tokens: ~400
 
 # 백엔드 개발 원칙
 
+<rules>
+
 ## 레이어 간 객체 변환 규칙
 
 > **객체 변환은 필요한 시점에 해당 레이어에서 수행한다.**
@@ -15,12 +17,16 @@ estimated_tokens: ~400
 
 | 레이어 | 입력 | 출력 | 변환 책임 |
 |--------|------|------|----------|
-| **Controller** | Request DTO | Response DTO/Schema | Entity → Response 변환 |
-| **Service** | DTO (그대로 사용) | Entity 또는 일반 객체 | DTO → Entity 변환 (필요시) |
+| **Controller** | Request DTO | Response DTO/Schema | Entity -> Response 변환 |
+| **Service** | DTO (그대로 사용) | Entity 또는 일반 객체 | DTO -> Entity 변환 (필요시) |
 | **Repository** | Entity | Entity | 없음 |
 
-### Controller → Service 호출
+</rules>
+
+### Controller -> Service 호출
 
+<examples>
+<example type="bad">
 ```typescript
 // ❌ Controller에서 미리 Entity로 변환
 @Post()
@@ -30,13 +36,18 @@ async create(@Body() dto: CreateUserDto) {
   entity.email = dto.email;
   return this.userService.create(entity);  // Entity 전달
 }
-
+```
+</example>
+<example type="good">
+```typescript
 // ✅ DTO 그대로 전달
 @Post()
 async create(@Body() dto: CreateUserDto) {
   return this.userService.create(dto);  // DTO 전달
 }
 ```
+</example>
+</examples>
 
 ### Service 내부 처리
 
@@ -55,7 +66,7 @@ async create(dto: CreateUserDto) {
 }
 ```
 
-### Service → Controller 반환
+### Service -> Controller 반환
 
 ```typescript
 // ✅ Service: Entity 또는 일반 객체 반환
@@ -79,9 +90,11 @@ async findOne(@Param('id') id: number) {
 
 ---
 
+<rules>
+
 ## TypeORM 사용 규칙
 
-> **find 메서드를 기본으로 사용하고, QueryBuilder는 꼭 필요한 경우에만 사용한다.**
+> **find 메서드를 기본으로 사용하고, QueryBuilder는 필요한 경우에만 사용한다.**
 
 ### find 메서드 우선 사용
 
@@ -115,6 +128,10 @@ const users = await this.userRepository.find({
 | **복잡한 서브쿼리** | 중첩 쿼리 |
 | **복잡한 JOIN 조건** | ON 절 커스텀 |
 
+</rules>
+
+<examples>
+<example type="good">
 ```typescript
 // ✅ QueryBuilder 허용: groupBy + getRawMany
 const stats = await this.orderRepository
@@ -124,24 +141,36 @@ const stats = await this.orderRepository
   .addSelect('SUM(order.amount)', 'total')
   .groupBy('order.status')
   .getRawMany();
-
+```
+</example>
+<example type="bad">
+```typescript
 // ❌ 불필요한 QueryBuilder 사용
 const user = await this.userRepository
   .createQueryBuilder('user')
   .where('user.id = :id', { id })
   .getOne();
-
+```
+</example>
+<example type="good">
+```typescript
 // ✅ find로 대체
 const user = await this.userRepository.findOneBy({ id });
 ```
+</example>
+</examples>
 
 ---
 
+<checklist>
+
 ## 체크리스트
 
-- [ ] Controller에서 Entity로 변환하지 않고 DTO를 그대로 Service에 전달하는가?
+- [ ] Controller에서 DTO를 그대로 Service에 전달하는가? (Entity 변환은 Service에서)
 - [ ] Service에서 Entity가 필요한 시점에 변환하는가?
 - [ ] Service의 return은 Entity 또는 일반 객체인가?
 - [ ] Controller에서 Response DTO/Schema로 변환하는가?
 - [ ] TypeORM find 메서드를 우선 사용하는가?
 - [ ] QueryBuilder는 groupBy, getRawMany 등 필요한 경우에만 사용하는가?
+
+</checklist>

package/templates/global/skills/Coding/SKILL.md

@@ -7,29 +7,31 @@ estimated_tokens: ~500
 
 # 공통 코딩 원칙
 
+<rules>
+
 ## 단일 책임 원칙 (SRP)
 
 > **하나의 모듈/컴포넌트는 하나의 책임만 가진다.**
 
 ### 백엔드 레이어별 책임
 
-| 레이어 | 책임 | 금지 |
-|--------|------|------|
-| **Entity** | 데이터 구조 정의 | 비즈니스 로직 |
-| **Repository** | 데이터 접근 | 비즈니스 로직 |
-| **Service** | 비즈니스 로직 | HTTP 의존 |
-| **Controller** | 요청 라우팅 | 비즈니스 로직 |
-| **DTO/Schema** | 데이터 전송 구조 | 로직 |
+| 레이어 | 책임 | 전담 영역 |
+|--------|------|----------|
+| **Entity** | 데이터 구조 정의 | 구조 정의에 집중 |
+| **Repository** | 데이터 접근 | 데이터 접근에 집중 |
+| **Service** | 비즈니스 로직 | 비즈니스 로직에 집중 |
+| **Controller** | 요청 라우팅 | 요청/응답 처리에 집중 |
+| **DTO/Schema** | 데이터 전송 구조 | 데이터 전송에 집중 |
 
 ### 프론트엔드 컴포넌트별 책임
 
-| 유형 | 책임 | 금지 |
-|------|------|------|
-| **Page** | 레이아웃, 데이터 fetch | 복잡한 로직 |
-| **Container** | 상태 관리, API 호출 | 과도한 UI |
-| **Presentational** | UI 렌더링 | API 호출, 전역 상태 |
-| **Hook** | 특정 로직 캡슐화 | 여러 책임 혼합 |
-| **Store** | 전역 상태 | UI 로직 |
+| 유형 | 책임 | 전담 영역 |
+|------|------|----------|
+| **Page** | 레이아웃, 데이터 fetch | 레이아웃과 fetch에 집중 |
+| **Container** | 상태 관리, API 호출 | 상태/API에 집중 |
+| **Presentational** | UI 렌더링 | UI 렌더링에 집중 (props로 데이터 수신) |
+| **Hook** | 특정 로직 캡슐화 | 단일 로직에 집중 |
+| **Store** | 전역 상태 | 상태 관리에 집중 |
 
 ---
 
@@ -41,31 +43,45 @@ estimated_tokens: ~500
 
 | 규칙 | 설명 |
 |------|------|
-| **순환 의존 금지** | A → B → A 형태 금지 |
-| **상위 모듈 의존 금지** | shared는 도메인 모듈 의존 금지 |
-| **인터페이스로 의존** | 구체 클래스 대신 추상화에 의존 |
+| **단방향 의존 유지** | A → B 단방향으로 유지 (순환 구조 대신) |
+| **상위 모듈은 독립적으로 유지** | shared는 도메인 모듈과 독립 유지 |
+| **인터페이스에 의존** | 구체 클래스 대신 추상화에 의존 |
 | **공개 API 통해 접근** | index.ts를 통한 export만 사용 |
 
 ### 백엔드
 
+<examples>
+<example type="good">
 ```typescript
 // 토큰 기반 주입 / 인터페이스 의존
 @Inject(PRODUCT_REPOSITORY)
 private readonly repository: IProductRepository
-
-// 구체 클래스 직접 의존 금지
+```
+</example>
+<example type="bad">
+```typescript
+// ❌ 구체 클래스 직접 의존
 private readonly repository: ProductRepository
 ```
+</example>
+</examples>
 
 ### 프론트엔드
 
+<examples>
+<example type="good">
 ```typescript
 // props로 의존성 전달
 function ProductCard({ product, onAction }: Props) { ... }
-
-// 전역 상태 직접 접근 (Presentational에서) 금지
+```
+</example>
+<example type="bad">
+```typescript
+// ❌ Presentational에서 전역 상태 직접 접근
 const action = useStore(s => s.action);
 ```
+</example>
+</examples>
 
 ---
 
@@ -99,7 +115,7 @@ src/
 │   │   ├── product.dto.ts
 │   │   └── product.module.ts
 │   └── order/
-└── shared/              # 공통 (상위 의존 금지)
+└── shared/              # 공통 (도메인 모듈과 독립 유지)
 ```
 
 ```
@@ -109,20 +125,26 @@ src/
 │   │   ├── ProductCard.tsx
 │   │   ├── ProductList.tsx
 │   │   └── index.ts
-│   └── common/          # 공통 (도메인 의존 금지)
+│   └── common/          # 공통 (도메인과 독립 유지)
 ├── hooks/               # 도메인별 hook
 ├── store/               # 전역 상태
 └── shared/              # 유틸리티
 ```
 
+</rules>
+
 ---
 
+<rules>
+
 ## 가독성 규칙
 
 ### try-catch vs then-catch
 
 > **Promise 처리 시 `then-catch` 패턴을 사용한다.**
 
+<examples>
+<example type="bad">
 ```typescript
 // ❌ try-catch (가독성 저하)
 async function fetchUser(id: string) {
@@ -133,7 +155,10 @@ async function fetchUser(id: string) {
     throw new NotFoundException('User not found');
   }
 }
-
+```
+</example>
+<example type="good">
+```typescript
 // ✅ then-catch (가독성 향상)
 function fetchUser(id: string) {
   return userService.findById(id)
@@ -143,17 +168,24 @@ function fetchUser(id: string) {
     });
 }
 ```
+</example>
+</examples>
 
 ### 삼항연산자 규칙
 
-> **삼항연산자에서 인자가 2개 이상인 함수를 호출하지 않는다.**
+> **삼항연산자에서 인자가 2개 이상인 함수 호출은 변수로 분리한다.**
 
+<examples>
+<example type="bad">
 ```typescript
 // ❌ 삼항연산자 내 복잡한 함수 호출
 const result = isAdmin
   ? processAdminData(data, options, config)
   : processUserData(data, options);
-
+```
+</example>
+<example type="good">
+```typescript
 // ✅ 변수로 분리 후 사용
 const processor = isAdmin ? processAdminData : processUserData;
 const result = processor(data, options, config);
@@ -166,19 +198,27 @@ if (isAdmin) {
   result = processUserData(data, options);
 }
 ```
+</example>
+</examples>
 
 **삼항연산자 허용 케이스:**
 - 단순 값 선택: `const name = isKorean ? '홍길동' : 'John';`
 - 인자 없는/1개 함수: `const value = isValid ? getValue() : getDefault();`
 
+</rules>
+
 ---
 
+<checklist>
+
 ## 코드 작성 시 체크리스트
 
 - [ ] 이 파일의 책임은 하나인가?
-- [ ] 다른 모듈에 불필요하게 의존하고 있지 않은가?
+- [ ] 다른 모듈에 불필요한 의존이 있는가? (있다면 제거)
 - [ ] 관련 파일들이 같은 폴더에 있는가?
-- [ ] 순환 의존이 발생하지 않는가?
+- [ ] 단방향 의존이 유지되는가?
 - [ ] 공개 API(index.ts)를 통해 접근하는가?
 - [ ] Promise 처리에 then-catch 패턴을 사용했는가?
-- [ ] 삼항연산자에서 복잡한 함수 호출을 피했는가?
+- [ ] 삼항연산자에서 복잡한 함수 호출을 변수로 분리했는가?
+
+</checklist>

package/templates/global/skills/Director/SKILL.md

@@ -74,14 +74,16 @@ keywords: [관련 키워드]
 
 | 축 | 검증 질문 | 예시 |
 |----|----------|------|
-| **기능 범위** | 기존 기능과 겹치거나 모순되지 않는가? | 결제 기능이 이미 존재하는데 별도 결제 모듈 추가 |
-| **비즈니스 규칙** | 기존 규칙과 충돌하는 조건이 없는가? | "주문 최소 금액 1만원" vs "0원 주문 허용" |
+| **기능 범위** | 기존 기능과 겹치거나 모순되는 부분이 있는가? | 결제 기능이 이미 존재하는데 별도 결제 모듈 추가 |
+| **비즈니스 규칙** | 기존 규칙과 충돌하는 조건이 있는가? | "주문 최소 금액 1만원" vs "0원 주문 허용" |
 | **데이터 모델** | 기존 모델 구조와 호환되는가? | 필수 필드 제거, 타입 변경 |
 | **UX 플로우** | 기존 사용자 플로우와 일관되는가? | 로그인 후 리다이렉트 경로 변경 |
-| **기술 제약** | 아키텍처/기술 스택 제약을 위반하지 않는가? | REST API에 GraphQL 엔드포인트 혼용 |
+| **기술 제약** | 아키텍처/기술 스택 제약을 준수하는가? | REST API에 GraphQL 엔드포인트 혼용 |
 
 ---
 
+<checklist>
+
 ## 충돌 탐지 체크리스트
 
 스펙 변경 시 아래 4가지 유형의 충돌을 확인합니다.
@@ -92,16 +94,18 @@ keywords: [관련 키워드]
 
 ### 2. 의존성 파괴
 - 변경이 다른 기능의 전제 조건을 깨뜨리는 경우
-- 예: 사용자 테이블 구조 변경 → 인증 모듈 파괴
+- 예: 사용자 테이블 구조 변경 -> 인증 모듈 파괴
 
 ### 3. 암묵적 충돌
 - 명시되지 않았지만 전제가 변경되어 발생하는 충돌
-- 예: 응답 포맷 변경 → 프론트엔드 파싱 실패
+- 예: 응답 포맷 변경 -> 프론트엔드 파싱 실패
 
 ### 4. 데이터 불일치
 - 같은 데이터를 다른 문서에서 다르게 정의
 - 예: A 문서에서 "status: string", B 문서에서 "status: enum"
 
+</checklist>
+
 ---
 
 ## 심각도 분류

package/templates/global/skills/Documentation/SKILL.md

@@ -2,7 +2,7 @@
 name: Documentation
 description: .claude 폴더 내 문서 생성/수정 시 사용. frontmatter 형식, Context/Skill/Agent 템플릿, 파일 분리 기준 제공.
 keywords: [문서, 작성, CLAUDE.md, context, skill, agent, frontmatter, 템플릿]
-estimated_tokens: ~800
+estimated_tokens: ~1200
 ---
 
 # .claude 문서 작성 스킬
@@ -119,10 +119,19 @@ estimated_tokens: ~300
 
 (필요시 코드 블록, 상세 설명)
 
+## 제약 사항
+
+<constraints>
+- 제약 1
+- 제약 2
+</constraints>
+
 ## 관련 파일
 
+<reference>
 - `path/to/related.md` - 설명
 - `src/module/` - 관련 소스 코드
+</reference>
 ```
 
 ### Skill 템플릿
@@ -139,25 +148,33 @@ estimated_tokens: ~400
 
 ## 핵심 역할
 
+<instructions>
 - 역할 1
 - 역할 2
+</instructions>
 
 ## 필수 준수 사항
 
+<rules>
 | 규칙 | 올바른 예 | 잘못된 예 |
 |------|----------|----------|
 | ... | ... | ... |
+</rules>
 
 ## 코드 예제
 
+<examples>
 \`\`\`typescript
 // 올바른 패턴
 \`\`\`
+</examples>
 
 ## 체크리스트
 
+<checklist>
 - [ ] 확인 항목 1
 - [ ] 확인 항목 2
+</checklist>
 
 ## 관련 문서
 
@@ -179,16 +196,19 @@ color: blue
 
 # Agent 이름
 
+<role>
 ## 역할
 
 1. 첫 번째 역할
 2. 두 번째 역할
+</role>
 
 ## 언제 사용하는가
 
 - 사용 시점 1
 - 사용 시점 2
 
+<instructions>
 ## 프로세스
 
 ### Step 1: 준비
@@ -196,7 +216,16 @@ color: blue
 
 ### Step 2: 실행
 ...
+</instructions>
+
+<constraints>
+## 제약 사항
 
+- 이 Agent는 A만 전담한다
+- B 작업은 other-agent에 위임한다
+</constraints>
+
+<output_format>
 ## 출력 형식
 
 \`\`\`markdown
@@ -205,6 +234,7 @@ color: blue
 ## 요약
 ...
 \`\`\`
+</output_format>
 ```
 
 ## 인덱스 파일 작성법
@@ -272,6 +302,43 @@ keywords:
 - frontmatter 누락
 - 모호한 keywords
 
+## 프롬프트 구조화 (XML 태그)
+
+문서에 XML 태그를 사용하면 Claude가 지시/규칙/제약을 정확히 구분하여 준수율이 높아집니다.
+
+### 파일 유형별 권장 XML 태그
+
+| 파일 유형 | 필수 태그 | 선택 태그 |
+|----------|----------|----------|
+| Agent | `<role>`, `<instructions>`, `<constraints>`, `<output_format>` | `<rules>`, `<examples>`, `<reference>` |
+| Skill | `<instructions>`, `<rules>`, `<checklist>` | `<examples>`, `<constraints>`, `<reference>` |
+| CLAUDE.md | `<workflow>`, `<delegation_rules>`, `<constraints>` | `<rules>`, `<reference>` |
+| Hook | `<phase name="...">`, `<checklist>` | `<delegation_rules>`, `<rules>` |
+
+### 긍정 표현 원칙
+
+프롬프트는 부정 표현 대신 긍정 표현으로 작성합니다.
+
+| 부정 표현 (비권장) | 긍정 표현 (권장) |
+|-------------------|-----------------|
+| "직접 수정하지 마라" | "모든 수정은 code-writer가 전담한다" |
+| "Git 명령어 실행 금지" | "Git 작업은 git-manager에 위임한다" |
+| "3개 이상 파일 수정 금지" | "파일 수정은 2개 이하만 직접 수행한다" |
+
+- 제약은 "~만 한다", "~전용", "~전담" 형태로 표현
+- 대안 행동을 구체적으로 명시 (무엇을 대신 해야 하는지)
+
+### XML 태그 사용 규칙
+
+1. **섹션 경계를 명확히**: 태그는 논리적 블록 단위로 감싼다
+2. **중첩 최소화**: 2단계 이상 중첩은 지양한다
+3. **태그 이름 통일**: 위 테이블의 태그명을 일관되게 사용한다
+4. **Markdown과 병행**: 태그 안에서 Markdown 서식을 그대로 사용한다
+
+> 상세 가이드: `.claude/skills/PromptStructuring/`
+
+---
+
 ## 체크리스트
 
 ### 새 파일 작성 시

package/templates/global/skills/Git/SKILL.md

@@ -14,6 +14,8 @@ estimated_tokens: ~100
 - PR/MR 코드 리뷰
 - 리뷰 피드백 반영
 
+<reference>
+
 ## 관련 문서
 
 | 주제 | 위치 | 설명 |
@@ -22,6 +24,8 @@ estimated_tokens: ~100
 | PR 리뷰 | `pr-review.md` | 체크리스트 기반 코드 리뷰 워크플로우 |
 | PR 피드백 적용 | `pr-apply.md` | 리뷰 피드백 분류 및 반영 방법 |
 
+</reference>
+
 ## 빠른 참조
 
 ### Commit PREFIX
@@ -45,10 +49,10 @@ estimated_tokens: ~100
 
 | 섹션 | 설명 |
 |------|------|
-| 📋 Summary | 핵심 변경 1-2문장 요약 |
-| 🔄 주요 변경사항 | 파일별 변경 내용 |
-| ⚠️ 사이드 이펙트 | 다른 영역 영향 분석 |
-| 🔀 변경 흐름 | mermaid 다이어그램 (선택) |
+| Summary | 핵심 변경 1-2문장 요약 |
+| 주요 변경사항 | 파일별 변경 내용 |
+| 사이드 이펙트 | 다른 영역 영향 분석 |
+| 변경 흐름 | mermaid 다이어그램 (선택) |
 
 ### PR 워크플로우