jun-claude-code 0.0.16 → 0.1.0

package/templates/global/hooks/skill-forced.sh

@@ -48,27 +48,7 @@ Main Agent의 Context Window는 제한적입니다.
 - Subagent 호출 및 결과 전달
 - 단순 명령 실행 (Bash) - **Git/코드수정은 Subagent 전담**
 
-### Git 작업은 git-manager 전담
-
-**모든 Git 작업은 `git-manager` Agent에 위임하세요.**
-
-\`\`\`
-Task(subagent_type="git-manager", prompt="현재 변경사항을 커밋해줘")
-Task(subagent_type="git-manager", prompt="PR을 생성해줘")
-\`\`\`
-
-| Git 작업 | 전담 여부 | 이유 |
-|----------|----------|------|
-| 단순 커밋 | **전담** | 커밋 규칙 자동 준수 |
-| PR 생성 | **전담** | PR 템플릿 자동 적용 |
-| 브랜치 관리 | **전담** | 안전 규칙 자동 적용 |
-
-### 왜 Subagent를 사용해야 하는가?
-
-1. **Context 절약**: Subagent의 탐색/분석 결과는 요약되어 Main에 전달
-2. **대화 지속성**: Main Context가 절약되어 더 긴 대화 가능
-3. **전문성**: 각 Agent는 특정 작업에 최적화됨
-4. **병렬 처리**: 여러 Agent를 동시에 실행 가능
+모든 Git 작업(커밋, PR, 브랜치)은 git-manager에 위임
 
 </delegation_rules>
 
@@ -133,16 +113,10 @@ cat << 'EOF'
 아래는 이 프로젝트의 배경 정보입니다. 작업 판단 시 참고하세요.
 상세 분석이 필요하면 아래 Agent에 위임하세요.
 
-| 필요한 정보 | Agent | 호출 예시 |
-|------------|-------|----------|
-| 프로젝트 배경/도메인 지식 | project-context-collector | \`Task(subagent_type="project-context-collector", prompt="[작업]에 필요한 프로젝트 배경 정보를 수집해줘")\` |
-| 소스 코드 패턴/구현 방식 | context-collector | \`Task(subagent_type="context-collector", prompt="[작업]에 필요한 코드 패턴을 수집해줘")\` |
-
-두 Agent를 순차적으로 사용하면 가장 포괄적인 Context를 수집할 수 있습니다:
-\`\`\`
-1. project-context-collector → 프로젝트 배경 수집
-2. context-collector → 소스 코드 패턴 수집
-\`\`\`
+| 필요한 정보 | Agent |
+|------------|-------|
+| 프로젝트 배경/도메인 지식 | project-context-collector |
+| 소스 코드 패턴/구현 방식 | context-collector |
 
 EOF
 
@@ -263,11 +237,7 @@ Step 5 - 구현: 모든 관련 Skill 확인 및 Agent 호출 후에 구현을
 
 ---
 
-### 핵심 원칙
-
-- **탐색 작업은 Subagent 전담**: Main Context 절약
-- **구현 후 검증 수행**: code-reviewer + qa-tester
-- **단순 작업은 예외**: 설정 파일 수정, 오타 수정은 직접 처리 가능
+탐색은 Subagent 전담, 구현 후 검증(code-reviewer + qa-tester), 단순 작업은 직접 처리 가능
 
 지금 바로 모든 사용 가능한 Skill과 Agent를 평가하세요.
 

package/templates/global/hooks/workflow-enforced.sh

@@ -25,7 +25,6 @@ MANDATORY WORKFLOW SEQUENCE PROTOCOL
 
 ### Step 1.1: Context 수집
 
-필수 조건:
 - [ ] EnterPlanMode 진입 (복잡한 작업인 경우)
 - [ ] 관련 Context 문서 확인 (.claude/context/)
 - [ ] 필요한 Skill 활성화 (.claude/skills/)
@@ -38,8 +37,6 @@ MANDATORY WORKFLOW SEQUENCE PROTOCOL
 - [ ] 각 Task에 명확한 완료 조건 정의
 - [ ] Task 간 의존성 설정
 
-도구: TaskCreate, TaskUpdate, TaskList
-
 ### Step 1.3: 코드 수정 계획 작성
 
 필수 출력:
@@ -47,11 +44,9 @@ MANDATORY WORKFLOW SEQUENCE PROTOCOL
 - [ ] 각 파일의 변경 내용 요약
 - [ ] 예상되는 영향 범위
 
-### Step 1.4: 사용자 Confirm 받기 -- 필수
+### Step 1.4: 사용자 Confirm -- 필수
 
-중요: 계획을 사용자에게 보여주고 승인받은 후에만 구현 진행
-- ExitPlanMode 사용 (Plan Mode인 경우)
-- 또는 계획 내용을 명시적으로 보여주고 확인 요청
+- [ ] 계획을 사용자에게 보여주고 승인받은 후 구현 진행
 
 </checklist>
 
@@ -70,8 +65,6 @@ MANDATORY WORKFLOW SEQUENCE PROTOCOL
 - [ ] UI/UX UserFlow 분석: 사용자 경험에 미치는 영향
 - [ ] Breaking Change 여부 확인
 
-도구: impact-analyzer Agent (복잡한 경우)
-
 </checklist>
 
 </phase>
@@ -113,11 +106,8 @@ MANDATORY WORKFLOW SEQUENCE PROTOCOL
 - [ ] Skill checklist 기준 검토
 - [ ] lint 실행
 
-도구: code-reviewer Agent
-
 ### Step 4.2: Task 완료 검증
 
-필수 확인:
 - [ ] 원래 요청사항이 모두 충족되었는지 확인
 - [ ] 예상한 동작이 구현되었는지 확인
 - [ ] 모든 엣지케이스가 처리되었는지 점검
@@ -128,26 +118,7 @@ MANDATORY WORKFLOW SEQUENCE PROTOCOL
 
 ### 워크플로우 요약
 
-┌─────────────────────────────────────────────────────────────┐
-│  PHASE 1: 계획                                              │
-│  ├─ 1.1 Context 수집                                        │
-│  ├─ 1.2 TaskList 생성                                       │
-│  ├─ 1.3 수정 계획 작성                                       │
-│  └─ 1.4 사용자 Confirm                                      │
-│                        ↓                                    │
-│  PHASE 2: 검증                                              │
-│  └─ 2.1 사이드이펙트 검증 (Code Flow, UserFlow)              │
-│                        ↓                                    │
-│  PHASE 3: 구현                                              │
-│  ├─ 3.1 코드 수정 (작은 단위)                                │
-│  └─ 3.2 git add & commit (단위별)                           │
-│                        ↓                                    │
-│  PHASE 4: 리뷰                                              │
-│  ├─ 4.1 Self Code Review + lint                             │
-│  └─ 4.2 Task 완료 검증                                      │
-└─────────────────────────────────────────────────────────────┘
-
----
+계획(Context->TaskList->수정계획->Confirm) -> 검증(사이드이펙트) -> 구현(코드수정->커밋) -> 리뷰(CodeReview->완료검증)
 
 ### 참조 가능한 Skills (자동 탐색됨)
 
@@ -189,13 +160,5 @@ done
 
 cat << 'EOF'
 
-### 예외 상황
-
-다음의 경우 Phase를 축소/생략 가능:
-- 단순 오타 수정
-- 설정 파일 간단 수정
-- 1-2줄 변경
-- 사용자가 명시적으로 빠른 수정 요청
-
-그 외 모든 코드 작업은 위 순서를 따르세요.
+예외: 단순 오타/설정/1-2줄 수정, 사용자가 빠른 수정 요청 시 Phase 축소 가능
 EOF

package/templates/global/settings.json

@@ -1,4 +1,8 @@
 {
+  "statusLine": {
+    "type": "command",
+    "command": "~/.claude/statusline-command.sh"
+  },
   "hooks": {
     "UserPromptSubmit": [
       {
@@ -23,6 +27,17 @@
           }
         ]
       }
+    ],
+    "PreToolUse": [
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "~/.claude/hooks/dangerous-command-blocker.sh"
+          }
+        ]
+      }
     ]
   }
 }

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

@@ -0,0 +1,54 @@
+---
+name: context-handoff
+description: 컨텍스트 압축을 위한 HANDOFF.md 작성 가이드
+keywords: [HANDOFF, 컨텍스트, context, 압축, handoff, 세션, clear, 토큰]
+estimated_tokens: ~300
+---
+
+# Context Handoff
+
+긴 대화에서 컨텍스트 성능이 저하될 때 HANDOFF.md를 생성하여 핵심 정보만 이어갑니다.
+
+<instructions>
+
+## 언제 사용하는가
+
+- 토큰 사용량이 50k 이상일 때 (`/context`로 확인)
+- 응답 품질이 눈에 띄게 저하될 때
+- 복잡한 작업을 새 세션에서 이어갈 때
+
+## HANDOFF.md 포맷
+
+```markdown
+# 프로젝트: [이름]
+## 목표
+[현재 작업의 최종 목표]
+## 완료된 작업
+- [완료 항목 1]
+- [완료 항목 2]
+## 시도했지만 실패한 것
+- [실패 항목]: [실패 이유]
+## 현재 문제
+[지금 막혀있는 것]
+## 다음 단계
+1. [즉시 해야 할 것]
+2. [그 다음 해야 할 것]
+```
+
+## 워크플로우
+
+1. `/context`로 토큰 사용량 확인
+2. HANDOFF.md 생성 (프로젝트 루트)
+3. `/clear`로 컨텍스트 초기화
+4. 새 대화에서 "HANDOFF.md를 읽고 이어서 작업해줘" 입력
+
+</instructions>
+
+<rules>
+
+- HANDOFF.md는 **500자 이내**로 작성 (길면 의미 없음)
+- "시도했지만 실패한 것"을 반드시 포함 (같은 실수 반복 방지)
+- 코드 스니펫은 포함하지 않음 (파일 경로만 기록)
+- 작업 완료 후 HANDOFF.md 삭제
+
+</rules>

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

@@ -1,67 +1,19 @@
 ---
 name: PromptStructuring
-description: "Claude Code 프롬프트의 XML 태그 구조화 및 긍정 표현 전환 가이드"
-keywords: [prompt, xml-tags, positive-phrasing, structuring, 프롬프트, 구조화, 긍정표현, XML]
-estimated_tokens: 800
+description: "Claude Code 프롬프트의 XML 태그 구조화, 긍정 표현 전환, 출력 최적화 가이드"
+keywords: [prompt, xml-tags, positive-phrasing, output-optimization, 프롬프트, 구조화, 긍정표현, XML, 출력최적화]
+estimated_tokens: 300
 ---
 
 # 프롬프트 구조화 스킬
 
-## 개요
-
-프롬프트의 **형식과 표현 방식**은 LLM 출력 품질에 직접적인 영향을 준다.
-
-- **형식**: 동일한 내용이라도 XML 태그로 의미를 구분하면 모델이 역할/지시/규칙을 명확히 구분
-- **표현**: 부정 표현("~금지") 대신 긍정 표현("~한다")을 사용하면 의도한 행동을 직접 유도
-
-### 연구 근거
-
-| 연구 | 핵심 발견 | 시사점 |
-|------|----------|--------|
-| Sclar et al. (2023) | 동일 내용, 형식만 변경해도 최대 76%p 성능 차이 | 프롬프트 구조가 정확도에 직결 |
-| Voronov et al. (2024) | 프롬프트 포맷팅이 Few-shot 성능에 체계적 영향 | 일관된 태그 구조가 안정적 성능 보장 |
-| Anthropic 공식 가이드 | XML 태그 사용을 공식 권장 | Claude 모델에 최적화된 구조화 방식 |
+프롬프트의 형식과 표현 방식은 LLM 출력 품질에 직접적인 영향을 준다.
 
 ## 핵심 원칙
 
-### 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` | 부정 -> 긍정 전환 패턴, 카테고리별 변환 테이블, 체크리스트 |
+| 원칙 | 요약 | 상세 |
+|------|------|------|
+| 1. XML 태그 | `##` 대신 `<role>`, `<instructions>`, `<rules>` 등으로 의미 구분 | `xml-tags.md` |
+| 2. 긍정 표현 | "~금지" 대신 "~한다"로 행동 직접 유도 | `positive-phrasing.md` |
+| 3. 흐름 기호 | 단계/변환/위임에 `->` 사용: 계획 -> 구현 -> 검증 | - |
+| 4. 출력 최적화 | 반복 제거, 테이블 > 산문, Hook 출력 150줄 이내 | `output-optimization.md` |

package/templates/global/skills/PromptStructuring/output-optimization.md

@@ -0,0 +1,66 @@
+---
+name: PromptStructuring-output-optimization
+description: "Hook/프롬프트 출력의 토큰 최적화 기법과 가이드라인"
+keywords: [output, optimization, hook, 토큰절약, 출력최적화, 슬림화]
+estimated_tokens: 500
+---
+
+# 출력 최적화 가이드
+
+## 목표
+
+Hook/프롬프트 출력은 매 실행마다 Context Window를 소비한다. 최소한의 텍스트로 최대한의 지시를 전달한다.
+
+## 출력 예산
+
+| 항목 | 권장 | 최대 |
+|------|------|------|
+| 개별 Hook 출력 | ~50줄 | 80줄 |
+| 전체 Hook 출력 합계 | ~120줄 | 150줄 |
+| Subagent Hook 출력 | ~30줄 | 50줄 |
+
+## 반복 제거 규칙
+
+- 동일 내용을 2회 이상 출력하지 않는다
+- CLAUDE.md에 이미 있는 내용은 Hook에서 반복하지 않는다
+- 여러 Hook 간 중복 내용을 제거한다
+
+## 축약 기법
+
+| 기법 | Before | After |
+|------|--------|-------|
+| 테이블 > 산문 | 3줄 설명 | 1행 테이블 |
+| 인라인 > 블록 | 코드 블록 예시 | 인라인 `코드` |
+| 키워드 > 문장 | "이 작업은 git-manager Agent에 위임하세요" | "Git 작업 -> git-manager" |
+| 1줄 요약 > 상세 | 5줄 설명 | 1줄 핵심 |
+
+## 삭제 대상 판별
+
+- "왜 이렇게 하는가?" 설명 -> 삭제 (이유보다 행동이 중요)
+- 동일 규칙의 예시 3개 -> 1개로 축소
+- ASCII 다이어그램 -> 인라인 흐름으로 대체: `A -> B -> C`
+- 반복되는 라벨 ("필수 조건:", "필수 원칙:") -> 제거
+
+## Before/After 예시
+
+```
+Before (15줄):
+### 왜 Subagent를 사용해야 하는가?
+1. Context 절약: ...
+2. 대화 지속성: ...
+3. 전문성: ...
+4. 병렬 처리: ...
+
+After (0줄): 삭제 (이유보다 규칙 자체가 중요)
+```
+
+```
+Before (20줄 ASCII 다이어그램):
+┌────────────────────┐
+│  PHASE 1: 계획     │
+│  ...               │
+└────────────────────┘
+
+After (1줄):
+계획(Context→TaskList→Confirm) → 검증 → 구현(코드수정→커밋) → 리뷰
+```

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

@@ -1,206 +1,29 @@
 ---
-name: "Positive Phrasing Guide"
-description: "프롬프트의 부정 표현을 긍정 표현으로 전환하는 가이드"
-keywords: [positive-phrasing, prompt-optimization, negation-removal, 긍정표현, 부정제거]
-estimated_tokens: 2000
+name: PromptStructuring-positive-phrasing
+description: "부정 표현을 긍정 표현으로 전환하는 패턴과 체크리스트"
+keywords: [positive, phrasing, 긍정표현, 부정표현, 전환]
+estimated_tokens: 350
 ---
 
 # 긍정 표현 전환 가이드
 
-## 왜 긍정 표현인가
-
-부정 명령("~하지 마", "~금지")은 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가 전담"
+| 부정 표현 | 긍정 표현 |
+|----------|----------|
+| "코드 직접 수정 금지" | "모든 코드 수정은 code-writer에 위임" |
+| "git add -A 금지" | "수정한 파일만 개별 지정하여 git add" |
+| "과도한 추상화 금지" | "필요한 만큼만 추상화" |
+| "main에 직접 push 금지" | "feature 브랜치에서 작업 후 PR 생성" |
+| "테스트 없이 배포 금지" | "배포 전 테스트 통과 확인" |
 
-"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>
+- [ ] "금지", "불가", "하지 마" 표현이 있는가? -> 긍정 행동으로 전환
+- [ ] 제약사항이 행동 지시로 변환 가능한가? -> 가능하면 변환
+- [ ] 예외 상황 설명이 "~하면 안 됨"인가? -> "~하는 경우에만 허용"으로 변환