Composes atomic, intent-revealing, grep-friendly writing (Zettelkasten) for code comments, docs, logs, prompts, schema/ticket fields, and long-form technical articles. Use when cognitive load and token cost matter. Triggers: 寫註解, 寫文件, 寫日誌, 寫 prompt, 寫文章, 技術文章, post-mortem, 架構決策, 除錯復盤, 欄位設計, atomic, reusable.

2026-04-220

agent-team

tarrragon/ccsession

Agent Teams 協作派發指南。Use when: (1) Agent A 的發現會改變 Agent B 正在進行的工作, (2) 用戶要求使用 team/swarm, (3) 多代理人需即時協商共用介面或 API 契約。涵蓋 team 建立、Ticket-Task 橋接、teammate 入職、生命週期管理。

2026-04-220

branch-worktree-guardian

tarrragon/ccsession

Branch Worktree Guardian - Git 分支和 Worktree 管理工具。Use for: (1) 新開發需求時建立隔離分支, (2) 使用 worktree 機制避免分支衝突, (3) 驗證當前工作分支正確性, (4) 預防在錯誤分支上開發

2026-04-220

broken-link-check

tarrragon/ccsession

broken-link 偵測工具。掃描 .claude/ 目錄所有 Markdown 文件中的路徑引用，偵測失效連結。Use for: (1) 一次性掃描所有 broken links, (2) 搭配 /loop 定期監控, (3) 修改規則/方法論/代理人文件後驗證路徑完整性。Use when: user runs /broken-link-check, 或搭配 /loop 定期執行, 或發現 broken link 錯誤後。

2026-04-220

bulk-evaluate

tarrragon/ccsession

子任務拆分與 Context 卸載工具。將可拆分的大型任務分成 N 個子 Ticket，各由 Agent 獨立執行，結論直接寫入 Ticket 不回報主線程。Use for: 批量檔案評估, 大型審查任務拆分, 任何需要讀取大量資料但結果可落地到 Ticket 的任務

2026-04-220

cognitive-load-assessment

tarrragon/ccsession

認知負擔評估與審查工具。作為決策樹、代理人、Code Review 的基本參考標準。用於: (1) 任務複雜度評估, (2) 代理人升級判斷, (3) 任務拆分建議, (4) 程式碼品質審查與熱點識別

2026-04-220

name	tdd-phase1-split
description	[DEPRECATED] 已遷移至 /tdd SKILL。請使用 /tdd split 命令。

[DEPRECATED] TDD Phase 1 Split

此 SKILL 已棄用，所有功能已遷移至 /tdd SKILL。

SOLID 拆分分析：/tdd split

CLI 腳本：.claude/skills/tdd/scripts/tdd-phase1-split.py

方法論文件：.claude/skills/tdd/references/phase1/rules.md（SOLID 拆分進階工具與範本章節）

Phase 1 設計指引：.claude/skills/tdd/references/phase1/rules.md

遷移日期：2026-03-12 遷移 Ticket：已遷移

以下為原始內容（僅供參考，不再維護）：

SOLID 原則驅動的功能拆分輔助工具 - 在設計階段就進行拆分，而非實作階段。

核心理念

Phase 1（功能設計）就要考慮：
- DIP（依賴反轉）→ 介面設計
- LSP（里氏替換）→ 繼承規劃
- ISP（介面隔離）→ 介面拆分
           ↓
     才能實踐
- SRP（單一職責）
- OCP（開閉原則）

拆分時機：Phase 1，不是 Phase 3a

關鍵原則：設計階段就要拆分，不是等到實作才發現需要拆分。

SOLID 原則檢查清單

SRP（Single Responsibility Principle）

檢查問題：

這個功能有幾個獨立的修改原因？
能用「動詞 + 單一目標」描述嗎？
所有驗收條件都指向同一目標嗎？

拆分信號：

有 2+ 個修改原因
需要用「和」連接描述
驗收條件指向不同目標

OCP（Open-Closed Principle）

檢查問題：

未來擴展需要修改現有程式碼嗎？
有沒有可以抽象的變化點？

拆分信號：

需要 switch/case 或 if/else 處理不同類型
未來新增類型需要修改現有程式碼

LSP（Liskov Substitution Principle）

檢查問題：

有繼承關係嗎？
子類別能完全替換父類別嗎？

拆分信號：

子類別需要覆寫並改變父類別行為
某些方法在子類別中沒有意義

ISP（Interface Segregation Principle）

檢查問題：

介面有沒有強迫實作不需要的方法？
一個介面服務多少個不同的客戶端？

拆分信號：

實作類別有空方法或拋出 NotImplemented
不同客戶端只使用介面的一部分

DIP（Dependency Inversion Principle）

檢查問題：

高層模組是否依賴低層模組？
依賴的是抽象還是具體實作？

拆分信號：

直接 import 具體類別
無法獨立測試（依賴外部服務）

命令

分析功能

uv run .claude/skills/tdd-phase1-split/scripts/tdd-phase1-split.py analyze \
  --description "實作書籍搜尋功能"

互動式分析，產出 SOLID 檢查報告。

產出拆分建議

uv run .claude/skills/tdd-phase1-split/scripts/tdd-phase1-split.py suggest \
  --description "實作書籍搜尋功能" \
  --version 0.29.0

輸出範例：

[Split] 功能拆分建議

原始需求：實作書籍搜尋功能

SOLID 分析結果：
[SRP] 識別 3 個獨立職責
[DIP] 需要 2 個介面抽象
[ISP] 建議拆分 1 個介面

拆分建議：
----------------------------------------------------------------------
| 子功能 | 描述 | 架構層 | 版本 | 依賴 |
|--------|------|--------|------|------|
| A | SearchQuery 值物件 | Domain | 0.29.1 | 無 |
| B | SearchResult Entity | Domain | 0.29.1 | 無 |
| C | ISearchRepository 介面 | Domain | 0.29.1 | 無 |
| D | SearchBooksUseCase | Application | 0.29.2 | A, B, C |
| E | SearchRepository 實作 | Infrastructure | 0.29.2 | C |
| F | SearchWidget | Presentation | 0.29.3 | D |

版本分配說明：
- v0.29.1：無依賴任務（A, B, C 可並行）
- v0.29.2：依賴 v0.29.1 的任務（D, E）
- v0.29.3：依賴 v0.29.2 的任務（F）

建立拆分 Tickets

uv run .claude/skills/tdd-phase1-split/scripts/tdd-phase1-split.py create-tickets \
  --description "實作書籍搜尋功能" \
  --version 0.29.0 \
  --wave 3

根據分析結果建立父 Ticket 和子 Tickets。

驗證拆分

uv run .claude/skills/tdd-phase1-split/scripts/tdd-phase1-split.py validate \
  --ticket-id {version}-W{wave}-{seq}

驗證已拆分的 Tickets 是否符合 SOLID 原則。

拆分流程

Step 1: 功能範圍分析

lavender 收到功能需求
    |
    v
識別功能邊界
    |
    +-- 輸入是什麼？
    +-- 輸出是什麼？
    +-- 涉及哪些實體？
    +-- 需要哪些操作？

Step 2: SOLID 原則應用

對每個識別的元素
    |
    +-- SRP：有幾個修改原因？
    +-- OCP：如何支援擴展？
    +-- LSP：繼承關係正確嗎？
    +-- ISP：介面需要拆分嗎？
    +-- DIP：依賴方向正確嗎？

Step 3: 拆分決策

根據 SOLID 分析
    |
    +-- 識別獨立職責 → 各自一個 Ticket
    +-- 識別需要的介面 → 介面定義 Ticket
    +-- 識別依賴關係 → 決定版本分配

Step 4: 版本號分配

依賴分析
    |
    +-- 無依賴 → 同小版本（可並行）
    +-- 有依賴 → 不同小版本（序列）
    |
    v
產出版本分配建議

Step 5: Ticket 建立

使用 /ticket create 建立 Tickets（詳見 ticket Skill）。

拆分範例

範例：書籍搜尋功能

原始需求：「實作書籍搜尋功能」

Step 1: 功能範圍分析

輸入：搜尋關鍵字、篩選條件
輸出：搜尋結果列表
實體：SearchQuery, SearchResult, Book
操作：查詢、篩選、排序、分頁

Step 2: SOLID 分析

原則	分析結果	建議
SRP	搜尋查詢建立、搜尋執行、結果呈現是 3 個職責	拆分為 3+ 個 Ticket
OCP	未來可能有不同搜尋來源（本地、API）	定義 ISearchRepository
LSP	無繼承需求	-
ISP	Repository 可能同時有讀寫	考慮 ISearchRepository 只負責搜尋
DIP	UseCase 不應依賴具體 Repository	定義介面

Step 3: 拆分結果

父 Ticket（例：書籍搜尋功能）
├── version: 0.29.3（整體完成版本）
└── children: [子 Ticket 1..N]

子 Ticket：SearchQuery 值物件
├── version: 0.29.1
├── blockedBy: []
└── where: Domain

子 Ticket：SearchResult Entity
├── version: 0.29.1
├── blockedBy: []
└── where: Domain

子 Ticket：ISearchRepository 介面
├── version: 0.29.1
├── blockedBy: []
└── where: Domain

子 Ticket：SearchBooksUseCase
├── version: 0.29.2
├── blockedBy: [值物件、Entity、介面]
└── where: Application

子 Ticket：SearchWidget
├── version: 0.29.3
├── blockedBy: [UseCase]
└── where: Presentation

Step 4: 執行順序

階段 1：值物件 + Entity + 介面（並行）
階段 2：UseCase（序列）
階段 3：Widget（序列）

版本號分配規則

小版本分配原則

情況	版本分配	範例
無依賴任務	同小版本	Domain Entities → v0.29.1
依賴前一批	下一個小版本	UseCases → v0.29.2
依賴多批次	最後依賴的下一版	Widget → v0.29.3

並行判斷

條件	可並行
同一小版本	是
無 blockedBy	是
不同架構層但無依賴	是
有 blockedBy	否

輸出格式

拆分報告

## Phase 1 拆分報告

### 原始需求
- **描述**: [需求描述]
- **預估複雜度**: 高

### SOLID 分析

| 原則 | 分析結果 | 拆分建議 |
|------|---------|---------|
| SRP | [結果] | [建議] |
| OCP | [結果] | [建議] |
| LSP | [結果] | [建議] |
| ISP | [結果] | [建議] |
| DIP | [結果] | [建議] |

### 拆分清單

| ID | 描述 | 層級 | 版本 | 依賴 | 代理人 |
|----|------|------|------|------|--------|
| A | [描述] | Domain | 0.29.1 | - | lavender |
| B | [描述] | Domain | 0.29.1 | - | lavender |

### 執行計畫

1. **v0.29.1**（並行）
   - Ticket A
   - Ticket B

2. **v0.29.2**（序列）
   - Ticket C（依賴 A, B）

### 建議行動
- 建立父 Ticket
- 建立子 Tickets
- 設定依賴關係

tdd-phase1-split

المزيد من هذا المستودع

المزيد من هذا المستودع

[DEPRECATED] TDD Phase 1 Split

核心理念

SOLID 原則檢查清單

SRP（Single Responsibility Principle）

OCP（Open-Closed Principle）

LSP（Liskov Substitution Principle）

ISP（Interface Segregation Principle）

DIP（Dependency Inversion Principle）

命令

分析功能

產出拆分建議

建立拆分 Tickets

驗證拆分

拆分流程

Step 1: 功能範圍分析

Step 2: SOLID 原則應用

Step 3: 拆分決策

Step 4: 版本號分配

Step 5: Ticket 建立

拆分範例

範例：書籍搜尋功能

版本號分配規則

小版本分配原則

並行判斷

輸出格式

拆分報告

相關資源

[DEPRECATED] TDD Phase 1 Split

核心理念

SOLID 原則檢查清單

SRP（Single Responsibility Principle）

OCP（Open-Closed Principle）

LSP（Liskov Substitution Principle）

ISP（Interface Segregation Principle）

DIP（Dependency Inversion Principle）

命令

分析功能

產出拆分建議

建立拆分 Tickets

驗證拆分

拆分流程

Step 1: 功能範圍分析

Step 2: SOLID 原則應用

Step 3: 拆分決策

Step 4: 版本號分配

Step 5: Ticket 建立

拆分範例

範例：書籍搜尋功能

版本號分配規則

小版本分配原則

並行判斷

輸出格式

拆分報告

相關資源