@kood/claude-code 0.6.6 → 0.7.0

package/templates/.claude/skills/project-optimizer/SKILL.md

@@ -0,0 +1,375 @@
+---
+name: project-optimizer
+description: 범용 프로젝트 최적화 스킬. 언어/프레임워크 무관하게 코드 품질, 성능, 빌드, DX를 분석하고 개선. 코드 리뷰, 리팩토링, 성능 개선, 빌드 최적화, 의존성 정리 작업에 트리거.
+license: MIT
+metadata:
+  author: kood
+  version: "1.0.0"
+  adapted_for: universal
+---
+
+@../../instructions/agent-patterns/read-parallelization.md
+@../../instructions/agent-patterns/agent-teams-usage.md
+@../../instructions/validation/forbidden-patterns.md
+@../../instructions/validation/required-behaviors.md
+@../../instructions/multi-agent/coordination-guide.md
+@../../instructions/multi-agent/execution-patterns.md
+
+# Project Optimizer
+
+범용 프로젝트 최적화 가이드. 언어/프레임워크에 종속되지 않는 8개 카테고리, 38개 규칙. 영향도별 우선순위로 자동 분석/리팩토링/코드 생성 가이드 제공. 어떤 프로젝트든 적용 가능한 보편적 최적화 원칙 기반.
+
+---
+
+<when_to_use>
+
+## 사용 시점
+
+| 상황 | 설명 |
+|------|------|
+| **성능 개선** | 응답 시간, 처리량, 메모리 사용량 최적화 |
+| **빌드 최적화** | 빌드 속도, 출력 크기, CI/CD 파이프라인 개선 |
+| **코드 품질** | 데드 코드 제거, 복잡도 감소, 중복 제거 |
+| **의존성 정리** | 미사용 패키지 제거, 보안 취약점, 버전 관리 |
+| **DX 개선** | 타입 안전성, 린팅, 테스트, 컨벤션 강화 |
+| **코드 리뷰** | 성능/품질 이슈 검토 |
+| **리팩토링** | 기존 코드 구조 개선 |
+
+</when_to_use>
+
+---
+
+<parallel_agent_execution>
+
+## 병렬 에이전트 실행
+
+### 기본 원칙
+
+| 원칙 | 실행 방법 | 효과 |
+|------|----------|------|
+| **PARALLEL** | 독립 작업을 단일 메시지에서 동시 실행 | 5-15배 속도 향상 |
+| **DELEGATE** | 전문 에이전트에게 즉시 위임 | 품질 향상, 컨텍스트 격리 |
+| **SMART MODEL** | 복잡도별 모델 선택 (haiku/sonnet/opus) | 비용 최적화 |
+
+### Phase별 에이전트 활용
+
+| Phase | 작업 | 에이전트 | 병렬 실행 |
+|-------|------|---------|----------|
+| **1. 프로젝트 분석** | 언어/프레임워크 감지, 구조 파악, 빌드 시스템 확인 | explore (haiku) | 여러 도메인 동시 탐색 |
+| **2. 문제 진단** | 성능 병목, 코드 품질 이슈, 빌드 비효율 식별 | analyst (sonnet) | 카테고리별 동시 분석 |
+| **3. 규칙 적용** | 최적화 규칙 적용, 리팩토링 실행 | implementation-executor (sonnet) | 독립 모듈/파일 동시 수정 |
+| **4. 검증** | typecheck/lint/build/test 확인 | lint-fixer (sonnet), code-reviewer (opus) | lint 순차, review 병렬 |
+| **5. 완료** | git commit | git-operator (sonnet) | 순차 |
+
+### 실전 패턴
+
+#### 패턴 1: 프로젝트 전체 분석 (Fan-Out)
+
+```typescript
+// 4개 도메인 동시 탐색 (60초)
+Task(subagent_type="explore", model="haiku",
+     prompt="프로젝트 언어/프레임워크/빌드 시스템 감지. package.json, Cargo.toml, go.mod, pyproject.toml, Makefile 등 확인")
+
+Task(subagent_type="explore", model="haiku",
+     prompt="코드 구조 분석: 디렉토리 구조, 진입점, 모듈 의존성 그래프 파악")
+
+Task(subagent_type="explore", model="haiku",
+     prompt="빌드/CI 설정 분석: 빌드 스크립트, CI 파이프라인, Docker 설정")
+
+Task(subagent_type="explore", model="haiku",
+     prompt="의존성 분석: 직접/간접 의존성 수, 보안 취약점, 미사용 패키지")
+```
+
+#### 패턴 2: 카테고리별 병렬 최적화
+
+```typescript
+// 독립 모듈에 다른 규칙 동시 적용
+Task(subagent_type="implementation-executor", model="sonnet",
+     prompt="모듈 A 최적화: concurrency-parallel, io-batch-queries")
+
+Task(subagent_type="implementation-executor", model="sonnet",
+     prompt="모듈 B 최적화: memory-pool-reuse, code-dead-elimination")
+```
+
+#### 패턴 3: 대규모 리팩토링 (배치 처리)
+
+```typescript
+// 10개+ 파일에 동일 규칙 적용 (토큰 70-90% 절감)
+Task(subagent_type="implementation-executor", model="sonnet",
+     prompt=`다음 파일들에 concurrency-parallel 적용:
+     파일 목록: [...]
+     공통 규칙: 독립 I/O는 동시 실행`)
+```
+
+### Model Routing
+
+| 복잡도 | 모델 | 작업 예시 | 비용 | 속도 |
+|--------|------|----------|------|------|
+| **LOW** | haiku | 파일 구조 파악, 의존성 목록 확인 | 1x | 3x |
+| **MEDIUM** | sonnet | 규칙 적용, 리팩토링 실행 | 2x | 2x |
+| **HIGH** | opus | 아키텍처 설계, 보안 검토, 성능 전략 | 3x | 1x |
+
+</parallel_agent_execution>
+
+---
+
+<categories>
+
+## 카테고리별 우선순위
+
+| 우선순위 | 카테고리 | 영향도 | 접두사 | 적용 범위 |
+|---------|---------|--------|--------|----------|
+| 1 | 동시성/병렬화 | **CRITICAL** | `concurrency-` | 모든 언어 |
+| 2 | 빌드/번들 최적화 | **CRITICAL** | `build-` | 빌드 시스템 보유 프로젝트 |
+| 3 | I/O 성능 | **HIGH** | `io-` | DB/네트워크/파일 I/O 사용 |
+| 4 | 메모리/리소스 관리 | HIGH | `memory-` | 모든 언어 |
+| 5 | 코드 품질 | MEDIUM-HIGH | `code-` | 모든 프로젝트 |
+| 6 | 의존성 관리 | MEDIUM | `deps-` | 패키지 매니저 사용 |
+| 7 | DX (개발자 경험) | MEDIUM | `dx-` | 팀 프로젝트 |
+| 8 | 아키텍처 | LOW-MEDIUM | `arch-` | 중대형 프로젝트 |
+
+</categories>
+
+---
+
+<rules>
+
+## 빠른 참조
+
+### 1. 동시성/병렬화 (CRITICAL)
+
+| 규칙 | 설명 |
+|------|------|
+| `concurrency-parallel` | 독립 작업은 동시 실행 (Promise.all, goroutine, asyncio.gather, rayon 등) |
+| `concurrency-defer-await` | await/블로킹을 실제 사용 지점으로 이동 |
+| `concurrency-pipeline` | 파이프라인 병렬화 (생산자-소비자, 스트리밍) |
+| `concurrency-pool` | 동시 실행 수 제한 (connection pool, worker pool, semaphore) |
+
+### 2. 빌드/번들 최적화 (CRITICAL)
+
+| 규칙 | 설명 |
+|------|------|
+| `build-incremental` | 증분 빌드 활성화 (캐시, 변경 감지) |
+| `build-tree-shake` | 미사용 코드 자동 제거 (dead code elimination) |
+| `build-code-split` | 진입점/라우트별 코드 분할 (lazy loading) |
+| `build-minify` | 프로덕션 출력 최소화 (minification, compression) |
+| `build-cache` | 빌드 캐시 활용 (CI/로컬) |
+
+### 3. I/O 성능 (HIGH)
+
+| 규칙 | 설명 |
+|------|------|
+| `io-batch-queries` | N+1 쿼리 → 배치/조인으로 전환 |
+| `io-cache-layer` | 반복 읽기에 캐시 레이어 추가 (TTL, LRU, 인메모리) |
+| `io-stream` | 대용량 데이터는 스트리밍 처리 (청크, 이터레이터, 제너레이터) |
+| `io-connection-reuse` | 커넥션 풀/keep-alive/재사용 |
+| `io-serialize-minimal` | 필요한 필드만 직렬화/전송 |
+
+### 4. 메모리/리소스 관리 (HIGH)
+
+| 규칙 | 설명 |
+|------|------|
+| `memory-leak-prevention` | 리소스 해제 보장 (close, dispose, cleanup, finally) |
+| `memory-pool-reuse` | 객체 풀링/재사용 (버퍼, 커넥션, 스레드) |
+| `memory-lazy-init` | 비싼 초기화는 지연 실행 |
+| `memory-bounded-cache` | 캐시에 크기 제한 설정 (LRU, TTL, maxSize) |
+| `memory-large-data` | 대용량 데이터는 스트림/페이지네이션 처리 |
+
+### 5. 코드 품질 (MEDIUM-HIGH)
+
+| 규칙 | 설명 |
+|------|------|
+| `code-dead-elimination` | 미사용 코드/변수/import 제거 |
+| `code-duplication` | 중복 코드 추출/통합 (DRY, 단 3회 이상부터) |
+| `code-complexity` | 순환 복잡도 감소 (early return, guard clause, 분리) |
+| `code-naming` | 의도를 드러내는 명확한 이름 |
+| `code-error-handling` | 일관된 에러 처리 패턴 (Result, Either, 에러 타입 계층) |
+
+### 6. 의존성 관리 (MEDIUM)
+
+| 규칙 | 설명 |
+|------|------|
+| `deps-unused-removal` | 미사용 의존성 제거 |
+| `deps-security-audit` | 보안 취약점 스캔 및 업데이트 |
+| `deps-version-pin` | 프로덕션 의존성 버전 고정 |
+| `deps-lightweight-alt` | 무거운 라이브러리 → 경량 대안 또는 자체 구현 |
+| `deps-peer-align` | peer dependency 버전 충돌 해결 |
+
+### 7. DX - 개발자 경험 (MEDIUM)
+
+| 규칙 | 설명 |
+|------|------|
+| `dx-type-safety` | 타입 시스템 최대 활용 (strict mode, 제네릭, 유니온) |
+| `dx-lint-config` | 린터/포매터 최적 설정 |
+| `dx-test-coverage` | 핵심 로직 테스트 커버리지 확보 |
+| `dx-ci-speed` | CI 파이프라인 속도 최적화 (캐시, 병렬, 불필요 단계 제거) |
+| `dx-dev-server` | 로컬 개발 서버 시작 속도 개선 |
+
+### 8. 아키텍처 (LOW-MEDIUM)
+
+| 규칙 | 설명 |
+|------|------|
+| `arch-module-boundary` | 모듈 경계 명확화 (순환 의존 제거) |
+| `arch-interface-segregation` | 인터페이스 분리 (큰 인터페이스 → 작은 단위) |
+| `arch-config-centralize` | 설정/환경변수 중앙 관리 |
+| `arch-hot-path` | 핫 패스 식별 및 집중 최적화 |
+
+</rules>
+
+---
+
+<language_detection>
+
+## 언어/프레임워크 자동 감지
+
+### 감지 매트릭스
+
+| 감지 파일 | 언어/도구 | 추가 확인 |
+|-----------|----------|----------|
+| `package.json` | Node.js/TypeScript | `tsconfig.json` → TS |
+| `Cargo.toml` | Rust | `rust-toolchain.toml` |
+| `go.mod` | Go | `go.sum` |
+| `pyproject.toml` / `requirements.txt` | Python | `setup.py`, `poetry.lock` |
+| `pom.xml` / `build.gradle` | Java/Kotlin | `settings.gradle` |
+| `Gemfile` | Ruby | `Rakefile` |
+| `composer.json` | PHP | |
+| `mix.exs` | Elixir | |
+| `CMakeLists.txt` | C/C++ | `Makefile` |
+| `*.sln` / `*.csproj` | C#/.NET | |
+| `pubspec.yaml` | Dart/Flutter | |
+| `Package.swift` | Swift | `*.xcodeproj` |
+
+### 감지 후 동작
+
+1. **규칙 필터링**: 감지된 언어의 `languages` 태그가 `all` 또는 해당 언어를 포함하는 규칙만 적용
+2. **예시 선택**: 규칙 내 코드 예시 중 감지된 언어의 관용적 패턴 우선 제시
+3. **도구 매핑**: 감지된 언어에 맞는 빌드/린트/테스트 도구 자동 선택
+4. **프레임워크 체이닝**: 프레임워크 감지 시 해당 best-practices 스킬 자동 참조
+
+</language_detection>
+
+---
+
+<workflow>
+
+## 실행 워크플로우
+
+### Phase 1: 프로젝트 분석 (병렬)
+
+```
+1. 언어/프레임워크/빌드 시스템 감지 (explore x haiku)
+2. 코드 구조/모듈 의존성 파악 (explore x haiku)
+3. 빌드/CI 설정 분석 (explore x haiku)
+4. 의존성 상태 분석 (explore x haiku)
+```
+
+### Phase 2: 문제 진단 (병렬)
+
+```
+1. 카테고리별 이슈 스캔 (analyst x sonnet)
+   - 우선순위 1-4 (CRITICAL/HIGH) 집중
+   - 각 이슈에 영향도/규칙 매핑
+2. 기존 best-practices 스킬과 교차 참조
+   - nextjs-react-best-practices (Next.js 프로젝트)
+   - tanstack-start-react-best-practices (TanStack 프로젝트)
+   - tauri-react-best-practices (Tauri 프로젝트)
+```
+
+### Phase 3: 최적화 실행 (병렬)
+
+```
+1. CRITICAL 이슈 먼저 (concurrency, build)
+2. HIGH 이슈 (io, memory)
+3. MEDIUM+ 이슈 (code, deps, dx)
+4. 독립 모듈은 병렬 실행
+```
+
+### Phase 4: 검증
+
+```
+1. 빌드 성공 확인
+2. 테스트 통과 확인
+3. 린트/타입체크 확인
+4. 성능 벤치마크 (있으면)
+```
+
+</workflow>
+
+---
+
+<skill_chaining>
+
+## 다른 스킬과 병행
+
+### 자동 감지 및 체이닝
+
+| 감지 조건 | 추천 스킬 | 역할 |
+|-----------|----------|------|
+| Next.js 프로젝트 | `nextjs-react-best-practices` | 프레임워크 특화 규칙 병행 |
+| TanStack Start 프로젝트 | `tanstack-start-react-best-practices` | 프레임워크 특화 규칙 병행 |
+| Tauri 프로젝트 | `tauri-react-best-practices` | IPC/보안/번들 특화 규칙 병행 |
+| 코드 구조 문제 | `refactor` | 구조적 리팩토링 계획 |
+| 버그 발견 | `bug-fix` | 버그 수정 워크플로우 |
+| 의존성 문서 필요 | `docs-fetch` | 라이브러리 문서 수집 |
+| 배포 전 검증 | `pre-deploy` | typecheck/lint/build 전체 검증 |
+
+### 우선순위 규칙
+
+| 우선순위 | 규칙 |
+|---------|------|
+| 1 | **프레임워크 특화 스킬 우선**: 프레임워크 스킬의 규칙이 project-optimizer 범용 규칙보다 우선 |
+| 2 | **충돌 시 특화 우선**: 동일 주제에서 범용 규칙과 프레임워크 규칙이 충돌하면 프레임워크 규칙 적용 |
+| 3 | **보완 병행**: 프레임워크 스킬에 없는 카테고리 (concurrency, memory, deps 등)는 project-optimizer 규칙 적용 |
+| 4 | **단계적 적용**: Phase 1-2에서 project-optimizer 분석 → Phase 3에서 프레임워크 스킬과 병합 실행 |
+
+</skill_chaining>
+
+---
+
+<usage>
+
+## 사용법
+
+**상세 규칙 및 예시:**
+
+```
+rules/concurrency-parallel.md
+rules/build-incremental.md
+rules/io-batch-queries.md
+rules/memory-leak-prevention.md
+rules/code-dead-elimination.md
+rules/deps-unused-removal.md
+rules/dx-type-safety.md
+rules/arch-module-boundary.md
+```
+
+각 규칙 파일 포함 내용:
+- 중요한 이유 설명
+- 여러 언어의 ❌ 잘못된 코드 예시
+- 여러 언어의 ✅ 올바른 코드 예시
+- 추가 컨텍스트 및 참조
+
+</usage>
+
+---
+
+<references>
+
+## 참고 자료
+
+### 범용
+1. [Google Engineering Practices](https://google.github.io/eng-practices/)
+2. [The Twelve-Factor App](https://12factor.net/)
+
+### 언어별
+3. [Effective Go](https://go.dev/doc/effective_go)
+4. [Rust Performance Book](https://nnethercote.github.io/perf-book/)
+5. [Python Performance Tips](https://docs.python.org/3/howto/perf_profiling.html)
+6. [Node.js Best Practices](https://github.com/goldbergyoni/nodebestpractices)
+
+### 빌드/번들
+7. [Vite Performance](https://vite.dev/guide/performance)
+8. [webpack Tree Shaking](https://webpack.js.org/guides/tree-shaking/)
+9. [Turborepo](https://turbo.build/repo/docs)
+
+</references>

package/templates/.claude/skills/project-optimizer/rules/arch-config-centralize.md

@@ -0,0 +1,66 @@
+---
+title: Centralize Configuration and Environment Variables
+impact: LOW-MEDIUM
+impactDescription: Single source of truth, easier deployment management
+tags: arch, config, env, centralize, validation
+languages: all
+related: [code-error-handling, dx-type-safety]
+---
+
+## 설정/환경변수 중앙 관리
+
+코드 전체에 흩어진 `process.env`, `os.environ` 접근을 하나의 설정 모듈로 통합합니다.
+
+**❌ 잘못된 예시 (분산된 환경변수 접근):**
+
+```typescript
+// file_a.ts
+const dbUrl = process.env.DATABASE_URL!  // 누락 시 런타임 에러
+
+// file_b.ts
+const port = parseInt(process.env.PORT || '3000')  // 중복 파싱
+
+// file_c.ts
+if (process.env.NODE_ENV === 'production') { ... }
+```
+
+**✅ 올바른 예시 (중앙 관리):**
+
+```typescript
+// config.ts - 단일 설정 모듈
+import { z } from 'zod'
+
+const envSchema = z.object({
+  DATABASE_URL: z.string().url(),
+  PORT: z.coerce.number().default(3000),
+  NODE_ENV: z.enum(['development', 'production', 'test']).default('development'),
+})
+
+export const config = envSchema.parse(process.env)
+// 시작 시 검증, 누락/잘못된 값 즉시 감지
+```
+
+```python
+# Python (pydantic-settings)
+from pydantic_settings import BaseSettings
+
+class Config(BaseSettings):
+    database_url: str
+    port: int = 3000
+    debug: bool = False
+
+config = Config()  # .env + 환경변수 자동 로드
+```
+
+```go
+// Go (envconfig)
+type Config struct {
+    DatabaseURL string `envconfig:"DATABASE_URL" required:"true"`
+    Port        int    `envconfig:"PORT" default:"3000"`
+}
+
+var cfg Config
+envconfig.Process("", &cfg)
+```
+
+**원칙:** 환경변수는 애플리케이션 시작 시 한 번 파싱/검증하고, 이후 타입 안전한 config 객체로 접근.

package/templates/.claude/skills/project-optimizer/rules/arch-hot-path.md

@@ -0,0 +1,35 @@
+---
+title: Identify and Optimize Hot Paths
+impact: LOW-MEDIUM
+impactDescription: Targeted optimization on code that matters most
+tags: arch, hot-path, profiling, optimization, bottleneck
+languages: all
+related: [concurrency-parallel, io-batch-queries, memory-pool-reuse]
+---
+
+## 핫 패스 식별 및 집중 최적화
+
+전체 코드의 80%는 최적화 불필요. 실행 빈도가 높은 20% (핫 패스)를 프로파일링으로 식별하고 집중 최적화합니다.
+
+**프로파일링 도구:**
+
+| 언어 | 도구 | 명령어 |
+|------|------|--------|
+| **JS/TS** | Node.js `--prof` | `node --prof app.js` + `node --prof-process` |
+| **JS/TS** | Chrome DevTools | Performance 탭 |
+| **Python** | cProfile / py-spy | `python -m cProfile -s cumtime app.py` |
+| **Go** | pprof (내장) | `go tool pprof http://localhost:6060/debug/pprof/profile` |
+| **Rust** | flamegraph | `cargo flamegraph` |
+| **Java** | async-profiler | `-agentpath:libasyncProfiler.so` |
+
+**최적화 순서:**
+
+```
+1. 측정 (프로파일링) → 핫 패스 식별
+2. 알고리즘 개선 (O(n²) → O(n log n))
+3. I/O 최적화 (이 스킬의 io-* 규칙 적용)
+4. 메모리 최적화 (이 스킬의 memory-* 규칙 적용)
+5. 마이크로 최적화 (마지막 수단)
+```
+
+**원칙:** "추측하지 말고, 측정하라." 프로파일링 없는 최적화는 시간 낭비. 핫 패스가 아닌 코드의 최적화는 ROI가 낮음.

package/templates/.claude/skills/project-optimizer/rules/arch-interface-segregation.md

@@ -0,0 +1,51 @@
+---
+title: Segregate Large Interfaces
+impact: LOW-MEDIUM
+impactDescription: Reduced coupling, easier testing and mocking
+tags: arch, interface, segregation, coupling
+languages: [ts, go, rust, java, csharp]
+related: [arch-module-boundary, code-duplication]
+---
+
+## 큰 인터페이스를 작은 단위로 분리
+
+하나의 거대한 인터페이스 대신 용도별 작은 인터페이스를 사용합니다.
+
+**❌ 잘못된 예시:**
+
+```typescript
+interface UserService {
+  getUser(id: string): User
+  createUser(data: CreateUserData): User
+  deleteUser(id: string): void
+  sendEmail(userId: string, subject: string): void
+  generateReport(userId: string): Report
+  uploadAvatar(userId: string, file: File): string
+}
+// 이메일만 보내려는 컴포넌트도 전체 인터페이스에 의존
+```
+
+**✅ 올바른 예시:**
+
+```typescript
+interface UserReader { getUser(id: string): User }
+interface UserWriter { createUser(data: CreateUserData): User; deleteUser(id: string): void }
+interface EmailSender { sendEmail(userId: string, subject: string): void }
+// 각 소비자는 필요한 인터페이스만 의존
+```
+
+```go
+// Go - 암시적 인터페이스 (소비자 쪽에서 정의)
+// reader.go - 이 패키지에서 필요한 것만 정의
+type UserGetter interface {
+    GetUser(ctx context.Context, id string) (*User, error)
+}
+```
+
+```rust
+// Rust - trait 분리
+trait Readable { fn read(&self, id: &str) -> Result<User>; }
+trait Writable { fn write(&self, user: &User) -> Result<()>; }
+```
+
+**원칙:** "클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않아야 한다" (ISP).

package/templates/.claude/skills/project-optimizer/rules/arch-module-boundary.md

@@ -0,0 +1,42 @@
+---
+title: Enforce Clear Module Boundaries
+impact: LOW-MEDIUM
+impactDescription: Prevents spaghetti dependencies, enables parallel work
+tags: arch, module, boundary, circular, dependency
+languages: all
+related: [arch-interface-segregation, code-complexity]
+---
+
+## 모듈 경계 명확화
+
+모듈 간 순환 의존을 제거하고 명확한 의존 방향을 유지합니다.
+
+**순환 의존 감지:**
+
+| 언어 | 도구 |
+|------|------|
+| **JS/TS** | `madge --circular src/` |
+| **Python** | `pydeps --no-show` |
+| **Go** | 컴파일러 (순환 import = 컴파일 에러) |
+| **Rust** | 컴파일러 (순환 crate = 컴파일 에러) |
+| **Java** | ArchUnit, JDepend |
+
+**해결 패턴:**
+
+```
+❌ 순환: A → B → C → A
+
+✅ 의존성 역전:
+A → Interface ← B → C
+(A는 인터페이스에 의존, B가 구현)
+
+✅ 이벤트/메시지:
+A → EventBus ← B
+(A가 이벤트 발행, B가 구독)
+
+✅ 추출:
+A → D ← B → C
+(공통 부분을 D로 추출)
+```
+
+**원칙:** 의존 방향은 상위(추상) → 하위(구체). 도메인 모듈이 인프라에 의존하지 않음.

package/templates/.claude/skills/project-optimizer/rules/build-cache.md

@@ -0,0 +1,57 @@
+---
+title: Leverage Build Cache in CI and Local
+impact: HIGH
+impactDescription: 40-80% CI pipeline time reduction
+tags: build, cache, ci, pipeline
+languages: all
+related: [build-incremental, dx-ci-speed]
+---
+
+## 빌드 캐시 활용
+
+CI와 로컬 환경에서 빌드 아티팩트, 의존성, 컴파일 캐시를 재사용합니다.
+
+**✅ GitHub Actions 캐시:**
+
+```yaml
+# Node.js
+- uses: actions/cache@v4
+  with:
+    path: node_modules
+    key: node-${{ hashFiles('yarn.lock') }}
+
+# Rust
+- uses: actions/cache@v4
+  with:
+    path: |
+      ~/.cargo/registry
+      ~/.cargo/git
+      target
+    key: rust-${{ hashFiles('Cargo.lock') }}
+
+# Go
+- uses: actions/cache@v4
+  with:
+    path: |
+      ~/go/pkg/mod
+      ~/.cache/go-build
+    key: go-${{ hashFiles('go.sum') }}
+
+# Python
+- uses: actions/cache@v4
+  with:
+    path: ~/.cache/pip
+    key: pip-${{ hashFiles('requirements.txt') }}
+```
+
+**모노레포 캐시 도구:**
+
+| 도구 | 특징 |
+|------|------|
+| **Turborepo** | 원격 캐시, 태스크 그래프 |
+| **Nx** | 영향 받은 프로젝트만 빌드 |
+| **Bazel** | 세밀한 캐시, 원격 실행 |
+| **sccache** | Rust/C/C++ 컴파일 캐시 |
+| **ccache** | C/C++ 컴파일 캐시 |
+
+**핵심:** 캐시 키에 lockfile 해시 포함, 의존성 변경 시에만 캐시 무효화.

package/templates/.claude/skills/project-optimizer/rules/build-code-split.md

@@ -0,0 +1,56 @@
+---
+title: Code Splitting by Entry Point
+impact: HIGH
+impactDescription: 30-70% initial load reduction
+tags: build, code-splitting, lazy-loading, bundle
+languages: [js, ts]
+related: [build-tree-shake, memory-lazy-init]
+---
+
+## 진입점/라우트별 코드 분할
+
+단일 거대 번들 대신 진입점/라우트/기능별로 분할하여 초기 로딩 크기를 줄입니다.
+
+**❌ 잘못된 예시 (단일 번들):**
+
+```typescript
+// 모든 페이지가 하나의 번들에 포함
+import { Dashboard } from './pages/Dashboard'
+import { Settings } from './pages/Settings'
+import { Admin } from './pages/Admin'  // 대부분 사용자에게 불필요
+```
+
+**✅ 올바른 예시 (동적 import):**
+
+```typescript
+// JS/TS - 라우트별 코드 분할
+const Dashboard = lazy(() => import('./pages/Dashboard'))
+const Settings = lazy(() => import('./pages/Settings'))
+const Admin = lazy(() => import('./pages/Admin'))
+```
+
+```python
+# Python - 무거운 모듈 지연 로딩
+def analyze():
+    import pandas as pd  # 필요 시점에만 로드 (import 시간 ~200ms)
+    return pd.read_csv("data.csv")
+```
+
+```go
+// Go - 플러그인 시스템으로 런타임 로딩
+p, _ := plugin.Open("analytics.so")
+analyze, _ := p.Lookup("Analyze")
+```
+
+**프레임워크별 패턴:**
+
+| 프레임워크 | 코드 분할 방법 |
+|-----------|-------------|
+| React | `React.lazy()` + `Suspense` |
+| Vue | `defineAsyncComponent()` |
+| Svelte | `import()` in routes |
+| Next.js | `next/dynamic` |
+| TanStack Router | `.lazy.tsx` 파일 컨벤션 |
+| Angular | `loadChildren` (lazy routes) |
+
+**적용 기준:** 50KB+ 모듈, 조건부 표시 UI, 관리자 전용 기능.