do

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/do - Smart Router

/do - 智能路由器

Operator Context

操作者上下文

This skill operates as the primary routing operator for the Claude Code agent system, classifying requests and dispatching them to specialized agents and skills. It implements the Router architectural pattern -- parse request, select agent, pair skill, execute -- with Domain Intelligence embedded in trigger matching and force-routing rules.

该Skill作为Claude Code Agent系统的主要路由操作者，负责对请求进行分类并将其分派给专门的Agent和Skill。它实现了路由器架构模式——解析请求、选择Agent、匹配Skill、执行——并在触发器匹配和强制路由规则中嵌入了领域智能。

Hardcoded Behaviors (Always Apply)

硬编码行为（始终适用）

CLAUDE.md Compliance: Read and follow repository CLAUDE.md before any routing decision
Over-Engineering Prevention: Route to the simplest agent+skill that satisfies the request. Do not stack unnecessary skills
Route Code Changes: NEVER edit code directly. Any code modification MUST be routed to a domain agent
Force-Route Compliance: When force-route triggers match, invoke that skill BEFORE any other action
Anti-Rationalization Injection: Auto-inject anti-rationalization patterns for code, review, security, and testing tasks
Plan Before Execute: Create
```
task_plan.md
```
for Simple+ complexity before routing to agents
Parallel First: Check for parallelizable patterns BEFORE standard sequential routing
Branch Safety: Route to agents that create branches; never allow direct main/master commits
Mandatory Pre-Merge Review Loop: For repos without organization-gated workflows, run up to 3 iterations of
```
/pr-review
```
→ fix before creating a PR. Fully automated: review, fix, re-review until clean or max 3 iterations. This is how we catch missed README updates, stale references, and quality gaps.
Organization-Gated Workflow: Repos under protected organizations (configured via
```
scripts/classify-repo.py
```
) require user confirmation before EACH git action: commit message approval, push approval, PR creation approval. NEVER auto-execute these steps. NEVER auto-merge. Their CI gates and human reviewers handle quality — we assist mindfully. Configure protected orgs by editing the classification script.
Routing Banner: ALWAYS display the routing decision banner as the FIRST visible output after classifying the request. This is mandatory — never skip it, never defer it to later in execution. Show the banner BEFORE creating plans, BEFORE invoking agents, BEFORE any work begins.
Creation Protocol: For any "create" or "new" request involving a significant component (pipeline, agent, skill, feature) at Simple+ complexity, automatically sequence: (1) ADR at
```
adr/[name].md
```
, (2) task plan at
```
task_plan.md
```
, (3) implementation via domain agent. The user should never need to say "do the ADR first, then plan, then implement" — this sequence IS the default. Show the full three-step sequence in the routing banner when a creation request is detected.

CLAUDE.md合规性：在做出任何路由决策前，阅读并遵循仓库中的CLAUDE.md
防止过度设计：将请求路由到能满足需求的最简单Agent+Skill组合。不要叠加不必要的Skill
路由代码变更：绝不直接编辑代码。任何代码修改都必须路由到领域Agent
强制路由合规：当强制路由触发器匹配时，在执行任何其他操作前先调用该Skill
反合理化注入：针对代码、评审、安全和测试任务自动注入反合理化模式
先规划后执行：对于复杂度为Simple+的任务，在路由到Agent前创建
```
task_plan.md
```
优先并行处理：在标准顺序路由前，先检查是否存在可并行处理的模式
分支安全：路由到会创建分支的Agent；绝不允许直接提交到main/master分支
强制合并前评审循环：对于没有组织级 gated 工作流的仓库，最多运行3轮
```
/pr-review
```
→ 修复循环，然后再创建PR。完全自动化：评审、修复、重新评审，直到无问题或达到最大3轮。这是我们捕获遗漏的README更新、过时引用和质量差距的方式。
组织级Gated工作流：受保护组织下的仓库（通过
```
scripts/classify-repo.py
```
配置）在执行每个Git操作前都需要用户确认：提交消息批准、推送批准、PR创建批准。绝不自动执行这些步骤。绝不自动合并。它们的CI gates和人工评审负责质量把控——我们仅提供辅助。可通过编辑分类脚本配置受保护组织。
路由横幅：在对请求进行分类后，必须首先显示路由决策横幅作为第一个可见输出。这是强制性要求——绝不能跳过，也不能推迟到执行后期显示。在创建计划、调用Agent、开始任何工作之前，都要显示该横幅。
创建协议：对于涉及重要组件（流水线、Agent、Skill、功能）且复杂度为Simple+的“创建”或“新建”请求，自动按以下顺序执行：(1) 在
```
adr/[name].md
```
编写ADR，(2) 在
```
task_plan.md
```
创建任务计划，(3) 通过领域Agent实现。用户无需明确说出“先做ADR，再做计划，然后实现”——这个顺序是默认的。当检测到创建请求时，在路由横幅中显示完整的三步序列。

Default Behaviors (ON unless disabled)

默认行为（启用状态，除非手动禁用）

Retro Knowledge Injection: Auto-inject accumulated knowledge from learning.db for cross-feature learning (benchmark: +5.3 avg, 67% win rate). Relevance-gated by FTS5 keyword matching.
Enhancement Stacking: Add verification-before-completion, TDD, or parallel reviewers when signals detected
MCP Auto-Invocation: Use Context7 for documentation lookups; use gopls MCP for Go workspace intelligence (symbols, diagnostics, references)
Dynamic Discovery: Check
```
agents/INDEX.json
```
first, fall back to static routing tables
Local Agent Discovery: Route to
```
.claude/agents/
```
local agents when
```
[cross-repo]
```
output is present
Auto-Pipeline Fallback: When no agent/skill matches, invoke auto-pipeline to classify the task type, select a canonical chain (8-12 steps), and execute with phase gates. In the toolkit repo, auto-crystallize into a permanent pipeline immediately.
Post-Task Learning: After Simple+ tasks, extract reusable patterns and record via
```
retro-record-adhoc
```
to build the knowledge store from all work, not just feature lifecycles

回溯知识注入：自动从learning.db中注入积累的知识，用于跨功能学习（基准数据：平均提升5.3，胜率67%）。通过FTS5关键词匹配进行相关性筛选。
增强叠加：当检测到相关信号时，添加完成前验证、TDD或并行评审等增强Skill
MCP自动调用：使用Context7进行文档查询；使用gopls MCP获取Go工作区智能（符号、诊断信息、引用）
动态发现：首先检查
```
agents/INDEX.json
```
，回退到静态路由表
本地Agent发现：当存在
```
[cross-repo]
```
输出时，路由到
```
.claude/agents/
```
下的本地Agent
自动流水线回退：当没有匹配的Agent/Skill时，调用自动流水线来分类任务类型，选择一个标准流程（8-12步），并通过阶段门执行。在工具包仓库中，立即将其固化为永久流水线。
任务后学习：在完成Simple+复杂度的任务后，提取可复用模式并通过
```
retro-record-adhoc
```
记录，从所有工作中构建知识存储，而不仅仅是功能生命周期。

Optional Behaviors (OFF unless enabled)

可选行为（禁用状态，除非手动启用）

Dry Run Mode: Show routing decision without executing
Verbose Routing: Explain why each alternative was rejected
Force Direct: Override routing for explicitly trivial operations

试运行模式：仅显示路由决策，不执行实际操作
详细路由：解释为什么拒绝每个备选方案
强制直接处理：为明确的琐碎操作覆盖路由规则

What This Skill CAN Do

该Skill能做什么

Route to any agent, skill, or command in the system
Decompose multi-part requests into parallel or sequential sub-tasks
Stack enhancement skills (TDD, verification, anti-rationalization) on top of primary routing
Detect force-route triggers and invoke mandatory skills
Launch up to 10 parallel agents in a single message

将请求路由到系统中的任何Agent、Skill或命令
将多部分请求分解为并行或串行子任务
在主路由之上叠加增强Skill（TDD、验证、反合理化）
检测强制路由触发器并调用必需的Skill
在单条消息中启动最多10个并行Agent

What This Skill CANNOT Do

该Skill不能做什么

Edit code directly (must route to a domain agent)
Override CLAUDE.md requirements or skip verification steps
Route to agents or skills that do not exist
Handle Medium+ complexity tasks without creating a plan first
Skip force-route triggers when they match

直接编辑代码（必须路由到领域Agent）
违反CLAUDE.md要求或跳过验证步骤
路由到不存在的Agent或Skill
在不先创建计划的情况下处理Medium+复杂度的任务
当强制路由触发器匹配时跳过该步骤

Instructions

说明

Phase Banners (MANDATORY)

阶段横幅（强制性要求）

Every phase of the /do pipeline MUST display a visible banner to the user BEFORE executing that phase's work. The user should always know what stage they're in.

Banner format:

───────────────────────────────────────────────────
 /do ► Phase N: PHASE_NAME
───────────────────────────────────────────────────

The full sequence the user sees:

/do ► Phase 0: PRE-CLASSIFY — running task-type classifier...
/do ► Phase 1: CLASSIFY — assessing complexity...
/do ► Phase 2: ROUTE — selecting agent + skill...

===================================================================
 ROUTING: [summary]                        ← full routing decision
===================================================================

/do ► Phase 3: ENHANCE — checking for enhancements...
/do ► Phase 4: EXECUTE — invoking [agent] with [skill]...
/do ► Phase 5: LEARN — capturing session insights...

Phase banners are short single-line indicators. The routing decision banner (the

===

block) is the detailed output shown after Phase 2 completes. Both are required — the phase banner tells the user where they are, the routing banner tells them what was decided.

/do流水线的每个阶段都必须在执行该阶段的工作前，向用户显示一个可见的横幅。用户应始终知道当前处于哪个阶段。

横幅格式：

───────────────────────────────────────────────────
 /do ► Phase N: PHASE_NAME
───────────────────────────────────────────────────

用户将看到的完整序列：

/do ► Phase 0: PRE-CLASSIFY — 运行任务类型分类器...
/do ► Phase 1: CLASSIFY — 评估复杂度...
/do ► Phase 2: ROUTE — 选择Agent + Skill...

===================================================================
 ROUTING: [摘要]                        ← 完整路由决策
===================================================================

/do ► Phase 3: ENHANCE — 检查增强项...
/do ► Phase 4: EXECUTE — 调用[agent]并使用[skill]...
/do ► Phase 5: LEARN — 捕获会话洞察...

阶段横幅是简短的单行指示器。路由决策横幅（

===

块）是在Phase 2完成后显示的详细输出。两者都是必需的——阶段横幅告诉用户当前位置，路由横幅告诉用户做出了什么决策。

Phase 0: DETERMINISTIC PRE-CLASSIFICATION (Mandatory)

Phase 0: 确定性预分类（强制性）

Goal: Run the task-type classifier script BEFORE any LLM-based routing to get a deterministic signal.

This phase is mandatory for every
/do
invocation except Trivial (exact file reads).

Step 0: Display phase banner FIRST, before running the script:

───────────────────────────────────────────────────
 /do ► Phase 0: PRE-CLASSIFY — running task-type classifier...
───────────────────────────────────────────────────

Step 1: Run the classifier:

bash

python3 ~/.claude/scripts/task-type-classifier.py --request "{user_request}" --check-catalog ~/.claude/skills/auto-pipeline/references/pipeline-catalog.json --json

Step 2: Read the JSON output. Three possible outcomes:

Output	Action
`"existing_pipeline": "pipeline-name"`	Route to that pipeline. Skip Phase 1-2 classification — the script found a match. Display banner and invoke the pipeline.
`"task_type": "analysis"` (or any type) + no existing pipeline	Record the classification. Proceed to Phase 1-2 normally. If Phase 2 finds no route, use this classification to invoke auto-pipeline (Step 5).
Script fails or returns error	Proceed normally. Phase 0 is advisory when the script fails — fall back to LLM-based routing.

Step 3: Display the Phase 0 result in the routing banner:

===================================================================
 ROUTING: [brief summary]
===================================================================

 Phase 0 classification: {task_type} | existing: {pipeline_name or "none"}
 ...
===================================================================

Why Phase 0 exists: The LLM will rationalize skipping auto-pipeline ("this seems simple enough to handle directly"). The script doesn't rationalize — it classifies deterministically. Phase 0 gives the router a data point to follow rather than a judgment call to make.

Anti-rationalization: If Phase 0 says

task_type: analysis

and Phase 2 finds no matching agent, you MUST invoke auto-pipeline. "I can handle this directly" is not an option when Phase 0 has classified it and no route exists.

Gate: Script output captured. Proceed to Phase 1.

目标：在任何基于LLM的路由之前，运行任务类型分类器脚本以获取确定性信号。

除了琐碎的（精确文件读取）请求外，每个
/do
调用都必须执行此阶段。

步骤0：在运行脚本前，首先显示阶段横幅：

───────────────────────────────────────────────────
 /do ► Phase 0: PRE-CLASSIFY — 运行任务类型分类器...
───────────────────────────────────────────────────

步骤1：运行分类器：

bash

python3 ~/.claude/scripts/task-type-classifier.py --request "{user_request}" --check-catalog ~/.claude/skills/auto-pipeline/references/pipeline-catalog.json --json

步骤2：读取JSON输出。有三种可能的结果：

输出	操作
`"existing_pipeline": "pipeline-name"`	路由到该流水线。跳过Phase 1-2分类——脚本找到了匹配项。显示横幅并调用该流水线。
`"task_type": "analysis"` （或其他类型）且无现有流水线	记录分类结果。正常进入Phase 1-2。如果Phase 2未找到路由，使用此分类结果调用自动流水线（步骤5）。
脚本失败或返回错误	正常继续。当脚本失败时，Phase 0仅作为参考——回退到基于LLM的路由。

步骤3：在路由横幅中显示Phase 0的结果：

===================================================================
 ROUTING: [简要摘要]
===================================================================

 Phase 0分类结果: {task_type} | 现有流水线: {pipeline_name 或 "无"}
 ...
===================================================================

Phase 0存在的原因：LLM会找理由跳过自动流水线（“这看起来足够简单，可以直接处理”）。而脚本不会进行合理化——它只是确定性地分类。Phase 0为路由器提供了一个可遵循的数据点，而非主观判断。

反合理化：如果Phase 0的结果为

task_type: analysis

且Phase 2未找到匹配的Agent，则必须调用自动流水线。当Phase 0已分类且无可用路由时，“我可以直接处理”不是可选方案。

阶段门：已捕获脚本输出。进入Phase 1。

Phase 1: CLASSIFY

Phase 1: 分类

Goal: Determine request complexity and whether routing is needed.

Display phase banner:

───────────────────────────────────────────────────
 /do ► Phase 1: CLASSIFY — assessing complexity...
───────────────────────────────────────────────────

Step 1: Assess complexity

Complexity	Agent	Skill	Direct Action
Trivial	No	No	ONLY reading a file the user named by exact path
Simple	Yes	Yes	Never
Medium	Required	Required	Never
Complex	Required (2+)	Required (2+)	Never

Trivial = reading a file the user named by exact path. That is the ONLY Trivial case. Everything else is Simple or above and MUST use an agent, skill, or pipeline.

Classification bias: when uncertain, classify UP not down. Over-routing costs tokens. Under-routing costs quality. Tokens are cheap.

NOT Trivial (route these — common misclassifications):

Evaluating external repos/URLs →
```
repo-value-analysis
```
(Simple)
Fetching and analyzing external content → Simple (requires judgment)
Any request requiring an opinion or recommendation → Simple
Shell commands needing interpretation → Simple
"Is this good?" / "What do you think?" → Simple (analysis)
"Check status of X" → route to appropriate skill
Git operations of any kind → route through git skills
Questions about the codebase →
```
explore-pipeline
```
or
```
codebase-overview
```
Looking up learning.db / retro stats →
```
retro
```
skill
Comparing approaches or trade-offs → Simple with appropriate agent

Maximize skill/agent/pipeline usage. The system has 90+ agents, 100+ skills, and 12+ pipelines. If a skill or pipeline exists for the task, USE IT — even if handling directly seems faster. The skill encodes methodology that improves output quality.

Banner requirement: Display the routing banner for ALL classifications including Trivial.

Step 2: Check for parallel patterns FIRST

Pattern	Detection	Route To
2+ independent test failures	Different files failing	dispatching-parallel-agents
3+ independent subtasks	Numbered list, "and also"	dispatching-parallel-agents
Research breadth needed	"research", "investigate" + broad scope	research-coordinator-engineer
Multi-agent orchestration	"coordinate", complex project	project-coordinator-engineer
Implementation with plan	Plan exists + "execute"	subagent-driven-development
Feature lifecycle	"new feature", "build feature", .feature/ exists	feature-design (entry point)

If a parallel pattern matches, route to the parallel mechanism FIRST.

Feature Lifecycle Detection: When user requests a new feature (not a bug fix or refactor), check for

.feature/

directory. If absent, route to

feature-design

as pipeline entry. If present, route to the skill matching the current phase (

feature-state.py status

determines this).

Gate: Complexity classified. Display routing banner (ALL classifications). If not Trivial, proceed to Phase 2. If Trivial, handle directly after showing banner.

目标：确定请求的复杂度以及是否需要路由。

显示阶段横幅：

───────────────────────────────────────────────────
 /do ► Phase 1: CLASSIFY — 评估复杂度...
───────────────────────────────────────────────────

步骤1：评估复杂度

复杂度	Agent	Skill	直接操作
Trivial（琐碎）	不需要	不需要	仅读取用户指定精确路径的文件
Simple（简单）	需要	需要	绝不允许
Medium（中等）	必须	必须	绝不允许
Complex（复杂）	必须（2+）	必须（2+）	绝不允许

Trivial = 读取用户指定精确路径的文件。这是唯一的Trivial情况。所有其他请求都属于Simple或更高复杂度，必须使用Agent、Skill或流水线。

分类偏差：当不确定时，向上分类而非向下。过度路由只会消耗token，而路由不足会影响质量。token成本低廉。

非Trivial情况（需要路由——常见误分类）：

评估外部仓库/URL →
```
repo-value-analysis
```
（Simple）
获取并分析外部内容 → Simple（需要判断）
任何需要意见或建议的请求 → Simple
需要解释的Shell命令 → Simple
“这个好吗？” / “你觉得怎么样？” → Simple（分析）
“检查X的状态” → 路由到相应Skill
任何Git操作 → 通过Git Skill路由
关于代码库的问题 →
```
explore-pipeline
```
或
```
codebase-overview
```
查询learning.db / 回溯统计数据 →
```
retro
```
Skill
比较方法或权衡 → Simple，搭配相应Agent

最大化Skill/Agent/流水线的使用率。系统拥有90+个Agent、100+个Skill和12+个流水线。如果存在适用于该任务的Skill或流水线，请使用它——即使直接处理看起来更快。Skill中编码了能提高输出质量的方法论。

横幅要求：对于所有分类结果（包括Trivial），都要显示路由横幅。

步骤2：首先检查并行模式

模式	检测条件	路由到
2+个独立测试失败	不同文件失败	dispatching-parallel-agents
3+个独立子任务	编号列表、“以及”	dispatching-parallel-agents
需要广泛研究	“research”、“investigate” + 广泛范围	research-coordinator-engineer
多Agent编排	“coordinate”、复杂项目	project-coordinator-engineer
带计划的实现	存在计划 + “execute”	subagent-driven-development
功能生命周期	“new feature”、“build feature”、.feature/目录存在	feature-design（入口点）

如果匹配到并行模式，首先路由到并行机制。

功能生命周期检测：当用户请求新功能（不是bug修复或重构）时，检查是否存在

.feature/

目录。如果不存在，路由到

feature-design

作为流水线入口。如果存在，路由到与当前阶段匹配的Skill（由

feature-state.py status

确定）。

阶段门：已完成复杂度分类。显示路由横幅（所有分类结果都需要）。如果不是Trivial，进入Phase 2。如果是Trivial，显示横幅后直接处理。

Phase 2: ROUTE

Phase 2: 路由

Goal: Select the correct agent + skill combination.

Display phase banner:

───────────────────────────────────────────────────
 /do ► Phase 2: ROUTE — selecting agent + skill...
───────────────────────────────────────────────────

Step 1: Check force-route triggers

These skills have MANDATORY routing. They MUST be invoked when triggers appear:

Skill	Triggers
go-testing	Go test, *_test.go, table-driven, t.Run, t.Helper, benchmark, mock
go-concurrency	goroutine, channel, sync.Mutex, WaitGroup, worker pool, fan-out, rate limit
go-error-handling	error handling, fmt.Errorf, errors.Is, errors.As, %w, sentinel error
go-code-review	review Go, Go PR, Go code review, check Go quality
go-anti-patterns	anti-pattern, code smell, over-engineering, premature abstraction
python-quality-gate	bandit, Python security scan, Python SAST
go-sapcc-conventions	sapcc, sap-cloud-infrastructure, go-bits, keppel, go-api-declarations, go-makefile-maker
create-voice	create voice, new voice, build voice, voice from samples, calibrate voice
voice-writer	write in voice, generate voice content, voice workflow, write article, blog post, draft article, write about, write post, blog about, create content
feature-design	design feature, feature design, think through feature, explore approaches
pre-planning-discussion	discuss ambiguities, resolve gray areas, clarify before planning, assumptions mode
feature-plan	plan feature, feature plan, break down design, create tasks
feature-implement	implement feature, execute plan, start building, feature implement
feature-validate	validate feature, run quality gates, feature validate
feature-release	release feature, merge feature, ship it, feature release
system-upgrade	upgrade agents, system upgrade, claude update, upgrade skills, apply claude update, apply update, new claude version, apply retro to system
de-ai-pipeline	de-ai docs, clean ai patterns, fix ai writing, scan and fix docs, remove ai tells
pr-sync	push, push this, push changes, commit and push, push to GitHub, sync to GitHub, create a PR, create PR, open PR, open pull request, ship this, send this
git-commit-flow	commit, commit this, commit changes, stage and commit
github-actions-check	check CI, CI status, actions status, did CI pass, are tests passing
fast	quick fix, typo fix, one-line change, trivial fix, rename variable, update value, fix import
quick	quick task, small change, ad hoc task, add a flag, extract function, small refactor, targeted fix
install	install toolkit, verify installation, health check toolkit, toolkit setup, /install

If a force-route trigger matches, invoke that skill BEFORE any other action.

Critical: "push", "commit", "create PR", "merge" are NOT trivial git commands. They MUST route through skills that run quality gates (lint, tests, review) before executing. Running raw

git push

gh pr create

without routing through pr-sync or pr-pipeline bypasses all quality gates.

Step 2: Select domain agent

Primary lookup:

agents/INDEX.json

. Fallback: table below.

Triggers	Agent	Default Skill
Go, Golang, .go, gofmt	golang-general-engineer	go-pr-quality-gate
Go (tight context)	golang-general-engineer-compact	go-pr-quality-gate
Go + sapcc (go-bits, keppel)	golang-general-engineer	go-sapcc-conventions
Python, .py, pip, pytest	python-general-engineer	python-quality-gate
Python + OpenStack	python-openstack-engineer	python-quality-gate
TypeScript, .ts	typescript-frontend-engineer	universal-quality-gate
React, Next.js	typescript-frontend-engineer	verification-before-completion
React portfolio	react-portfolio-engineer	distinctive-frontend-design
Next.js e-commerce	nextjs-ecommerce-engineer	verification-before-completion
Node.js, Express, API	nodejs-api-engineer	systematic-code-review
SQLite, Peewee	sqlite-peewee-engineer	verification-before-completion
Database, PostgreSQL	database-engineer	verification-before-completion
Kubernetes, Helm, K8s	kubernetes-helm-engineer	verification-before-completion
Ansible, playbook	ansible-automation-engineer	verification-before-completion
Prometheus, Grafana	prometheus-grafana-engineer	verification-before-completion
OpenSearch, Elasticsearch	opensearch-elasticsearch-engineer	verification-before-completion
RabbitMQ, messaging	rabbitmq-messaging-engineer	verification-before-completion
MCP, docs server	mcp-local-docs-engineer	verification-before-completion
UI, design, Tailwind	ui-design-engineer	distinctive-frontend-design
Performance, speed	performance-optimization-engineer	verification-before-completion
Testing, E2E, Playwright	testing-automation-engineer	test-driven-development
Documentation, README	technical-documentation-engineer	comment-quality
Articles, journalism	technical-journalist-writer	professional-communication
TypeScript debug, async bug, race condition	typescript-debugging-engineer	systematic-debugging
Nano Banana, Gemini image web app	typescript-frontend-engineer	nano-banana-builder
Python image generation, AI sprite	python-general-engineer	gemini-image-generator
Three.js, 3D web, WebGL	typescript-frontend-engineer	threejs-builder
image to video, audio visualization	(skill only)	image-to-video

Step 3: Select task-type agent (if no domain agent matches)

Triggers	Agent	Skill
create pipeline, new pipeline, scaffold pipeline, build pipeline	pipeline-orchestrator-engineer	pipeline-scaffolder
upgrade agents, system upgrade, claude update, upgrade skills	system-upgrade-engineer	system-upgrade
github rules, profile analysis, coding style extraction	github-profile-rules-engineer	github-profile-rules
create agent, new agent	agent-creator-engineer	agent-evaluation
create skill, new skill	skill-creator-engineer	agent-evaluation
create hook, event handler	hook-development-engineer	verification-before-completion
research, investigate	research-coordinator-engineer	workflow-orchestrator
coordinate, multi-agent	project-coordinator-engineer	workflow-orchestrator
roast, critique	(roast skill runs 5 personas)	roast
research subtask, delegated research	research-subagent-executor	(internal)
security review, OWASP, XSS	reviewer-security	systematic-code-review
business logic, domain review	reviewer-business-logic	systematic-code-review

Step 4: Apply skill override (task verb overrides default skill)

Task Verb	Use This Skill Instead
review, check	systematic-code-review
debug, fix bug	systematic-debugging
implement, build	workflow-orchestrator
refactor, rename	systematic-refactoring
TDD, test first	test-driven-development

For complete category-specific skill routing, see

references/routing-tables.md

Step 6: Display routing decision (MANDATORY — do this NOW, before anything else)

For standard skills:

===================================================================
 ROUTING: [brief summary]
===================================================================

 Selected:
   -> Agent: [name] - [why]
   -> Skill: [name] - [why]
   -> Anti-Rationalization: [auto-injected for code/security/testing]

 Invoking...
===================================================================

For pipeline skills — add the Pipeline: line with all phases in order:

===================================================================
 ROUTING: [brief summary]
===================================================================

 Selected:
   -> Agent: [name]
   -> Skill: [name] ([N]-phase pipeline)
   Pipeline: PHASE1 → PHASE2 → PHASE3 → ... → PHASEN

 Invoking...
===================================================================

Pipeline Phase Registry — all pipelines live in

pipelines/

(synced to

~/.claude/skills/

at install):

Pipeline	Phases
`system-upgrade`	CHANGELOG → AUDIT → PLAN → IMPLEMENT → VALIDATE → DEPLOY
`skill-creation-pipeline`	DISCOVER → DESIGN → SCAFFOLD → VALIDATE → INTEGRATE
`hook-development-pipeline`	SPEC → IMPLEMENT → TEST → REGISTER → DOCUMENT
`research-pipeline`	SCOPE → GATHER → SYNTHESIZE → VALIDATE → DELIVER
`agent-upgrade`	AUDIT → DIFF → PLAN → IMPLEMENT → RE-EVALUATE
`explore-pipeline`	SCAN → MAP → ANALYZE → REPORT
`research-to-article`	RESEARCH → COMPILE → GROUND → GENERATE → VALIDATE → REFINE → OUTPUT
`pr-pipeline`	CLASSIFY → STAGE → REVIEW → COMMIT → PUSH → CREATE → VERIFY → CLEANUP
`voice-writer`	LOAD → GROUND → GENERATE → VALIDATE → REFINE → JOY-CHECK → OUTPUT → CLEANUP
`github-profile-rules`	ADR → FETCH → RESEARCH → SAMPLE → COMPILE → GENERATE → VALIDATE → OUTPUT
`doc-pipeline`	RESEARCH → OUTLINE → GENERATE → VERIFY → OUTPUT
`workflow-orchestrator`	BRAINSTORM → WRITE-PLAN → EXECUTE-PLAN
`de-ai-pipeline`	SCAN → FIX → VERIFY (loop max 3) → REPORT
`comprehensive-review`	WAVE-0 → WAVE-1 → WAVE-2 → AGGREGATE → FIX
`article-evaluation-pipeline`	FETCH → VALIDATE → ANALYZE → REPORT
`mcp-pipeline-builder`	ANALYZE → DESIGN → GENERATE → VALIDATE → EVALUATE → REGISTER
`do-perspectives`	VALIDATE → ANALYZE → SYNTHESIZE → APPLY → VERIFY
`voice-calibrator`	VOICE-GROUNDING → VOICE-METRICS → THINKING-PATTERNS → VALIDATION
`auto-pipeline`	DEDUP → CLASSIFY → SELECT → ADAPT → EXECUTE (ephemeral) or CRYSTALLIZE (permanent)

Pipeline Companion Sequences — common multi-pipeline workflows:

Workflow	Sequence
Pipeline creation	domain-research → chain-composer → pipeline-scaffolder → pipeline-test-runner → pipeline-retro
Content creation	research-pipeline → voice-writer
Feature delivery	explore-pipeline → workflow-orchestrator → pr-pipeline
Code review + ship	comprehensive-review → pr-pipeline
Voice development	voice-calibrator → voice-writer → article-evaluation-pipeline

If a skill is not in this registry but has explicit phases in its SKILL.md, show those phases. If it's not a pipeline, omit the Pipeline: line entirely.

For Trivial classification (file reads only):

===================================================================
 ROUTING: [brief summary]
===================================================================

 Classification: Trivial - [why: e.g., "user asked to read a specific file"]
 Handling directly (no agent/skill needed)

===================================================================

This banner MUST be the FIRST visible output for EVERY /do invocation — including Trivial. Display it immediately after classifying, BEFORE any work begins. No exceptions.

Gate: Agent and skill selected. Banner displayed. Proceed to Phase 3.

目标：选择正确的Agent + Skill组合。

显示阶段横幅：

───────────────────────────────────────────────────
 /do ► Phase 2: ROUTE — 选择Agent + Skill...
───────────────────────────────────────────────────

步骤1：检查强制路由触发器

以下Skill具有强制性路由。当触发器出现时，必须调用它们：

Skill	触发器
go-testing	Go test、*_test.go、table-driven、t.Run、t.Helper、benchmark、mock
go-concurrency	goroutine、channel、sync.Mutex、WaitGroup、worker pool、fan-out、rate limit
go-error-handling	error handling、fmt.Errorf、errors.Is、errors.As、%w、sentinel error
go-code-review	review Go、Go PR、Go code review、check Go quality
go-anti-patterns	anti-pattern、code smell、over-engineering、premature abstraction
python-quality-gate	bandit、Python security scan、Python SAST
go-sapcc-conventions	sapcc、sap-cloud-infrastructure、go-bits、keppel、go-api-declarations、go-makefile-maker
create-voice	create voice、new voice、build voice、voice from samples、calibrate voice
voice-writer	write in voice、generate voice content、voice workflow、write article、blog post、draft article、write about、write post、blog about、create content
feature-design	design feature、feature design、think through feature、explore approaches
pre-planning-discussion	discuss ambiguities、resolve gray areas、clarify before planning、assumptions mode
feature-plan	plan feature、feature plan、break down design、create tasks
feature-implement	implement feature、execute plan、start building、feature implement
feature-validate	validate feature、run quality gates、feature validate
feature-release	release feature、merge feature、ship it、feature release
system-upgrade	upgrade agents、system upgrade、claude update、upgrade skills、apply claude update、apply update、new claude version、apply retro to system
de-ai-pipeline	de-ai docs、clean ai patterns、fix ai writing、scan and fix docs、remove ai tells
pr-sync	push、push this、push changes、commit and push、push to GitHub、sync to GitHub、create a PR、create PR、open PR、open pull request、ship this、send this
git-commit-flow	commit、commit this、commit changes、stage and commit
github-actions-check	check CI、CI status、actions status、did CI pass、are tests passing
fast	quick fix、typo fix、one-line change、trivial fix、rename variable、update value、fix import
quick	quick task、small change、ad hoc task、add a flag、extract function、small refactor、targeted fix
install	install toolkit、verify installation、health check toolkit、toolkit setup、/install

如果匹配到强制路由触发器，在执行任何其他操作前先调用该Skill。

关键提示：“push”、“commit”、“create PR”、“merge”不是琐碎的Git命令。必须路由到会在执行前运行质量 gates（lint、测试、评审）的Skill。直接运行

git push

或

gh pr create

而不通过pr-sync或pr-pipeline路由会绕过所有质量 gates。

步骤2：选择领域Agent

主要查询：

agents/INDEX.json

。回退：下表。

触发器	Agent	默认Skill
Go、Golang、.go、gofmt	golang-general-engineer	go-pr-quality-gate
Go（紧凑上下文）	golang-general-engineer-compact	go-pr-quality-gate
Go + sapcc（go-bits、keppel）	golang-general-engineer	go-sapcc-conventions
Python、.py、pip、pytest	python-general-engineer	python-quality-gate
Python + OpenStack	python-openstack-engineer	python-quality-gate
TypeScript、.ts	typescript-frontend-engineer	universal-quality-gate
React、Next.js	typescript-frontend-engineer	verification-before-completion
React作品集	react-portfolio-engineer	distinctive-frontend-design
Next.js电商	nextjs-ecommerce-engineer	verification-before-completion
Node.js、Express、API	nodejs-api-engineer	systematic-code-review
SQLite、Peewee	sqlite-peewee-engineer	verification-before-completion
Database、PostgreSQL	database-engineer	verification-before-completion
Kubernetes、Helm、K8s	kubernetes-helm-engineer	verification-before-completion
Ansible、playbook	ansible-automation-engineer	verification-before-completion
Prometheus、Grafana	prometheus-grafana-engineer	verification-before-completion
OpenSearch、Elasticsearch	opensearch-elasticsearch-engineer	verification-before-completion
RabbitMQ、messaging	rabbitmq-messaging-engineer	verification-before-completion
MCP、docs server	mcp-local-docs-engineer	verification-before-completion
UI、design、Tailwind	ui-design-engineer	distinctive-frontend-design
Performance、speed	performance-optimization-engineer	verification-before-completion
Testing、E2E、Playwright	testing-automation-engineer	test-driven-development
Documentation、README	technical-documentation-engineer	comment-quality
Articles、journalism	technical-journalist-writer	professional-communication
TypeScript debug、async bug、race condition	typescript-debugging-engineer	systematic-debugging
Nano Banana、Gemini图像Web应用	typescript-frontend-engineer	nano-banana-builder
Python图像生成、AI sprite	python-general-engineer	gemini-image-generator
Three.js、3D web、WebGL	typescript-frontend-engineer	threejs-builder
image to video、audio visualization	（仅Skill）	image-to-video

步骤3：选择任务类型Agent（如果没有匹配的领域Agent）

触发器	Agent	Skill
create pipeline、new pipeline、scaffold pipeline、build pipeline	pipeline-orchestrator-engineer	pipeline-scaffolder
upgrade agents、system upgrade、claude update、upgrade skills	system-upgrade-engineer	system-upgrade
github rules、profile analysis、coding style extraction	github-profile-rules-engineer	github-profile-rules
create agent、new agent	agent-creator-engineer	agent-evaluation
create skill、new skill	skill-creator-engineer	agent-evaluation
create hook、event handler	hook-development-engineer	verification-before-completion
research、investigate	research-coordinator-engineer	workflow-orchestrator
coordinate、multi-agent	project-coordinator-engineer	workflow-orchestrator
roast、critique	（roast Skill运行5个角色）	roast
research subtask、delegated research	research-subagent-executor	（内部）
security review、OWASP、XSS	reviewer-security	systematic-code-review
business logic、domain review	reviewer-business-logic	systematic-code-review

步骤4：应用Skill覆盖（任务动词覆盖默认Skill）

任务动词	使用该Skill替代默认Skill
review、check	systematic-code-review
debug、fix bug	systematic-debugging
implement、build	workflow-orchestrator
refactor、rename	systematic-refactoring
TDD、test first	test-driven-development

完整的特定类别Skill路由，请参阅

references/routing-tables.md

。

步骤6：显示路由决策（强制性要求——立即执行，不要做其他事情）

对于标准Skill：

===================================================================
 ROUTING: [简要摘要]
===================================================================

 已选择:
   -> Agent: [名称] - [原因]
   -> Skill: [名称] - [原因]
   -> 反合理化: [针对代码/安全/测试自动注入]

 正在调用...
===================================================================

对于流水线Skill——添加Pipeline行，按顺序列出所有阶段：

===================================================================
 ROUTING: [简要摘要]
===================================================================

 已选择:
   -> Agent: [名称]
   -> Skill: [名称] ([N]阶段流水线)
   流水线: PHASE1 → PHASE2 → PHASE3 → ... → PHASEN

 正在调用...
===================================================================

流水线阶段注册表——所有流水线都位于

pipelines/

（安装时同步到

~/.claude/skills/

）：

流水线	阶段
`system-upgrade`	CHANGELOG → AUDIT → PLAN → IMPLEMENT → VALIDATE → DEPLOY
`skill-creation-pipeline`	DISCOVER → DESIGN → SCAFFOLD → VALIDATE → INTEGRATE
`hook-development-pipeline`	SPEC → IMPLEMENT → TEST → REGISTER → DOCUMENT
`research-pipeline`	SCOPE → GATHER → SYNTHESIZE → VALIDATE → DELIVER
`agent-upgrade`	AUDIT → DIFF → PLAN → IMPLEMENT → RE-EVALUATE
`explore-pipeline`	SCAN → MAP → ANALYZE → REPORT
`research-to-article`	RESEARCH → COMPILE → GROUND → GENERATE → VALIDATE → REFINE → OUTPUT
`pr-pipeline`	CLASSIFY → STAGE → REVIEW → COMMIT → PUSH → CREATE → VERIFY → CLEANUP
`voice-writer`	LOAD → GROUND → GENERATE → VALIDATE → REFINE → JOY-CHECK → OUTPUT → CLEANUP
`github-profile-rules`	ADR → FETCH → RESEARCH → SAMPLE → COMPILE → GENERATE → VALIDATE → OUTPUT
`doc-pipeline`	RESEARCH → OUTLINE → GENERATE → VERIFY → OUTPUT
`workflow-orchestrator`	BRAINSTORM → WRITE-PLAN → EXECUTE-PLAN
`de-ai-pipeline`	SCAN → FIX → VERIFY（最多3轮循环）→ REPORT
`comprehensive-review`	WAVE-0 → WAVE-1 → WAVE-2 → AGGREGATE → FIX
`article-evaluation-pipeline`	FETCH → VALIDATE → ANALYZE → REPORT
`mcp-pipeline-builder`	ANALYZE → DESIGN → GENERATE → VALIDATE → EVALUATE → REGISTER
`do-perspectives`	VALIDATE → ANALYZE → SYNTHESIZE → APPLY → VERIFY
`voice-calibrator`	VOICE-GROUNDING → VOICE-METRICS → THINKING-PATTERNS → VALIDATION
`auto-pipeline`	DEDUP → CLASSIFY → SELECT → ADAPT → EXECUTE（临时）或CRYSTALLIZE（永久）

流水线配套序列——常见的多流水线工作流：

工作流	序列
流水线创建	domain-research → chain-composer → pipeline-scaffolder → pipeline-test-runner → pipeline-retro
内容创作	research-pipeline → voice-writer
功能交付	explore-pipeline → workflow-orchestrator → pr-pipeline
代码评审 + 交付	comprehensive-review → pr-pipeline
语音开发	voice-calibrator → voice-writer → article-evaluation-pipeline

如果某个Skill不在此注册表中，但在其SKILL.md中有明确的阶段，则显示这些阶段。如果不是流水线，则完全省略Pipeline行。

对于Trivial分类（仅文件读取）：

===================================================================
 ROUTING: [简要摘要]
===================================================================

 分类结果: Trivial - [原因：例如“用户要求读取特定文件”]
 直接处理（无需Agent/Skill）

===================================================================

该横幅必须是每个/do调用的第一个可见输出——包括Trivial请求。在分类后立即显示，然后再开始任何工作。无例外。

阶段门：已选择Agent和Skill。已显示横幅。进入Phase 3。

Phase 3: ENHANCE

Phase 3: 增强

Goal: Stack additional skills based on signals in the request.

Display phase banner:

───────────────────────────────────────────────────
 /do ► Phase 3: ENHANCE — checking for enhancements...
───────────────────────────────────────────────────

Signal in Request	Enhancement to Add
Any substantive work (code, design, plan)	Auto-inject retro knowledge (from learning.db via `retro-knowledge-injector` hook)
"comprehensive" / "thorough" / "full"	Add parallel reviewers (security + business + quality)
"with tests" / "production ready"	Append test-driven-development + verification-before-completion
"research needed" / "investigate first"	Prepend research-coordinator-engineer
Multiple independent problems (2+)	Use dispatching-parallel-agents
"review" with 5+ files	Use parallel-code-review (3 reviewers)
Complex implementation	Offer subagent-driven-development

Auto-inject retro knowledge (DEFAULT ON — benchmark validated: +5.3 avg, 67% win rate):

The

retro-knowledge-injector

hook automatically queries learning.db (FTS5) when:

The prompt indicates substantive work (not trivial lookups)
Keywords match entries in the database (relevance gate)
The knowledge store has non-graduated entries above confidence threshold

This is the system's cross-feature learning mechanism. Agents receiving retro knowledge should:

Adapt, don't copy — note where patterns apply AND where they don't
Document transfer — explicitly state which prior learnings were reused
Skip when irrelevant — if the injected content doesn't apply, ignore it entirely

Auto-inject anti-rationalization for these task types:

Task Type	Patterns Injected
Code modification	anti-rationalization-core, verification-checklist
Code review	anti-rationalization-core, anti-rationalization-review
Security work	anti-rationalization-core, anti-rationalization-security
Testing	anti-rationalization-core, anti-rationalization-testing
Debugging	anti-rationalization-core, verification-checklist
External content evaluation	untrusted-content-handling (Reddit, WordPress, Bluesky, any external user-generated text)

For explicit maximum rigor, use

/with-anti-rationalization [task]

Gate: Enhancements applied. Proceed to Phase 4.

目标：根据请求中的信号叠加额外的Skill。

显示阶段横幅：

───────────────────────────────────────────────────
 /do ► Phase 3: ENHANCE — 检查增强项...
───────────────────────────────────────────────────

请求中的信号	要添加的增强项
任何实质性工作（代码、设计、计划）	自动注入回溯知识（通过 `retro-knowledge-injector` 钩子从learning.db获取）
“comprehensive” / “thorough” / “full”	添加并行评审（安全 + 业务 + 质量）
“with tests” / “production ready”	追加test-driven-development + verification-before-completion
“research needed” / “investigate first”	前置research-coordinator-engineer
多个独立问题（2+）	使用dispatching-parallel-agents
“review”且涉及5+个文件	使用parallel-code-review（3个评审者）
复杂实现	提供subagent-driven-development

自动注入回溯知识（默认启用——基准验证：平均提升5.3，胜率67%）：

当满足以下条件时，

retro-knowledge-injector

钩子会自动查询learning.db（FTS5）：

提示表明是实质性工作（非琐碎查询）
关键词与数据库中的条目匹配（相关性筛选）
知识存储中有高于置信度阈值的未毕业条目

这是系统的跨功能学习机制。接收回溯知识的Agent应：

适配，而非复制——记录模式适用和不适用的场景
记录知识转移——明确说明复用了哪些先前的经验
无关时跳过——如果注入的内容不适用，完全忽略它

针对以下任务类型自动注入反合理化模式：

任务类型	注入的模式
代码修改	anti-rationalization-core、verification-checklist
代码评审	anti-rationalization-core、anti-rationalization-review
安全工作	anti-rationalization-core、anti-rationalization-security
测试	anti-rationalization-core、anti-rationalization-testing
调试	anti-rationalization-core、verification-checklist
外部内容评估	untrusted-content-handling（Reddit、WordPress、Bluesky、任何外部用户生成的文本）

如需明确的最高严谨性，使用

/with-anti-rationalization [任务]

。

阶段门：已应用增强项。进入Phase 4。

Phase 4: EXECUTE

Phase 4: 执行

Goal: Invoke the selected agent + skill and deliver results.

Display phase banner (include the agent and skill names):

───────────────────────────────────────────────────
 /do ► Phase 4: EXECUTE — invoking {agent} with {skill}...
───────────────────────────────────────────────────

Step 0: Execute Creation Protocol (for creation requests ONLY)

Detect creation requests by checking if the request contains: "create", "new", "scaffold", "build pipeline", "build agent", "build skill", "build hook". If detected AND complexity is Simple+:

1. Write ADR: adr/{kebab-case-name}.md
   - Include: Context, Decision, Component list, Consequences
2. Register session: python3 ~/.claude/scripts/adr-query.py register --adr adr/{name}.md
3. Display in banner: "ADR: adr/{name}.md (registered)"
4. Proceed to Step 1 (plan creation)

If NOT a creation request, skip to Step 1. The ADR session persists across sub-agent dispatches. The

adr-context-injector

hook injects relevant ADR sections into every sub-agent prompt. The

adr-enforcement

hook checks compliance after every Write/Edit.

Step 1: Create plan (for Simple+ complexity)

Create

task_plan.md

before execution. The

auto-plan-detector.py

hook auto-detects and injects

<auto-plan-required>

context. See

skills/planning-with-files/SKILL.md

for template. Skip only for Trivial tasks.

Step 2: Retro knowledge injection

The

retro-knowledge-injector

hook automatically queries learning.db and injects relevant knowledge into agent context via

<retro-knowledge>

blocks. No manual injection step is needed — the hook handles this on every

UserPromptSubmit

Step 2.5: Inject MCP tool discovery into agent dispatch prompt

MCP server instructions are injected into the main session but NOT propagated to subagents. Subagents have MCP tools available as deferred tools but don't know to use

ToolSearch

to activate them. When dispatching agents, include this block in the agent prompt:

MCP TOOL DISCOVERY (do this FIRST, before reading code):
- Use ToolSearch("gopls") to check for Go analysis tools (go_file_context,
  go_diagnostics, go_symbol_references, go_package_api). If found AND
  working in a Go repo: use go_file_context after reading .go files,
  go_diagnostics after edits, go_symbol_references before renaming.
- Use ToolSearch("context7") to check for library documentation tools
  (resolve-library-id, query-docs). If found: use for verifying library
  API usage and looking up unfamiliar dependencies.
- Use ToolSearch("chrome-devtools") to check for browser inspection tools
  (list_pages, navigate_page, take_screenshot, lighthouse_audit,
  list_console_messages, list_network_requests). If found: use for live
  browser debugging, page inspection, and performance profiling tasks.
- If ToolSearch returns no results for any of these, proceed without them.

When to include: Include gopls block when dispatching Go-related agents (

golang-general-engineer

golang-general-engineer-compact

, or any agent working on

.go

files). Include Context7 block for any agent that may encounter library/dependency questions. Include chrome-devtools block when dispatching agents that need to inspect live browser pages (performance-optimization-engineer, testing-automation-engineer, or any agent working on frontend debugging). Skip entirely for trivial tasks or non-code agents.

Step 3: Invoke agent with skill

Let the agent do the work. Do not intervene in agent execution.

Step 4: Handle multi-part requests

Detect: "first...then", "and also", numbered lists, semicolons.

Sequential dependencies: Execute in order
Independent items: Launch multiple Task tools in single message
Max parallelism: 10 agents

Step 5: Auto-Pipeline Fallback (uses Phase 0 output)

When no agent/skill matches AND complexity >= Simple:

Check Phase 0 output: The classifier already ran in Phase 0. Use its result — do NOT re-run the script.
If Phase 0 found existing pipeline: You should have routed to it in Phase 0 Step 2. If you're here, something went wrong — re-check Phase 0 output.
If Phase 0 classified a task type: Invoke
```
auto-pipeline
```
with the classified type. The auto-pipeline skill will:
- Select and adapt a canonical chain (8-12 steps)
- In toolkit repo: crystallize into permanent pipeline immediately, then execute
- In other repos: execute ephemeral chain (crystallize after 3+ runs)
If Phase 0 failed or returned no classification: Fall back to closest agent + verification-before-completion as safety net.

CRITICAL: If Phase 0 classified a task type and you're at Step 5 with no route, invoking auto-pipeline is MANDATORY. "Handle directly" is not an option — the script has already determined this needs structured execution.

When uncertain which route: ROUTE ANYWAY. Route to the most likely agent + skill, add verification-before-completion as safety net, let the agent ask clarifying questions.

Gate: Agent invoked, results delivered. Proceed to Phase 5.

目标：调用选定的Agent + Skill并交付结果。

显示阶段横幅（包含Agent和Skill名称）：

───────────────────────────────────────────────────
 /do ► Phase 4: EXECUTE — 调用{agent}并使用{skill}...
───────────────────────────────────────────────────

步骤0：执行创建协议（仅适用于创建请求）

通过检查请求中是否包含“create”、“new”、“scaffold”、“build pipeline”、“build agent”、“build skill”、“build hook”来检测创建请求。如果检测到且复杂度为Simple+：

1. 编写ADR: adr/{kebab-case-name}.md
   - 包含：上下文、决策、组件列表、后果
2. 注册会话: python3 ~/.claude/scripts/adr-query.py register --adr adr/{name}.md
3. 在横幅中显示: "ADR: adr/{name}.md（已注册）"
4. 进入步骤1（创建计划）

如果不是创建请求，跳过到步骤1。ADR会话在子Agent分派过程中持续存在。

adr-context-injector

钩子会将相关ADR部分注入到每个子Agent的提示中。

adr-enforcement

钩子会在每次写入/编辑后检查合规性。

步骤1：创建计划（适用于Simple+复杂度）

在执行前创建

task_plan.md

。

auto-plan-detector.py

钩子会自动检测并注入

<auto-plan-required>

上下文。模板请参阅

skills/planning-with-files/SKILL.md

。仅Trivial任务可跳过此步骤。

步骤2：回溯知识注入

retro-knowledge-injector

钩子会自动查询learning.db，并通过

<retro-knowledge>

块将相关知识注入到Agent上下文中。无需手动注入——钩子会在每次

UserPromptSubmit

时处理此操作。

步骤2.5：将MCP工具发现注入到Agent分派提示中

MCP服务器说明仅注入到主会话中，不会传播到子Agent。子Agent的上下文中会显示MCP工具作为延迟工具，但除非被告知调用

ToolSearch

，否则Agent不会使用它们。在分派Agent时，必须在Agent提示中包含以下块：

MCP工具发现（请首先执行，然后再读取代码）：
- 使用ToolSearch("gopls")检查Go分析工具（go_file_context,
  go_diagnostics, go_symbol_references, go_package_api）。如果找到且在Go仓库中工作：在读取.go文件后使用go_file_context，
  在编辑后使用go_diagnostics，在重命名前使用go_symbol_references。
- 使用ToolSearch("context7")检查库文档工具
  （resolve-library-id, query-docs）。如果找到：用于验证库
  API使用情况和查找不熟悉的依赖项。
- 使用ToolSearch("chrome-devtools")检查浏览器检查工具
  （list_pages, navigate_page, take_screenshot, lighthouse_audit,
  list_console_messages, list_network_requests）。如果找到：用于实时
  浏览器调试、页面检查和性能分析任务。
- 如果ToolSearch对上述任何工具返回无结果，则继续执行，不使用它们。

何时包含：当分派与Go相关的Agent（

golang-general-engineer

、

golang-general-engineer-compact

或任何处理

.go

文件的Agent）时，包含gopls块。对于可能遇到库/依赖问题的任何Agent，包含Context7块。当分派需要检查实时浏览器页面的Agent（performance-optimization-engineer、testing-automation-engineer或任何处理前端调试的Agent）时，包含chrome-devtools块。对于琐碎任务或非代码Agent，完全跳过。

步骤3：调用Agent和Skill

让Agent完成工作。不要干预Agent的执行。

步骤4：处理多部分请求

检测以下情况：“first...then”、“and also”、编号列表、分号。

顺序依赖：按顺序执行
独立项：在单条消息中启动多个Task工具
最大并行数：10个Agent

步骤5：自动流水线回退（使用Phase 0输出）

当没有匹配的Agent/Skill且复杂度 >= Simple时：

检查Phase 0输出：分类器已在Phase 0中运行。使用其结果——不要重新运行脚本。
如果Phase 0找到现有流水线：你应该已在Phase 0步骤2中路由到该流水线。如果仍在此处，说明出现了问题——重新检查Phase 0输出。
如果Phase 0已分类任务类型：调用
```
auto-pipeline
```
并传入分类后的类型。auto-pipeline Skill会：
- 选择并适配一个标准流程（8-12步）
- 在工具包仓库中：立即固化为永久流水线，然后执行
- 在其他仓库中：执行临时流程（运行3+次后固化）
如果Phase 0失败或未返回分类结果：回退到最接近的Agent + verification-before-completion作为安全网。

关键提示：如果Phase 0已分类任务类型且你处于步骤5且无可用路由，则必须调用auto-pipeline。“直接处理”不是可选方案——脚本已确定此任务需要结构化执行。

当不确定路由时：无论如何都要路由。路由到最可能的Agent + Skill，添加verification-before-completion作为安全网，让Agent提出澄清问题。

阶段门：已调用Agent，已交付结果。进入Phase 5。

Phase 5: LEARN

Phase 5: 学习

Goal: Ensure session insights are captured to

learning.db

Display phase banner:

───────────────────────────────────────────────────
 /do ► Phase 5: LEARN — capturing session insights...
───────────────────────────────────────────────────

Auto-capture (hooks, zero LLM cost):

```
error-learner.py
```
(PostToolUse) → captures tool errors + solutions
```
review-capture.py
```
(PostToolUse) → captures review agent findings
```
session-learning-recorder.py
```
(Stop) → warns on substantive sessions with no learnings

Skill-scoped recording (preferred — low friction, one-liner):

bash

python3 ~/.claude/scripts/learning-db.py learn --skill go-testing "insight about testing"
python3 ~/.claude/scripts/learning-db.py learn --agent golang-general-engineer "insight about agent"
python3 ~/.claude/scripts/learning-db.py learn "general insight without scope"

Skill-scoped entries (topic=

skill:{name}

agent:{name}

) are automatically injected when that skill/agent is relevant to a future prompt. Use after any substantive task.

Legacy recording (for entries that don't map to a specific skill/agent):

bash

python3 ~/.claude/scripts/learning-db.py record TOPIC KEY "VALUE" --category CATEGORY

Record specific, actionable insights — not generic advice. "Force-route triggers must not contain sibling skill names" is good. "Be careful with routing" is not.

Immediate graduation for review findings (MANDATORY):

When a wave review finds an issue and it gets fixed in the same PR, the fix IS the validation. Do not passively record at 0.7 and wait. Instead:

Record the learning scoped to the responsible agent/skill

Boost to confidence 1.0 immediately (

python3 ~/.claude/scripts/learning-db.py boost TOPIC KEY

x3)

Embed the pattern into the agent/skill's FORBIDDEN patterns or anti-patterns section

Graduate the entry (

python3 ~/.claude/scripts/learning-db.py graduate TOPIC KEY "target.md"

)

Stage the agent/skill changes alongside the code changes in the same PR

One cycle. Review finds it → fix it → record at 1.0 → graduate into agent → ship together. No waiting for "multiple observations." The PR review was the observation.

Gate: After Simple+ tasks, record at least one learning via

learn

. Review findings get immediate graduation. Hooks handle error capture automatically.

目标：确保将会话洞察捕获到

learning.db

中。

显示阶段横幅：

───────────────────────────────────────────────────
 /do ► Phase 5: LEARN — 捕获会话洞察...
───────────────────────────────────────────────────

自动捕获（钩子，无LLM成本）：

```
error-learner.py
```
（PostToolUse）→ 捕获工具错误 + 解决方案
```
review-capture.py
```
（PostToolUse）→ 捕获评审Agent的发现
```
session-learning-recorder.py
```
（Stop）→ 对无学习成果的实质性会话发出警告

Skill范围的记录（首选——低摩擦，单行命令）：

bash

python3 ~/.claude/scripts/learning-db.py learn --skill go-testing "关于测试的洞察"
python3 ~/.claude/scripts/learning-db.py learn --agent golang-general-engineer "关于Agent的洞察"
python3 ~/.claude/scripts/learning-db.py learn "无范围的通用洞察"

Skill范围的条目（topic=

skill:{name}

或

agent:{name}

）会在该Skill/Agent与未来提示相关时自动注入。请在任何实质性任务后使用此命令。

旧版记录方式（适用于不映射到特定Skill/Agent的条目）：

bash

python3 ~/.claude/scripts/learning-db.py record TOPIC KEY "VALUE" --category CATEGORY

记录具体、可操作的洞察——而非通用建议。“强制路由触发器不得包含同级Skill名称”是好的示例。“路由时要小心”则不是。

评审发现的立即毕业（强制性要求）：

当wave评审发现问题并在同一个PR中修复时，该修复就是验证。不要被动地以0.7的置信度记录并等待。而是：

将学习成果记录到负责的Agent/Skill的范围内

立即将置信度提升到1.0（

python3 ~/.claude/scripts/learning-db.py boost TOPIC KEY

x3）

将该模式嵌入到Agent/Skill的FORBIDDEN patterns或anti-patterns部分

毕业该条目（

python3 ~/.claude/scripts/learning-db.py graduate TOPIC KEY "target.md"

）

将Agent/Skill的变更与代码变更一起在同一个PR中提交

一个循环。评审发现问题 → 修复 → 以1.0置信度记录 → 毕业到Agent → 一起交付。无需等待“多次观察”。PR评审本身就是观察。

阶段门：在完成Simple+任务后，至少通过

learn

记录一个学习成果。评审发现要立即毕业。钩子会自动处理错误捕获。

MCP Auto-Invocation

MCP自动调用

MCP	Triggers	Rule
Chrome DevTools	inspect page, lighthouse, console errors, network requests, performance profile, debug in browser, check my site, what's on this page	AUTO-USE for live browser debugging — controls the user's real Chrome browser. Use for interactive inspection, profiling, and Lighthouse audits. Requires Chrome to be open.
Playwright	validate page, test layout, automated check, screenshot test, responsive check, browser test	AUTO-USE for automated browser validation — spins up a headless browser instance. Use for deterministic testing workflows, screenshot comparisons, and repeatable validation.
Context7	Library/API docs, unfamiliar library, setup steps, "how do I use X", Claude Code hooks/settings/slash commands/API	AUTO-USE for documentation lookups
gopls	Go workspace, .go files, go.mod, Go symbols, Go diagnostics	AUTO-USE for Go development — use `go_workspace` at session start, `go_file_context` after reading .go files, `go_diagnostics` after edits, `go_symbol_references` before renaming. Scoped to Go agents/skills only.

Do not wait for explicit requests. If the task involves documentation or API reference, use Context7 proactively. This explicitly includes Claude Code itself — hooks schema, settings.json format, slash commands, CLAUDE.md syntax, MCP server setup, and SDK usage. If the task involves Go development in a Go workspace, use gopls MCP tools proactively.

IMPORTANT — Subagent propagation: MCP server instructions are only injected into the main session's system prompt — subagents spawned via the Agent tool do NOT receive them. MCP tools appear as deferred tools in subagent contexts but agents won't use them unless told to call

ToolSearch

. Always include MCP tool discovery instructions in agent dispatch prompts (see Phase 4, Step 2.5).

MCP	触发器	规则
Chrome DevTools	inspect page、lighthouse、console errors、network requests、performance profile、debug in browser、check my site、what's on this page	自动用于实时浏览器调试——控制用户的真实Chrome浏览器。用于交互式检查、分析和Lighthouse审计。要求Chrome已打开。
Playwright	validate page、test layout、automated check、screenshot test、responsive check、browser test	自动用于自动化浏览器验证——启动一个无头浏览器实例。用于确定性测试工作流、截图比较和可重复验证。
Context7	库/API文档、不熟悉的库、设置步骤、“如何使用X”、Claude Code钩子/设置/斜杠命令/API	自动用于文档查询
gopls	Go工作区、.go文件、go.mod、Go符号、Go诊断信息	自动用于Go开发——在会话开始时使用 `go_workspace` ，在读取.go文件后使用 `go_file_context` ，在编辑后使用 `go_diagnostics` ，在重命名前使用 `go_symbol_references` 。仅适用于Go Agent/Skill。

不要等待明确请求。如果任务涉及文档或API参考，请主动使用Context7。这明确包括Claude Code本身——钩子架构、settings.json格式、斜杠命令、CLAUDE.md语法、MCP服务器设置和SDK使用。如果任务涉及在Go工作区中进行Go开发，请主动使用gopls MCP工具。

重要提示——子Agent传播：MCP服务器说明仅注入到主会话的系统提示中——通过Agent工具生成的子Agent不会收到这些说明。MCP工具会作为延迟工具出现在子Agent的上下文中，但除非被告知调用

ToolSearch

，否则Agent不会使用它们。在Agent分派提示中始终包含MCP工具发现说明（请参阅Phase 4，步骤2.5）。

Error Handling

错误处理

Error: "No Agent Matches Request"

错误：“无匹配的Agent”

Cause: Request domain not covered by any agent Solution:

Check

agents/INDEX.json

and

references/routing-tables.md

for near-matches

Route to closest agent with verification-before-completion as safety net
Report the gap and suggest
```
/do create an agent for [domain]
```

原因：请求的领域未被任何Agent覆盖解决方案：

检查

agents/INDEX.json

和

references/routing-tables.md

寻找近似匹配项

路由到最接近的Agent，并添加verification-before-completion作为安全网
报告此差距并建议
```
/do create an agent for [domain]
```

Error: "Force-Route Conflict"

错误：“强制路由冲突”

Cause: Multiple force-route triggers match the same request Solution:

Force-routes are ordered by specificity (go-testing > golang-general-engineer)
Apply most specific force-route first
Stack secondary routes as enhancements if compatible

原因：多个强制路由触发器匹配同一个请求解决方案：

强制路由按特异性排序（go-testing > golang-general-engineer）
首先应用特异性最高的强制路由
如果兼容，将次要路由作为增强项叠加

Error: "Plan Required But Not Created"

错误：“需要计划但未创建”

Cause: Simple+ task attempted without task_plan.md Solution:

Stop execution immediately
Create
```
task_plan.md
```
with goal, phases, and key questions
Resume routing after plan is in place

原因：尝试执行Simple+任务但未创建task_plan.md 解决方案：

立即停止执行
创建包含目标、阶段和关键问题的
```
task_plan.md
```
计划完成后恢复路由

Anti-Patterns

反模式

Anti-Pattern 1: Handling Code Directly

反模式1：直接处理代码

What it looks like: Editing source files without routing to a domain agent Why wrong: Bypasses domain expertise, testing methodology, and quality gates Do instead: Route to the domain agent. Always. Even for "simple" changes.

表现：不路由到领域Agent，直接编辑源文件 错误原因：绕过了领域专业知识、测试方法论和质量 gates 正确做法：路由到领域Agent。始终如此。即使是“简单”变更也不例外。

Anti-Pattern 2: Under-Routing

反模式2：路由不足

What it looks like: Treating code changes as "trivial" to avoid routing overhead Why wrong: Under-routing wastes implementations. Over-routing only wastes tokens. Tokens are cheap; bad code is expensive. Do instead: Default to routing. Trivial = reading a file the user named by path. Nothing else qualifies.

表现：将代码变更视为“琐碎”以避免路由开销 错误原因：路由不足会浪费实现成果。路由过度只会消耗token。token成本低廉；糟糕的代码代价高昂。 正确做法：默认进行路由。Trivial仅指读取用户指定路径的文件。其他任何情况都不符合Trivial的定义。

Anti-Pattern 3: Skipping Force-Routes

反模式3：跳过强制路由

What it looks like: Writing Go tests without invoking go-testing, or Go concurrency without go-concurrency Why wrong: Force-routes encode critical domain patterns that prevent common mistakes Do instead: Check force-route table BEFORE selecting a general agent. Force-routes override defaults.

表现：编写Go测试时未调用go-testing，或处理Go并发时未调用go-concurrency 错误原因：强制路由编码了关键的领域模式，可防止常见错误 正确做法：在选择通用Agent前，先检查强制路由表。强制路由会覆盖默认设置。

Anti-Pattern 4: Sequential When Parallel Is Possible

反模式4：可并行时却串行处理

What it looks like: Fixing 3 independent test failures one at a time Why wrong: Independent work items can run concurrently, saving significant time Do instead: Detect independent items and use dispatching-parallel-agents.

表现：逐个修复3个独立的测试失败 错误原因：独立工作项可以并行处理，节省大量时间 正确做法：检测独立项并使用dispatching-parallel-agents。

Anti-Pattern 5: Raw Git Commands Instead of Skills

反模式5：使用原始Git命令而非Skill

What it looks like: Running

git push

git commit

gh pr create

, or

gh pr merge

directly without routing through pr-sync, git-commit-flow, or pr-pipeline Why wrong: Bypasses lint checks, test runs, review loops, CI verification, and repo classification. This is how broken code gets merged. A CI failure after merge costs more than a pre-push check. Do instead: Route ALL git submission actions through their skills. "push" routes to pr-sync. "commit" routes to git-commit-flow. "create PR" routes to pr-pipeline. No exceptions, even when the user asks to "just push it."

表现：直接运行

git push

、

git commit

、

gh pr create

或

gh pr merge

，而不通过pr-sync、git-commit-flow或pr-pipeline路由 错误原因：绕过了lint检查、测试运行、评审循环、CI验证和仓库分类。这是坏代码被合并的原因。合并后出现CI失败的成本远高于推送前检查的成本。 正确做法：所有Git提交操作都必须通过相应Skill路由。“push”路由到pr-sync。“commit”路由到git-commit-flow。“create PR”路由到pr-pipeline。无例外，即使用户要求“直接推送”。

Anti-Pattern 6: Force-Route Triggers Containing Sibling Skill Names

反模式6：强制路由触发器包含同级Skill名称

What it looks like: A force-route trigger list includes the name of another skill (e.g.,

go-testing

trigger includes "go-concurrency") Why wrong: The router matches the sibling skill's name as a trigger for the wrong skill, swallowing requests that should route elsewhere. Do instead: Force-route triggers must contain only base-level keywords (user language), never sibling skill names. Test each trigger against the full force-route table to confirm it matches exactly one skill. Graduated from learning.db — routing/force-route-swallows-siblings

表现：强制路由触发器列表中包含另一个Skill的名称（例如

go-testing

的触发器包含“go-concurrency”） 错误原因：路由器会将同级Skill的名称匹配为错误Skill的触发器，导致应路由到其他地方的请求被拦截。 正确做法：强制路由触发器只能包含基础级关键词（用户语言），绝不能包含同级Skill名称。针对完整的强制路由表测试每个触发器，确保它仅匹配一个Skill。 从learning.db毕业——routing/force-route-swallows-siblings

Anti-Pattern 7: Duplicate Trigger Phrases Across Skills

反模式7：Skill间存在重复触发器短语

What it looks like: Two skills both claim the same trigger phrase (e.g., both

go-testing

and

go-anti-patterns

claim "test smell") Why wrong: The router cannot deterministically pick between them — which skill fires depends on table ordering, not intent. Do instead: Each trigger phrase must map to exactly one skill. Check for collisions before adding new force-routes. Graduated from learning.db — routing/trigger-collision-causes-nondeterministic-routing

表现：两个Skill都声明了相同的触发器短语（例如

go-testing

和

go-anti-patterns

都声明了“test smell”） 错误原因：路由器无法确定性地选择其中一个——哪个Skill被触发取决于表的顺序，而非意图。 正确做法：每个触发器短语必须仅映射到一个Skill。在添加新的强制路由前，检查是否存在冲突。 从learning.db毕业——routing/trigger-collision-causes-nondeterministic-routing

Anti-Pattern 8: Agents Modifying .gitignore

反模式8：Agent修改.gitignore

What it looks like: An agent edits

.gitignore

to un-ignore paths so it can commit gitignored files Why wrong:

.gitignore

defines repository safety boundaries. Agents bypassing it can commit ADRs, research, or local state. Do instead: NEVER allow agents to modify

.gitignore

. If a file is gitignored, it stays local. Graduated from incident — agent modified .gitignore to un-ignore adr/ and research/

表现：Agent编辑

.gitignore

以取消忽略某些路径，以便提交被忽略的文件 错误原因：

.gitignore

定义了仓库的安全边界。Agent绕过它可能会提交ADR、研究或本地状态文件。 正确做法：绝不允许Agent修改

.gitignore

。如果文件被忽略，它应保持本地状态。 从事件中毕业——Agent修改.gitignore以取消忽略adr/和research/

Anti-Pattern 9: Agents Using git add --force

反模式9：Agent使用git add --force

What it looks like: An agent runs

git add -f

to force-add gitignored files Why wrong: Bypasses

.gitignore

safety boundaries. Do instead: NEVER use

git add -f

git add --force

. If git refuses to add a file, that's correct. Graduated from incident — two worktree agents force-added gitignored files

表现：Agent运行

git add -f

以强制添加被忽略的文件 错误原因：绕过了

.gitignore

的安全边界。 正确做法：绝不使用

git add -f

或

git add --force

。如果Git拒绝添加文件，那是正确的行为。 从事件中毕业——两个工作区Agent强制添加了被忽略的文件

Anti-Pattern 10: Registering Hooks Before Deploying Files

反模式10：在部署文件前注册钩子

What it looks like: Adding a hook to

settings.json

before the script exists at

~/.claude/hooks/

Why wrong: Python file-not-found = exit code 2 = blocks ALL PreToolUse tools. Total session deadlock. Do instead: Deploy file first, verify it runs, THEN register. Never reverse this order. Graduated from incident — hook-development-engineer bricked all PreToolUse

表现：在脚本存在于

~/.claude/hooks/

之前，就将钩子添加到

settings.json

中 错误原因：Python文件未找到错误=退出码2=阻止所有PreToolUse工具。导致整个会话死锁。 正确做法：先部署文件，验证其可运行，然后再注册。绝不要颠倒此顺序。 从事件中毕业——hook-development-engineer导致所有PreToolUse工具失效

Anti-Pattern 11: "Acceptable" as a Review Disposition

反模式11：“可接受”作为评审结论

What it looks like: "This is a real issue but acceptable for now" / "valid but deferred" / "conservative, not a bug" Why wrong: "Acceptable" acknowledges a problem while avoiding the cost of addressing it. Creates the illusion of thoroughness without substance. Do instead: FIX NOW, FIX IN FOLLOW-UP (with tracked artifact), or NOT AN ISSUE (with evidence). No middle ground. Graduated from incident — Kafka PR shipped double-backoff classified as "conservative, not a bug"

表现：“这确实是个问题，但目前可以接受” / “有效但推迟处理” / “保守，不是bug” 错误原因：“可接受”承认了问题，但又避免了处理它的成本。制造了全面性的假象，却没有实质内容。 正确做法：立即修复、后续修复（带跟踪工件），或不视为问题（带证据）。没有中间地带。 从事件中毕业——Kafka PR中被归类为“保守，不是bug”的双重退避机制被合并

Anti-Pattern 12: Deferred Findings Without Tracking Artifacts

反模式12：推迟处理但无跟踪工件

What it looks like: "We'll address this in a follow-up" with no issue, TODO, or learning.db entry created. Why wrong: "Follow-up" without a tracking artifact is a polite way of saying "never." Do instead: Create a tracking artifact (GitHub issue,

TODO(follow-up):

in code, learning.db entry) before marking any finding as deferred. Graduated from incident — Kafka PR deferred findings lost between review rounds

表现：“我们将在后续处理中解决此问题”但未创建issue、TODO或learning.db条目。 错误原因：没有跟踪工件的“后续处理”只是礼貌地说“永远不会处理”。 正确做法：在将任何发现标记为推迟处理前，创建跟踪工件（GitHub issue、代码中的

TODO(follow-up):

、learning.db条目）。 从事件中毕业——Kafka PR中推迟处理的发现在评审轮次间丢失

Anti-Pattern 13: Protocol Reasoning Instead of Library Verification

反模式13：协议推理而非库验证

What it looks like: "Kafka consumer groups will rebalance after a member leaves, so this is safe." Why wrong: Protocol-level behavior and library-level behavior are not the same. LLMs reason from training data about protocols, not from reading the specific library version in go.mod. Do instead: Read the library source in GOMODCACHE. The question is never "how does the protocol work?" but "how does THIS library version implement THIS method?" Graduated from incident — 40 agent reviews missed segmentio/kafka-go Reader offset behavior

表现：“Kafka消费者组在成员离开后会重新平衡，所以这是安全的。” 错误原因：协议级行为和库级行为并不相同。LLMs从训练数据中推理协议，而非从go.mod中的特定库版本中读取。 正确做法：读取GOMODCACHE中的库源代码。问题永远不是“协议如何工作？”而是“这个库版本如何实现这个方法？” 从事件中毕业——40次Agent评审都遗漏了segmentio/kafka-go Reader的偏移行为

References

参考

This skill uses these shared patterns:

Anti-Rationalization - Prevents shortcut rationalizations
Verification Checklist - Pre-completion checks
Gate Enforcement - Phase transition gates

该Skill使用以下共享模式：

Anti-Rationalization - 防止捷径式合理化
Verification Checklist - 完成前检查
Gate Enforcement - 阶段转换门

Domain-Specific Anti-Rationalization

特定领域的反合理化

Rationalization	Why It's Wrong	Required Action
"This is trivial, I'll handle it directly"	Trivial = reading a named file, nothing else	Route to agent; show banner regardless
"No agent matches, I'll just do it myself"	Missing agent is a gap to report, not a bypass	Report gap, route to closest match
"Force-route doesn't apply here"	If triggers match, force-route applies. No exceptions	Check trigger table literally
"Routing overhead isn't worth it for this"	Routing overhead < cost of unreviewed code changes	Route anyway; tokens are cheap
"User wants it fast, skip the plan"	Fast without a plan produces wrong results faster	Create plan, then execute
"User seems impatient, skip the review"	There is never time pressure. The user wants correct, reviewed results — not fast broken ones. A denied tool call or follow-up message is NOT permission to skip quality gates.	Run the full review loop. If a tool is denied, try a different approach — never skip the step entirely
"Just push it, we can fix later"	Post-merge fixes cost 2 PRs instead of 1. Review before merge is always cheaper	Route through pr-sync/pr-pipeline. The git-submission-gate hook will block raw git push anyway

合理化理由	错误原因	必需操作
“这很琐碎，我可以直接处理”	Trivial仅指读取指定路径的文件，其他情况都不是	路由到Agent；无论如何都要显示横幅
“没有匹配的Agent，我自己处理”	缺少Agent是一个需要报告的差距，而非绕过路由的理由	报告差距，路由到最接近的匹配项
“强制路由不适用于此情况”	如果触发器匹配，强制路由就适用。无例外	严格检查触发器表
“路由开销不值得”	路由开销 < 未评审代码变更的成本	无论如何都要路由；token成本低廉
“用户想要快速完成，跳过计划”	没有计划的快速只会更快地产生错误结果	创建计划，然后执行
“用户看起来很不耐烦，跳过评审”	永远不存在时间压力。用户想要的是正确、经过评审的结果——而非快速但有问题的结果。工具调用被拒绝或收到后续消息并不意味着可以跳过质量 gates。	运行完整的评审循环。如果工具被拒绝，尝试其他方法——绝不要完全跳过该步骤
“直接推送，我们以后再修复”	合并后修复需要2个PR，而合并前修复只需要1个。合并前评审始终更便宜	通过pr-sync/pr-pipeline路由。git-submission-gate钩子无论如何都会阻止原始git push

Reference Files

参考文件

```
${CLAUDE_SKILL_DIR}/references/routing-tables.md
```
: Complete category-specific skill routing (Process, Analysis, PR, Content, Voice, Pipeline, Validation, Roaster Agents, Quick Examples)

```
${CLAUDE_SKILL_DIR}/references/routing-tables.md
```
：完整的特定类别Skill路由（流程、分析、PR、内容、语音、流水线、验证、Roaster Agents、快速示例）