jun-claude-code 0.0.12 → 0.0.13

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

@@ -7,6 +7,8 @@ estimated_tokens: ~600
 
 # Git 작업 가이드
 
+<rules>
+
 ## Commit 메시지
 
 ### 형식
@@ -34,7 +36,7 @@ Co-Authored-By: Claude <noreply@anthropic.com>
 ### 작성 원칙
 
 - **한글 사용**, 50자 이내
-- **현재형**: "추가함" → "추가"
+- **현재형**: "추가함" 대신 "추가"
 - **Why 중심**: 무엇보다 왜 변경했는지
 
 ### Commit 단위
@@ -43,6 +45,8 @@ Co-Authored-By: Claude <noreply@anthropic.com>
 - 각 커밋 후 빌드 에러 없음
 - 되돌리기 용이한 단위
 
+</rules>
+
 ---
 
 ## 브랜치 전략
@@ -56,6 +60,8 @@ chore/{작업명}       # 설정/빌드
 
 ---
 
+<instructions>
+
 ## PR (Pull Request) 생성
 
 ### Step 1: 변경사항 분석
@@ -121,11 +127,11 @@ grep -r "import.*변경된함수명" --include="*.ts" --include="*.tsx"
 ### Step 4: PR 본문 작성
 
 ```markdown
-## 📋 Summary
+## Summary
 
 > 이 PR이 해결하는 문제와 접근 방식을 1-2문장으로 설명
 
-## 🔄 주요 변경사항
+## 주요 변경사항
 
 ### [변경 제목 1]
 **파일:** `path/to/file.ts`
@@ -135,7 +141,7 @@ grep -r "import.*변경된함수명" --include="*.ts" --include="*.tsx"
 **파일:** `path/to/file.ts`
 - 변경 내용 설명
 
-## ⚠️ 사이드 이펙트
+## 사이드 이펙트
 
 > 이 변경으로 인해 다른 부분에 발생할 수 있는 영향
 
@@ -143,7 +149,7 @@ grep -r "import.*변경된함수명" --include="*.ts" --include="*.tsx"
 |---------------|----------|--------|
 | 없음 | - | - |
 
-## 🔀 변경 흐름
+## 변경 흐름
 
 ```mermaid
 graph LR
@@ -166,20 +172,24 @@ EOF
 )"
 ```
 
+</instructions>
+
 ---
 
-## Git 명령어 주의사항
+<rules>
 
-### 금지
+## Git 명령어 안전 규칙
 
-| 명령어 | 이유 |
+### 사용 제한 명령어
+
+| 명령어 | 대안 |
 |--------|------|
-| `git add -A`, `git add .` | 민감 파일 포함 위험 |
-| `git push --force` | 히스토리 손상 |
-| `git reset --hard` | 작업 손실 위험 |
-| `--no-verify` | hook 우회 금지 |
+| `git add -A`, `git add .` | 파일을 지정하여 `git add path/to/file` 사용 |
+| `git push --force` | `git push` 또는 `--force-with-lease` 사용 |
+| `git reset --hard` | `git stash` 또는 `git checkout -- file` 사용 |
+| `--no-verify` | hook을 통과하도록 코드 수정 |
 
-### 권장
+### 권장 패턴
 
 ```bash
 # 파일 지정하여 add
@@ -196,8 +206,12 @@ EOF
 )"
 ```
 
+</rules>
+
 ---
 
+<checklist>
+
 ## PR 생성 전 체크리스트
 
 - [ ] `lint` 통과
@@ -207,8 +221,12 @@ EOF
 - [ ] 영향 범위 분석 완료
 - [ ] Breaking change 명시 (해당시)
 
+</checklist>
+
 ---
 
+<instructions>
+
 ## PR 생성 후 워크플로우
 
 ### Step 6: Self PR Review
@@ -227,15 +245,19 @@ gh pr view <PR번호>
 
 | 항목 | 확인 |
 |------|------|
-| 불필요한 코드/주석 제거 | ☐ |
-| 디버그 코드 제거 (console.log 등) | ☐ |
-| 하드코딩된 값 없음 | ☐ |
-| 타입 안전성 확인 | ☐ |
-| 에러 핸들링 적절함 | ☐ |
-| 네이밍 컨벤션 준수 | ☐ |
+| 불필요한 코드/주석 제거 | |
+| 디버그 코드 제거 (console.log 등) | |
+| 하드코딩된 값 확인 | |
+| 타입 안전성 확인 | |
+| 에러 핸들링 적절함 | |
+| 네이밍 컨벤션 준수 | |
+
+<reference>
 
 > 상세 체크리스트: `.claude/skills/Git/pr-review.md`
 
+</reference>
+
 **Self Review 이슈 발견 시:**
 
 ```bash
@@ -287,30 +309,40 @@ git push
 gh pr comment <PR번호> --body "리뷰 피드백 반영 완료. 재확인 부탁드립니다."
 ```
 
+<reference>
+
 > 상세 가이드: `.claude/skills/Git/pr-apply.md`
 
+</reference>
+
+</instructions>
+
 ---
 
 ## 전체 PR 워크플로우 요약
 
 ```mermaid
 graph TD
-  A[📊 변경사항 분석] --> B[🔍 영향 범위 분석]
-  B --> C[⚖️ 영향 판단]
-  C --> D[✍️ PR 본문 작성]
-  D --> E[🚀 PR 생성]
-  E --> F[🔎 Self PR Review]
-  F -->|이슈 발견| G[🔧 수정 & Push]
+  A[변경사항 분석] --> B[영향 범위 분석]
+  B --> C[영향 판단]
+  C --> D[PR 본문 작성]
+  D --> E[PR 생성]
+  E --> F[Self PR Review]
+  F -->|이슈 발견| G[수정 & Push]
   G --> F
-  F -->|OK| H[👥 팀원 리뷰 대기]
-  H -->|피드백| I[📝 PR Apply Mode]
+  F -->|OK| H[팀원 리뷰 대기]
+  H -->|피드백| I[PR Apply Mode]
   I --> H
-  H -->|Approve| J[✅ Merge]
+  H -->|Approve| J[Merge]
 ```
 
+<reference>
+
 ### 관련 Skill 참조
 
 | 단계 | Skill |
 |------|-------|
 | PR Review | `.claude/skills/Git/pr-review.md` |
 | PR Apply | `.claude/skills/Git/pr-apply.md` |
+
+</reference>

package/templates/global/skills/Git/pr-apply.md

@@ -10,6 +10,8 @@ user-invocable: true
 
 PR 리뷰 피드백을 코드에 반영하는 가이드.
 
+<instructions>
+
 ## Apply Workflow
 
 ### Step 1: 리뷰 피드백 확인
@@ -58,6 +60,10 @@ git push origin feature/branch-name
 gh pr comment <PR번호> --body "리뷰 피드백 반영 완료했습니다. 재확인 부탁드립니다."
 ```
 
+</instructions>
+
+<rules>
+
 ## 피드백 대응 원칙
 
 ### 수용할 때
@@ -77,11 +83,17 @@ gh pr comment <PR번호> --body "리뷰 피드백 반영 완료했습니다. 재
 - 해당 코멘트에 직접 답변
 - 필요시 코드에 주석 추가
 
+</rules>
+
+<checklist>
+
 ## 체크리스트
 
-- [ ] 모든 Critical 피드백 반영
-- [ ] Suggestion 검토 및 결정
-- [ ] Question 답변 완료
-- [ ] `lint` 통과
-- [ ] `build` 성공
-- [ ] 리뷰어에게 재확인 요청
+- [ ] 모든 Critical 피드백을 반영했는가?
+- [ ] Suggestion을 검토하고 결정했는가?
+- [ ] Question에 답변을 완료했는가?
+- [ ] `lint` 통과하는가?
+- [ ] `build` 성공하는가?
+- [ ] 리뷰어에게 재확인을 요청했는가?
+
+</checklist>

package/templates/global/skills/Git/pr-review.md

@@ -10,6 +10,8 @@ user-invocable: true
 
 체크리스트 기반 Pull Request 리뷰.
 
+<instructions>
+
 ## Review Workflow
 
 ### Step 1: Review Plan 작성
@@ -58,6 +60,8 @@ user-invocable: true
 ### Highlights (좋은 점)
 ```
 
+</instructions>
+
 ## PR 타입별 Focus
 
 | Type | Focus Areas |

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

@@ -0,0 +1,67 @@
+---
+name: PromptStructuring
+description: "Claude Code 프롬프트의 XML 태그 구조화 및 긍정 표현 전환 가이드"
+keywords: [prompt, xml-tags, positive-phrasing, structuring, 프롬프트, 구조화, 긍정표현, XML]
+estimated_tokens: 800
+---
+
+# 프롬프트 구조화 스킬
+
+## 개요
+
+프롬프트의 **형식과 표현 방식**은 LLM 출력 품질에 직접적인 영향을 준다.
+
+- **형식**: 동일한 내용이라도 XML 태그로 의미를 구분하면 모델이 역할/지시/규칙을 명확히 구분
+- **표현**: 부정 표현("~금지") 대신 긍정 표현("~한다")을 사용하면 의도한 행동을 직접 유도
+
+### 연구 근거
+
+| 연구 | 핵심 발견 | 시사점 |
+|------|----------|--------|
+| Sclar et al. (2023) | 동일 내용, 형식만 변경해도 최대 76%p 성능 차이 | 프롬프트 구조가 정확도에 직결 |
+| Voronov et al. (2024) | 프롬프트 포맷팅이 Few-shot 성능에 체계적 영향 | 일관된 태그 구조가 안정적 성능 보장 |
+| Anthropic 공식 가이드 | XML 태그 사용을 공식 권장 | Claude 모델에 최적화된 구조화 방식 |
+
+## 핵심 원칙
+
+### 1. XML 태그로 의미 구분
+
+마크다운 제목(`##`) 대신 XML 태그로 역할/지시/규칙/제약을 구분한다.
+
+```
+마크다운만 사용 -> XML 태그로 의미 구분
+
+## 역할          ->  <role>
+## 지시사항      ->  <instructions>
+## 규칙          ->  <rules>
+## 제약사항      ->  <constraints>
+```
+
+### 2. 긍정 표현으로 행동 유도
+
+부정 명령 대신 긍정 행동을 명시한다.
+
+```
+부정 표현 -> 긍정 표현
+
+"코드 직접 수정 금지"    ->  "모든 코드 수정은 code-writer에 위임"
+"git add -A 금지"       ->  "수정한 파일만 개별 지정하여 git add"
+"과도한 추상화 금지"     ->  "필요한 만큼만 추상화"
+```
+
+### 3. `->` 흐름 기호 활용
+
+단계, 변환, 위임을 나타낼 때 `->` 기호를 사용한다.
+
+```
+단계: 계획 -> 구현 -> 검증
+변환: 부정 표현 -> 긍정 표현
+위임: 코드 수정 -> code-writer Agent
+```
+
+## 관련 문서
+
+| 문서 | 설명 |
+|------|------|
+| `xml-tags.md` | XML 태그 표준 목록, 파일 유형별 권장 조합, Before/After 예시 |
+| `positive-phrasing.md` | 부정 -> 긍정 전환 패턴, 카테고리별 변환 테이블, 체크리스트 |

package/templates/global/skills/PromptStructuring/positive-phrasing.md

@@ -0,0 +1,206 @@
+---
+name: "Positive Phrasing Guide"
+description: "프롬프트의 부정 표현을 긍정 표현으로 전환하는 가이드"
+keywords: [positive-phrasing, prompt-optimization, negation-removal, 긍정표현, 부정제거]
+estimated_tokens: 2000
+---
+
+# 긍정 표현 전환 가이드
+
+## 왜 긍정 표현인가
+
+부정 명령("~하지 마", "~금지")은 LLM이 **금지 대상을 먼저 인식**하게 만든다.
+
+```
+"코드를 직접 수정하지 마세요"
+  -> 모델이 "코드를 직접 수정" 개념을 활성화한 후 억제 시도
+  -> 의도치 않은 활성화 가능성 존재
+
+"모든 코드 수정은 code-writer에 위임하세요"
+  -> 모델이 "code-writer에 위임" 행동을 직접 활성화
+  -> 원하는 행동을 바로 유도
+```
+
+긍정 표현은 **원하는 행동 자체를 명시**하므로 모델이 바로 올바른 방향으로 행동한다.
+
+---
+
+## 전환 패턴
+
+### 카테고리 1: 금지/제한 패턴
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "~금지" | -> | "~전담/전용" |
+| "절대 ~않는다" | -> | "항상 ~한다" |
+| "NEVER ~" | -> | "ALWAYS ~" |
+| "~하지 마세요" | -> | "~하세요" (원하는 행동) |
+| "~을 사용하지 않는다" | -> | "~을 사용한다" (대안 명시) |
+
+**예시:**
+
+```
+"git add -A 금지"
+  -> "수정한 파일만 개별 지정하여 git add"
+
+"구체 클래스 직접 의존 금지"
+  -> "인터페이스/추상화에 의존한다"
+
+"전역 상태 직접 접근 금지 (Presentational에서)"
+  -> "props로 의존성을 전달한다"
+```
+
+### 카테고리 2: 확인 패턴
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "~없는지 확인" | -> | "~인지 확인" |
+| "에러가 발생하지 않는지 확인" | -> | "정상 동작하는지 확인" |
+| "누락된 것이 없는지 점검" | -> | "모든 항목이 포함되었는지 점검" |
+
+**예시:**
+
+```
+"순환 의존이 발생하지 않는가?"
+  -> "의존 방향이 단방향인가?"
+
+"빌드 에러가 발생하지 않는 상태 유지"
+  -> "빌드 가능 상태를 유지"
+
+"누락된 엣지케이스 없는지 점검"
+  -> "모든 엣지케이스가 처리되었는지 점검"
+```
+
+### 카테고리 3: 과도 방지 패턴
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "과도한 X 금지" | -> | "필요한 만큼만 X" |
+| "불필요한 X 금지" | -> | "필요한 X만 포함" |
+| "복잡한 X 피하기" | -> | "단순한 X 유지" |
+
+**예시:**
+
+```
+"과도한 추상화 금지"
+  -> "필요한 만큼만 추상화"
+
+"불필요한 파일 생성 금지"
+  -> "기존 파일 수정을 우선"
+
+"주석 과다 금지"
+  -> "코드가 자명할 때는 주석 생략"
+```
+
+### 카테고리 4: 위임 패턴
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "직접 수행 금지" | -> | "Subagent에 위임" |
+| "Main Agent에서 직접 X 금지" | -> | "X는 [Agent명]이 전담" |
+| "직접 수정하지 않는다" | -> | "[Agent명]에 위임한다" |
+
+**예시:**
+
+```
+"Main Agent에서 직접 코드 수정 금지"
+  -> "모든 코드 수정은 code-writer가 전담"
+
+"Main Agent에서 직접 Git 명령어 실행 금지"
+  -> "모든 Git 작업은 git-manager에 위임"
+
+"Main Agent에서 직접 여러 파일 탐색 금지"
+  -> "파일 탐색은 explore Agent가 전담"
+```
+
+---
+
+## 파일 유형별 자주 등장하는 전환
+
+### Agent 파일
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "코드 직접 수정 금지" | -> | "모든 코드 수정은 code-writer에 위임" |
+| "여러 기능을 동시에 구현하지 않는다" | -> | "한 번에 하나의 기능만 구현한다" |
+| "import 경로가 올바르지 않은 상태로 두지 않는다" | -> | "각 파일 작성 후 import 경로가 올바른지 확인한다" |
+
+### Skill 파일
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "중첩 요소 사용 금지" | -> | "단일 수준 구조를 유지한다" |
+| "장황한 설명 금지" | -> | "테이블과 코드 예제로 압축한다" |
+| "1000줄 초과 금지" | -> | "500줄 이내로 유지하고, 초과 시 파일을 분리한다" |
+
+### Hook 파일
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "Phase를 건너뛰지 마세요" | -> | "모든 Phase를 순서대로 완료한다" |
+| "검증 없이 진행하지 않는다" | -> | "검증을 통과한 후에만 다음 단계로 진행한다" |
+| "계획 없이 코드를 작성하지 않는다" | -> | "계획을 확인한 후 코드를 작성한다" |
+
+### CLAUDE.md 파일
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "git add -A 금지" | -> | "수정한 파일만 개별 지정하여 git add" |
+| "자동으로 커밋/푸시하지 않는다" | -> | "사용자가 명시적으로 요청할 때만 커밋/푸시한다" |
+| "3개 이상 파일 수정 금지" | -> | "파일 수정은 Subagent에 위임한다" |
+
+---
+
+## 전환 시 주의사항
+
+### 맥락을 보존한다
+
+부정 표현을 긍정으로 바꿀 때 원래 의도가 손실되지 않도록 한다.
+
+```
+원문: "Presentational 컴포넌트에서 API 호출, 전역 상태 접근 금지"
+
+나쁜 전환: "Presentational 컴포넌트에서 작업한다"
+  -> 원래 의도(제한 사항)가 사라짐
+
+좋은 전환: "Presentational 컴포넌트는 UI 렌더링만 전담한다. 데이터는 props로 전달받는다"
+  -> 허용 범위를 명시하여 제한 의도를 보존
+```
+
+### 대안을 함께 명시한다
+
+"~하지 마"만 긍정으로 바꾸면 모호해질 수 있다. **대안 행동**을 함께 제시한다.
+
+```
+나쁜 전환: "try-catch 대신 다른 것을 사용한다"
+  -> "다른 것"이 모호
+
+좋은 전환: "Promise 처리 시 then-catch 패턴을 사용한다"
+  -> 구체적 대안 제시
+```
+
+### 정량적 기준이 있으면 유지한다
+
+```
+원문: "1000줄 초과 금지"
+좋은 전환: "500줄 이내로 유지하고, 초과 시 파일을 분리한다"
+  -> 수치 기준을 유지하면서 긍정형으로 전환
+```
+
+---
+
+## 체크리스트
+
+<checklist>
+- [ ] 파일 내에 "금지", "~하지 마", "절대", "NEVER" 문자열이 없는가?
+- [ ] 모든 규칙이 "~한다", "~해야 한다" 형태의 긍정문인가?
+- [ ] 제약사항이 "~만 한다", "~전용", "~전담" 형태로 표현되었는가?
+- [ ] 부정 -> 긍정 전환 시 원래 의도가 보존되었는가?
+- [ ] 대안 행동이 구체적으로 명시되었는가?
+- [ ] 정량적 기준(줄 수, 파일 수 등)이 유지되었는가?
+</checklist>
+
+<reference>
+- `SKILL.md` - 프롬프트 구조화 개요 및 핵심 원칙
+- `xml-tags.md` - XML 태그 표준 및 사용 가이드
+</reference>