菜单
多視角審核/code review 工具。派發三人組（含常駐委員 linux）並行掃描程式碼品質、架構設計、重構評估。Use for: 程式碼審查, 架構評估, 重構掃描, 結論審查, 系統設計變更審查, 功能規劃審查。Use when: Phase 3b 完成後 PR 前, Phase 4 重構評估前, 重大架構決策前, ANA Ticket 結論審查, 任何分析報告產出後, 規則/Skill/方法論變更後, Wave 完成審查, 規格設計完成後
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Branch Worktree Guardian - Git 分支和 Worktree 管理工具。Use for: (1) 新開發需求時建立隔離分支, (2) 使用 worktree 機制避免分支衝突, (3) 驗證當前工作分支正確性, (4) 預防在錯誤分支上開發
Claude Code release notes 框架影響評估工具。比對 last-reviewed 版本篩出新版本，逐項分類（對框架有幫助 / 需評估 / 無影響 / 不適用），對採用項引導建 ANA + WRAP + spawn 落地。Use when: 執行 /release-notes 看到新版本、定期檢查 CC 更新、評估新功能對專案框架的影響時。Triggers: release notes, release-notes, CC 更新, claude code 更新, 版本更新評估, 新功能評估, 框架影響評估。
Use this skill for managing git worktrees for Ticket-based development. Triggers include: creating a worktree for a new ticket, checking worktree status, viewing all worktrees, or any mention of /worktree, worktree management, feature branches, or setting up development environment.
版本發布整合工具。Use for: (1) 發布新版本（合併到 main、打 Tag、推送）, (2) 發布前健康檢查（所有 Ticket 完成？CHANGELOG 更新？）, (3) 更新版本文件（worklog 狀態、CHANGELOG）。Use when: 準備發布版本、執行 /version-release check 確認發布前狀態、完成所有 Ticket 後要收尾時。
Composes atomic, intent-revealing, grep-friendly writing (Zettelkasten) for code comments, docs, logs, prompts, schema/ticket fields, external-analysis transformation, and long-form technical articles. Use when cognitive load and token cost matter. **Also triggers during multi-round review / batch review / 寫作 audit** — provides the keyword bank (正向陳述 / 口語修辭 / 地區用語 / 廢話前綴 / 裝飾符號 / 對讀者喊話 / 自評誇飾 / 必然性框架) and frame-specific check lists that multi-round-review reviewer agents need. Triggers: 寫註解, 寫文件, 寫日誌, 寫 prompt, 寫文章, 技術文章, 商業分析, 外部分析文章, post-mortem, 架構決策, 除錯復盤, 欄位設計, atomic, reusable, 多輪審查, multi-round review, batch review, 寫作 audit, 正向陳述, 口語修辭, 字句層 grep.
寫多篇章節後做多輪 agent reviewer audit 的標準操作流程。每輪用不同 frame 切換、跨輪 finding 互不重疊、停止訊號是 frame 涵蓋而非 finding 數遞減。Round 1-A 寫作規範 reviewer 必須同步 invoke `compositional-writing` skill 的字句層 keyword bank（正向陳述 / 口語修辭 / 地區用語 / 廢話前綴 / 裝飾符號 / 對讀者喊話 / 自評誇飾 / 必然性框架）、且命中後要做語意判定（命中是候選不是判決）。觸發詞：多輪審查、Round 1/2/3、frame 切換、跨輪審查、reviewer 規劃、何時停止 review、寫作 audit、batch review、cadence 同骨化、enumeration 不窮盡、正向陳述、self-application sweep。Trigger when reviewing multiple writings via successive rounds of agent reviewers.
| name | parallel-evaluation |
| description | 多視角審核/code review 工具。派發三人組（含常駐委員 linux）並行掃描程式碼品質、架構設計、重構評估。Use for: 程式碼審查, 架構評估, 重構掃描, 結論審查, 系統設計變更審查, 功能規劃審查。Use when: Phase 3b 完成後 PR 前, Phase 4 重構評估前, 重大架構決策前, ANA Ticket 結論審查, 任何分析報告產出後, 規則/Skill/方法論變更後, Wave 完成審查, 規格設計完成後 |
方法論: .claude/methodologies/parallel-evaluation-methodology.md
Phase 1 → 收集標的（確定掃描範圍） Phase 2 → 並行視角掃描（2-4 Agent 同時掃描）
Phase 2 預算檢查:
reference_tokens + (N x avg_target_tokens) + (N x output_tokens) < 100,000。超過則減少 N 或拆分標的。
Phase 3 → 彙整 + Worth-It Filter + 建立 Ticket + 錯誤模式記錄（決定執行方式，所有發現必須追蹤）
Phase 3 強制步驟：(1) 彙整發現 → (2) Worth-It Filter 分類 → (3) 對每個「延後執行」項目執行
ticket create→ (4) 將 Ticket ID 填入報告表格 → (5) 結構性發現→錯誤模式記錄（見下方判斷標準）→ (6) 輸出報告。步驟 3-5 不可省略，報告中不可出現沒有 Ticket ID 的「延後追蹤」行。 Phase 3 步驟 5 判斷標準：發現是否為結構性模式（跨專案可重現的錯誤類型，而非單次的專案 bug）？若是，執行/error-pattern add記錄到.claude/error-patterns/。判斷方式：將發現中的專案名稱和檔案路徑替換為通用描述，如果仍然有意義 → 是結構性模式。 Phase 3 衝突處理：視角間有衝突時，依衝突分類策略處理（加法vs減法預設減法，linux 品味否決權）。詳見 .claude/methodologies/parallel-evaluation-methodology.md「衝突處理策略」。
parallel-evaluation 的常駐委員分兩類，加入規則與 opt-out 條件不同：
| 類型 | 代理人 | 加入情境 | 可 opt-out |
|---|---|---|---|
universal_lens | linux | 所有情境（A-G）無條件加入（Good Taste / 架構複雜度為所有產出的元維度） | 否 |
default_lens_per_scenario | basil-writing-critic | 情境 C / D / F / G 預設加入（書面文字產出量最高的場景）；情境 A / B / E 不加入 | 是（--skip-basil） |
linux 常駐說明：linux 評分對應 Worth-It Filter：Garbage = 高幅度、Acceptable = 中幅度、Good taste = 無發現。Wave 完成審查時，除了標準的多視角代理人外，必須額外派發 linux 代理人作為常駐審查委員，與 code-reviewer（Bug/安全）和 code-explorer（架構/設計）組成固定三人組（見 parallel-dispatch.md 多視角審查固定三人組章節）。
basil opt-out 機制（--skip-basil）：PM 在以下任一條件成立時可宣告 --skip-basil，略過本次 basil 加入：
| 條件 | 判斷依據 |
|---|---|
| Context 使用率 > 70% 或 session 後段 | 剩餘 token 預算不足以同時承載 basil 審查輸出 |
| 審查標的為已知非文字密集產出 | 例如：schema 定義、YAML 設定、程式碼變更（僅情境 C/D/F/G 意外含大量程式碼） |
| 本 session 已完成一次 basil 審查且標的無重大變更 | 同一文件短期內重複審查，邊際收益低 |
Why：basil 在 C/D/F/G 預設加入是保護書面文字品質的必要機制；但強制無 opt-out 會在 token 緊張的 session 後段單方面增加 +33% 派發成本，違反「Never break userspace」（W17-066 linux L-W1 共識）。opt-out 讓 PM 在資源受限時能主動降低摩擦，同時保留預設強制的保護效果。
Consequence：未宣告 --skip-basil 即代表 basil 必然加入情境 C/D/F/G；濫用 --skip-basil（在非緊急條件下略過）會使文字品質防護缺失，後期需要更高成本的人工修正。
Action：PM 在 parallel-evaluation 情境判斷時，先確認情境屬 C/D/F/G，若是則 basil 預設加入；若任一 opt-out 條件成立，可宣告 --skip-basil 並在 Ticket append-log 記錄原因。
| 情境 | 適用時機 | 視角 | Agent 數 | basil 預設 |
|---|---|---|---|---|
| A: 程式碼審查 | Phase 3b 後、PR 前 | Reuse + Quality + Efficiency | 3 | 否 |
| B: 重構評估 | Phase 4 前、TD 清理 | Redundancy + Coupling + Complexity | 3 | 否 |
| C: 架構評估 | SA 審查、新架構決策 | Consistency + Impact + Simplicity | 3+1 | 是（--skip-basil 可 opt-out） |
| D: 功能評估 | Phase 1 後、需求確認 | Overlap + Fit + Scope | 3+1 | 是（--skip-basil 可 opt-out） |
| E: 冗餘偵測 | 版本規劃、系統清理 | Duplication + State + Interface | 3 | 否 |
| F: 結論審查 | 任何分析報告產出後 | Evidence + Alternatives + Scope | 3+1 | 是（--skip-basil 可 opt-out） |
| G: 系統設計 | 規則/Skill/方法論變更後 | Consistency + Completeness + CogLoad | 3+1 | 是（--skip-basil 可 opt-out） |
各視角詳細檢查項目: references/lens-configurations.md
語言代理人加入規則：當審查標的涉及語言/框架專屬的基礎設施或開發流程時，將對應語言代理人作為額外審查委員加入標準三人組：
| 審查標的涉及 | 加入代理人 | 常見場景 |
|---|---|---|
| Flutter/Dart | parsley-flutter-developer | Widget 架構、Riverpod 設計、Dart 慣例 |
| Python | thyme-python-developer | Hook 系統、腳本設計、Python 慣例 |
| Go | fennel-go-developer | 後端服務、Go 慣例 |
此規則對情境 C（架構評估）和 D（功能評估）尤為重要，因為規劃階段的決策深受語言/框架限制影響。語言代理人可提供框架專業知識，避免產出不符合實際開發慣例的方案。
核心原則：Worth-It Filter 只決定「是否立即執行」，不決定「是否追蹤」。所有發現都必須建 Ticket 或寫入 todolist。發現技術債是一個問題，修復成本是否值得是另一個問題——兩者不在同一時刻決策。
| 改善幅度 | 風險低 | 風險高 | 追蹤方式 |
|---|---|---|---|
| 高（bug/安全） | 立即執行 | 立即執行 | 建 Ticket（P0/P1） |
| 高（簡化） | 立即執行 | 延後執行 | 建 Ticket（P1） |
| 中（維護性） | 立即執行 | 延後執行 | 建 Ticket（P2） |
| 低（風格） | 延後執行 | 延後執行 | 建 Ticket（P2） |
Why：本表的「延後執行」是合法狀態（b）——延後決策必須綁 ticket trigger（見 .claude/rules/core/decision-trigger-binding.md 規則 1 / 1.5）。表格右欄的「建 Ticket」就是 trigger 綁定，缺一即退化為無 trigger 延後。
Consequence：報告中出現「延後」但 Ticket 欄為空，等同未追蹤；該發現會在「以後」與「永不」之間累積為死議題（PC-093 反模式）。
Action：執行有疑慮就延後，但追蹤不可省略。Phase 3 產出報告前，必須對所有延後項目執行 ticket create，並在報告表格的 Ticket 欄填入實際 ID。禁止行為：報告中出現「延後」但 Ticket 欄為空。
量化標準和案例: references/worth-it-filter-details.md
Phase 1: git diff --name-only 取得變更檔案
Phase 2: 並行派發 3 Agent
- Explore: 掃描是否有可重用的既有 utility
- code-reviewer #1: 掃描冗餘狀態和 copy-paste
- code-reviewer #2: 掃描不必要的工作和效能問題
Phase 3: 彙整發現 → Worth-It Filter → 行動清單
Phase 1: 收集分析報告/結論
Phase 2: 並行派發 3 Agent
- Explore #1: 驗證結論是否有程式碼佐證
- Plan: 檢查是否遺漏替代方案
- Explore #2: 評估影響範圍估計是否合理
Phase 3: 任一視角發現問題 → 回到分析階段補充
## 並行評估報告
**標的**: [範圍] **情境**: [A-G]
### 值得行動
| # | 視角 | 發現 | 幅度 | 風險 | 決策 |
|---|------|------|------|------|------|
### 延後追蹤（建 Ticket，不立即執行）
> **強制**：此表格每一行的 Ticket 欄必須填入實際 Ticket ID（格式如 `{version}-W{wave}-{seq}`）。空白 Ticket 欄 = 未追蹤 = 違反 quality-baseline 規則 5。
| # | 視角 | 發現 | 延後原因 | Ticket |
|---|------|------|---------|--------|
### 結構性錯誤模式（已記錄到 error-patterns/）
> 此區段僅在有結構性發現時出現。判斷標準：將發現中的專案名稱和檔案路徑替換為通用描述，如果仍然有意義 → 記錄。
| # | Pattern ID | 標題 | 來源發現 |
|---|-----------|------|---------|
### 結論
[總結]
/bulk-evaluate 的區別| 維度 | /parallel-evaluation | /bulk-evaluate |
|---|---|---|
| 並行軸 | N 個視角 x 1 組標的 | 1 個標準 x N 個單位 |
| 產出物 | 彙整報告（回到主線程） | N 個子 Ticket（不回主線程） |
| 適用 | 多角度快速評估 | 批量處理 + context 卸載 |
選擇原則：需要多角度掃描同一標的 → 本工具；需要用同一標準掃描 N 個獨立目標 → /bulk-evaluate
Last Updated: 2026-05-04
Version: 1.2.0 — 套用 compositional-writing 改寫（W17-135）：Worth-It Filter 段「核心原則 / 強制規則」改寫為三明示 Why / Consequence / Action，明示連結至 .claude/rules/core/decision-trigger-binding.md 規則 1 / 1.5；負向「禁止行為」保留並加正向錨點
Version: 1.1.0 - 新增 basil-writing-critic 常駐委員機制（情境 C/D/F/G 預設加入）+ --skip-basil opt-out 機制 + 常駐委員概念拆分（universal_lens / default_lens_per_scenario）（W17-069 / W17-066 R-3）