@wooojin/forgen 0.2.0 → 0.3.0

package/commands/deep-interview.md

@@ -0,0 +1,273 @@
+---
+name: deep-interview
+description: This skill should be used when the user asks to "deep-interview,딥인터뷰,심층인터뷰,deep interview". Deep requirement interview with weighted dimension scoring, challenge modes, and ontology tracking
+argument-hint: "[project or feature description]"
+triggers:
+  - "deep-interview"
+  - "딥인터뷰"
+  - "심층인터뷰"
+  - "deep interview"
+  - "요구사항 인터뷰"
+---
+
+<Purpose>
+프로젝트의 요구사항을 체계적으로 심층 인터뷰하여 모호성을 제거합니다.
+가중 차원 점수(Weighted Dimension Scoring)로 모호성을 정량화하고,
+한 번에 하나의 질문만 던져 깊이 있는 답변을 이끌어냅니다.
+목표: ambiguity <= 0.20 (20% 이하)까지 인터뷰를 진행합니다.
+</Purpose>
+
+<Compound_Integration>
+## 시작 전: compound-search로 이전 인터뷰 검색
+
+인터뷰 시작 전 반드시 compound-search MCP 도구로 유사한 프로젝트의 이전 인터뷰를 검색합니다.
+
+```
+compound-search("[프로젝트명 또는 핵심 도메인 키워드]")
+```
+
+검색 결과가 있으면 인터뷰 시작 시 표시합니다:
+
+```
+이전 인터뷰 발견:
+- [프로젝트명]: [핵심 토픽] (최종 ambiguity: 0.XX)
+- 재사용 가능한 결정사항: [패턴/결론]
+- 이전 인터뷰에서 해결된 항목은 이번에 건너뜁니다.
+```
+
+## 진행 중: 관련 compound 솔루션 로드
+
+질문 주제와 관련된 compound 솔루션이 있으면 더 정확한 질문을 구성합니다.
+
+## 종료 후: 인터뷰 결과를 compound로 저장
+
+```bash
+forgen compound --solution "interview-{project}-spec" "인터뷰 결과 명세서 전문"
+```
+</Compound_Integration>
+
+<Steps>
+## Phase 0: 프로젝트 유형 감지
+
+사용자 요청을 분석하여 프로젝트 유형을 자동 판별합니다.
+
+### Greenfield (새 프로젝트)
+- 채점 공식: `ambiguity = 1 - (goal * 0.40 + constraints * 0.30 + criteria * 0.30)`
+
+### Brownfield (기존 코드베이스 확장/수정)
+- Glob/Grep/Read로 기존 코드베이스를 탐색하여 기술 컨텍스트를 자동 수집
+- 채점 공식: `ambiguity = 1 - (goal * 0.35 + constraints * 0.25 + criteria * 0.25 + context * 0.15)`
+
+### 자동 감지 절차
+```
+1. 현재 디렉토리에 package.json, tsconfig.json, go.mod 등이 있는가?
+2. git log가 존재하는가?
+3. 사용자 요청에 "기존", "현재", "수정", "추가" 등의 키워드가 있는가?
+→ 2개 이상 해당하면 Brownfield → 아니면 Greenfield
+```
+
+## Phase 1: 차원 초기 채점
+
+각 차원을 0.0 ~ 1.0 범위로 채점합니다 (1.0 = 완전히 명확, 0.0 = 전혀 모름).
+
+### Greenfield 차원 (3개)
+| 차원 | 가중치 | 의미 |
+|------|--------|------|
+| **goal** | 0.40 | 무엇을 만드는가? 최종 산출물은? 성공 기준은? |
+| **constraints** | 0.30 | 기술 제약, 시간, 예산, 팀 역량, 비기능 요구사항 |
+| **criteria** | 0.30 | 완료 기준, 수용 기준, 테스트 가능한 조건 |
+
+### Brownfield 추가 차원 (1개)
+| 차원 | 가중치 | 의미 |
+|------|--------|------|
+| **context** | 0.15 | 기존 아키텍처, 의존성, 코드 패턴, 데이터 모델 |
+
+### 채점 기준 상세
+
+**goal (가중치 0.40)**
+- 최종 산출물이 명확한가? (0.0~1.0)
+- 핵심 기능이 열거되었는가? (0.0~1.0)
+- 사용자/대상이 특정되었는가? (0.0~1.0)
+- 비즈니스 근거(왜 만드는가)가 있는가? (0.0~1.0)
+
+**constraints (가중치 0.30)**
+- 기술 스택이 결정되었는가? (0.0~1.0)
+- 비기능 요구사항이 정의되었는가? (0.0~1.0)
+- 일정/예산 제약이 있는가? (0.0~1.0)
+- 외부 연동/의존성이 파악되었는가? (0.0~1.0)
+
+**criteria (가중치 0.30)**
+- 수용 기준이 테스트 가능한 형태인가? (0.0~1.0)
+- 엣지 케이스가 고려되었는가? (0.0~1.0)
+- 비정상 시나리오 대응이 정의되었는가? (0.0~1.0)
+
+**context (가중치 0.15, Brownfield만)**
+- 기존 아키텍처를 파악했는가? (0.0~1.0)
+- 영향받는 모듈/파일을 식별했는가? (0.0~1.0)
+- 기존 테스트 커버리지를 확인했는가? (0.0~1.0)
+- 기존 코드 패턴을 이해했는가? (0.0~1.0)
+
+## Phase 2: 인터뷰 루프 (라운드 기반)
+
+### 질문 프로토콜 -- 반드시 한 번에 하나의 질문만
+
+매 라운드마다:
+1. **가장 약한 차원 식별**: 가중 점수가 가장 낮은 차원을 선택
+2. **질문 하나만 생성**: 해당 차원의 점수를 가장 효과적으로 올릴 수 있는 질문
+3. **표시 형식**:
+   ```
+   Round N | ambiguity: 0.XX | 목표 차원: {dimension}
+   ─────────────────────────────────────────────────
+   Q. [구체적이고 개방형 질문]
+   (이 답변으로 {dimension} 점수 +0.X 예상)
+   ```
+4. **답변 수신 후**: 점수 재산정 -> 보드 갱신 -> 다음 라운드
+
+### Push Until Evidence 규칙
+
+모호한 답변("대충", "아마", "비슷한") → 같은 차원에서 후속 질문.
+가정 기반 답변("아마 ~일 거예요") → "확인된 사실인가요, 검증이 필요한 가정인가요?"
+범위 미정 답변("다 되면 좋겠어요") → "MVP 범위에서 반드시 포함해야 하는 3가지는?"
+
+## Phase 3: 챌린지 모드 (라운드 기반 자동 활성화)
+
+### Round 4+: Contrarian (반론 모드)
+"만약 정반대가 사실이라면?" — 사용자의 전제를 뒤집어 검증합니다.
+
+### Round 6+: Simplifier (단순화 모드)
+"가장 단순하면서도 가치있는 버전은?" — 불필요한 복잡성을 제거합니다.
+
+### Round 8+ (ambiguity > 0.30): Ontologist (본질 탐구 모드)
+"이것은 본질적으로 무엇인가요?" — 핵심 엔티티의 정의와 경계를 명확히 합니다.
+
+## Phase 4: 온톨로지 추적
+
+매 라운드마다 핵심 엔티티(명사)를 추적합니다.
+```
+ONTOLOGY TRACKER
+──────────────────────────────────────
+Entity          | First  | Last  | Status
+User            | R1     | R5    | stable
+Order           | R1     | R6    | refined
+──────────────────────────────────────
+Stability: 3/4 (75%)
+```
+- stability_ratio >= 0.90: 도메인 모델 안정 -> 종료 가능
+- stability_ratio < 0.70: 유동적 -> 본질 질문 필요
+</Steps>
+
+## 반아첨(Anti-Sycophancy) 규칙
+
+| 금지 표현 | 대체 행동 |
+|-----------|-----------|
+| "좋은 접근이네요" | 입장을 취합니다. 근거와 함께 동의 또는 반대. |
+| "그것도 될 수 있어요" | 근거를 바탕으로 된다/안 된다 판단. |
+| "고려해 보시면..." | "이것은 틀렸습니다. 이유는..." 또는 "이것이 맞습니다. 이유는..." |
+| "흥미로운 접근이네요" | "이 접근은 {구체적 이유}로 {성공/실패}할 것입니다." |
+
+사용자가 틀렸으면 틀렸다고 말합니다. 근거를 함께 제시합니다.
+
+## Ambiguity Score 보드
+
+```
+DEEP INTERVIEW BOARD
+═══════════════════════════════════════════════════
+Project: {name}  |  Type: {Greenfield/Brownfield}
+Round: {N}  |  Ambiguity: {0.XX}  |  Target: <= 0.20
+
+DIMENSION SCORES
+────────────────────────────────────────────────────
+ Dimension    Weight   Score    Weighted    Trend
+ goal         0.40     0.75     0.300       0.2->0.5->0.75 ++
+ constraints  0.30     0.50     0.150       0.1->0.50 +
+ criteria     0.30     0.30     0.090       0.3 NEW
+────────────────────────────────────────────────────
+ Clarity: 0.540 | Ambiguity: 0.460 | Status: Continue
+
+ONTOLOGY ({N} entities, {stability}% stable)
+ACTIVE CHALLENGE: {None / CONTRARIAN / SIMPLIFIER / ONTOLOGIST}
+═══════════════════════════════════════════════════
+```
+
+## 종료 조건
+
+| 조건 | 기준 |
+|------|------|
+| **Ready** | ambiguity <= 0.20 |
+| **Conditional** | 0.20 < ambiguity <= 0.35 |
+| **User Exit** | 사용자 요청 (경고 표시 후 종료) |
+| **Plateau** | 3라운드 연속 변화 < 0.05 -> Ontologist 전환 |
+| **Hard Cap** | 20라운드 도달 -> 강제 종료 |
+
+라운드 제한: 최소 3, 소프트 캡 10, 하드 캡 20.
+
+## 실행 브릿지
+
+```
+ambiguity <= 0.20 -> "준비 완료. 권장: /forge-loop"
+ambiguity 0.20~0.35 -> "가정 목록 확인 필요. 확인 후 /forge-loop"
+ambiguity > 0.35 -> "인터뷰 계속 필요."
+```
+
+## 최종 명세서 형식
+
+```markdown
+# Deep Interview Spec: {title}
+## Metadata (rounds, score, type, timestamp)
+## Clarity Breakdown (dimension scores table)
+## Goal
+## Constraints
+## Non-Goals
+## Acceptance Criteria (testable)
+## Assumptions (exposed & resolved)
+## Technical Context
+## Key Entities (ontology table)
+## Ontology Convergence (round-by-round stability)
+## Next Action: /forge-loop | /ch-architecture-decision | manual
+```
+
+<Failure_Modes>
+## 피해야 할 실패 패턴
+
+NEVER: **한 번에 여러 질문**: 질문은 반드시 1개. 2개 이상 금지.
+
+NEVER: **코드에서 답을 찾을 수 있는 것을 질문**: Brownfield에서 Read/Grep으로 먼저 확인.
+
+NEVER: **보드 갱신 누락**: 매 라운드 종료 후 반드시 보드 표시.
+
+NEVER: **아첨/동의 기본값**: 근거 없는 동의 금지. 모든 판단에 근거 필요.
+
+NEVER: **모호한 답변 수용**: Push Until Evidence 규칙 적용.
+
+NEVER: **3라운드 전 종료**: 경고 표시 필수.
+
+NEVER: **챌린지 모드 건너뛰기**: Round 4+ 이후 반드시 적용.
+</Failure_Modes>
+
+<Policy>
+- 라운드당 질문은 반드시 1개만 (깊이 > 넓이)
+- 가장 낮은 가중 점수의 차원부터 공략
+- 답변 후 즉시 점수 재산정 + 보드 갱신
+- 사용자가 "모르겠다" -> 해당 요소 0.0 유지, 다음 질문
+- 기술적 판단 가능한 항목 -> 합리적 가정 제안
+- 비즈니스 판단 필요 항목 -> 반드시 사용자 확인
+- Anti-Sycophancy 규칙 준수
+- Brownfield -> 코드 탐색 선행, context 차원 자동 채점
+- 온톨로지 추적 매 라운드 수행
+</Policy>
+
+<Arguments>
+## 사용법
+`deep-interview {프로젝트 또는 기능 설명}`
+
+### 예시
+- `deep-interview 이커머스 플랫폼 MVP`
+- `deep-interview 사내 HR 시스템 리뉴얼`
+- `deep-interview 실시간 채팅 기능 추가`
+
+### 인자
+- 인터뷰할 프로젝트 또는 기능의 자연어 설명
+- 기존 코드베이스가 있으면 Brownfield로 자동 전환
+</Arguments>
+
+$ARGUMENTS

package/commands/docker.md

@@ -1,6 +1,17 @@
 ---
 name: docker
-description: This skill should be used when the user asks to "docker,container,컨테이너,dockerfile,도커,docker-compose". Containerization with Docker, Dockerfile optimization, and compose configuration
+description: This skill should be used when the user asks to "docker,container,컨테이너,dockerfile,도커,docker-compose". Docker 컨테이너화 -- Dockerfile 최적화, Compose 구성, 보안 강화
+argument-hint: "[컨테이너화 대상]"
+model: sonnet
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
+  - Write
+  - Edit
+  - mcp__forgen-compound__compound-search
+  - mcp__forgen-compound__compound-read
 triggers:
   - "docker"
   - "container"
@@ -9,7 +20,6 @@ triggers:
   - "도커"
   - "docker-compose"
 ---
-<!-- forgen-managed -->
 
 <Purpose>
 Docker를 활용한 컨테이너화를 체계적으로 수행합니다.
@@ -17,107 +27,35 @@ Docker를 활용한 컨테이너화를 체계적으로 수행합니다.
 Docker Compose 구성, 헬스 체크까지 컨테이너 라이프사이클 전체를 다룹니다.
 </Purpose>
 
-<Steps>
-1. **의존성 분석**: 애플리케이션의 런타임 요구사항을 파악합니다
-   - 런타임 환경 (Node.js, Python, Go 등)
-   - 시스템 의존성 (네이티브 바이너리, 라이브러리)
-   - 환경 변수 목록 및 기본값
-   - 포트 매핑 (애플리케이션 포트, 디버그 포트)
-   - 볼륨 마운트 필요 사항 (데이터 영속성, 설정 파일)
-   - 외부 서비스 의존성 (DB, Redis, 메시지 큐)
-
-2. **Dockerfile 작성**: 최적화된 Dockerfile을 구성합니다
-   - 베이스 이미지 선택 (alpine vs slim vs distroless)
-   - 멀티스테이지 빌드 적용 (빌드 스테이지 / 런타임 스테이지)
-   - 레이어 캐싱 최적화 (변경 빈도 낮은 것부터 순서)
-     * 시스템 의존성 설치
-     * package.json / lockfile 복사 + npm install
-     * 소스 코드 복사 + 빌드
-   - .dockerignore 설정 (node_modules, .git, 테스트 파일)
-   - 비루트 사용자 설정 (보안)
-   - 시그널 핸들링 (SIGTERM graceful shutdown)
-   - HEALTHCHECK 명령 설정
-
-3. **이미지 최적화**: 이미지 크기와 보안을 개선합니다
-   - 레이어 수 최소화 (RUN 명령 결합)
-   - 불필요한 파일 제거 (빌드 도구, 캐시, 문서)
-   - 프로덕션 의존성만 설치 (--omit=dev)
-   - 이미지 크기 측정 및 목표 설정
-   - 보안 스캔 (Trivy, Docker Scout)
-   - 이미지 태깅 전략 (semver, git SHA, latest)
+<Compound_Integration>
+## 시작 전: 이전 Docker 구성 패턴 검색
 
-4. **Docker Compose 구성**: 멀티 컨테이너 환경을 정의합니다
-   - 서비스 정의 (app, db, cache, proxy)
-   - 네트워크 구성 (서비스 간 통신)
-   - 볼륨 정의 (데이터 영속성)
-   - 환경 변수 관리 (.env 파일, 인라인)
-   - 의존성 순서 (depends_on + healthcheck)
-   - 개발/프로덕션 오버라이드 분리
-   - 리소스 제한 설정 (CPU, 메모리)
-
-5. **헬스 체크 및 모니터링**: 컨테이너 상태를 관리합니다
-   - HEALTHCHECK 엔드포인트 구현 (/health, /ready)
-   - Liveness probe vs Readiness probe 구분
-   - 로그 수집 구성 (stdout/stderr → 로그 시스템)
-   - 메트릭 노출 (Prometheus 엔드포인트)
-   - Graceful shutdown 구현 (SIGTERM 처리)
-   - 재시작 정책 설정 (restart: unless-stopped)
-</Steps>
-
-## 에이전트 위임
-
-`executor` 에이전트(Sonnet 모델)에 위임하여 Docker 구성을 구현합니다:
+컨테이너화를 시작하기 전에 compound-search MCP 도구로 유사한 런타임/애플리케이션의 과거 Docker 구성을 검색합니다.
 
 ```
-Agent(
-  subagent_type="executor",
-  model="sonnet",
-  prompt="DOCKER TASK
-
-Docker 컨테이너화를 구현하세요.
-
-Application: [애플리케이션 설명]
-Runtime: [Node.js / Python / Go / etc.]
-Services: [필요한 외부 서비스 목록]
-
-Docker Checklist:
-1. Dockerfile 작성 (멀티스테이지, 최적화)
-2. .dockerignore 설정
-3. Docker Compose 구성 (개발/프로덕션)
-4. 헬스 체크 설정
-5. 보안 설정 (비루트 사용자, 이미지 스캔)
-6. 볼륨 및 네트워크 구성
-
-Output: Docker 구성 파일 및 문서:
-- Dockerfile
-- .dockerignore
-- docker-compose.yml (dev/prod)
-- 이미지 크기 리포트
-- 실행 명령 가이드"
-)
+compound-search("[런타임명 또는 애플리케이션 타입 키워드]")
+compound-search("Docker 최적화")
 ```
 
-## External Consultation (Optional)
-
-executor 에이전트는 교차 검증을 위해 Claude Task 에이전트에 자문할 수 있습니다.
-
-### Protocol
-1. **자체 Docker 구성을 먼저 완료** -- 독립적으로 구현
-2. **검증을 위한 자문** -- Claude Task 에이전트를 통해 구성 교차 확인
-3. **비판적 평가** -- 외부 제안을 맹목적으로 수용하지 않음
-4. **우아한 폴백** -- 위임이 불가능할 경우 절대 차단하지 않음
+검색 결과가 있으면 의존성 분석 단계 전에 표시합니다:
+```
+이전 Docker 구성 패턴:
+- [애플리케이션명]: [베이스 이미지] → 최종 크기 [N]MB (날짜: YYYY-MM-DD)
+- 주요 최적화: [레이어 전략, 보안 설정 등]
+- 주의사항: [이전에 발견된 문제나 트릭]
+```
 
-### 자문이 필요한 경우
-- 복잡한 멀티스테이지 빌드
-- 프로덕션 수준의 보안 강화
-- 오케스트레이션 (Kubernetes 연동)
-- 네이티브 의존성이 있는 이미지 최적화
+이전 구성을 출발점으로 삼아 중복 탐색을 줄이고, 검증된 패턴을 재사용합니다.
+완료 후 주요 최적화 내용과 이미지 크기를 compound에 기록합니다.
+</Compound_Integration>
 
-### 자문을 생략하는 경우
-- 단순 Node.js/Python 컨테이너화
-- 개발 환경용 Docker Compose
-- 잘 알려진 이미지 패턴
-- 기존 Dockerfile의 경미한 수정
+<Steps>
+1. **의존성 분석**: 런타임 환경, 시스템 의존성, 포트, 볼륨, 외부 서비스
+2. **Dockerfile 작성**: 멀티스테이지, 레이어 캐싱, 비루트 사용자, HEALTHCHECK
+3. **이미지 최적화**: 레이어 최소화, 프로덕션 의존성만, 보안 스캔, 크기 측정
+4. **Docker Compose 구성**: 서비스, 네트워크, 볼륨, 환경 변수, 오버라이드
+5. **헬스 체크 및 모니터링**: probe, 로그 수집, graceful shutdown, 재시작 정책
+</Steps>
 
 ## Docker 체크리스트
 
@@ -129,11 +67,12 @@ executor 에이전트는 교차 검증을 위해 Claude Task 에이전트에 자
 - [ ] 레이어 캐싱이 최적화됨
 - [ ] HEALTHCHECK가 설정됨
 
-### 보안 (4개)
+### 보안 (5개)
 - [ ] 이미지 취약점 스캔 완료
 - [ ] 최소 권한 원칙 적용 (비루트, 읽기 전용 파일시스템)
-- [ ] 시크릿이 이미지에 포함되지 않음
+- [ ] 시크릿이 이미지에 포함되지 않음 (ENV, ARG, COPY 모두 확인)
 - [ ] 불필요한 도구/패키지가 제거됨
+- [ ] 빌드 시 민감 레이어 캐시 방지
 
 ### 운영 (4개)
 - [ ] Graceful shutdown이 구현됨 (SIGTERM)
@@ -154,7 +93,28 @@ executor 에이전트는 교차 검증을 위해 Claude Task 에이전트에 자
 | Node.js | < 150MB | node:20-alpine |
 | Python | < 200MB | python:3.12-slim |
 | Go | < 30MB | gcr.io/distroless/static |
-| Rust | < 30MB | debian:bookworm-slim (빌드) + scratch (런타임) |
+| Rust | < 30MB | debian:bookworm-slim + scratch |
+| Java | < 250MB | eclipse-temurin:21-jre-alpine |
+
+<Failure_Modes>
+## 피해야 할 실패 패턴
+
+### 이미지 빌드
+- **:latest 태그 사용**: 빌드 재현 불가능. 항상 `node:20.11.1-alpine3.19` 같이 고정.
+- **단일 스테이지**: 빌드 도구가 런타임에 포함됨. 멀티스테이지 필수.
+- **레이어 순서 오류**: 소스 코드를 lockfile보다 먼저 배치하면 캐시 무효화.
+
+### 보안
+- **root 실행**: `USER` 지시어 없이 실행. 컨테이너 탈출 시 호스트 루트 권한 획득 위험.
+- **시크릿 하드코딩**: ENV/ARG/RUN에 시크릿 포함. BuildKit `--mount=type=secret` 사용.
+- **ARG로 시크릿 전달**: 중간 레이어에 남음. BuildKit secret mount 사용.
+
+### 구성
+- **.dockerignore 누락**: node_modules, .git, .env가 이미지에 포함됨.
+- **SIGTERM 미처리**: 10초 후 SIGKILL로 강제 종료. 데이터 손실 가능.
+- **HEALTHCHECK 누락**: 애플리케이션 응답 불능 상태 미감지.
+- **Compose 비밀번호 하드코딩**: .env 파일 또는 Docker secrets 사용.
+</Failure_Modes>
 
 <Output>
 ```
@@ -166,95 +126,25 @@ Runtime: [Node.js 20]
 Image Size: [최종 이미지 크기]
 
 DOCKERFILE / Dockerfile
--------------------------
-# Build stage
-FROM node:20-alpine AS builder
-WORKDIR /app
-COPY package*.json ./
-RUN npm ci --omit=dev
-COPY . .
-RUN npm run build
-
-# Runtime stage
-FROM node:20-alpine AS runtime
-RUN addgroup -g 1001 -S appgroup && \
-    adduser -S appuser -u 1001 -G appgroup
-WORKDIR /app
-COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
-COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
-USER appuser
-EXPOSE 3000
-HEALTHCHECK --interval=30s --timeout=3s \
-  CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1
-CMD ["node", "dist/index.js"]
-
 DOCKER COMPOSE / docker-compose.yml
---------------------------------------
-services:
-  app:
-    build: .
-    ports: ["3000:3000"]
-    depends_on:
-      db: { condition: service_healthy }
-    environment:
-      DATABASE_URL: postgres://user:pass@db:5432/app
-  db:
-    image: postgres:16-alpine
-    volumes: ["pgdata:/var/lib/postgresql/data"]
-    healthcheck:
-      test: ["CMD-SHELL", "pg_isready"]
-
 IMAGE ANALYSIS / 이미지 분석
-------------------------------
-Total Size: 142MB
-Layers: 8
-Base Image: node:20-alpine (45MB)
-Dependencies: 85MB
-Application: 12MB
-
 SECURITY SCAN / 보안 스캔
----------------------------
-Vulnerabilities: 0 CRITICAL, 0 HIGH, 2 MEDIUM
-Recommendation: [조치 사항]
 ```
 </Output>
 
 <Policy>
-- 베이스 이미지에 항상 고정 태그를 사용합니다 (latest 금지)
-- 프로덕션 이미지에서 반드시 비루트 사용자로 실행합니다
-- 시크릿은 절대 이미지에 포함하지 않습니다 (빌드 시에도)
-- 이미지 크기를 정기적으로 모니터링합니다
-- 보안 스캔을 CI/CD에 통합하여 취약한 이미지 배포를 차단합니다
-- Graceful shutdown을 반드시 구현하여 데이터 손실을 방지합니다
+- 베이스 이미지에 항상 고정 태그 사용 (latest 금지)
+- 프로덕션 이미지에서 비루트 사용자 실행 필수
+- 시크릿은 절대 이미지에 포함하지 않음
+- 멀티스테이지 빌드 기본 적용
+- .dockerignore 필수 작성
+- Graceful shutdown 필수 구현
 </Policy>
 
 ## 다른 스킬과의 연동
-
-**CI/CD 연동:**
-```
-/forgen:ci-cd Docker 이미지 빌드 및 푸시 파이프라인
-```
-CI에서 Docker 이미지 자동 빌드/배포
-
-**보안 리뷰 연동:**
-```
-/forgen:security-review Dockerfile 및 이미지
-```
-Docker 구성의 보안 취약점 점검
-
-**성능 연동:**
-```
-/forgen:performance 컨테이너 리소스 사용량 분석
-```
-컨테이너의 리소스 최적화
-
-## Best Practices
-
-- **작은 이미지** -- 불필요한 것을 빼서 크기를 줄임
-- **멀티스테이지** -- 빌드 도구를 런타임에 포함하지 않음
-- **캐시 활용** -- 레이어 순서를 변경 빈도 기준으로 정렬
-- **보안 우선** -- 비루트, 최소 권한, 시크릿 분리
-- **헬스 체크** -- 컨테이너 상태를 자동으로 모니터링
+- `/forgen:ci-cd` -- Docker 이미지 빌드/배포 파이프라인
+- `/forgen:security-review` -- Dockerfile/이미지 보안 점검
+- `/forgen:performance` -- 컨테이너 리소스 최적화
 
 <Arguments>
 ## 사용법