| 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 |
Complexity Triage
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.
Triage Signals
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 |
Mode Selection
| 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.
Output Templates
Solo Mode
## 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 Input
| Specialist | Finding | Confidence |
|---|
| Lead (solo assessment) | [Key finding] | [High/Medium/Low] |
Conflicts Resolved
N/A — solo assessment.
Action Items (Inline)
Action Items (Separate Issue Required)
None identified.
Files to Modify
path/to/file - [actual change description — required for solo shortcut]
Testing Strategy
[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.]
Open Questions
[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)
