菜单
Complexity assessment framework for routing issues to appropriate preparation depth. Defines triage signals, mode selection criteria, and output templates for solo and lightweight modes. Referenced by prepare-issue before design session dispatch.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | complexity-triage |
| description | Complexity assessment framework for routing issues to appropriate preparation depth. Defines triage signals, mode selection criteria, and output templates for solo and lightweight modes. Referenced by prepare-issue before design session dispatch. |
| domains | ["triage","complexity","workflow","planning"] |
| user-invocable | false |
Assess issue complexity and route to the appropriate design session depth: solo, lightweight, or full.
Iron rule: When uncertain, choose the higher-process mode. Solo is only for clearly simple issues.
Evaluate against already-fetched issue data only. No codebase scans during triage.
| Signal | What to Check |
|---|---|
| Domain count | How many specialist domains does the issue touch? (mapped against available agents) |
| Precedent | Does the issue reference existing commands/skills as a pattern to follow? |
| Ambiguity | Are there open questions, conflicting requirements, or underspecified acceptance criteria? |
| Scope | Additive (new files) vs cross-cutting (modifying existing systems)? |
| Scale | Number of acceptance criteria, number of files mentioned |
| Labels | Any complexity indicators from issue labels |
| Signal Profile | Mode |
|---|---|
| 1 domain, clear precedent, no ambiguity, additive scope, ≤5 acceptance criteria | Solo |
| 1-2 domains, minor ambiguity OR moderate scope, some uncertainty | Lightweight |
| 3+ domains, OR significant ambiguity, OR cross-cutting scope, OR competing concerns | Full |
| Ambiguous / insufficient signal to classify | Lightweight (err toward more process) |
| Very sparse issue body (< 3 sentences, no acceptance criteria) | Full (insufficient info to triage safely) |
Signal precedence: Any single Full-tier signal (3+ domains, significant ambiguity, cross-cutting scope, competing concerns) overrides all Solo/Lightweight signals. Solo requires ALL signals to be low-complexity — one elevated signal is enough to escalate.
## Design Session
*Complexity triage: solo — lead assessment only, no specialist dispatch.*
### Decision
[Lead's analysis of what to build and key approach]
### Rationale
[Why this approach, including trade-offs considered]
### Architecture Diagram
<!-- Optional: include when the subject involves component interactions,
data flows, or state transitions. Omit entirely for non-architectural topics. -->
```mermaid
[Diagram matching the subject]
| Specialist | Finding | Confidence |
|---|---|---|
| Lead (solo assessment) | [Key finding] | [High/Medium/Low] |
N/A — solo assessment.
None identified.
path/to/file - [actual change description — required for solo shortcut][Concrete testing approach — required for solo shortcut. Use "N/A — no testable code changes" ONLY for doc-only issues. Placeholder text fails guard rail #5.]
[Any items needing human input, or "None."]
Solo design assessment via /coding-workflows:prepare-issue (complexity: low)
> *Note: The Files to Modify and Testing Strategy sections serve dual purpose: they document design intent (design session role) and provide structured input for the solo plan derivation in `prepare-issue` (plan bridge role). This intentional overlap eliminates a separate planning step for trivially-scoped issues.*
### Lightweight Mode
Same structure as full design session output, with these degenerate values:
- `### Specialist Input` table has exactly 1 row
- `### Conflicts Resolved` → "N/A — single specialist, no conflicting perspectives."
- `### Architecture Diagram` → optional, same rules as full template (include when subject involves component interactions, data flows, or state transitions)
- Footer: `*Lightweight design session via /coding-workflows:prepare-issue (complexity: medium, 1 specialist)*`
---
## Edge Cases
| Scenario | Behavior |
|----------|----------|
| No agents available + lightweight requested | Degrade to solo with warning |
| Low-signal / sparse issue body in auto mode | Default to full |
| Invalid mode value | Warn with valid options, default to auto |
| `planning.triage.default_mode: full` in config | Triage effectively disabled — always full |
---
## Anti-Patterns
- **Over-triaging**: Spending significant tokens evaluating complexity defeats the purpose. Triage reads the issue body and applies the decision table — nothing more.
- **Triage as analysis**: Triage does NOT perform codebase exploration, dependency research, or deep analysis. It classifies and routes.
---
## Examples
| Issue | Signals | Mode |
|-------|---------|------|
| "Fix typo in README" | 1 domain, clear precedent, additive, 1 AC | Solo |
| "Add a new command that wraps existing logic" | 1-2 domains, follows pattern, additive | Solo |
| "Add complexity triage to prepare-issue" | 3+ domains, cross-cutting, novel pattern | Full |
| "Improve error handling in plan-issue" | 1-2 domains, moderate scope | Lightweight |
| "Redesign the agent discovery system" | 3+ domains, architecture decision, cross-cutting | Full |
| "Add OAuth2 authentication" | Sparse, no precedent, significant scope | Full |
---
## Cross-References
- `coding-workflows:prepare-issue` -- uses this skill for complexity assessment before design session dispatch
- `coding-workflows:design-session` -- full deliberation mode (invoked when triage selects full)
- `coding-workflows:agent-patterns` -- agent discovery (used by lightweight mode for specialist selection)
Documents agent frontmatter metadata spec and patterns for creating effective project-specific agents. Use when: creating agents, understanding agent discovery, or configuring agent metadata.
Discovers existing skills and agents across project, user, and plugin layers and provides similarity heuristics for detecting overlapping assets. Use when generating skills or agents, detecting duplicate assets, or checking for name collisions.
Governs multi-round specialist deliberation for design sessions, plan reviews, and adversarial dispatch. Defines conflict detection, dispatch rounds, cross-pollination, and resolution protocols. Referenced during design sessions, plan reviews, and adversarial plan challenges.
Structured workflow for planning and executing GitHub issues. Ensures thorough research, proper requirements analysis, and build-vs-buy evaluation before implementation. Use when: planning an issue, executing an issue, or reviewing a plan.
Writes requirements-focused issues that describe what needs to be done, not how to implement it. Works with any tracker. Use when creating issues, updating requirements, or planning work.
Framework for reviewing pull requests with severity-tiered findings, ecosystem-adapted focus areas, and strict exit criteria. Defines review principles, severity tiers, finding disposition framework, and the CREATE ISSUE protocol. Use when reviewing PRs from CLI or CI.