Triage

Assess an incoming request to determine whether it needs a response and, if so, the size, nature, and priority of that response.

Triage applies to all incoming work — new feature requests, bug reports, internal needs, and technical debt. These are not the same and should not be prioritised the same way. This process provides a shared framework for making that distinction.

Config Integration

Before starting, follow the migration preflight in references/config-migration.md, then read .assistant-config.md from the project root.

If it exists, read the Task Management section to determine:

• •Tracker: Where issues are managed (e.g. Linear, GitHub Issues, Jira)
• •Accessible via tools: Whether you can create/search issues directly
• •Local tasks: Where code-adjacent task files go

If the config doesn't exist or has no task management section, ask the user where they track work before routing (Step 5). Suggest running /teach-charter to set this up permanently.

When to invoke

• •A new request or bug arrives (from an issue tracker, chat, or conversation)
• •Before starting work on something that hasn't been assessed
• •When reprioritising existing work against new information

Step 1: Classify the request

Ask the user (or determine from context) what type of work this is:

If unclear, ask: "Is this fixing something broken, adding something new, improving something existing, or cleaning something up?"

Step 2: Check for duplicates

Before going further, check whether this already exists:

• •If the project's tracker is accessible via tools (per config), search it for matching items
• •Search the codebase for TODO/FIXME comments related to the issue
• •Check the local task location (per config) for related task files
• •If a duplicate exists, report it and ask whether to update the existing item or proceed as new

Step 3: Assess the seven dimensions

Evaluate each dimension and assign a rating. Use your judgement and evidence from the codebase.

Where

Is this localised to one place or spread across the codebase? Explore the project structure to determine which areas are affected:

• •Single module or package
• •Multiple modules with a shared boundary
• •Cross-cutting (touches many parts of the system)

Impact

Rate: Critical | High | Medium | Low

• •Critical: Blocks users from core functionality
• •High: Breaks a feature but workarounds exist
• •Medium: Degrades experience but doesn't block usage
• •Low: Cosmetic or minor annoyance

Effort

Rate: Unknown | Small (< half day) | Medium (1-2 days) | Large (3+ days)

• •If Unknown, the first action is investigation, not implementation
• •If Large, it likely needs decomposition before work begins

Blast radius

What else could be affected by the fix or change?

• •Shared libraries or components affect all consumers
• •Auth or session changes may require coordinated restarts or migrations
• •External API changes may have rate limiting or compatibility implications
• •Style or theme changes may cascade across many views

Risk

• •What happens if we do nothing?
• •Does this risk blocking other in-flight work?
• •Is there a release, deadline, or dependency at stake?
• •Does this touch auth, security, or data integrity?

Priority

Rate using concrete tiers:

• •P1 — Blocks user acquisition or breaks production functionality. Act now.
• •P2 — Blocks another task in active development. Schedule this week.
• •P3 — Improves quality or developer experience. Schedule when capacity allows.
• •P4 — Nice to have, no deadline. Backlog.

Scope

If enough is known, define what a response looks like:

• •Which files/components need to change
• •Whether new infrastructure or dependencies are needed
• •Whether this can be done in one PR or needs decomposition

When scoping, aim for the smallest response that solves the problem:

Level 1: Extend existing code slightly (5-10 lines)
Level 2: Add one small component/hook (<50 lines)
Level 3: Refactor existing systems
Level 4: New architecture

Most problems are solved at Level 1-2. If your proposed scope is Level 3-4, challenge whether a simpler response exists.

Step 4: Make a recommendation

Based on the assessment, recommend one of:

Step 5: Draft the issue

Always produce a ready-to-use issue, regardless of whether the tracker is accessible. This is the primary deliverable — the user should be able to paste it straight into their tracker or hand it to a teammate with no further editing.

Draft the issue using the assessment from Steps 1-4:

• •Title: Short, specific, actionable (e.g. "Fix: session token not cleared on logout" not "Auth bug")
• •Description: What's happening, what should happen, and why it matters
• •Acceptance criteria: Concrete, testable conditions for "done"
• •Labels/metadata: Type, priority, affected area — formatted as the tracker expects if known from config

Step 6: Route the work

Use the task management settings from .assistant-config.md to route appropriately:

• •Tracker accessible → Create the issue directly using the available tools
• •Tracker not accessible → Present the drafted issue for the user to copy into their tracker
• •Code-adjacent work → Create a task file in the configured local task location
• •Link dependencies if this blocks or is blocked by other work

If no config exists and you haven't already asked, ask the user where this should be tracked.

Output format

Present the triage result followed by the drafted issue:

## Triage: [Brief title]

**Type**: Bug | Feature | Enhancement | Debt
**Where**: [Affected areas]
**Impact**: Critical | High | Medium | Low
**Effort**: Unknown | Small | Medium | Large
**Blast radius**: [One-line summary]
**Risk**: [Key risk if we do nothing]
**Priority**: P1 | P2 | P3 | P4

### Recommendation
[Act now | Schedule | Investigate | Decompose | Defer | Decline]

### Reasoning
[2-3 sentences explaining the recommendation]

---

### Ready-to-file issue

**Title:** [Actionable title]

**Description:**
[What's happening, what should happen, why it matters. Include relevant file paths or code references if known.]

**Acceptance criteria:**
- [ ] [Testable condition]
- [ ] [Testable condition]
- [ ] [Testable condition]

**Labels:** [type], [priority], [affected area]

Flags for elevated scrutiny

Automatically flag if the request touches any of these areas:

• •Auth/session management — identity, tokens, permissions
• •External API integrations — third-party dependencies, rate limits
• •Database schema — migrations, data integrity, access policies
• •Shared libraries or components — blast radius across all consumers
• •Security boundaries — input validation, secrets, encryption