Automatically analyzes the current situation, inventories available resources, intelligently selects the best agent/skill combination and executes it. Suitable for when you are unsure which tool to use.
With
/designdivision of labor:/assistis the universal routing entry point, covering review/documentation/research/build fixes and other various situations;/designfocuses on producing complete implementation plans. When unsure which to use, choose/assistfirst — when it determines that full planning is needed it will delegate to/design, rather than manually reinventing a planning process.
Step 0: Task tracking (default text checklist)
By default, maintain a numbered Step checklist in the reply and mark the status of each item, without relying on the Task tool —TaskCreate / TaskUpdate / TaskList does not exist by default on Opus 4.8, Sonnet 5, Fable 5, Mythos 5 and newer models (as of Claude Code v2.1.233, see rules/task-tracking-availability.md）。
if the session has no Task tool, do not ask this AskUserQuestion— asking about a switch that cannot be turned on right now just adds another round of HITL (the env var only takes effect after restarting the session). Only when the session actually has the Task tool should you follow the CLAUDE.md global rules and ask whether to switch to tool-based tracking (attach a token estimate for complex tasks; for simple tasks, proceed without asking); after enabling it, TaskCreate a subtask before each Step begins (including activeForm, and addBlockedBy when necessary), and after completion TaskUpdate it to completed,if the call fails, continue without aborting the pipeline。
Step 1: Situation analysis
Collect the key facts needed to decide routing:
- Git status：
git status、git diff --stat、git log --oneline -5— whether there are uncommitted changes, which files were changed, what the most recent commit was doing - Project detection：
ls -ladetermine language/framework (package.json/go.mod/requirements.txt etc.), whether there are test/CI settings - User instructions：
$ARGUMENTSand requirements in the conversation context - Build status: only run a quick check when an explicit build setup is detected (
npm run build、go buildetc.)
Step 2: Inventory available resources
Inventory Claude Code built-in resources and this repo's own skills as routing candidates:
Built-in Agent types:
| Agent | Applicable situations |
|---|---|
| Plan | Complex tasks requiring planning (see /design） |
| Explore | read-only search and locating, quick inventory |
| general-purpose | multi-step research/review/documentation updates/TDD guidance etc.; document review/sync/TDD/complexity triage have self-contained definition files (for invocation conventions see agents/SKILL.md), the rest use explicit prompts |
Built-in Skills:
| Skill | Applicable situations |
|---|---|
/code-review |
Code quality review (supports --comment、--fix; language-specific review is specified via prompt as go/python/ts) |
/security-review |
Security analysis |
/simplify |
reuse/simplification/efficiency cleanup (dead code, naming, nesting, duplicated code) |
/verify |
End-to-end behavior verification, not just running tests |
/review |
Review GitHub PR |
deep-research |
Open-ended multi-source research, including fact-check |
This repo's own Skills (filter relevant ones based on the situation):
| Skill | Applicable situations |
|---|---|
/design |
Requires a complete implementation plan (new features/architecture changes) |
/update |
Knowledge consolidation (document updates + review + context organization + pattern extraction) |
/pr |
commit/push/create or update PR |
/plan-run |
Advance the implementation according to the existing plan's DAG state machine |
/worktree |
worktree creation/cleanup |
/handoff |
Cross-context/session handoff |
/evidence-check、/verify-evidence-loop |
Technical decision verification; the latter is the iterative convergence version for high-risk decisions |
If a needed resource is unavailable (for example, a skill has been deferred), prompt the user to restore it first or choose an alternative combination.
Step 3: Intelligent routing
Based on the scenario analysis in Step 1, select the corresponding resource combination:
| Detected scenario | Selected combination | Description |
|---|---|---|
| New feature request / bug fix | /design → implementation → /code-review → /simplify |
/design Built-in industry-standard research, architecture decisions, and requirements traceability matrix; delegate rather than manually reinventing |
| Uncommitted changes need review | /code-review → /simplify |
Quick quality review, fix first and then add security review as needed |
| build failure | general-purpose agent (prompt requires minimal diff to fix the build, no architectural changes) | Fix directly, taking priority over other work |
| Refactoring needed | /design(including architecture decisions) → implementation → /simplify → /code-review |
Safe refactoring process |
| Need to write documentation | general-purpose agent (according to agents/doc-updater.md definition) or directly /update |
Documentation update process; document review does not apply to /simplify |
| Touches security-sensitive surfaces (auth/input/endpoint/DB/deserialization/file/shell/SSRF/DOM/encryption) | In the combinationAttached by default /security-review |
According to rules/security-guidance/skill-integration.md trigger gate; if none are touched, do not attach |
| Need a complete implementation plan | /design |
See the division of labor described above and in this skill |
| Need to proceed according to an existing plan | /plan-run |
Advance via DAG state machine, without skipping steps |
| Need commit/PR | /pr |
Summarize conversation context + commit + push + PR |
| Need cross-session/context handoff | /handoff |
Generate a self-contained prompt |
| Need open-ended technical research | deep-research or general-purpose + WebSearch |
Multi-source research and fact-check |
| Need to verify technical decisions | /evidence-check(single-shot) or /verify-evidence-loop(high-risk, iterative convergence) |
|
| Uncertain / multiple possibilities | List recommended combinations, use AskUserQuestion to let the user choose |
Determine priority order: $ARGUMENTS explicit instructions > build failure (blocks subsequent verification) > security issues > uncommitted changes > inferred intent from conversation context. When multiple scenarios conflict, first explain the detection results and ask the user whether to continue according to the original instructions.
When uncertain, use AskUserQuestion to present options:
情境分析結果：[簡述偵測到的狀態]
建議的組合：
1. [組合 A] — [適用原因]
2. [組合 B] — [適用原因]
3. [組合 C] — [適用原因]
When delegating to a general-purpose agent(for scenarios without a dedicated skill, such as build failures or documentation updates), the prompt must clearly define the scope, for example:
Agent(subagent_type="general-purpose")
- build failure: only fix the minimal diff to make the build pass, do not make architectural changes, do not add features
- File updates: scan this change, update the corresponding documents (README, API docs, CODEMAPS), following the existing documentation conventions for format
Step 4: Execute
Tracking: Before executing each resource, mark it as in progress in the Step list in the reply, and mark it as complete after execution; if there is a dependency order, note the preceding items in the list. (When the session has the Task tool and it is enabled, use instead
TaskCreate(including activeForm, retain the returned task ID) →TaskUpdate(completed), use for dependenciesaddBlockedByto mark the preceding task ID.)
Execute the selected agent/skill in order. After each one completes, organize "what was done, key findings, modified files, unresolved issues" into a paragraph to hand off to the next step—the handoff content must be self-contained (the next executor cannot see the full process of the previous step), and no fixed required-field template is needed.
If a step discovers a CRITICAL issue, pause the pipeline and use AskUserQuestion to ask the user whether to continue.
Step 5: Output report
After all steps are complete, output a summary covering the following content; no fixed template is needed:
- Scenario analysis results and the chosen combination (including reasons)
- Result summary and important findings for each step
- Modified files
- Unresolved issues and suggested next steps
The authoritative source of completion status is the list from Step 0；TaskList It is only a mirror when the tool is enabled, not the basis for determination (a failed Task call or a nonexistent tool should not affect the completion determination).No need to create a separate manifest table or completion rate calculation。