@decencia/ch-cli 1.33.4 → 1.33.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/agent/2t-decencia-channel-issue-coder.md +1 -1
- package/agent/2t-decencia-channel-pr-merger.md +1 -1
- package/agent/2t-decencia-channel-terraformer.md +1 -1
- package/package.json +1 -1
- package/skill/2t-decencia-channel-change-manager/SKILL.md +1 -1
- package/skill/2t-decencia-channel-change-propagation-v2/SKILL.md +1 -1
- package/skill/2t-decencia-channel-cli-v2/SKILL.md +1 -1
- package/skill/2t-decencia-channel-db-schema-v2/SKILL.md +1 -1
- package/skill/2t-decencia-channel-github-issue/SKILL.md +1 -1
- package/skill/2t-decencia-channel-ia-v2/SKILL.md +1 -1
- package/skill/2t-decencia-channel-orchestrator/SKILL.md +1 -1
- package/skill/2t-decencia-channel-policy-v2/SKILL.md +1 -1
- package/skill/2t-decencia-channel-prd-v2/SKILL.md +1 -1
- package/skill/2t-decencia-channel-project-bootstrap/SKILL.md +4 -4
- package/skill/2t-decencia-channel-screen-v2/SKILL.md +1 -1
- package/skill/2t-decencia-channel-spec-v2/SKILL.md +3 -3
- package/skill/2t-decencia-channel-sprint-builder-v2/SKILL.md +1 -1
- package/skill/2t-decencia-channel-sprint-runner/SKILL.md +1 -1
- package/skill/2t-decencia-channel-sqa-v2/SKILL.md +4 -4
- package/skill/2t-decencia-channel-userflow-v2/SKILL.md +1 -1
- package/skill/2t-decencia-channel-work-status-v2/SKILL.md +1 -1
|
@@ -3,7 +3,7 @@ name: 2t-decencia-channel-issue-coder
|
|
|
3
3
|
description: GitHub issue 1개를 입력으로 받아 끝까지 처리하는 코딩 에이전트. 이슈 읽기 → 소통채널 spec/SQA 확인 → git worktree+브랜치에서 구현 → 자체 소프트리뷰 루프 → unittest + SQA → PR 생성 → 소통채널 workStatus·이슈 기록. 다수 병렬 실행 전제, PR까지만(머지·base 브랜치 직접 push·이슈 close는 사람).
|
|
4
4
|
tools: Read, Write, Edit, Grep, Glob, Bash, Agent
|
|
5
5
|
model: opus
|
|
6
|
-
version: 1.33.
|
|
6
|
+
version: 1.33.5
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
## 역할
|
|
@@ -3,7 +3,7 @@ name: 2t-decencia-channel-pr-merger
|
|
|
3
3
|
description: issue-coder가 낸 PR을 기본 완전 자율로 base 브랜치(기본 브랜치 또는 sprint 통합 브랜치)에 머지하는 에이전트. 핵심 역량은 다수 병렬 worktree가 만든 충돌을 작업 의도 기반(semantic)으로 해결하는 것. CI green+충돌없음이면 바로 squash 머지, 충돌이면 의도대로 해결 후 테스트로 검증하여 머지. 재SQA·전면 재리뷰는 하지 않음. 다수 PR은 직렬 머지.
|
|
4
4
|
tools: Read, Write, Edit, Grep, Glob, Bash
|
|
5
5
|
model: opus
|
|
6
|
-
version: 1.33.
|
|
6
|
+
version: 1.33.5
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
## 역할
|
|
@@ -3,7 +3,7 @@ name: 2t-decencia-channel-terraformer
|
|
|
3
3
|
description: 소통채널을 쓰지 않던 기존 코드베이스를 역분석하여 소통채널 프로젝트로 편입(terraforming)하는 자율 에이전트. 코드가 single source of truth — 코드를 읽어 DB 스키마 → 기능명세(spec) → PRD를 bottom-up으로 역생성한다(SQA 제외). 대량 분석은 서브에이전트 병렬, 코드로 못 메우는 의도는 [추정]으로 채우고 "사람확인 질문 리스트"를 산출물로 남긴다. PR/머지·이슈 발행은 하지 않음.
|
|
4
4
|
tools: Read, Write, Edit, Grep, Glob, Bash, Agent
|
|
5
5
|
model: opus
|
|
6
|
-
version: 1.33.
|
|
6
|
+
version: 1.33.5
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
## 역할
|
package/package.json
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: 2t-decencia-channel-change-manager
|
|
3
3
|
description: 기존 소통채널 프로젝트의 기능 추가/수정을 사용자와 대화로 명확화 → 전파 스킬로 연관 PRD/spec/DB/SQA 일괄 갱신 → 변경으로 생긴 새 할일을 GitHub 이슈로 발행하는 오케스트레이터 스킬. (1)대화로 변경 내용 확정 → (2)[게이트] 영향 범위 확인 후 전파 적용 → (3)[게이트] 할일 목록 확인 후 이슈 발행. "이 기능 바꿀래"·"기획 수정"·"이거 추가해줘(기존 프로젝트)" 류 요청 시.
|
|
4
4
|
allowed-tools: Bash(ch:*) Bash(git:*) Bash(gh:*) Read Write
|
|
5
|
-
version: 1.33.
|
|
5
|
+
version: 1.33.5
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
<!-- ch-version-gate -->
|
|
@@ -10,7 +10,7 @@ description: |
|
|
|
10
10
|
(4) ch screens 명령(list/get/create/update/delete/migrate)으로 화면을 다루거나 레거시 프로젝트를 화면 모드로 이관할 때,
|
|
11
11
|
(5) spec의 화면 연결을 CLI로 걸거나 풀 때 (`ch specs screen-refs`),
|
|
12
12
|
(6) Spec ID를 JIRA 스타일(`LOGIN-001`)로 직접 지정할 때 (`ch specs create --id`).
|
|
13
|
-
version: 1.33.
|
|
13
|
+
version: 1.33.5
|
|
14
14
|
---
|
|
15
15
|
|
|
16
16
|
<!-- ch-version-gate -->
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: 2t-decencia-channel-github-issue
|
|
3
3
|
description: gh CLI로 현재 repo에 GitHub 이슈를 작성한다. 이슈 1개=유형 1개(feat/fix/bug), 표준 본문 양식(작업내용·관련 명세 백링크·완료조건)으로 발행. "이슈 만들어줘"/"깃헙 이슈로 등록해줘" 요청 시, 또는 소통채널 기획·명세 작업 후 처리할 일들을 GitHub 이슈로 옮길 때 사용. 멱등성/중복방지·확인단계는 다루지 않음(요청대로 바로 생성).
|
|
4
4
|
allowed-tools: Bash(gh:*) Bash(git:*) Read Write
|
|
5
|
-
version: 1.33.
|
|
5
|
+
version: 1.33.5
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
<!-- ch-version-gate -->
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: 2t-decencia-channel-orchestrator
|
|
3
3
|
description: 소통채널 작업의 단일 진입점(디스패처). 사용자 요청을 듣고 7종(bootstrap·terraformer·change-manager·github-issue·issue-coder·pr-merger·sprint-runner) 중 적절한 곳으로 라우팅하고, 필요하면 여러 단계를 순차 오케스트레이션한다. 대화형 스킬은 메인 세션에서 Skill로, 자율 에이전트는 Agent로 위임. "소통채널 작업 해줘"·"이거 어떻게 처리하지?"처럼 무엇부터 할지 모를 때, 또는 신규기획/코드편입/기획변경/이슈/구현/머지/스프린트실행 어디로든 시작할 때.
|
|
4
4
|
allowed-tools: Skill Agent Read Bash(ch:*) Bash(gh:*) Bash(git:*)
|
|
5
|
-
version: 1.33.
|
|
5
|
+
version: 1.33.5
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
<!-- ch-version-gate -->
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: 2t-decencia-channel-project-bootstrap
|
|
3
3
|
description: 신규 기획을 사용자와 대화하며 step-by-step으로 소통채널 프로젝트로 만드는 오케스트레이터 스킬. (1)대화로 PRD 완성 → (2)기능명세(spec) 내용 확정 → (3)spec 업로드 → (4)유저플로우 → (5)정책정의서 → (6)DB 스키마·spec 연결 → (7)화면설계서(화면 생성·연결) → (8)검증기준서(SQA). 각 단계 사용자 승인 게이트, 작성 디테일은 기존 2t-decencia-channel-*-v2 스킬을 적극 재사용. "새 기획 만들어줘"·"프로젝트 처음부터 세팅" 류 요청 시.
|
|
4
4
|
allowed-tools: Bash(ch:*) Bash(git:*) Read Write
|
|
5
|
-
version: 1.33.
|
|
5
|
+
version: 1.33.5
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
<!-- ch-version-gate -->
|
|
@@ -111,7 +111,7 @@ ch specs create --id PROJ-001 --name "프로젝트 목록" \
|
|
|
111
111
|
- ⚠️ **이 시점엔 흐름 `refs`를 넣지 않는다** — 테이블이 아직 없고, 서버가 refs의 tableId를 실존 검증해 400이 난다. 완결 문장으로만 쓰고 §6에서 refs를 보강한다.
|
|
112
112
|
- `--ui`도 넣지 않는다. 화면이 아직 없다 — 연결은 §8에서 `ch specs screen-refs`로 건다.
|
|
113
113
|
- 레거시 프로젝트(§0-1)는 종전 플래그(`--type`·`--content`·`--ui ui.json`)를 그대로 쓴다 — [[2t-decencia-channel-cli-v2]] §1.
|
|
114
|
-
- **spec마다
|
|
114
|
+
- **spec마다 Testable 자문만 한다** — 이 스토리로 통과/실패를 판정하는 TC 문장이 나오는가? 안 나오면 스토리를 다시 쓰거나 쪼갠다([[2t-decencia-channel-spec-v2]] §13-11). **TC 등록은 여기서 하지 않는다** — §9 검증기준서에서 A축·B축·시나리오를 일괄 등록한다.
|
|
115
115
|
- → **[게이트] 사용자 확인.** OK면 4단계.
|
|
116
116
|
|
|
117
117
|
## 4. 유저플로우
|
|
@@ -242,8 +242,8 @@ ch specs screen-refs PROJ-002 --screens SCR-PROJECTS,SCR-PROJECT-DETAIL # 화
|
|
|
242
242
|
탭·모달·바텀시트는 별도 화면이 아니다. 그 화면의 `states`·`entryPoints`로 적는다.
|
|
243
243
|
|
|
244
244
|
## 9. 검증기준서 (SQA)
|
|
245
|
-
*(화면 연결 후에만 — 작성 순서 마지막.
|
|
246
|
-
- `2t-decencia-channel-sqa-v2`로
|
|
245
|
+
*(화면 연결 후에만 — 작성 순서 마지막. SQA 전체를 여기서 한번에 쓴다)*
|
|
246
|
+
- `2t-decencia-channel-sqa-v2`로 마무리한다(시트가 없으면 `ch sqa create` 먼저): **A축(Story TC 2겹)**(§2 — spec당 2~5개, 플로우 있으면 분기당·없으면 규칙당, 여정형은 유저플로우 분기당) + **B축**(비기능 핵심 9개) + **시나리오**(§4.6 — 유저플로우 기반 5~10개, 역할별 여정·상태 누적 확인 포인트, 대응 TC 등록·매핑, Sprint 완료조건으로 할당) + **§4.5 커버리지 게이트**(전 spec에 TC 2겹이 있는지 최종 검증).
|
|
247
247
|
|
|
248
248
|
### 디자인 핸드오프로 이어가기 (안내만)
|
|
249
249
|
화면이 다 짜였으면 **디자인 핸드오프**로 넘어갈 수 있다. 디자이너가 웹 화면 탭 **[통합 핸드오프 zip 받기]** 또는 `ch handoff export --dir <폴더>`로 화면 기획 묶음을 받아 Claude Design에 넣는다. 절차는 `docs/design-handoff-sop.md`. 읽기전용 export라 이 스킬이 대신 실행하지 않는다 — 화면이 막 만들어진 이 지점에서 **사용자에게 안내만** 한다. (명령 상세는 [[2t-decencia-channel-cli-v2]] handoff 명령.)
|
|
@@ -12,7 +12,7 @@ description: |
|
|
|
12
12
|
(3) 사용자 스토리·사전 조건·로직 플로우·비즈니스 규칙을 작성할 때,
|
|
13
13
|
(4) Story 규모를 Story Point(`--points`)로 매길 때,
|
|
14
14
|
(5) 신규 spec ID를 `AUTH-001` 같은 JIRA 스타일로 부여할 때 (`ch specs create --id`).
|
|
15
|
-
version: 1.33.
|
|
15
|
+
version: 1.33.5
|
|
16
16
|
---
|
|
17
17
|
|
|
18
18
|
<!-- ch-version-gate -->
|
|
@@ -463,8 +463,8 @@ ch specs create --id AUTH-001 --name "로그인" \
|
|
|
463
463
|
```
|
|
464
464
|
|
|
465
465
|
10. `ch specs get <id> --json`으로 결과 검증
|
|
466
|
-
11. **
|
|
467
|
-
12. 이후 문서는 작성 순서대로: 유저플로우(②) → 정책정의서(③) → DB 스키마(이때 dbTableRefs·refs 보강) → 화면설계서(④, 이때 화면 연결) → 검증기준서(⑤ —
|
|
466
|
+
11. **Testable 자문** — 이 스토리로 통과/실패를 판정하는 TC 문장이 나오는가? 안 나오면 스토리가 물렁한 것이다 — §5로 돌아가 다시 쓰거나 §2로 쪼갠다. **등록은 여기서 하지 않는다** — TC는 ⑤ 검증기준서에서 A축·B축·시나리오와 함께 일괄 등록한다([[2t-decencia-channel-sqa-v2]] §2)
|
|
467
|
+
12. 이후 문서는 작성 순서대로: 유저플로우(②) → 정책정의서(③) → DB 스키마(이때 dbTableRefs·refs 보강) → 화면설계서(④, 이때 화면 연결) → 검증기준서(⑤ — **TC(A축)·B축·시나리오를 여기서 일괄 등록** + 커버리지 게이트, [[2t-decencia-channel-sqa-v2]])
|
|
468
468
|
13. 개발 착수 후 진행 일지는 [[2t-decencia-channel-work-status-v2]]
|
|
469
469
|
|
|
470
470
|
---
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: 2t-decencia-channel-sprint-runner
|
|
3
3
|
description: 특정 Sprint를 끝까지 실행(run)하는 오케스트레이터 스킬. Sprint의 spec을 시드로 이슈 목록을 분해·발행(github-issue)하고, GitHub milestone에 묶인 이슈를 상태별로 분류해 issue-coder(병렬)·pr-merger(직렬)로 전진시킨 뒤, 사람확인이 필요한 곳에서 멈춘다. 사람이 확인·체크 후 재호출하면 멱등하게 이어간다(반복 루프). "스프린트 돌려줘"·"sprint N 실행"·"이 스프린트 개발 진행해줘" 류 요청 시.
|
|
4
4
|
allowed-tools: Skill Agent Read Bash(ch:*) Bash(gh:*) Bash(git:*)
|
|
5
|
-
version: 1.33.
|
|
5
|
+
version: 1.33.5
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
<!-- ch-version-gate -->
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: 2t-decencia-channel-sqa-v2
|
|
3
3
|
description: |
|
|
4
4
|
[2t][v2] 소통채널 SQA(검증기준서) 운영 가이드 — 검증 = TC 검증 + 시나리오 검증.
|
|
5
|
-
TC는 Story 완료조건(2겹: 해피패스(결과 상태까지)·경계/예외 — spec에서 도출,
|
|
5
|
+
TC는 Story 완료조건(2겹: 해피패스(결과 상태까지)·경계/예외 — spec에서 도출, ⑤ 검증기준서에서 일괄 등록 — §2),
|
|
6
6
|
시나리오는 Sprint 완료조건(유저플로우 기반 5~10개, 상태 누적·역할 여정 검증 — §4.6).
|
|
7
7
|
권한·상태반영은 시나리오+B축(핵심 9개)이 담당. 실행은 시나리오로 하되 판정·기록은 TC 단위.
|
|
8
8
|
Use when:
|
|
@@ -12,7 +12,7 @@ description: |
|
|
|
12
12
|
(4) 보안/성능/접근성/호환성 비기능 TC를 시트에 채워야 할 때,
|
|
13
13
|
(5) 명세 영역별 완성형 TC 번들(퍼블리싱/프론트/백엔드 디센시아 운영 관점 포함)을 가져다 쓸 때,
|
|
14
14
|
(6) Sprint 종료 전 spec별 TC 통과·시나리오 통과 여부를 점검할 때.
|
|
15
|
-
version: 1.33.
|
|
15
|
+
version: 1.33.5
|
|
16
16
|
---
|
|
17
17
|
|
|
18
18
|
<!-- ch-version-gate -->
|
|
@@ -74,12 +74,12 @@ SQA 항목은 spec이 정의한 동작·규칙에서 도출한다. Story는 Task
|
|
|
74
74
|
| 2 | **경계·예외** | 플로우의 **실패·차단 분기당 1개**. 같은 겹의 변형(형식 오류 이메일/숫자/날짜 등)은 대표 1개로 묶는다 | **비즈니스 규칙당 위반 1개** + 사전 조건 미충족 대표 1개. 여정형이면 **유저플로우의 해당 spec 구간 분기당 1개**도 더한다 |
|
|
75
75
|
|
|
76
76
|
- **Story당 표준 2~5개.** 12개를 넘으면 TC를 줄일 게 아니라 Story가 크다는 신호다([[2t-decencia-channel-spec-v2]] §14).
|
|
77
|
-
- **작성 시점 =
|
|
77
|
+
- **작성 시점 = ⑤ 검증기준서에서 일괄.** A축·B축·시나리오를 한 자리에서 등록한다 — ①~④를 거치며 기획이 계속 바뀌는데 TC를 미리 등록하면 그 변경을 따라다니는 유지 대상만 는다. ⑤ 시점이 도출 재료(유저플로우 분기·정책·stateMachines·화면)도 가장 풍부하다. 검증 불가능한 spec 걸러내기는 ①의 Testable 자문이 맡는다([[2t-decencia-channel-spec-v2]] §13) — 자문은 ①에서, 등록은 ⑤에서.
|
|
78
78
|
- **권한·상태반영은 Story TC의 몫이 아니다** — 권한 차단 대표 검증은 B축(§4.2), 역할별 실사용·상태 누적 확인은 시나리오(§4.6)가 담당한다. 단, 그 Story 고유의 권한 규칙(예: "본인 문서만")은 businessRules의 경계·예외 TC로 자연 도출된다.
|
|
79
79
|
|
|
80
80
|
## 3. 신규 SQA 작성 워크플로우
|
|
81
81
|
|
|
82
|
-
> A축(Story TC 2겹)
|
|
82
|
+
> SQA는 **⑤ 검증기준서에서 한번에** 쓴다(§2) — A축(Story TC 2겹) → B축(핵심 9개) → 시나리오·확인 포인트 TC 순으로 채우고 §4.5 커버리지 게이트를 돌린다.
|
|
83
83
|
|
|
84
84
|
0. **시트 생성** (없으면 먼저):
|
|
85
85
|
```bash
|