@decencia/ch-cli 1.3.6 → 1.5.0

package/skill/2t-decencia-channel-db-schema-v2/SKILL.md

@@ -0,0 +1,313 @@
+---
+name: 2t-decencia-channel-db-schema-v2
+description: |
+  [2t][v2] 소통채널 DB 스키마 운영 가이드 — 전체 스펙 문서(/db-schema)와 per-table 리소스(/db-tables)를 함께 다룬다.
+  데이터 모델 개요·ERD·정책은 전체 문서에, 컬럼·인덱스·보안규칙은 테이블별 문서에 저장.
+  Use when:
+  (1) 프로젝트 전체 DB 설계 문서(ERD/네이밍/마이그레이션 노트)를 작성·갱신할 때,
+  (2) DB 테이블 단위로 컬럼·인덱스·보안규칙을 등록·수정할 때,
+  (3) 새 테이블을 추가하면서 전체 인벤토리도 함께 업데이트할 때,
+  (4) spec.dbTableRefs와 양방향 동기화가 필요한 작업 시.
+version: 1.5.0
+---
+
+<!-- ch-version-gate -->
+## ⚠️ 시작 전 필수 — 버전 게이트 (생략 금지)
+
+이 스킬로 **어떤 작업이든 수행하기 전에 가장 먼저** 아래를 실행한다:
+
+```bash
+ch check
+```
+
+- exit code 0(통과)이 **아니면 즉시 중단**한다. 출력에 안내된 업데이트 명령(`npm install -g @decencia/ch-cli@latest` 또는 `ch setup-skill`)을 사용자에게 전달하고, 갱신이 끝나기 전까지 **이 스킬의 어떤 단계도 진행하지 않는다.**
+- `ch`가 미설치/미인증이어도 먼저 `ch check`를 시도한다. (네트워크 불가 시 ch check는 통과시키되 경고를 남긴다.)
+
+구버전 스킬·CLI 사용을 막기 위한 게이트다. 건너뛰지 말 것.
+
+
+# DB 스키마 — 전체 스펙 + per-table 분담
+
+소통채널은 두 개의 리소스를 함께 운영한다.
+
+| 리소스 | CLI | 저장 단위 | 담당 |
+|---|---|---|---|
+| **전체 스펙 문서** (`/db-schema`) | `ch db-schema get/set/versions` | 프로젝트당 **마크다운 1건** | 데이터 모델 개요·ERD·테이블 인벤토리·네이밍·마이그레이션 노트 |
+| **테이블 문서** (`/db-tables/{tableId}`) | `ch db-tables list/get/create/update/delete` | 테이블당 **JSON 1건** | 컬럼 정의·인덱스·보안 규칙·역할 매트릭스 |
+
+> 둘은 보완 관계다. 전체 스펙 문서는 **읽는 사람을 위한 설계 의도**, 테이블 문서는 **기계가 검증·동기화할 수 있는 정형 데이터**.
+
+---
+
+## 🚨 BLOCKING: Read-before-Write
+
+```bash
+# 전체 스펙 문서
+ch db-schema get --json > /tmp/schema.json   # 먼저
+# content 편집
+ch db-schema set --content /tmp/schema.md --dbtype firestore
+
+# 테이블 문서
+ch db-tables get <tableId> --json > /tmp/tbl.json
+ch db-tables update <tableId> --columns /tmp/cols.json
+```
+
+`--content` 통째 교체, `--columns/--indexes/--security` 각각 통째 교체. 기존 내용 보존하려면 반드시 `get` 후 편집.
+
+---
+
+## 1. DB 유형 판별 (작성 전 필수)
+
+| dbType | 대상 | 판단 단서 |
+|---|---|---|
+| **firestore** | Firebase Firestore | 코드에 `firebase-admin`, `firebase/firestore` |
+| **supabase** | Supabase / Postgres | `@supabase/supabase-js`, `pg` |
+| **mysql** | MySQL / MariaDB | `mysql2`, `prisma` (mysql provider) |
+| **generic** | 미정 또는 혼합 | 위 어느 것도 아닐 때 |
+
+`ch db-schema set --dbtype <type>` 로 명시. 미정이면 `generic`. DB 유형에 따라 컬럼 `type` 값·보안 규칙 `type` 값이 달라진다.
+
+---
+
+# Part A — 전체 스펙 문서 (`ch db-schema`)
+
+## 2. 전체 스펙 문서 구조
+
+마크다운 한 덩어리. 권장 목차:
+
+```markdown
+# {프로젝트명} DB 스키마
+
+## 1. 개요
+- DB 유형: firestore
+- 호스팅: Firebase (asia-northeast3)
+- 백업 정책: daily, 14d retention
+- 멀티테넌시: 단일 테넌트
+
+## 2. 설계 원칙
+- 비정규화 우선 (read-heavy 워크로드)
+- 모든 문서에 createdAt/updatedAt/deletedAt 필수
+- 소프트 삭제 (deletedAt = serverTimestamp())
+- 시간 필드는 timestamp 타입 통일
+- 통화는 number(원 단위), 분수 없음
+
+## 3. 네이밍 규칙
+- 컬렉션/테이블: 영문 소문자 복수형 (`users`, `orders`)
+- 필드: lowerCamelCase
+- 인덱스: `idx_{컬럼명}` / 복합은 `idx_{a}_{b}` / unique는 `_unique` 접미
+- ID: 모두 string (Firestore document ID 자동 생성 또는 UUID v4)
+
+## 4. 테이블 인벤토리
+
+| 이름 | tableId | 설명 | 핵심 키 | spec |
+|---|---|---|---|---|
+| users    | tbl_users    | 회원 기본정보 | id (uid) | [spec:로그인], [spec:회원가입] |
+| sessions | tbl_sessions | 로그인 세션  | id, userId | [spec:로그인] |
+| orders   | tbl_orders   | 주문 내역     | id, userId | [spec:주문] |
+| products | tbl_products | 상품 카탈로그 | id | [spec:상품 목록] |
+
+> 각 tableId의 컬럼·인덱스·보안규칙 상세는 `ch db-tables get <id>` 또는 웹의 DB 스키마 탭 참조.
+
+## 5. ERD (관계도)
+
+```
+users (1) ──< sessions (N)
+users (1) ──< orders (N)
+orders (N) >── products (1)  // 비정규화: orders.productName 캐시
+```
+
+또는 mermaid:
+
+\```mermaid
+erDiagram
+  USERS ||--o{ SESSIONS : has
+  USERS ||--o{ ORDERS : places
+  ORDERS }o--|| PRODUCTS : refers
+\```
+
+## 6. 정규화 / 비정규화 정책
+- `orders.productName` ← `products.name` 캐시 (상품명 변경 시 batch 갱신)
+- `orders.userDisplayName` ← `users.displayName` 캐시
+- 캐시 필드는 모두 `// denormalized from X` 주석 (테이블 문서의 description에)
+
+## 7. 보안 일관성 원칙
+- 모든 테이블에 admin 역할이 read/write/delete 전권
+- 일반 사용자는 본인 문서만 R/W (Firestore: `request.auth.uid == uid` 패턴)
+- 공개 컬렉션(예: products)은 read 전체 허용, write는 admin만
+
+## 8. 마이그레이션 노트
+- 2026-05-29: `users.lastLoginAt` 추가 (기존 문서는 backfill 안 함, null 허용)
+- 2026-04-10: `orders` 컬렉션 생성, products와 연결
+- 2026-03-01: 초기 스키마 v1 (users만)
+
+## 9. 운영 메모
+- Firestore 쿼리 1초 이상 시 인덱스 점검
+- 대량 삭제는 batch 500 단위로 분할
+```
+
+## 3. 작성·갱신 워크플로우 (전체 스펙)
+
+### 3-1. 신규 프로젝트 — 처음 작성
+
+```bash
+# 1) 위 §2 템플릿 기반으로 schema.md 작성 (테이블 인벤토리는 비어있는 상태로 시작)
+# 2) 업로드
+ch db-schema set --content schema.md --dbtype firestore
+ch db-schema get --json | jq '.content' | head        # 검증
+```
+
+### 3-2. 새 테이블 추가 시 — 두 곳 동기화
+
+```bash
+# 1) 테이블 문서부터 생성 (Part B 참조)
+ch db-tables create --name orders --description "주문" \
+  --columns ./orders-cols.json --indexes ./orders-idx.json --security ./orders-sec.json
+# → {"id": "tbl_orders_abc"}
+
+# 2) 전체 스펙 문서의 §4 테이블 인벤토리 + §5 ERD에 orders 추가
+ch db-schema get --json | jq -r '.content' > /tmp/schema.md
+# /tmp/schema.md 편집: 인벤토리에 행 추가, ERD에 관계 추가
+ch db-schema set --content /tmp/schema.md
+```
+
+> 테이블 생성/삭제할 때마다 전체 스펙 문서의 인벤토리·ERD·마이그레이션 노트를 함께 갱신한다.
+
+### 3-3. 정책 변경 — 전체 스펙에만 기록
+
+설계 원칙·네이밍·보안 일관성은 전체 스펙 문서에만 적는다. 개별 테이블의 securityRules.content와 충돌하지 않도록 정책은 한 곳에 통합.
+
+---
+
+# Part B — 테이블 문서 (`ch db-tables`)
+
+## 4. CLI 명령
+
+```bash
+ch db-tables list                                # 표: name | id | columns | indexes | security | specs
+ch db-tables get <tableId> --json
+ch db-tables create --name users --description "회원" \
+  --columns ./columns.json --indexes ./indexes.json --security ./security.json
+ch db-tables update <tableId> --security ./new-security.json
+ch db-tables delete <tableId>                    # 참조 spec의 dbTableRefs도 서버에서 자동 정리
+```
+
+`relatedSpecIds`는 사용자 입력 금지(서버 자동 관리).
+
+## 5. JSON 템플릿
+
+### 5-1. columns.json — DB 종류별 type 명세
+
+| DB 종류 | type 예 |
+|---|---|
+| **Firestore** | `string`, `number`, `boolean`, `timestamp`, `map`, `array`, `reference` |
+| **Supabase / Postgres** | `text`, `int8`, `numeric`, `boolean`, `timestamptz`, `jsonb`, `uuid` |
+| **MySQL** | `VARCHAR(255)`, `INT`, `DATETIME`, `JSON`, `TEXT` |
+| **Generic** | 자유 문자열 (`string` 등) |
+
+```json
+[
+  {"name": "id",        "type": "string",    "nullable": false, "description": "PK"},
+  {"name": "email",     "type": "string",    "nullable": false, "description": "로그인 이메일"},
+  {"name": "displayName", "type": "string",  "nullable": true,  "description": "표시명"},
+  {"name": "userId",    "type": "string",    "nullable": false, "description": "FK → users.id"},
+  {"name": "userDisplayName", "type": "string", "nullable": true, "description": "denormalized from users.displayName"},
+  {"name": "createdAt", "type": "timestamp", "nullable": false, "default": "serverTimestamp()"},
+  {"name": "deletedAt", "type": "timestamp", "nullable": true,  "description": "소프트 삭제"}
+]
+```
+
+description 활용 권장:
+- `PK` / `FK → table.col` 명시
+- 비정규화 캐시는 `denormalized from X` 적어 두면 ERD 단방향 추적 가능
+- enum이라면 허용값 나열 (`role: "admin" | "user"`)
+
+### 5-2. indexes.json
+
+```json
+[
+  {"name": "idx_email_unique", "fields": ["email"], "unique": true},
+  {"name": "idx_userId_created", "fields": ["userId", "createdAt"]},
+  {"name": "idx_deletedAt", "fields": ["deletedAt"]}
+]
+```
+
+규칙:
+- 자주 필터 + 정렬 쌍은 복합 인덱스 (`["userId", "createdAt"]`)
+- 소프트 삭제 사용 시 `deletedAt` 단일 인덱스 (살아있는 문서만 빠른 쿼리)
+- Firestore는 복합 인덱스가 자동 안 만들어지는 케이스가 많아 명시 권장
+
+### 5-3. security.json — 보안 규칙 + 역할 매트릭스
+
+`type` 옵션: `firestore` | `rls` (Supabase RLS) | `sql-grant` | `generic`
+
+```json
+{
+  "type": "firestore",
+  "summary": "본인만 R/W, admin은 전권",
+  "content": "match /users/{uid} {\n  allow read, write: if request.auth.uid == uid;\n  allow read, write: if request.auth.token.admin == true;\n}",
+  "roles": [
+    {"role": "admin", "read": true,  "write": true,  "delete": true},
+    {"role": "user",  "read": "own", "write": "own", "delete": false}
+  ]
+}
+```
+
+`read/write/delete`는 `true | false | 문자열 조건(예: "own", "auth.uid == doc.userId")` 자유 입력.
+
+### 5-4. 테이블 단위 작성 체크리스트
+
+- [ ] 모든 PK/FK가 columns에 명시되어 있는가
+- [ ] 시간 필드(createdAt/updatedAt/deletedAt) 컨벤션 준수
+- [ ] 비정규화 캐시는 description에 출처 명시
+- [ ] 보안 규칙의 roles 매트릭스가 실제 content와 일치
+- [ ] 자주 쓰는 쿼리에 맞는 인덱스 있음
+- [ ] 전체 스펙 문서 §4 인벤토리에도 등록되었는가
+
+---
+
+## 6. spec ↔ db-table 양방향 동기화
+
+- `spec.dbTableRefs`에 tableId 추가 → 서버가 해당 테이블의 `relatedSpecIds`에 specId 자동 add (batch)
+- spec 삭제 → 모든 테이블에서 정리
+- db-table 삭제 → 참조 spec의 `dbTableRefs`에서 정리
+
+웹: 칩 X 또는 picker로 변경. 모두 ch-api PATCH 경유.
+
+전체 스펙 문서 §4 인벤토리의 "spec" 컬럼은 수동 갱신 — 양방향 동기화는 정형 데이터(테이블 문서)에만 동작한다.
+
+---
+
+## 7. 웹 UI 흐름
+
+- 프로젝트 메뉴 → **DB 스키마** 탭
+  - **"문서" 서브탭** → 전체 스펙 문서(마크다운) 표시 / 편집
+  - **"테이블" 서브탭** → db-tables 목록 + 상세 패널
+- spec 상세의 "연관 DB 테이블" 섹션:
+  - **칩 클릭** → DbTableModal (컬럼·인덱스·보안규칙·역할·연관 명세 표시 + 전체 보기 링크)
+  - **칩 X 버튼** → 즉시 해제
+  - **+ 버튼** → DbTablePicker 모달 (체크박스 다중 선택)
+
+---
+
+## 8. 흔한 함정
+
+- columns/indexes/securityRules JSON은 **전체 교체**. 일부 수정 시 반드시 `get` 후 편집.
+- 전체 스펙 문서의 `--content`도 통째 교체. 작은 수정도 `get` 후 부분 편집해 통째 전송.
+- `relatedSpecIds`를 JSON에 명시해도 서버가 무시 (자동 관리 영역).
+- 새 테이블을 만들고 전체 스펙 인벤토리 갱신을 잊으면, 문서 읽는 사람이 그 테이블의 존재를 모른다.
+- 보안 정책을 테이블별 securityRules에만 적고 전체 스펙의 §7에 적지 않으면 일관성 검토가 누락된다.
+- ERD 관계를 그리지 않고 column description의 "FK"만 적으면, 신규 개발자가 전체 구조를 파악하기 어렵다.
+
+---
+
+## 9. 작업 순서 체크리스트
+
+신규 프로젝트의 DB를 처음 설계할 때:
+
+1. DB 유형 확정 → `ch db-schema set --dbtype firestore` 등
+2. 전체 스펙 문서 초안 (§1 개요 / §2 설계 원칙 / §3 네이밍 규칙 / §7 보안 일관성) 작성
+3. 핵심 테이블 1~2개를 `ch db-tables create`로 등록 (users 먼저)
+4. 전체 스펙 §4 인벤토리에 추가, §5 ERD에 노드 추가
+5. spec 작성 시 `--db-tables tbl_id`로 연결 → 양방향 동기화 자동
+6. 새 테이블이 늘 때마다 §2(테이블 문서) + §4·§5(전체 스펙) 동시 갱신
+7. 분기/릴리즈마다 §8 마이그레이션 노트 한 줄 추가

package/skill/2t-decencia-channel-github-issue/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: 2t-decencia-channel-github-issue
+description: gh CLI로 현재 repo에 GitHub 이슈를 작성한다. 이슈 1개=유형 1개(feat/fix/bug), 표준 본문 양식(작업내용·관련 명세 백링크·완료조건)으로 발행. "이슈 만들어줘"/"깃헙 이슈로 등록해줘" 요청 시, 또는 소통채널 기획·명세 작업 후 처리할 일들을 GitHub 이슈로 옮길 때 사용. 멱등성/중복방지·확인단계는 다루지 않음(요청대로 바로 생성).
+allowed-tools: Bash(gh:*) Bash(git:*) Read Write
+version: 1.5.0
+---
+
+<!-- ch-version-gate -->
+## ⚠️ 시작 전 필수 — 버전 게이트 (생략 금지)
+
+이 스킬로 **어떤 작업이든 수행하기 전에 가장 먼저** 아래를 실행한다:
+
+```bash
+ch check
+```
+
+- exit code 0(통과)이 **아니면 즉시 중단**한다. 출력에 안내된 업데이트 명령(`npm install -g @decencia/ch-cli@latest` 또는 `ch setup-skill`)을 사용자에게 전달하고, 갱신이 끝나기 전까지 **이 스킬의 어떤 단계도 진행하지 않는다.**
+- `ch`가 미설치/미인증이어도 먼저 `ch check`를 시도한다. (네트워크 불가 시 ch check는 통과시키되 경고를 남긴다.)
+
+구버전 스킬·CLI 사용을 막기 위한 게이트다. 건너뛰지 말 것.
+
+
+# 2t-decencia-channel-github-issue — GitHub 이슈 작성 스킬
+
+`gh` CLI로 **현재 repo**에 이슈를 작성한다.
+이 스킬의 본질은 **"이슈에 들어갈 내용 양식 + gh로 쏘는 방법"** 가이드다.
+
+핵심 원칙:
+- **이슈 1개 = 유형 1개** (`feat` | `fix` | `bug`) — 라벨로 표시.
+- 일괄 발행 가능(여러 이슈 = 양식대로 반복). 단건도 당연히 포함.
+- **멱등성/중복방지·dry-run·확인단계는 다루지 않는다.** 요청받은 이슈를 그냥 생성한다.
+
+## Use when
+- "이슈 만들어줘", "깃헙 이슈로 등록해줘"
+- 소통채널 기획/명세 작업 후 처리할 일을 깃헙 이슈로 발행할 때
+
+---
+
+## 0. 전제 (시작 시 확인)
+
+1. **gh 인증**
+   ```bash
+   gh auth status
+   ```
+   실패하면 진행하지 말고 안내: `gh auth login` 을 먼저 실행하세요.
+
+2. **repo**: cwd의 git `origin` 을 `gh` 가 자동 인식한다(별도 지정 불필요).
+   다른 repo에 쏘려면 각 `gh issue create` 에 `--repo <owner>/<name>` 추가.
+
+3. **라벨 보장** (없으면 생성 — 이미 있으면 무시):
+   ```bash
+   gh label create feat --color 0e8a16 --description "새 기능" 2>/dev/null || true
+   gh label create fix  --color 1d76db --description "의도된 동작 변경" 2>/dev/null || true
+   gh label create bug  --color d73a4a --description "결함/회귀" 2>/dev/null || true
+   ```
+
+---
+
+## 1. 유형 정의 + 작업내용 작성법
+
+| 유형 | 의미 | 작업내용 작성법 |
+|------|------|----------------|
+| **feat** | 새로 구현 | 무엇을 구현해야 하는지 |
+| **fix**  | **의도된** 동작 변경 | 현재 X → Y 로 변경해야 한다 |
+| **bug**  | **의도치 않은** 결함/회귀 | 어떤 작업을 수행하는 과정에서 어떤 문제가 생기는지 (재현 / 기대 동작) |
+
+> fix vs bug: 의도적으로 바꾸는 거면 `fix`, 하다가 터진 거면 `bug`.
+
+---
+
+## 2. 이슈 양식
+
+- **제목**: `<유형>: <한 줄 요약>`  (예: `feat: 로그인 자동완성 추가`)
+- **라벨**: 유형 1개
+- **본문 템플릿**(마크다운):
+
+```markdown
+## 작업내용
+<위 표의 유형별 가이드대로 구체적으로>
+
+## 관련 명세
+- [LOGIN-001](https://channel.decenciasoft.com/projects/<projectId>/specs)
+- [USER-003](https://channel.decenciasoft.com/projects/<projectId>/specs)
+
+## 완료조건
+- [ ] <무엇이 되면 done 인지>
+- [ ] ...
+```
+
+- **관련 명세(specid)**:
+  - `projectId` 는 cwd(또는 상위)의 `.ch-project` 파일에서 읽는다(`{"projectId": "..."}`). 없으면 사용자에게 묻거나 링크 없이 specid만 적는다.
+  - specid가 **비어 있으면 "관련 명세" 섹션 전체를 생략**한다(허용).
+- **완료조건(AC)**: 개발자가 "뭐가 되면 done"인지 알도록 체크리스트로.
+
+---
+
+## 3. 발행 (Procedure)
+
+1. 위 0번 전제(인증·라벨) 확인.
+2. 발행할 이슈 목록을 양식대로 구성(제목·유형·작업내용·관련명세·완료조건).
+3. 본문은 **파일로 저장 후 `--body-file`** 로 전달한다(따옴표·줄바꿈·한글 안전, Windows에서는 **LF 줄바꿈** 사용 — CRLF 주의).
+   ```bash
+   # 본문을 임시파일에 작성 (LF)
+   gh issue create --title "feat: 로그인 자동완성 추가" \
+                   --body-file /tmp/issue-body.md \
+                   --label feat
+   ```
+4. 여러 이슈면 3을 **반복**한다.
+5. 생성된 이슈 URL을 모아 사용자에게 보고한다.
+
+---
+
+## 주의
+- `--body "..."` 직접 인라인은 따옴표/줄바꿈/한글 깨짐 위험 → `--body-file` 권장.
+- 라벨 미존재 시 `gh issue create --label` 은 실패하므로 0-3번(라벨 보장)을 반드시 선행.
+- 이 스킬은 **중복 검사/되돌리기를 하지 않는다.** 재실행하면 같은 이슈가 또 생길 수 있으니, 호출 측(에이전트/사용자)이 무엇을 발행할지 판단한다.

package/skill/2t-decencia-channel-orchestrator/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: 2t-decencia-channel-orchestrator
+description: 소통채널 작업의 단일 진입점(디스패처). 사용자 요청을 듣고 6종(bootstrap·terraformer·change-manager·github-issue·issue-coder·pr-merger) 중 적절한 곳으로 라우팅하고, 필요하면 여러 단계를 순차 오케스트레이션한다. 대화형 스킬은 메인 세션에서 Skill로, 자율 에이전트는 Agent로 위임. "소통채널 작업 해줘"·"이거 어떻게 처리하지?"처럼 무엇부터 할지 모를 때, 또는 신규기획/코드편입/기획변경/이슈/구현/머지 어디로든 시작할 때.
+allowed-tools: Skill Agent Read Bash(ch:*) Bash(gh:*) Bash(git:*)
+version: 1.5.0
+---
+
+<!-- ch-version-gate -->
+## ⚠️ 시작 전 필수 — 버전 게이트 (생략 금지)
+
+이 스킬로 **어떤 작업이든 수행하기 전에 가장 먼저** 아래를 실행한다:
+
+```bash
+ch check
+```
+
+- exit code 0(통과)이 **아니면 즉시 중단**한다. 출력에 안내된 업데이트 명령(`npm install -g @decencia/ch-cli@latest` 또는 `ch setup-skill`)을 사용자에게 전달하고, 갱신이 끝나기 전까지 **이 스킬의 어떤 단계도 진행하지 않는다.**
+- `ch`가 미설치/미인증이어도 먼저 `ch check`를 시도한다. (네트워크 불가 시 ch check는 통과시키되 경고를 남긴다.)
+
+구버전 스킬·CLI 사용을 막기 위한 게이트다. 건너뛰지 말 것.
+
+
+# 2t-decencia-channel-orchestrator — 소통채널 작업 디스패처
+
+소통채널 관련 요청의 **단일 진입점**. 사용자 의도를 분류해 아래 6종 중 알맞은 것으로 보내고, 여러 단계가 필요하면 **순차 오케스트레이션**한다.
+이 스킬은 라우터다 — 실제 작업 디테일은 각 스킬/에이전트가 가지고 있으니 **중복 서술하지 않고 위임만** 한다.
+
+## 핵심 규칙
+- **대화형 = `Skill`로 메인 세션 실행** / **자율 = `Agent`로 위임**. (대화형을 서브에이전트로 던지면 turn-by-turn 대화가 안 됨)
+- **모호하면 1개 질문으로 확정** 후 라우팅 — 잘못 보내면 비싸다.
+- 연쇄 작업(예: "코드 편입하고 스프린트까지")이면 **한 단계 끝나면 다음으로** 순차 진행.
+
+## 라우팅 표
+
+| # | 사용자 의도 (신호) | 대상 | 종류 | 호출 |
+|---|---|---|---|---|
+| 1 | **새 아이디어/기획을 처음부터** ("새 프로젝트", 코드·문서 둘 다 없음) | `2t-decencia-channel-project-bootstrap` | 스킬(대화형) | `Skill` |
+| 2 | **기존 코드는 있는데 소통채널 문서 0** ("이 레포 편입/온보딩", 코드 O·`.ch-project` X) | `2t-decencia-channel-terraformer` | 에이전트(자율) | `Agent` |
+| 3 | **기존 기획을 변경/추가/수정** (문서 전파 + 새 할일 이슈까지) | `2t-decencia-channel-change-manager` | 스킬(대화형) | `Skill` |
+| 4 | **이슈만 발행** ("이거 이슈로 등록") | `2t-decencia-channel-github-issue` | 스킬 | `Skill` |
+| 5 | **이슈를 구현** ("이슈 #N 작업해줘") | `2t-decencia-channel-issue-coder` | 에이전트(자율) | `Agent` |
+| 6 | **PR을 머지** ("PR #N 머지", "쌓인 PR 정리") | `2t-decencia-channel-pr-merger` | 에이전트(자율) | `Agent` |
+
+## 판별 신호 (먼저 확인)
+- cwd(또는 상위)의 **`.ch-project` 존재 여부** → 이미 온보딩된 repo인지.
+  - 없음 + 코드 없음/아이디어 → **1 bootstrap**
+  - 없음 + 코드 있음 → **2 terraformer**
+  - 있음 → 변경/이슈/구현/머지(3~6)는 의도로 구분
+- `gh auth status` / `ch auth status` — 5·6(또는 이슈 발행)이면 미인증 시 먼저 안내.
+
+## 병렬/직렬 (에이전트 위임 시)
+- **issue-coder 다수 = 병렬** `Agent`(각자 worktree 격리, 독립 이슈).
+- **pr-merger 다수 = 직렬** `Agent`(한 번에 하나 — main 바뀌면 다음 PR mergeability 재평가, 레이스 방지).
+- terraformer는 보통 단건(repo 1개).
+
+## 순차 오케스트레이션 예시
+- "이 레포 소통채널에 올리고 스프린트도 짜줘" → 2 terraformer(Agent) → 끝나면 `2t-decencia-channel-sprint-builder-v2`(Skill).
+- "로그인에 SNS 추가하고 개발까지" → 3 change-manager(Skill, 전파+이슈 발행) → 발행된 이슈로 5 issue-coder(Agent, 병렬) → PR 나오면 6 pr-merger(Agent, 직렬).
+- 한 단계의 산출물(projectId·이슈번호·PR번호)을 다음 단계 입력으로 넘긴다.
+
+## 경계/주의
+- 라우터는 **분류·위임·순차 진행만** 한다. 문서/코드 작성 디테일은 각 대상이 책임.
+- 어디로 보낼지 끝내 모호하면 **추측하지 말고 사용자에게 한 번 더 물어** 확정.
+- 공통 함정(전 대상 공유): ch CLI content는 마크다운+CRLF 정제, spec 필드 단수+복수 동시, `--json`/`specs get` 윈도우 빈출력 시 PowerShell `Out-File` 우회 — 이는 각 스킬/에이전트가 이미 준수.

package/skill/2t-decencia-channel-prd-v2/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: 2t-decencia-channel-prd-v2
+description: |
+  [2t][v2] 소통채널 PRD 작성/수정 가이드.
+  Epic-Story-Task 체계와의 연결성에 초점 (PRD의 Epic 절 → spec의 --epic).
+  Use when:
+  (1) PRD를 작성하거나 갱신할 때,
+  (2) PRD 구성에서 Epic/스토리/태스크 구조를 후속 spec 작성에 매핑할 때,
+  (3) Read-before-Write 규칙으로 PRD content를 안전하게 수정해야 할 때.
+version: 1.5.0
+---
+
+<!-- ch-version-gate -->
+## ⚠️ 시작 전 필수 — 버전 게이트 (생략 금지)
+
+이 스킬로 **어떤 작업이든 수행하기 전에 가장 먼저** 아래를 실행한다:
+
+```bash
+ch check
+```
+
+- exit code 0(통과)이 **아니면 즉시 중단**한다. 출력에 안내된 업데이트 명령(`npm install -g @decencia/ch-cli@latest` 또는 `ch setup-skill`)을 사용자에게 전달하고, 갱신이 끝나기 전까지 **이 스킬의 어떤 단계도 진행하지 않는다.**
+- `ch`가 미설치/미인증이어도 먼저 `ch check`를 시도한다. (네트워크 불가 시 ch check는 통과시키되 경고를 남긴다.)
+
+구버전 스킬·CLI 사용을 막기 위한 게이트다. 건너뛰지 말 것.
+
+
+# PRD — Epic-Story-Task 매핑 가이드
+
+## 0. Read-before-Write
+
+PRD content는 마크다운 한 덩어리. 일부만 바꿔도 `--content`는 통째 덮어쓰므로:
+
+```bash
+ch prd get --json > /tmp/prd.json                  # 1) 현재 본문 추출
+# 본문 편집
+ch prd set --content /tmp/prd-edited.md            # 2) 통째 교체 (버전 기록됨)
+```
+
+## 1. 권장 목차 (Epic-Story-Task 추적성)
+
+```markdown
+# 프로젝트명 PRD
+
+## 1. 개요
+## 2. 사용자 페르소나 / 시나리오
+
+## 3. Epic 목록
+### 3.1 [Epic: 인증]
+- 목적, KPI
+- 포함 Story: 로그인, 회원가입, 비밀번호 재설정
+### 3.2 [Epic: 결제]
+- ...
+
+## 4. 비기능 요구사항
+## 5. 마일스톤 / 일정
+## 6. 데이터 모델 개요 (테이블 목록 — 자세한 건 db-tables 문서 참조)
+```
+
+PRD의 각 Epic 절 → spec 작성 시 `--epic` 값으로 그대로 사용.
+PRD의 각 Story 항목 → 1개 spec(=Story)으로 생성.
+
+## 2. 마크다운 작성 규칙
+
+- 본문은 **마크다운** (CLI --help에 "HTML"이라 표기되어 있어도 HTML 태그는 텍스트로 표시됨)
+- CRLF는 CLI가 자동 정제하지만 가능하면 LF로 작성
+- 표/이미지 링크 가능, 외부 링크 자유
+
+## 3. 운영 팁
+
+- PRD 큰 개정 시 버전 기록 활용: `ch prd versions` 로 이전 본문 비교
+- spec 작성 직전이라면 PRD의 Epic/Story 매핑 표를 만들어두면 일괄 등록 시 누락 방지
+- workStatus(=spec별 작업 현황)는 PRD와 분리. 진행 상태 메모는 spec.workStatus에.

package/skill/2t-decencia-channel-project-bootstrap/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: 2t-decencia-channel-project-bootstrap
+description: 신규 기획을 사용자와 대화하며 step-by-step으로 소통채널 프로젝트로 만드는 오케스트레이터 스킬. (1)대화로 PRD 완성 → 승인 → (2)페이지명세(spec)+DB스키마 → 승인 → (3)SQA 시트. 각 단계 사용자 승인 게이트, 작성 디테일은 기존 2t-decencia-channel-*-v2 스킬을 적극 재사용. "새 기획 만들어줘"·"프로젝트 처음부터 세팅" 류 요청 시.
+allowed-tools: Bash(ch:*) Bash(git:*) Read Write
+version: 1.5.0
+---
+
+<!-- ch-version-gate -->
+## ⚠️ 시작 전 필수 — 버전 게이트 (생략 금지)
+
+이 스킬로 **어떤 작업이든 수행하기 전에 가장 먼저** 아래를 실행한다:
+
+```bash
+ch check
+```
+
+- exit code 0(통과)이 **아니면 즉시 중단**한다. 출력에 안내된 업데이트 명령(`npm install -g @decencia/ch-cli@latest` 또는 `ch setup-skill`)을 사용자에게 전달하고, 갱신이 끝나기 전까지 **이 스킬의 어떤 단계도 진행하지 않는다.**
+- `ch`가 미설치/미인증이어도 먼저 `ch check`를 시도한다. (네트워크 불가 시 ch check는 통과시키되 경고를 남긴다.)
+
+구버전 스킬·CLI 사용을 막기 위한 게이트다. 건너뛰지 말 것.
+
+
+# 2t-decencia-channel-project-bootstrap — 신규 기획 → 프로젝트
+
+신규 기획을 **사용자와 대화하며 step-by-step**으로 소통채널 프로젝트로 만든다.
+이 스킬은 **오케스트레이터**다 — PRD/spec/DB/SQA의 실제 작성법은 기존 v2 스킬을 **적극 재사용**하고(중복 작성 금지), 흐름·승인 게이트만 책임진다.
+
+## 핵심 원칙
+- **각 단계마다 사용자 승인 게이트.** "괜찮다"는 확인 없이는 절대 다음 단계로 넘어가지 않는다. 수정 요청이면 그 단계를 반복.
+- 작성 디테일은 호출: PRD→`2t-decencia-channel-prd-v2`, 페이지명세→`2t-decencia-channel-spec-v2`, DB→`2t-decencia-channel-db-schema-v2`, SQA→`2t-decencia-channel-sqa-v2`, 업로드→`2t-decencia-channel-cli-v2`.
+
+## Use when
+- "새 기획 만들어줘", "프로젝트 처음부터 세팅해줘", 아이디어/요구사항을 소통채널 프로젝트로 구조화하고 싶을 때.
+
+---
+
+## 0. 프로젝트 준비
+- **이미 프로젝트가 있으면 생략**: cwd의 `.ch-project`가 있거나 사용자가 기존 프로젝트를 지정하면 그걸 사용.
+- 없으면 새로 생성:
+  - `ch projects create` 로 생성.
+  - **schema 설정**(⚠️ 빠지면 웹 UI가 빈 칼럼으로 보임) + **specVersion=2**(Epic-Story-Task).
+  - cwd에 `.ch-project`(`{"projectId":"..."}`) 기록 → 이후 issue-coder/머저가 사용.
+
+## 1. PRD (대화형)
+- 사용자와 **Q&A로 요구사항 수집**(목적/사용자/핵심 기능/범위/제약). 한 번에 다 묻지 말고 대화로 좁혀간다.
+- `2t-decencia-channel-prd-v2` 규칙대로 PRD 작성·업로드. 견적/유지보수성 항목은 제외.
+- → **[게이트] 사용자에게 PRD 확인 요청.** "괜찮다" 하면 2단계, 수정 요청이면 반영 후 재확인.
+
+## 2. 페이지명세(spec) + DB 스키마
+*(PRD 승인 후에만)*
+- **페이지명세 = spec**(ui 메타 포함): `2t-decencia-channel-spec-v2`로 PRD의 Epic/Story → spec 작성(ui: route/file/figmaNodeId·logic·dbTableRefs·tasks).
+- **DB 스키마**: `2t-decencia-channel-db-schema-v2`로 db-schema(ERD/정책) + db-tables(컬럼·인덱스·보안규칙). `spec.dbTableRefs` ↔ `dbTable.relatedSpecIds` 양방향.
+- → **[게이트] 사용자 확인.** OK면 3단계.
+
+## 3. SQA 시트
+*(spec/DB 승인 후에만)*
+- `2t-decencia-channel-sqa-v2`로 SQA 작성: **A축**(명세별 기능 TC — 영역별 번들에서 도출) + **B축**(비기능 표준 40).
+
+---
+
+## 업로드 주의 (전 단계 공통)
+- 모든 업로드는 `2t-decencia-channel-cli-v2`(=`ch` CLI) 경유.
+- ⚠️ content는 **마크다운**(HTML 아님) + **CRLF 정제**(`tr -d '\r'`). PowerShell 인자 분리 실패 시 Bash 도구로 우회.
+- spec 필드는 **단수+복수 동시 저장**(device/devices 등) 규칙 유지(미준수 시 웹 빈 칼럼).
+- `--json` 조회가 Windows에서 깨지면 파일 저장 + forward-slash 경로로 우회.
+
+## 후속 (자동 X — 안내만)
+- 완료 후 "스프린트 구성"(`2t-decencia-channel-sprint-builder-v2`) 또는 "이슈 발행 → issue-coder"로 자연스럽게 이어진다고 사용자에게 안내.