@simplysm/sd-claude 14.0.62 → 14.0.64

package/claude/skills/sd-subdomain/SKILL.md

@@ -0,0 +1,439 @@
+---
+name: sd-subdomain
+description: 대규모 요구사항을 DDD Subdomain(Core/Supporting/Generic) 단위로 1차 분해하여 sd-wbs 호출 단위를 확정하는 스킬. "도메인 분해", "Subdomain 식별", "프로젝트 카테고리 분해" 등을 요청할 때 사용한다.
+---
+
+# sd-subdomain: 메타 분해 (DDD Subdomain)
+
+대규모 요구사항을 DDD Subdomain 단위로 1차 분해해 sd-wbs 호출 단위를 정한다.
+
+DDD 전략 분해 기법(Eric Evans / Vlad Khononov / Nick Tune)을 따른다.
+비즈니스 컨텍스트(차별화 전략·조직 구조)를 토대로 문제 공간을 카테고리와 Subdomain 두 층으로 가르고, 각 Subdomain을 Core·Supporting·Generic으로 분류한다.
+산출물 `subdomain-map.md`는 사용자가 sd-wbs 호출 단위를 정할 때 참고하는 자료이고, sd-wbs가 자동으로 받아오지는 않는다.
+
+## What/How 경계
+
+이 스킬이 다루는 범위는 비즈니스 문제 공간을 어떻게 가를지(What)까지다.
+Bounded Context 설계, 솔루션 공간, 기술 스택은 sd-wbs와 sd-plan에 맡긴다.
+
+**여기서 반드시 확정한다 (다음 단계로 미루지 않는다):**
+
+- 카테고리와 Subdomain 1차 식별
+- Core/Supporting/Generic 분류와 그 근거
+- 차별화 점수, 복잡도 점수 (1~5)
+- Tune 패턴 (Decisive Core / Hidden Core / Suspect Supporting 등)
+- Subdomain 사이의 의존, 인접, 용어 충돌
+- 비즈니스 컨텍스트 안에서의 상대성
+
+**여기서는 다루지 않는다:**
+
+- Bounded Context 경계, 마이크로서비스 분리
+- 데이터베이스, API 형태, 통신 프로토콜
+- Activity / Task / Story 분해 (sd-wbs)
+- 기술 스택, 라이브러리 결정
+
+판단이 애매하면 What 쪽으로 본다.
+
+## 공통 규칙
+
+### 분해 원칙
+
+다음 분할은 절대 하지 않는다.
+
+| 분할 방식 | 왜 안 되는가 | 대신 |
+|---|---|---|
+| Sub-subdomain (3단 이상) | sd-wbs의 Activity·Task 영역까지 침범한다 | Subdomain 자체를 둘로 나눈다 |
+| 레이어 (Backend/Frontend/DB/관리자/사용자) | 솔루션 공간을 가르는 거지 문제 공간이 아니다 | 사용자 동작 단위로 본다 |
+| 액터별 (관리자/직원/고객) | 같은 도메인을 권한으로 쪼개면 응집이 깨진다 | Subdomain 안에서 액터를 표기한다 |
+| CRUD별 (Customer Create/Read/Update) | 한 도메인을 동작으로 쪼갠 거다 | 한 Subdomain으로 합친다 |
+| 잡탕 (`기타`/`공통`/`Utility`/`Common`) | 분해가 끝나지 않았다는 신호다 | 해체해서 어울리는 Subdomain에 흡수, 또는 Generic 인프라로 분리 |
+
+사용자가 위 분할을 직접 요청하더라도 그대로 따르지 않는다. DDD 관점으로 다시 해석해 문제 공간 단위로 가른다.
+
+추가 사례와 해소법은 `references/anti-patterns.md`(후속).
+
+### 분류 도구
+
+#### Khononov 결정 트리
+
+```
+Q1. 이 도메인을 시판 제품으로 갈아끼워도 경쟁 우위가 그대로인가?
+    예 → Generic
+    아니오 → Q2
+Q2. 비즈니스 로직이 단순한가? (CRUD 위주, 입력 검증 위주)
+    예 → Supporting
+    아니오 → Core
+```
+
+#### Tune 8 패턴
+
+| 패턴 | 특징 |
+|---|---|
+| Decisive Core | 매우 복잡 + 차별화 정점 |
+| Short-term Core | 차별화는 높지만 복잡도가 낮아 방어가 어렵다 |
+| Hidden Core | 복잡도는 낮지만 차별화 잠재력이 크다 |
+| Table Stakes Former Core | 한때는 혁신, 지금은 기본기 |
+| Commoditised Core | SaaS·OSS로 대체된 옛 코어 |
+| Black Swan Core | 예상 못 한 commodity가 코어로 부상 |
+| Big Bet Core | 차별화 잠재력은 미지수, 큰 투자가 필요 |
+| Suspect Supporting | Supporting인데 복잡도가 높다 — 숨은 Core일 수 있다 |
+
+#### 차별화·복잡도 점수
+
+- 차별화 (1~5): 비즈니스 경쟁 우위에 얼마나 기여하는가
+- 복잡도 (1~5): 모델 자체와 운영의 복잡도
+
+체크리스트와 점수 매기는 휴리스틱은 `references/classification-checklist.md`(후속).
+
+### 상대성
+
+분류는 절대값이 아니다. 같은 도메인이 한 곳에서는 Core, 다른 곳에서는 Generic이 될 수 있다.
+
+- Core나 Generic으로 분류한 모든 Subdomain은 *"이 비즈니스에서 ~ 이유로 X 분류"* 라고 근거를 적는다.
+- 분류 근거에는 모두 `[근거: ...]` 태그를 붙인다.
+
+### ID 형식
+
+- 카테고리: `1`, `2`, `3` ... (숫자만)
+- Subdomain: `1.1`, `1.2`, `2.1` ... (카테고리 번호 + `.` + 순번)
+- 분류는 ID 옆에 라벨로 표기한다 (예: `1.1 도서 대출 (Core)`).
+
+### sd-wbs 본체는 건드리지 않는다
+
+`subdomain-map.md`는 사용자 참고용이다.
+sd-wbs의 입력 시그니처를 바꾸지 않고, sd-subdomain이 sd-wbs를 자동으로 부르지도 않는다.
+사용자가 `subdomain-map.md`를 보고 *"카테고리 1로 wbs 만들어줘"* 또는 *"1.1 Subdomain만 wbs 만들어줘"* 같이 직접 부른다.
+
+## Step 1: 요구사항과 비즈니스 컨텍스트 파악
+
+요구사항과 비즈니스 컨텍스트(산업·차별화 전략·조직 구조)를 같이 살핀다.
+분류의 상대성을 잡으려면 컨텍스트부터 정리해야 한다.
+
+모든 항목은 `sd-clarify` 지침에 따라 명확화한다.
+
+### 입력 형태별 처리
+
+- 문서 파일(docx, xlsx, pdf 등)이 들어오면 `/sd-doc-extract`로 내용을 뽑아 분석한다.
+- 기존 `subdomain-map.md` 경로가 들어오고 수정 요청이면 그 문서를 읽어서 갱신한다.
+- 마이그레이션처럼 기존 시스템이 요구사항 출처일 때는 그 코드베이스를 보고 문제 공간을 파악한다.
+
+### 기존 subdomain-map.md 수정 시 보존 규칙
+
+- 기존 카테고리·Subdomain 번호, 사용자 메모, 이미 확정된 제외 사항은 임의로 초기화·삭제하지 않는다.
+- 번호를 바꿔야 한다면 옛 번호 → 새 번호 매핑과 변경 사유를 문서에 적는다.
+
+### 원본 완독
+
+- 첨부 파일, 메시지 본문, 메일 thread, 회의록 같은 원본은 끝까지 읽는다. 키워드 검색만으로 끝내지 않는다.
+- 자료별 분량(페이지·라인·통수)을 보고에 적어 부분 독해를 드러낸다.
+- 자료를 다 읽기 전에는 다음 단계로 넘어가지 않는다.
+
+### 비즈니스 컨텍스트 파악
+
+다음 항목을 명확히 정리한다 (분류의 상대성을 확보하기 위해서다).
+
+- 산업·시장 영역
+- 차별화 전략 (Core 분류의 기준이 된다)
+- 조직 구조·부서 (Khononov 휴리스틱 — 1차 컷의 시작점이 된다)
+- 이미 쓰고 있는 외부 솔루션·SaaS·OSS (Generic 후보를 미리 골라 둔다)
+
+## Step 2: Subdomain 1차 식별
+
+Step 1에서 정리한 컨텍스트를 바탕으로 Subdomain 후보를 거칠게 잡는다. 정련은 Step 3·4에서 한다.
+
+모든 항목은 `sd-clarify` 지침에 따라 명확화한다.
+
+### 1차 식별 방법
+
+- 조직도/부서 매핑 (Khononov 휴리스틱: *"subdomains correlated with organization units"*)
+- 사용자 활동을 묶었을 때 자연스럽게 응집되는 그룹
+- EventStorming pivotal events가 있다면 그 묶음
+
+### Subdomain 후보 작성 규칙
+
+각 후보에 다음을 같이 적는다.
+
+- 임시 이름
+- 1줄 설명 (이 도메인이 무엇을 다루는가)
+- 핵심 액터 (이해관계자·내부 사용자)
+- 인용 근거 (요구사항 출처, 사용자 답변 등)
+
+### 카테고리 가설
+
+응집도가 높은 Subdomain 묶음을 카테고리 가설로 둔다.
+카테고리는 Step 3·4를 거치며 정련될 수 있다.
+
+## Step 3: Subdomain 분류
+
+각 Subdomain을 Core/Supporting/Generic으로 분류하고 Tune 패턴까지 매핑한다.
+
+모든 항목은 `sd-clarify` 지침에 따라 명확화한다.
+
+### 3-1. Khononov 결정 트리 적용
+
+공통 규칙의 결정 트리를 각 Subdomain에 적용한다.
+
+### 3-2. 차별화·복잡도 점수
+
+차별화 점수(1~5)와 복잡도 점수(1~5)를 각 Subdomain에 매긴다.
+점수마다 `[근거: ...]` 태그를 붙인다.
+
+### 3-3. Tune 패턴 매핑
+
+차별화·복잡도 분포를 보고 Tune 8 패턴 가운데 하나를 고른다.
+특히 Suspect Supporting(Supporting인데 복잡도 4 이상)을 가려내 Step 5 자가검증의 재검토 대상에 둔다.
+
+### 3-4. 상대성 근거 명시
+
+Core나 Generic으로 분류한 모든 Subdomain에 상대성 근거를 적는다.
+
+- 형식: *"이 비즈니스가 ~ 산업에서 ~ 전략을 추구하므로 X 분류"*
+
+### 3-5. Vision Statement 작성 (Core만)
+
+Core Subdomain에는 Vision Statement를 한 줄로 적는다.
+
+- 형식: *"가치·존재 이유 한 줄 — 무엇이 차별화되는가, 사용자에게 어떤 가치를 주는가"*
+- Supporting/Generic은 1줄 설명만 두고 Vision은 적지 않는다.
+- Eric Evans의 *"Domain Vision Statement는 Core Domain의 가치와 책임을 짧게 적기 위한 것"* 정신을 따른다.
+
+작성 가이드는 `references/domain-vision-statement.md`(후속).
+
+## Step 4: Subdomain 관계 매핑
+
+Subdomain 사이의 의존·인접·용어 충돌을 정리한다. **Bounded Context 설계는 다루지 않는다.**
+
+모든 항목은 `sd-clarify` 지침에 따라 명확화한다.
+
+### 4-1. 의존성 매트릭스 (항상 작성)
+
+Subdomain 수가 적든 많든 의존성 매트릭스는 만든다. Subdomain이 한두 개뿐일 때도 한 줄짜리 매트릭스를 적는다.
+
+#### 의존성 판단 기준
+
+A의 산출물·결정·이벤트가 B에 영향을 줄 수 있으면 의존으로 등록한다.
+"코드끼리 import 안 한다"가 곧 "의존이 없다"는 아니다.
+의존이 없다는 근거를 댈 수 없으면 의존이 있다고 본다.
+
+#### 매트릭스 형식
+
+```
+| Subdomain | 의존 대상 | 의존 사유 |
+|---|---|---|
+| 1.1 | 없음 | (Bootstrap) |
+| 1.2 | 1.1 | 1.1의 회원 식별자를 쓴다 |
+| 2.1 | 1.1 | 1.1의 도서 식별자를 쓴다 |
+```
+
+#### 의존성 검증
+
+1. 의존이 `없음`인 Subdomain이 적어도 하나 있어야 한다 (1단계 시작점).
+2. A→B→A 같은 순환이 없어야 한다.
+3. 산출물·이벤트·결정의 영향 관계가 표에 빠짐없이 들어가 있는지 확인한다.
+
+### 4-2. 용어 충돌
+
+같은 용어가 두 Subdomain에서 다른 뜻으로 쓰이면 용어 충돌로 등록한다.
+해소는 sd-wbs/sd-plan에 맡긴다 (sd-subdomain은 등록까지만 한다).
+
+#### 형식
+
+```
+| 용어 | A 의미 | B 의미 | 처리 권고 |
+|---|---|---|---|
+| 주문 | (1.1 판매) 결제까지 끝난 주문 | (2.3 물류) 배송 대기 주문 | sd-wbs에서 어휘를 분리 |
+```
+
+매트릭스·용어 충돌 작성 가이드는 `references/subdomain-relations.md`(후속).
+
+## Step 5: 자가검증
+
+1차로 뽑은 결과를 메인 세션이 다음 6개 항목으로 점검한다. 한 건이라도 걸리면 `sd-clarify`로 명확화한 뒤 Step 2~4로 돌아간다.
+
+### 자가검증 항목
+
+1. **MECE 점검** — 두 Subdomain의 핵심 비즈니스 규칙이 같거나 강하게 겹치지 않는지. 겹치면 owner를 정하거나 한쪽으로 합친다.
+2. **분류 근거 누락** — 모든 Subdomain의 `타입`/`차별화 점수`/`복잡도 점수`에 `[근거: ...]` 태그가 붙어 있는지.
+3. **상대성 명시** — Core/Generic으로 분류한 모든 Subdomain에 상대성 근거가 적혀 있는지.
+4. **시작점 존재** — 의존이 `없음`인 Subdomain이 적어도 하나 있는지.
+5. **순환 의존** — A→B→A 순환이 없는지.
+6. **레이어/액터 분할 검출** — Subdomain 이름·설명·분해 기준에 `Backend`/`Frontend`/`Admin`/`User`가 분류 기준으로 들어가면 위반. 사용자 동작 단위로 다시 가른다.
+
+## Step 6: subdomain-map.md 작성, 격리 검증, 수행 순서 안내
+
+### 6-1. subdomain-map.md 작성
+
+산출 경로:
+
+- 입력이 이미 `.tasks/` 안의 문서라면 같은 폴더에 둔다 (예: `.tasks/260411_some-project/subdomain-map.md`).
+- 그 외에는 `.tasks/{timestamp}_{topic}/subdomain-map.md`.
+  - `{timestamp}`: `date +%y%m%d%H%M%S` 결과
+  - `{topic}`: 영어 kebab-case (예: `library-system`)
+
+#### 문서 템플릿
+
+```markdown
+# Subdomain Map: {프로젝트 한 줄 요약}
+
+## 프로젝트 개요
+
+- **비즈니스 컨텍스트:** [산업·차별화 전략]
+- **조직 구조:** [부서·팀 구조]
+- **이미 쓰고 있는 외부 솔루션:** [Generic 후보를 미리 골라 둔 결과]
+- **배경:** [왜 이 분해가 필요한가]
+- **참조 자료:** [원본 자료 경로 — 항목마다 확인 목적을 적는다]
+
+## 비즈니스 비전 (선택)
+
+[Eric Evans Domain Vision Statement — Core가 무엇이고 어떤 가치를 주는지 한 문단]
+
+## Subdomain 분해
+
+### 1. {카테고리 이름}
+
+#### 1.1 {Subdomain 이름} (Core)
+
+- **Vision:** [가치·존재 이유 한 줄 — Core만]
+- **1줄 설명:** [무엇을 다루는가]
+- **핵심 액터:** [이해관계자·내부 사용자]
+- **핵심 비즈니스 규칙:** [차별화 포인트 3~5개]
+- **차별화 점수:** 5/5 [근거: ...]
+- **복잡도 점수:** 4/5 [근거: ...]
+- **Tune 패턴:** Decisive Core
+- **상대성 근거:** [이 비즈니스에서 Core인 이유]
+- **인접 Subdomain:** 1.2, 2.1
+- **분류 근거:** [근거: ...]
+
+#### 1.2 {Subdomain 이름} (Supporting)
+
+- **1줄 설명:** [무엇을 다루는가]
+- **핵심 액터:** ...
+- **핵심 비즈니스 규칙:** ...
+- **차별화 점수:** 2/5 [근거: ...]
+- **복잡도 점수:** 3/5 [근거: ...]
+- **Tune 패턴:** (해당 없음 또는 Suspect Supporting)
+- **인접 Subdomain:** 1.1
+- **분류 근거:** [근거: ...]
+
+### 2. {카테고리 이름}
+
+#### 2.1 {Subdomain 이름} (Generic)
+
+- **1줄 설명:** ...
+- **외부 솔루션 후보:** [SaaS·OSS — 빌드 vs 바이 결정의 출발점]
+- **핵심 액터:** ...
+- **차별화 점수:** 1/5 [근거: ...]
+- **복잡도 점수:** 2/5 [근거: ...]
+- **상대성 근거:** [이 비즈니스에서 Generic인 이유]
+- **인접 Subdomain:** 1.1
+- **분류 근거:** [근거: ...]
+
+## 의존성 매트릭스
+
+| Subdomain | 의존 대상 | 의존 사유 |
+|---|---|---|
+| 1.1 | 없음 | (Bootstrap) |
+| 1.2 | 1.1 | 1.1의 회원 식별자를 쓴다 |
+| 2.1 | 1.1 | 1.1의 도서 식별자를 쓴다 |
+
+## 용어 충돌
+
+| 용어 | A 의미 | B 의미 | 처리 권고 |
+|---|---|---|---|
+| 주문 | (1.1) 결제까지 끝난 주문 | (2.3) 배송 대기 주문 | sd-wbs에서 어휘 분리 |
+
+## 격리 검증 결과
+
+[Step 6-2 subagent 보고 요약 — 누락·근거 없는 추가·Suspect Supporting·잡탕 Subdomain·상대성 미명시 항목]
+
+## 제외 사항
+
+- {제외 항목} — 사유: ... / 출처: ... / 재검토 조건: ...
+
+## 수행 순서 안내
+
+[Step 6-3 — 호출 단위 판단 기준 + 의존성 기반 단계별 묶음]
+```
+
+**제외 사항 작성 규칙:**
+
+- 사용자가 "이건 빼겠다"고 한 도메인, 그리고 차별화 전략과 연결되지 않는 도메인을 모은다.
+- 항목마다 `제외 항목 — 사유: ... / 출처: ... / 재검토 조건: ...` 형식으로 적는다.
+- 사유는 `차별화 미연결`, `사용자 명시 제외`, `범위 초과` 가운데 하나를 고른다. `미확정`은 사유로 쓰지 않는다.
+
+### 6-2. 격리 검증
+
+알아서 생략하지 않는다. 자체 요약 텍스트로 대체하지 않는다. 반드시 Agent tool을 호출한다.
+
+문서를 다 만든 뒤, 작성자 편향을 걷어내고 빠진 정보를 잡기 위해 메인 세션과 분리된 subagent로 격리 검증을 돌린다.
+
+#### 검증 호출
+
+subagent (effort: `low`)에 다음을 넘긴다:
+
+- **subdomain-map.md 절대 경로** — 검증 대상
+- **원본 자료 절대 경로 목록** — 첨부 파일(docx/xlsx/pdf 등). `/sd-doc-extract`로 뽑아 둔 파일이 있다면 같이 넘긴다.
+- **사용자가 처음에 보낸 요청 메시지 본문** — 프롬프트에 인라인으로 박는다.
+
+subagent에는 한 가지 제약을 건다: "보고만 한다. subdomain-map.md는 수정하지 않는다."
+
+#### subagent 프롬프트에 들어갈 검증 가이드
+
+##### 검증 항목
+
+1. **양방향 커버리지 (정량 매핑 표)** — 원본에서 뽑은 비즈니스 활동·도메인 어휘·이해관계자가 카테고리·Subdomain에 매핑되어 있는지.
+   - 뽑을 카테고리: 비즈니스 활동 / 도메인 어휘 / 이해관계자(액터) / 외부 솔루션·SaaS / 차별화 전략 / 정책·규제
+   - 누락: 원본에는 있는데 매핑이 안 된 항목
+   - 근거 없는 추가: subdomain-map에는 있는데 원본·근거에서 추적이 안 되는 항목
+2. **Suspect Supporting 검출** — Supporting인데 복잡도가 4 이상이면 숨은 Core일 가능성을 보고한다.
+3. **차별화 전략 역추적** — 차별화 전략 항목이 Core Subdomain까지 연결되는지. 연결이 안 되면 차별화 전략을 빠뜨렸거나 Core 분류를 빠뜨린 것이다.
+4. **잡탕 Subdomain 검출** — `기타`/`공통`/`Utility`/`Common`/`Misc` 같은 catch-all 이름은 해체 권고.
+5. **상대성 미명시** — Core/Generic인데 *"이 비즈니스에서 ~ 이유"* 가 빠진 항목.
+
+##### 완독 의무
+
+원본 자료(첨부 파일·인라인 요청 메시지)는 끝까지 읽는다. 키워드 검색만으로 끝내지 않는다.
+
+##### 출력 포맷
+
+- **요약** — 원본 항목 수 / 매핑·누락·근거 없는 추가·Suspect Supporting·잡탕·상대성 미명시 (각 정수)
+- **정량 매핑 표** — 컬럼: `원본 표현` / `출처(자료명·위치)` / `subdomain-map 반영 위치` / `subdomain-map 표현` (반영 위치가 비면 누락이다)
+- **항목별 목록** — 각 검증 항목의 발견 건. 출처·권장 반영 위치·권장 처리 방향을 적는다.
+  - 누락: "Subdomain X.Y에 추가" / "제외 사항으로 등록"
+  - 근거 없는 추가: "근거 보강" / "삭제"
+  - Suspect Supporting: "Core 재검토" / "복잡도 근거 보강"
+  - 잡탕 Subdomain: "해체해 어울리는 Subdomain에 흡수" / "Generic 인프라로 분리"
+  - 상대성 미명시: *"이 비즈니스에서 ~ 이유"* 명시
+
+#### 메인이 결과를 처리하는 방식
+
+1. 결과 항목은 모두 `sd-clarify` 지침에 따라 명확화한다.
+2. 카테고리·Subdomain 구조 자체를 다시 짜야 하면 Step 2~4 해당 단계로 돌아간다.
+
+각 sd-wbs 호출은 새 세션에서 진행되니, subdomain-map.md에 빠진 정보가 있어서는 안 된다.
+
+### 6-3. 수행 순서 안내
+
+문서 작성과 격리 검증이 끝나면 사용자에게 sd-wbs 호출 가이드를 보여 준다.
+
+- 호출 단위 판단 기준을 한 줄로 적는다.
+  - 카테고리 통째로: 응집도가 높고 카테고리 안 Subdomain이 2~3개로 적을 때
+  - Subdomain 하나씩: 카테고리가 크고 Subdomain이 4개 이상이거나, Subdomain마다 따로 wbs가 필요할 때
+- 의존성 매트릭스를 바탕으로 단계별 묶음을 적는다.
+  - 의존이 `없음`인 Subdomain (Bootstrap)을 1단계로
+  - 그 앞 단계에만 의존하는 Subdomain을 다음 단계로
+
+#### 안내 형식
+
+```
+1단계 (병렬 가능)
+  - 1.1 도서 대출 (Core)
+  - 2.1 회원 가입 (Supporting)
+
+2단계 (1단계 완료 후)
+  - 1.2 도서 예약 (Core, ← 1.1)
+  - 3.1 결제 (Generic, ← 2.1)
+```
+
+호출 명령은 사용자가 자기 말로 `subdomain-map.md`를 가리키며 sd-wbs를 직접 부른다.
+이 스킬이 sd-wbs를 자동으로 부르지는 않는다.

package/claude/skills/sd-use/SKILL.md

@@ -61,7 +61,6 @@ SKILLS
   문서
     sd-claude-docs      CLAUDE.md + usage 문서 생성
     sd-doc-extract      문서에서 텍스트/이미지 추출
-    sd-deliverable      매뉴얼 & SIT 문서 생성
 
   도구
     sd-prompt           스킬/프롬프트 파일 생성·개선

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simplysm/sd-claude",
-  "version": "14.0.62",
+  "version": "14.0.64",
   "description": "심플리즘 패키지 - Claude Code 셋업",
   "author": "심플리즘",
   "license": "Apache-2.0",