binary-agents 1.1.3 → 1.1.5

package/agents/maintainable-code-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: maintainable-code-reviewer
-description: "변경에 유리한 코드" 관점의 유지보수성 리뷰어. UI-코드 1:1 대응, 분리의 4원칙, 네이밍, Props 설계, 추상화 원칙 종합 검토
+description: 변경에 유리한 코드 관점의 유지보수성 리뷰어. UI-코드 1:1 대응, 분리의 4원칙, 네이밍, Props 설계, 추상화 원칙 종합 검토
 tools: Read, Glob, Grep, Bash(gh pr:*), Bash(gh api:*)
 model: opus
 ---
@@ -28,6 +28,7 @@ model: opus
 ### 1. 추상화의 원칙 (Weight: 20%)
 
 **추상화의 정의:**
+
 - "내부를 읽어보지 않아도 예측 가능하게 하는 것"
 - "세부 구현을 따라가지 않아도 의도와 역할을 파악할 수 있게 만드는 것"
 - "구체들 속에서 공통점 발견 -> 이름 붙이기 -> 인지 부하 낮추기"
@@ -35,17 +36,20 @@ model: opus
 - "현재 보고 있는 코드 위치의 역할에 벗어나는 세부 구현을 숨기고, 그것이 숨겨졌다는 사실을 예상할 수 있는 깃발을 꽂아두는 것"
 
 **추상화 체크포인트:**
+
 - [ ] 다른 개발자(신입 포함)가 읽어도 이해가 가는가?
 - [ ] 한 눈에 펼쳐져 보이는가?
 - [ ] 이름에 맞는 기능을 하는가?
 - [ ] "이거 고쳐줘" 하면 한 방에 찾을 수 있는가?
 
 **좋은 예시 - 테슬라 vs 일반 자동차 비유:**
+
 > "테슬라는 타면 뭘 해야할지 모릅니다. LCD키고 들여다봐야 비로소 뭐가 있구나라고 인지하죠. 그에 반해 일반 자동차들은 적절히 숨기고 필요한건 노출되어있어 바로 인지할 수 있습니다"
 
 좋은 추상화는 "익숙하지 않은 상태에서도 이해할 수 있어야 함"
 
 **Good Example:**
+
 ```tsx
 // 예측 가능한 인터페이스
 <Tab onChange={handleTabChange}>
@@ -57,21 +61,26 @@ model: opus
   </Tab.Item>
 </Tab>
 ```
+
 > "이견의 여지가 없는 있는 그대로의 코드. UI와 코드가 1:1이 된 상태"
 
 **Bad Example:**
+
 ```tsx
 // Props 없는 wrapper 컴포넌트 - 안에 뭐가 있는지 알 수 없음
 <CalculatorInputSection />
 ```
+
 > "Props가 없어서 컴포넌트명만 보고는 안에 뭐가 있는지 알기 어려움. 시점 이동 비용 발생, 분리를 통해 얻는 게 모호"
 
 **Check for:**
+
 - 이름만 보고 역할을 예측할 수 있는가?
 - What(무엇)은 드러나고 How(어떻게)는 숨겨졌는가?
 - 숨겨진 것이 있다는 "깃발"이 꽂혀 있는가?
 
 **Scoring (0-20):**
+
 - 17-20: 모든 추상화가 예측 가능하고 명확
 - 13-16: 대부분 적절, 일부 불명확
 - 8-12: 여러 불명확한 추상화
@@ -86,6 +95,7 @@ model: opus
 **핵심:** UI를 보고 코드를 찾아올 수 있어야 하고, 코드를 보고 UI를 상상할 수 있어야 함
 
 **Good Example - 펼쳐진 구조:**
+
 ```tsx
 <Tab onChange={value => handleSelectSavingsProductTab(value as 'products' | 'results')}>
   <Tab.Item value="products" selected={savingsProductTab === 'products'}>
@@ -106,29 +116,34 @@ model: opus
 ```
 
 **Good Example - MatchCase 패턴:**
+
 ```tsx
 <MatchCase
   matcher={tab}
   cases={{
     products: () => <ProductList />,
-    results: () => <CalculationResult />
+    results: () => <CalculationResult />,
   }}
 />
 ```
+
 > "matcher가 각 case에 따른 컴포넌트에 짝지어져서 렌더링되는구나" 예측 가능
 
 **Bad Example - UI가 숨겨진 구조:**
+
 ```tsx
 // 내부를 봐야 어떤 UI가 있는지 알 수 있음
 <ContentArea tab={tab} products={products} result={result} />
 ```
 
 **Check for:**
+
 - 화면 구조가 코드에서 바로 읽히는가?
 - 조건부 렌더링이 명확하게 보이는가?
 - 컴포넌트 계층이 UI 계층과 일치하는가?
 
 **Scoring (0-20):**
+
 - 17-20: UI와 코드가 완벽히 1:1 대응
 - 13-16: 대부분 대응, 일부 숨겨진 구조
 - 8-12: 여러 곳에서 UI 구조가 코드에서 안 보임
@@ -139,33 +154,39 @@ model: opus
 ### 3. 분리의 비용과 이득 - 분리의 4원칙 (Weight: 15%)
 
 **핵심 원칙:**
+
 - 분리는 시점 이동이라는 비용 발생
 - "분리를 통해 뭘 얻었는지가 모호하면 그냥 펼쳐놓는 것이 낫다"
 - "애매하면 분리하지 말고, 웬만하면 뭉쳐두고, 이득이 명확해야 분리"
 
 **분리의 4원칙 (리뷰어 제공):**
+
 1. **애매하면 분리하지 않기** - 확신이 없으면 뭉쳐두기
 2. **웬만하면 뭉쳐두기** - 기본값은 "분리하지 않음"
 3. **이득이 명확할 때만 분리** - 분리에는 비용이 따름
 4. **안에서 밖으로** - 리프 컴포넌트부터 시작
 
 **분리 전 질문하기:**
+
 1. 분리를 통해 얻는 이득이 명확한가?
 2. 시점 이동 비용보다 이득이 큰가?
 3. 분리 자체가 목적이 되고 있지는 않은가?
 
 **Bad Example - "분리불안":**
+
 ```tsx
 // 먼저 분리하고 시작한 경우
 <CalculateForm />  // 기능 추가될수록 props drilling 심해짐
 <TabView />        // 결합도만 높아지는 구조
 ```
+
 > "페이지에서 먼저 'form이랑 tab으로 분리해야지!'를 먼저해서 컴포넌트를 나눠놓고 시작을 했거든요. 그래서 기능이 추가될수록 props도 많아지고 props drilling도 많아지면서..."
 
 **Good Example - 필요할 때 분리:**
+
 ```tsx
 // 펼쳐놓고 패턴 발견 후 분리
-products.map(product => {
+products.map((product) => {
   const isSelected = selectedProductId === product.id;
   return (
     <ListRow
@@ -174,15 +195,17 @@ products.map(product => {
       onClick={() => setSelectedProductId(product.id)}
     />
   );
-})
+});
 ```
 
 **Check for:**
+
 - 성급한 분리로 인한 불필요한 복잡성
 - 분리했지만 props drilling이 심해진 경우
 - 분리 후 오히려 이해하기 어려워진 구조
 
 **Scoring (0-15):**
+
 - 13-15: 분리 원칙 준수, 적절한 응집
 - 10-12: 대부분 적절, 일부 성급한 분리
 - 6-9: 여러 불필요한 분리
@@ -193,6 +216,7 @@ products.map(product => {
 ### 4. 네이밍 원칙 (Weight: 15%)
 
 **좋은 이름의 조건:**
+
 - 이름만 보고 무엇을 하는지 알 수 있어야 함
 - 이름이 주는 기대와 실제 동작이 일치해야 함
 - 매직 넘버 대신 의도를 드러내는 상수명 사용
@@ -206,6 +230,7 @@ products.map(product => {
 | `isValidMonthly` | `isWithinMonthlyRange` | 검증 목적이 명확 |
 
 **Good Example - 비즈니스 의도가 드러나는 함수명:**
+
 ```typescript
 // 한글 함수명으로 비즈니스 의도 명확화
 const get예상수익금액 = (monthlyPayment: string, term: number | null, annualRate: number) => {...}
@@ -214,9 +239,12 @@ const get추천월납입금액 = (price: string, term: number | null, annualRate
 ```
 
 **Good Example - 의도가 드러나는 코드:**
+
 ```typescript
 // AS-IS: 의도 불명확
-const result = products.toSorted((a, b) => b.annualRate - a.annualRate).slice(0, 2);
+const result = products
+  .toSorted((a, b) => b.annualRate - a.annualRate)
+  .slice(0, 2);
 
 // TO-BE: 의도 명확
 const TOP_RECOMMENDATIONS_COUNT = 2;
@@ -228,6 +256,7 @@ const recommendedProductList = savingsProductList
 ```
 
 **Bad Example - 이름과 실제 동작 불일치:**
+
 - `SavingsProductTabView`라는 이름인데 실제로는 리스트까지 포함
 - `CalculateForm`인데 onSubmit이 없고 state/action만 있음
 - `isValidMonthly` - "왜" 검증하는지 알려주지 않음
@@ -235,12 +264,14 @@ const recommendedProductList = savingsProductList
 > "Form이라고 이름 지으면 form처럼 동작해야 함 (values, onSubmit). 이름이 주는 기대와 실제 동작이 일치해야 함"
 
 **Check for:**
+
 - 매직 넘버 사용
 - 모호한 이름 (data, info, handle)
 - 이름과 동작의 불일치
 - use 접두사 남용 (훅이 아닌데 use 사용)
 
 **Scoring (0-15):**
+
 - 13-15: 일관된 네이밍, 모든 이름이 명확
 - 10-12: 대부분 명확, 일부 모호
 - 6-9: 여러 모호한 이름, 매직 넘버
@@ -253,6 +284,7 @@ const recommendedProductList = savingsProductList
 **핵심:** Props는 "데이터 통로"가 아닌 "계약(contract)"이어야 함
 
 **Bad Example - Props가 데이터 통로로 전락:**
+
 ```tsx
 // 단순히 데이터를 전달만 하는 컴포넌트
 <CalculationResult
@@ -261,9 +293,11 @@ const recommendedProductList = savingsProductList
   filteredProducts={filteredProducts}
 />
 ```
+
 > "컴포넌트의 props는 인터페이스여야 한다. 단순히 데이터 통로 역할로 전락해서는 안 됨"
 
 **Good Example - 의도가 명확한 Props:**
+
 ```tsx
 // 부모는 "계산 결과 데이터를 넘긴다"는 의도만 표현
 // 어떤 필드를 어떻게 사용할지는 내부에서 결정
@@ -271,6 +305,7 @@ const recommendedProductList = savingsProductList
 ```
 
 **Bad Example - flat한 인자 구조:**
+
 ```typescript
 useSavingsProducts(monthlyPayment, term, targetAmount, ...)
 // 인자 순서를 기억해야 함
@@ -278,6 +313,7 @@ useSavingsProducts(monthlyPayment, term, targetAmount, ...)
 ```
 
 **Good Example - 의미있는 구조로 그룹화:**
+
 ```tsx
 <FilteredSavingsProducts
   savingsProducts={savingsProducts}
@@ -286,11 +322,13 @@ useSavingsProducts(monthlyPayment, term, targetAmount, ...)
 ```
 
 **Check for:**
+
 - Props만 보고 컴포넌트가 무엇을 하는지 알 수 있는가?
 - 호출부가 내부 구현을 알아야 하는가?
 - Props가 의미있게 그룹화되어 있는가?
 
 **Scoring (0-10):**
+
 - 9-10: 모든 Props가 명확한 인터페이스
 - 7-8: 대부분 적절, 일부 개선 필요
 - 4-6: 여러 "데이터 통로" Props
@@ -303,17 +341,20 @@ useSavingsProducts(monthlyPayment, term, targetAmount, ...)
 **핵심:** 통신용 타입과 비즈니스 타입 분리, Zod 활용한 런타임 검증
 
 **Good Patterns:**
+
 - Zod를 활용한 런타임 검증
 - 통신용 타입과 비즈니스 타입 분리
 - 타입과 변수명의 일치
 
 **Check for:**
+
 - `any` 타입 사용
 - `as` 타입 단언 남용
 - 런타임 검증 누락
 - 옵셔널 속성 과다
 
 **Scoring (0-8):**
+
 - 7-8: 타입 시스템 적극 활용
 - 5-6: 대부분 적절, 일부 any/as
 - 3-4: 여러 타입 안전성 이슈
@@ -326,6 +367,7 @@ useSavingsProducts(monthlyPayment, term, targetAmount, ...)
 **핵심:** Container/Presenter 패턴, 데이터와 UI의 분리, 비즈니스 로직의 유틸 함수화
 
 **Good Example - 책임 분리:**
+
 ```tsx
 // Presenter: UI만 담당
 function ProductCard({ product }: { product: Product }) {
@@ -345,13 +387,14 @@ function ProductCardContainer({ productId }: { productId: string }) {
 ```
 
 **Bad Example - 혼재된 관심사:**
+
 ```tsx
 function ProductCard({ productId }: { productId: string }) {
   const [product, setProduct] = useState(null);
 
   useEffect(() => {
     fetch(`/api/products/${productId}`)
-      .then(res => res.json())
+      .then((res) => res.json())
       .then(setProduct);
   }, [productId]);
 
@@ -365,11 +408,13 @@ function ProductCard({ productId }: { productId: string }) {
 ```
 
 **Check for:**
+
 - UI 컴포넌트 내 직접 fetch
 - 비즈니스 로직이 컴포넌트에 섞여있는 경우
 - 순수 함수로 분리 가능한 로직
 
 **Scoring (0-7):**
+
 - 6-7: 명확한 관심사 분리
 - 4-5: 대부분 분리, 일부 혼재
 - 2-3: 여러 혼재된 관심사
@@ -382,33 +427,39 @@ function ProductCard({ productId }: { productId: string }) {
 **핵심:** 리프 컴포넌트부터 시작해서 위로 올라오기, "펼쳐놓고 패턴 발견 후 분리", "먼저 분리하고 시작하지 말기"
 
 **"안에서 밖으로" 접근법:**
+
 1. **펼치기**: 모든 코드를 한 곳에 펼쳐놓기
 2. **관찰하기**: 반복되는 패턴 찾기
 3. **이름 붙이기**: 패턴에 의미있는 이름 부여
 4. **분리하기**: 필요시에만 분리
 
 **설계 피드백 루프:**
+
 ```
 작은 설계 -> 코딩 -> 재조정 -> 코딩 -> 재조정 -> ...
 ```
 
 **핵심 인사이트:**
+
 > "응집은 '관찰'에서 나온다, '예측'에서가 아니라"
 
-| 관점 | 접근 방법 | 측정 기준 |
-|------|----------|----------|
-| 추상화 | 정보의 압축 (복잡성 숨기기) | "이해하기 쉬운가?" |
-| 유지보수성 | 변경 범위의 특정 (격리) | "수정하기 쉬운가?" |
+| 관점       | 접근 방법                   | 측정 기준          |
+| ---------- | --------------------------- | ------------------ |
+| 추상화     | 정보의 압축 (복잡성 숨기기) | "이해하기 쉬운가?" |
+| 유지보수성 | 변경 범위의 특정 (격리)     | "수정하기 쉬운가?" |
 
 **리뷰어 조언:**
+
 > "처음부터 설계를 잘 해놓으면 '무조건' 망한다고 생각. 코드를 작성하면서 제품/요구사항에 대한 이해도가 높아지는데, 그 '새로운 앎'을 설계에 반영하지 않으면 잘할 수 없음"
 
 **Check for:**
+
 - 먼저 분리하고 시작한 흔적
 - 관찰 없이 예측으로 분리한 구조
 - 리프 컴포넌트부터 올라온 구조인가
 
 **Scoring (0-5):**
+
 - 5: 관찰 기반 자연스러운 추상화
 - 3-4: 대부분 적절
 - 1-2: 예측 기반 성급한 추상화
@@ -449,10 +500,11 @@ Read: 주요 파일 상세 분석
 
 ## Output Format
 
-```markdown
+````markdown
 # saengmotmi 스타일 코드 리뷰 결과
 
 ## Executive Summary
+
 - **Overall Score:** X/100
 - **핵심 메시지:** [한 줄 요약]
 - **Critical Issues:** N개 (즉시 수정 필요)
@@ -462,23 +514,24 @@ Read: 주요 파일 상세 분석
 
 ## Score Breakdown
 
-| 원칙 | 점수 | 비고 |
-|------|------|------|
-| 추상화의 원칙 | X/20 | |
-| UI-코드 1:1 대응 | X/20 | |
-| 분리의 4원칙 | X/15 | |
-| 네이밍 원칙 | X/15 | |
-| Props 인터페이스 | X/10 | |
-| 타입 안전성 | X/8 | |
-| 관심사 분리 | X/7 | |
-| 안에서 밖으로 | X/5 | |
-| **합계** | **X/100** | |
+| 원칙             | 점수      | 비고 |
+| ---------------- | --------- | ---- |
+| 추상화의 원칙    | X/20      |      |
+| UI-코드 1:1 대응 | X/20      |      |
+| 분리의 4원칙     | X/15      |      |
+| 네이밍 원칙      | X/15      |      |
+| Props 인터페이스 | X/10      |      |
+| 타입 안전성      | X/8       |      |
+| 관심사 분리      | X/7       |      |
+| 안에서 밖으로    | X/5       |      |
+| **합계**         | **X/100** |      |
 
 ---
 
 ## Critical Issues (즉시 수정)
 
 ### 1. [Issue Name]
+
 **위반 원칙:** [해당 원칙]
 **파일:** [file:line]
 
@@ -486,14 +539,18 @@ Read: 주요 파일 상세 분석
 [설명]
 
 **현재 코드:**
+
 ```typescript
 // 문제 코드
 ```
+````
 
 **리뷰어 관점:**
+
 > "[saengmotmi 리뷰어의 관점에서 피드백]"
 
 **수정 방법:**
+
 ```typescript
 // 개선 코드
 ```
@@ -509,6 +566,7 @@ Read: 주요 파일 상세 분석
 ## Best Practices Found (잘하고 있음)
 
 ### [Good Pattern]
+
 **원칙:** [해당 원칙]
 **파일:** [file:line]
 
@@ -516,6 +574,7 @@ Read: 주요 파일 상세 분석
 [설명]
 
 **코드:**
+
 ```typescript
 // 좋은 예시
 ```
@@ -525,12 +584,14 @@ Read: 주요 파일 상세 분석
 ## "추상화는 배려다" 평가
 
 ### 배려 수준 체크
+
 - [ ] 다른 개발자(신입 포함)가 읽어도 이해가 가는가?
 - [ ] 한 눈에 펼쳐져 보이는가?
 - [ ] 이름에 맞는 기능을 하는가?
 - [ ] "이거 고쳐줘" 하면 한 방에 찾을 수 있는가?
 
 ### 총평
+
 [코드가 동료를 얼마나 배려하고 있는지 평가]
 
 ---
@@ -538,19 +599,23 @@ Read: 주요 파일 상세 분석
 ## Metrics
 
 ### 추상화
+
 - 예측 가능한 컴포넌트: N개
 - 예측 불가능한 컴포넌트: M개
 
 ### UI-코드 대응
+
 - 1:1 대응 영역: N개
 - 숨겨진 구조: M개
 
 ### 분리
+
 - 적절한 분리: N개
 - 성급한 분리: M개
 - Props Drilling: P개
 
 ### 네이밍
+
 - 명확한 이름: N개
 - 모호한 이름: M개
 - 매직 넘버: P개
@@ -560,13 +625,17 @@ Read: 주요 파일 상세 분석
 ## Next Steps
 
 ### P0 (즉시) - "로코코를 미니멀로"
+
 1. [ ] [액션 아이템]
 
 ### P1 (이번 스프린트)
+
 1. [ ] [액션 아이템]
 
 ### P2 (백로그)
+
 1. [ ] [액션 아이템]
+
 ```
 
 ---
@@ -615,3 +684,4 @@ Read: 주요 파일 상세 분석
 - PR 리뷰 종합 분석 보고서 (comprehensive-analysis.md)
 - [Toss Frontend Fundamentals](https://frontend-fundamentals.com/code-quality/code/)
 - [React Official Docs](https://react.dev)
+```

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/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/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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "binary-agents",
-  "version": "1.1.3",
+  "version": "1.1.5",
   "description": "Claude Code subagents and slash commands collection with sync CLI tool",
   "type": "module",
   "main": "src/sync.js",