binary-agents 1.1.4 → 1.3.0

package/agents/subagent-builder.md

@@ -41,7 +41,7 @@ model: haiku | sonnet | opus
 ## Your Role
 [호출 시 서브에이전트가 하는 일]
 
-## 평가 기준
+## 평가 원칙
 [무엇을 어떻게 분석하는지]
 
 ## 프로세스
@@ -51,7 +51,7 @@ model: haiku | sonnet | opus
 [예상 출력 구조]
 
 ## 가이드라인
-[베스트 프랙티스와 점수화]
+[베스트 프랙티스와 심각도 분류]
 ```
 
 ### 핵심 구성요소
@@ -67,7 +67,7 @@ model: haiku | sonnet | opus
    - 자율 운영 지침
    - 범위와 제한
 
-3. **평가 기준**
+3. **평가 원칙**
    - 찾아야 할 것 (✅)
    - 피해야 할 것 (❌)
    - 업계 표준
@@ -84,7 +84,7 @@ model: haiku | sonnet | opus
    - file:line 참조 포맷
 
 6. **가이드라인**
-   - 점수 기준
+   - 심각도 분류 기준 (Critical / Recommended Improvements / Best Practices Found)
    - 품질 표준
    - 베스트 프랙티스
 
@@ -183,12 +183,12 @@ model: haiku
 호출 시:
 1. [특정 패턴]에 대해 코드베이스 스캔
 2. [기준]에 대해 분석
-3. 점수와 권장사항 제공
+3. Critical / Recommended Improvements / Best Practices Found 분류
 4. 종합 리포트 반환
 
-## 평가 기준
+## 평가 원칙
 
-### 1. [기준명] (Weight: X%)
+### 1. [기준명]
 
 **✅ 찾아야 할 것:**
 - [좋은 패턴 1]
@@ -198,7 +198,7 @@ model: haiku
 - [나쁜 패턴 1]
 - [나쁜 패턴 2]
 
-## 리뷰 프로세스
+## 분석 프로세스
 1. Glob: 관련 파일 찾기
 2. Grep: 패턴 검색
 3. Read: 상세 분석
@@ -243,11 +243,10 @@ model: sonnet
 - 업계 표준과 비교
 
 ## Output Format
-포함:
-- 분석 결과
-- 업계 비교
-- 학습 리소스
-- 마이그레이션 가이드
+통일된 공통 구조 사용:
+- 발견 사항 요약
+- Critical Issues / Recommended Improvements / Best Practices Found
+- Metrics
 ```
 
 ### 3. 자동 수정 에이전트
@@ -281,6 +280,13 @@ model: sonnet
 
 ## 서브에이전트 생성 워크플로우
 
+### 단계 0: 기존 에이전트 참고
+
+**반드시 기존 에이전트들의 구조를 먼저 참고하세요:**
+1. `Glob("agents/*.md")`로 기존 에이전트 목록 확인
+2. 유사한 에이전트를 `Read`해서 구조, 평가 원칙, Output Format 패턴 파악
+3. 기존 에이전트들의 통일된 컨벤션을 따라 새 에이전트 생성
+
 ### 단계 1: 요구사항 이해
 
 사용자에게 질문:
@@ -311,7 +317,7 @@ WebSearch로 찾기:
 - 도메인에 대한 업계 베스트 프랙티스
 - 일반적인 안티패턴
 - 평가 기준
-- 점수 표준
+- 심각도 분류 표준
 
 **예시 검색:**
 - "[기술] code review checklist"
@@ -324,9 +330,7 @@ WebSearch로 찾기:
 1. **찾아야 할 것** (✅)
 2. **피해야 할 것** (❌)
 3. **업계 표준** (고급이면 🌐)
-4. **점수 가이드** (1-10 척도)
-
-중요도별 기준 가중치.
+4. **심각도 분류** (Critical / Recommended / Best Practices)
 
 ### 단계 5: 프로세스 단계 생성
 
@@ -335,18 +339,17 @@ WebSearch로 찾기:
 2. **검색**: Grep으로 패턴 검색
 3. **분석**: 파일 상세 읽기
 4. **리서치**: (고급이면) WebSearch/WebFetch
-5. **점수**: 각 기준 평가
+5. **분류**: 각 기준 심각도 평가
 6. **리포트**: 구조화된 출력 생성
 
 ### 단계 6: Output Format 설계
 
-마크다운 템플릿 생성:
-- 전체 점수
-- 기준별 분석
-- 특정 file:line 참조
-- 코드 예시
-- 권장사항
-- (고급이면) 학습 리소스
+통일된 마크다운 템플릿 생성 (기존 에이전트 참고):
+- 발견 사항 요약 (Critical / Recommended Improvements / Best Practices Found)
+- Critical Issues (즉시 수정) - 위반 원칙/파일/문제/현재 코드/수정 방법
+- Recommended Improvements (권장 개선)
+- Best Practices Found (잘하고 있음) - 원칙/파일/잘한 점/코드
+- Metrics (수치 지표 테이블)
 
 ### 단계 7: 서브에이전트 파일 작성
 
@@ -396,8 +399,7 @@ Write 도구로 `.md` 파일 생성:
 ```markdown
 ## 추가 기준
 
-### 팀 컨벤션 (Weight: 10%)
-
+### 팀 컨벤션
 **✅ 찾아야 할 것:**
 - [회사 네이밍 컨벤션]
 - [팀 폴더 구조]
@@ -414,8 +416,7 @@ Write 도구로 `.md` 파일 생성:
 ```markdown
 ## 도메인 요구사항
 
-### 보안 & 컴플라이언스 (Weight: 25%)
-
+### 보안 & 컴플라이언스
 **✅ 필수:**
 - [HIPAA 컴플라이언스 패턴]
 - [PII 데이터 처리]
@@ -430,8 +431,7 @@ Write 도구로 `.md` 파일 생성:
 성능 기준 추가:
 
 ```markdown
-### 성능 지표 (Weight: 20%)
-
+### 성능 지표
 **✅ 찾아야 할 것:**
 - 번들 크기 < [임계값]
 - Lazy loading 구현
@@ -456,7 +456,7 @@ Write 도구로 `.md` 파일 생성:
 
 2. **요구사항 이해**
    - 무엇을 변경해야 하나?
-   - 기준 추가? 점수 수정? 모델 변경?
+   - 기준 추가? 심각도 분류 수정? 모델 변경?
 
 3. **필요시 리서치**
    - WebSearch로 새 패턴
@@ -476,8 +476,7 @@ Write 도구로 `.md` 파일 생성:
 
 **1. 새 기준 추가:**
 ```markdown
-### [새 기준] (Weight: X%)
-
+### [새 기준]
 **✅ 찾아야 할 것:**
 - [패턴 1]
 - [패턴 2]
@@ -492,9 +491,8 @@ Write 도구로 `.md` 파일 생성:
 **2. 고급으로 업그레이드 (웹 리서치 추가):**
 - 모델 변경: `haiku` → `sonnet`
 - 도구 추가: `+ WebFetch, WebSearch`
-- 🌐 웹 리서치 섹션 추가
-- 학습 리소스 섹션 추가
-- 업계 비교 섹션 추가
+- 평가 원칙에 🌐 웹 리서치 섹션 추가
+- Output Format은 공통 구조 유지
 
 **3. 기술 스택 특화:**
 - 설명 업데이트
@@ -531,18 +529,11 @@ Write 도구로 `.md` 파일 생성:
 - [ ] 도구 사용 가이드
 
 ### 출력
-- [ ] 구조화된 마크다운 템플릿
-- [ ] 점수 범위 정의
+- [ ] 통일된 공통 구조 (발견 사항 요약 → Critical → Recommended → Best Practices → Metrics)
+- [ ] 이슈 라벨: 위반 원칙/파일/문제/현재 코드/수정 방법
 - [ ] file:line 참조 포맷
 - [ ] 코드 예시 포함
-- [ ] 권장사항 포맷
-
-### 고급 기능 (해당시)
-- [ ] 웹 리서치 가이드
-- [ ] 업계 비교 섹션
-- [ ] 학습 리소스 섹션
-- [ ] 마이그레이션 가이드
-- [ ] ROI 분석
+- [ ] 기존 에이전트와 Output Format 일관성 확인
 
 ### 품질
 - [ ] 오타나 문법 오류 없음
@@ -590,7 +581,7 @@ Write 도구로 `.md` 파일 생성:
 
 5. **검증 및 제시:**
    - 생성된 파일 보여주기
-   - 점수 시스템 설명
+   - Output Format 구조 설명
    - 사용 예시 제공
 
 ### 예시 2: 기술 스택에 맞게 커스터마이징
@@ -623,40 +614,34 @@ Write 도구로 `.md` 파일 생성:
    - Vue 특정 추가사항 강조
    - 사용 가이드 제공
 
-### 예시 3: 고급 기능 추가
+### 예시 3: 새 평가 기준 추가
 
-**사용자:** "junior-checker에 학습 리소스 포함하도록 업그레이드해줘"
+**사용자:** "code-reviewer에 성능 관련 기준을 추가해줘"
 
 **프로세스:**
 1. **현재 버전 읽기:**
    ```typescript
-   Read("junior-checker.md")
+   Read("code-reviewer.md")
    ```
 
 2. **변경사항 결정:**
-   - 모델: haiku → sonnet
-   - 도구: + WebFetch, WebSearch
-   - 기준에 🌐 섹션 추가
-   - 학습 리소스 섹션 추가
-   - 큐레이션된 학습 경로 추가
+   - 기존 평가 원칙에 성능 기준 추가
+   - 도구: + WebFetch, WebSearch (필요시)
+   - 기준에 🌐 웹 리서치 섹션 추가
+   - Output Format은 공통 구조 유지
 
-3. **리소스 리서치:**
-   - WebSearch("best coding tutorials for beginners")
-   - 공식 문서 소스 찾기
+3. **도메인 리서치:**
+   - WebSearch("React performance best practices [current year]")
+   - 기존 react-performance-optimizer.md 참고
 
 4. **수정 적용:**
    ```typescript
-   Edit("junior-checker.md", [변경사항])
-   ```
-   또는 새 고급 버전 생성:
-   ```typescript
-   Write("advanced-junior-checker.md", [향상된 내용])
+   Edit("code-reviewer.md", [변경사항])
    ```
 
-5. **변경사항 문서화:**
-   - 모든 추가사항 목록
-   - 새 기능 설명
-   - 필요시 README 업데이트
+5. **변경사항 검증:**
+   - 통일된 Output Format 유지 확인
+   - 심각도 분류 일관성 확인
 
 ---
 
@@ -693,7 +678,7 @@ Write 도구로 `.md` 파일 생성:
 
 1. **과도하게 복잡하게 하지 말 것**
    - 과도한 기준 피하기 (최대 7-8개)
-   - 점수 단순하게 유지
+   - 심각도 분류 단순하게 유지
    - 너무 많은 관심사 섞지 않기
 
 2. **잘못된 모델 사용 금지**
@@ -725,7 +710,7 @@ Write 도구로 `.md` 파일 생성:
 - ✅ 구체적 예시 포함
 - ✅ 실행 가능한 출력 제공
 - ✅ file:line 참조 사용
-- ✅ 명확한 점수 기준 가짐
+- ✅ 통일된 Output Format 준수
 - ✅ 너비와 깊이 균형
 - ✅ 유지보수 및 업데이트 가능
 
@@ -760,7 +745,7 @@ model: haiku  # 빠르고 적절함
 
 ### ❌ 너무 많은 기준
 ```markdown
-## 평가 기준
+## 평가 원칙
 ### 1. 기준 A
 ### 2. 기준 B
 ### 3. 기준 C
@@ -781,10 +766,19 @@ model: haiku  # 빠르고 적절함
 ## Output Format
 ```markdown
 # 보안 분석
-## 점수: X/10
-## Critical 이슈 (즉시 수정)
-- [file:line] - [컴포넌트]의 XSS 취약점
-- 수정: [구체적 코드 예시]
+
+## 발견 사항 요약
+- **Critical:** N개 (즉시 수정 필요)
+- **Recommended Improvements:** M개 (권장 개선)
+- **Best Practices Found:** P개 (잘하고 있음)
+
+## Critical Issues (즉시 수정)
+### 1. [Issue Name]
+**위반 원칙:** [해당 원칙]
+**파일:** [file:line]
+**문제:** [설명]
+**현재 코드:** [코드]
+**수정 방법:** [코드]
 ```
 
 ---

package/commands/branch.md

@@ -34,7 +34,13 @@ main에서 최신 코드를 pull하고 프로젝트의 네이밍 컨벤션을
    - 커밋되지 않은 변경사항이 있으면 먼저 사용자에게 경고
 
 3. **사용자 의도 파악**
-   - 컨텍스트에서 명확하지 않으면 무엇을 작업할 건지 물어보기
+   - `/branch` 뒤에 추가 인자가 없으면:
+     - 위 컨텍스트 정보(현재 브랜치, 최근 커밋 등)를 분석하여 현재 상황 요약
+     - 감지된 브랜치 컨벤션 패턴을 보여주기
+     - 사용자에게 **어떤 작업을 할 것인지** 물어보기 (예: "어떤 작업을 위한 브랜치를 만드시겠습니까?")
+     - 사용자 응답을 바탕으로 브랜치 유형과 이름을 제안하고 확인받기
+   - `/branch` 뒤에 설명이 있으면 (예: `/branch 로그인 기능 추가`):
+     - 해당 설명을 바탕으로 브랜치 유형과 이름을 자동 결정
    - 적절한 브랜치 유형 결정:
      - `feature/` 또는 `feat/` - 새 기능
      - `fix/` - 버그 수정
@@ -42,10 +48,11 @@ main에서 최신 코드를 pull하고 프로젝트의 네이밍 컨벤션을
      - `hotfix/` - 긴급 프로덕션 수정
      - `docs/` - 문서 변경
 
-4. **브랜치 생성**
+4. **브랜치 이름 확인 및 생성**
    - 감지된 컨벤션 패턴 따르기
    - description 부분은 소문자와 하이픈 사용 (예: `feature/add-user-auth`)
    - 간결하면서도 설명적으로
+   - **생성 전 반드시 사용자에게 최종 브랜치 이름을 보여주고 확인받기**
    - 브랜치 생성: `git checkout -b {branch-name}` 또는 `git switch -c {branch-name}`
 
 ## 출력 형식

package/commands/code-review.md

@@ -27,7 +27,10 @@ Task 도구를 통해 다음 전문 에이전트를 사용할 수 있습니다:
 | `code-reviewer` | 아키텍처, 타입 안전성, 에러 처리, 테스트, 접근성, 보안 | opus |
 | `refactor-analyzer` | 코드 중복, 복잡성, 추상화 기회, 코드 스멜 | opus |
 | `junior-checker` | 주니어 개발자 관점 가독성, 네이밍, 복잡도 | opus |
-| `fundamentals-code` | Toss Frontend Fundamentals 기반 (가독성, 예측 가능성, 응집도, 결합도) | opus |
+| `fundamentals-readability` | Toss Fundamentals - 가독성 (코드 분리, 추상화, 함수 쪼개기, 조건 네이밍, 매직 넘버, 시점 이동, 삼항 연산자, 비교 순서) | opus |
+| `fundamentals-predictability` | Toss Fundamentals - 예측 가능성 (이름 충돌, 반환 타입 통일, 숨은 로직) | opus |
+| `fundamentals-cohesion` | Toss Fundamentals - 응집도 (디렉토리 구조, 매직 넘버 관리, 폼 응집도) | opus |
+| `fundamentals-coupling` | Toss Fundamentals - 결합도 (단일 책임, 중복 코드 허용, Props Drilling) | opus |
 | `react-performance-optimizer` | React 리렌더, 메모이제이션, 훅 최적화 | opus |
 | `react-principles-reviewer` | React 개발 원칙 (응집도/명시성, Props 관리, 네이밍, 부수효과, AsyncBoundary) | opus |
 | `maintainable-code-reviewer` | 유지보수성 (UI-코드 1:1 대응, 분리의 4원칙, 추상화 원칙) | opus |
@@ -55,7 +58,7 @@ Skill은 사용자 설치에 따라 다르며 추가 리뷰 가이드라인/컨
 
    | 옵션 | 이름 | 사용 에이전트 | 적합한 상황 |
    |------|------|--------------|-------------|
-   | 1 | **전체 리뷰** | 모든 7개 에이전트 병렬 실행 | 종합 코드 리뷰 (권장) |
+   | 1 | **전체 리뷰** | 모든 10개 에이전트 병렬 실행 | 종합 코드 리뷰 (권장) |
    | 2 | **커스텀** | 사용자가 직접 선택 | 특정 관점만 리뷰하고 싶을 때 |
 
 3. **Skill 포함 여부 질문** (AskUserQuestion 사용)
@@ -99,7 +102,7 @@ AskUserQuestion으로 포함할 skill 여부 질문.
 ```
 리뷰 실행 중...
 ├── code-reviewer: 완료
-├── fundamentals-code: 실행 중...
+├── fundamentals-readability: 실행 중...
 ├── refactor-analyzer: 완료
 └── junior-checker: 대기 중
 ```
@@ -112,7 +115,7 @@ AskUserQuestion으로 포함할 skill 여부 질문.
 ## 요약
 - **리뷰 대상:** [path]
 - **실행된 에이전트:** [list]
-- **총 발견 사항:** N개 (Critical: X, Warning: Y, Info: Z)
+- **총 발견 사항:** N개 (Critical: X, Recommended Improvements: Y, Best Practices Found: Z)
 
 ---
 
@@ -126,7 +129,7 @@ AskUserQuestion으로 포함할 skill 여부 질문.
 
 ---
 
-## Warnings (개선 권장)
+## Recommended Improvements (권장 개선)
 
 ### 1. [Issue Title]
 - **발견 에이전트:** [agent name]
@@ -136,7 +139,7 @@ AskUserQuestion으로 포함할 skill 여부 질문.
 
 ---
 
-## Good Practices (잘한 점)
+## Best Practices Found (잘하고 있음)
 
 - [Good practice 1] - [file:line]
 - [Good practice 2] - [file:line]
@@ -148,7 +151,7 @@ AskUserQuestion으로 포함할 skill 여부 질문.
 ### Code Reviewer
 [발견사항 요약]
 
-### Fundamentals Code
+### Fundamentals (Readability / Predictability / Cohesion / Coupling)
 [발견사항 요약]
 
 ### Refactor Analyzer
@@ -158,11 +161,14 @@ AskUserQuestion으로 포함할 skill 여부 질문.
 
 ---
 
-## 우선순위 개선 항목
+## Metrics
 
-1. **[최우선]** [Issue] - [file]
-2. **[높음]** [Issue] - [file]
-3. **[보통]** [Issue] - [file]
+| 지표 | 수치 |
+|------|------|
+| 총 파일 수 | X |
+| Critical 이슈 | N |
+| Recommended Improvements | M |
+| Best Practices Found | P |
 ```
 
 ## 도구 사용 예시
@@ -175,7 +181,13 @@ AskUserQuestion으로 포함할 skill 여부 질문.
 // 여러 에이전트를 병렬로 실행 (단일 메시지, 다중 Task 호출)
 Task(code-reviewer): "src/components 코드를 리뷰하세요. 아키텍처, 타입 안전성, 에러 처리, 접근성, 보안에 집중하세요. file:line 참조와 함께 발견사항을 반환하세요."
 
-Task(fundamentals-code): "src/components를 Toss Frontend Fundamentals 원칙으로 분석하세요. 가독성, 예측 가능성, 응집도, 결합도를 확인하세요. file:line 참조와 함께 발견사항을 반환하세요."
+Task(fundamentals-readability): "src/components를 Toss Fundamentals 가독성 원칙으로 분석하세요. 코드 분리, 추상화, 조건 네이밍, 매직 넘버, 시점 이동, 삼항 연산자를 확인하세요. file:line 참조와 함께 발견사항을 반환하세요."
+
+Task(fundamentals-predictability): "src/components를 Toss Fundamentals 예측 가능성 원칙으로 분석하세요. 이름 충돌, 반환 타입 통일, 숨은 로직을 확인하세요. file:line 참조와 함께 발견사항을 반환하세요."
+
+Task(fundamentals-cohesion): "src/components를 Toss Fundamentals 응집도 원칙으로 분석하세요. 디렉토리 구조, 매직 넘버 관리, 폼 응집도를 확인하세요. file:line 참조와 함께 발견사항을 반환하세요."
+
+Task(fundamentals-coupling): "src/components를 Toss Fundamentals 결합도 원칙으로 분석하세요. 단일 책임, 중복 코드 허용, Props Drilling을 확인하세요. file:line 참조와 함께 발견사항을 반환하세요."
 
 Task(refactor-analyzer): "src/components의 리팩토링 기회를 분석하세요. 코드 중복, 복잡성, 추상화 기회를 확인하세요. file:line 참조와 함께 발견사항을 반환하세요."
 

package/commands/commit.md

@@ -33,15 +33,17 @@ allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git c
    - 이 변경들의 주요 목적은 무엇인가?
    - 별도 커밋으로 분리해야 할 여러 논리적 변경이 있는가?
 
-3. **커밋 메시지 생성**
+3. **커밋 메시지 생성 및 확인**
    - 감지된 컨벤션 패턴 따르기 (type prefix, scope 등)
    - **한국어로 작성** (기존 히스토리가 영어여도)
    - **간결하게, 가능하면 1줄** (권장 50자, 최대 72자)
    - body는 정말 필요할 때만 추가
    - **Co-Authored-By footer 추가 금지**
+   - **생성한 커밋 메시지를 사용자에게 보여주고 확인받기**
+   - 사용자가 수정을 원하면 반영 후 다시 확인
 
 4. **커밋 실행**
-   - 생성된 메시지로 `git commit -m "message"` 실행
+   - **사용자가 승인한 후에만** `git commit -m "message"` 실행
    - body가 필요하면 멀티라인 포맷 사용
    - **커밋 메시지에 Co-Authored-By 절대 포함 금지**
 
@@ -51,6 +53,6 @@ allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git c
 - 감지된 컨벤션 패턴
 - 변경사항 요약
 
-그 다음 커밋 명령 직접 실행.
+그 다음 커밋 메시지를 제안하고 사용자 확인 후 실행.
 
 Staged 변경사항이 없으면 사용자에게 알리고 먼저 `git add` 사용을 제안.

package/commands/design-to-code.md

@@ -73,7 +73,10 @@ Task(Plan): "다음 설계를 구현하기 위한 계획을 수립하세요:
 
 | 에이전트 | 검증 내용 |
 |----------|----------|
-| `fundamentals-code` | 가독성, 예측 가능성, 응집도, 결합도 관점에서 설계 검증 |
+| `fundamentals-readability` | 가독성 관점에서 설계 검증 |
+| `fundamentals-predictability` | 예측 가능성 관점에서 설계 검증 |
+| `fundamentals-cohesion` | 응집도 관점에서 설계 검증 |
+| `fundamentals-coupling` | 결합도 관점에서 설계 검증 |
 | `refactor-analyzer` | 추상화 기회, 재사용 가능한 컴포넌트 식별 |
 
 **조건부 에이전트 (React 프로젝트):**
@@ -93,10 +96,22 @@ Task(Plan): "다음 설계를 구현하기 위한 계획을 수립하세요:
 **에이전트 실행 예시:**
 
 ```
-// 필수 에이전트 (항상 실행)
-Task(fundamentals-code): "다음 구현 계획을 Toss Frontend Fundamentals 원칙으로 검증하세요:
+// 필수 에이전트 (항상 실행 - 4개 병렬)
+Task(fundamentals-readability): "다음 구현 계획을 가독성 원칙으로 검증하세요:
 [Plan 결과]
-가독성, 예측 가능성, 응집도, 결합도 관점에서 개선점을 제안하세요."
+코드 분리, 추상화, 함수 쪼개기, 조건 네이밍, 매직 넘버, 시점 이동 관점에서 개선점을 제안하세요."
+
+Task(fundamentals-predictability): "다음 구현 계획을 예측 가능성 원칙으로 검증하세요:
+[Plan 결과]
+이름 충돌, 반환 타입 통일, 숨은 로직 관점에서 개선점을 제안하세요."
+
+Task(fundamentals-cohesion): "다음 구현 계획을 응집도 원칙으로 검증하세요:
+[Plan 결과]
+디렉토리 구조, 매직 넘버 관리, 폼 응집도 관점에서 개선점을 제안하세요."
+
+Task(fundamentals-coupling): "다음 구현 계획을 결합도 원칙으로 검증하세요:
+[Plan 결과]
+단일 책임, 중복 코드 허용, Props Drilling 관점에서 개선점을 제안하세요."
 
 Task(refactor-analyzer): "다음 구현 계획에서 추상화 기회를 분석하세요:
 [Plan 결과]
@@ -195,13 +210,13 @@ export function NewComponent({ ... }: Props) {
 
 ## 4. 설계 검증 결과
 
-### fundamentals-code 검증
-| 원칙 | 상태 | 피드백 |
-|------|------|--------|
-| 가독성 | ✅/🟡/🔴 | [피드백] |
-| 예측 가능성 | ✅/🟡/🔴 | [피드백] |
-| 응집도 | ✅/🟡/🔴 | [피드백] |
-| 결합도 | ✅/🟡/🔴 | [피드백] |
+### Toss Fundamentals 검증
+| 원칙 | 에이전트 | 상태 | 피드백 |
+|------|----------|------|--------|
+| 가독성 | fundamentals-readability | ✅/🟡/🔴 | [피드백] |
+| 예측 가능성 | fundamentals-predictability | ✅/🟡/🔴 | [피드백] |
+| 응집도 | fundamentals-cohesion | ✅/🟡/🔴 | [피드백] |
+| 결합도 | fundamentals-coupling | ✅/🟡/🔴 | [피드백] |
 
 ### refactor-analyzer 검증
 **추상화 기회:**

package/commands/pr.md

@@ -1,6 +1,6 @@
 ---
 description: 브랜치 차이, 커밋, 변경 파일을 분석하여 Pull Request 자동 생성
-allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git branch:*), Bash(git rev-parse:*), Bash(gh pr:*), Bash(gh auth:*)
+allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git branch:*), Bash(git rev-parse:*), Bash(gh pr:*), Bash(gh auth:*), Bash(gh api:*)
 ---
 
 # 자동 PR 생성기
@@ -44,18 +44,33 @@ allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git b
    - 코드베이스의 어느 영역이 영향받는가?
    - breaking changes가 있는가?
 
-4. **PR 제목 및 설명 생성**
+4. **기존 PR 확인**
+   - `gh pr view --json number,title,body,url,state` 로 현재 브랜치에 열린 PR이 있는지 확인
+   - **PR이 이미 열려 있으면 → 5-A (업데이트 플로우)**
+   - **PR이 없으면 → 5-B (생성 플로우)**
+
+5-A. **기존 PR 업데이트 플로우**
+   - 기존 PR의 title과 body를 가져오기
+   - 현재 변경사항을 기반으로 새로운 title과 body를 생성
+   - 기존 내용과 새 내용을 비교하여 **변경점을 사용자에게 보여주기**
+   - 사용자가 승인하면 `gh pr edit --title "title" --body "body"` 로 업데이트
+   - 사용자가 수정을 원하면 반영 후 다시 확인
+
+5-B. **새 PR 생성 플로우**
    - **제목**: 한국어로 간결한 요약 (커밋 컨벤션이 있으면 따르기)
    - **설명**: 다음 섹션 포함:
      - `## 변경 사항` (변경사항 요약)
      - `## 변경된 파일` (주요 변경 파일 목록)
      - `## 테스트` (해당되는 경우 테스트 방법)
    - **"Generated with Claude Code" 또는 AI attribution footer 추가 금지**
+   - **생성한 title과 body를 사용자에게 보여주고 확인받기**
+   - 사용자가 수정을 원하면 반영 후 다시 확인
 
-5. **PR 생성**
-   - 먼저 브랜치가 remote에 push되었는지 확인
-   - 생성된 title과 body로 `gh pr create` 사용
-   - PR이 이미 존재하면 사용자에게 알림
+6. **실행**
+   - **사용자가 승인한 후에만** 실행
+   - 먼저 브랜치가 remote에 push되었는지 확인 (안 되었으면 push 제안)
+   - 새 PR: `gh pr create --title "title" --body "body"`
+   - 기존 PR 업데이트: `gh pr edit --title "title" --body "body"`
 
 ## 출력 형식
 
@@ -63,17 +78,14 @@ allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git b
 - 현재 브랜치와 타겟 브랜치
 - 포함될 커밋 수
 - 변경사항 요약
+- 기존 PR 존재 여부
 
-그 다음 PR 생성 전 확인 요청, 제안된 title과 description 표시.
-
-확인 후 실행:
-```bash
-gh pr create --title "title" --body "body"
-```
+그 다음:
+- **새 PR**: 제안된 title과 body를 보여주고 사용자 확인 후 생성
+- **기존 PR 업데이트**: 기존 내용 vs 새 내용 비교를 보여주고 사용자 확인 후 업데이트
 
 ## 에러 처리
 
 - GitHub CLI 로그인 안됨: `gh auth login` 실행 안내
 - 브랜치 미푸시: `git push -u origin <branch>`로 push 제안
-- PR 이미 존재: 기존 PR URL 표시
 - main 브랜치에서 실행: feature 브랜치 먼저 생성하라고 안내

package/commands/review-pr.md

@@ -19,7 +19,10 @@ Task 도구를 통해 다음 전문 에이전트를 사용할 수 있습니다:
 | Agent | 초점 영역 |
 |-------|----------|
 | `code-reviewer` | 아키텍처, 타입 안전성, 에러 처리, 테스트, 접근성, 보안 |
-| `fundamentals-code` | Toss Frontend Fundamentals 기반 (가독성, 예측 가능성, 응집도, 결합도) |
+| `fundamentals-readability` | Toss Fundamentals - 가독성 |
+| `fundamentals-predictability` | Toss Fundamentals - 예측 가능성 |
+| `fundamentals-cohesion` | Toss Fundamentals - 응집도 |
+| `fundamentals-coupling` | Toss Fundamentals - 결합도 |
 | `refactor-analyzer` | 코드 중복, 복잡성, 추상화 기회, 코드 스멜 |
 | `junior-checker` | 주니어 개발자 관점 가독성, 네이밍, 복잡도 |
 | `react-performance-optimizer` | React 리렌더, 메모이제이션, 훅 최적화 |
@@ -91,15 +94,33 @@ Skill은 사용자 설치에 따라 다르며 추가 리뷰 가이드라인/컨
    - GitHub 리뷰 스타일로 file:line 참조와 함께 발견사항 반환
    - 심각도를 Must Fix / Should Fix / Consider / Suggestion으로 구분"
 
-   Task(fundamentals-code): "PR #<PR번호>를 Toss Frontend Fundamentals 원칙으로 분석해주세요.
+   Task(fundamentals-readability): "PR #<PR번호>를 가독성 원칙으로 분석해주세요.
+   [작업 순서]
+   1. `gh pr view <PR번호>`로 PR 정보 확인
+   2. `gh pr diff <PR번호>`로 전체 변경사항 확인
+   3. 필요 시 관련 파일 Read
+   [리뷰 관점] 코드 분리, 추상화, 함수 쪼개기, 조건 네이밍, 매직 넘버, 시점 이동, 삼항 연산자, 비교 순서"
 
+   Task(fundamentals-predictability): "PR #<PR번호>를 예측 가능성 원칙으로 분석해주세요.
    [작업 순서]
    1. `gh pr view <PR번호>`로 PR 정보 확인
    2. `gh pr diff <PR번호>`로 전체 변경사항 확인
    3. 필요 시 관련 파일 Read
+   [리뷰 관점] 이름 충돌, 반환 타입 통일, 숨은 로직"
 
-   [리뷰 관점]
-   가독성, 예측 가능성, 응집도, 결합도 4가지 관점에서 점수화하고 리뷰"
+   Task(fundamentals-cohesion): "PR #<PR번호>를 응집도 원칙으로 분석해주세요.
+   [작업 순서]
+   1. `gh pr view <PR번호>`로 PR 정보 확인
+   2. `gh pr diff <PR번호>`로 전체 변경사항 확인
+   3. 필요 시 관련 파일 Read
+   [리뷰 관점] 디렉토리 구조, 매직 넘버 관리, 폼 응집도"
+
+   Task(fundamentals-coupling): "PR #<PR번호>를 결합도 원칙으로 분석해주세요.
+   [작업 순서]
+   1. `gh pr view <PR번호>`로 PR 정보 확인
+   2. `gh pr diff <PR번호>`로 전체 변경사항 확인
+   3. 필요 시 관련 파일 Read
+   [리뷰 관점] 단일 책임, 중복 코드 허용, Props Drilling"
 
    Task(refactor-analyzer): "PR #<PR번호>에서 리팩토링 기회를 찾아주세요.
 
@@ -207,7 +228,7 @@ const user: User = response.data
 
 ## ✅ 잘한 점
 
-- `src/hooks/useUser.ts` - 훅 분리가 잘 되어 있음 (fundamentals-code)
+- `src/hooks/useUser.ts` - 훅 분리가 잘 되어 있음 (fundamentals-cohesion)
 - `src/types/index.ts` - 타입 정의가 명확함 (code-reviewer)
 
 ---