---
name: minimalist-router
description: Use when a software request must be routed through a fast change, feature prototype, architectural design, sprint cycle, review, or next-iteration workflow.
---

# Minimalist Router

Use minimalist-constitution as the governing contract. Resolve its shared
references through the installed plugin root, not the caller's current
directory. Select the smallest route that preserves decision quality and
evidence.

## Choose the route

| Observable request state | Route |
|---|---|
| One low-risk, local change with clear acceptance | Fast → minimalist-fast-change |
| New or changed behavior that can be delivered as stories | Feature |
| Changed boundaries, contracts, persistence, security, deployment, or several independent subsystems | Architectural → minimalist-architecture |
| Active sprint with new feedback or incomplete work | Review and next iteration |

Do not choose the route from estimated code size alone. Choose it from
uncertainty, risk, dependencies, and the cost of being wrong.

## Select the next skill

| Current state | Next skill |
|---|---|
| Raw idea or unclear request | minimalist-brainstorming |
| Clear, local, low-risk change with acceptance | minimalist-fast-change |
| Architectural uncertainty or changed boundary | minimalist-architecture |
| Approved outcome without bounded requirements | minimalist-specification |
| Specification without stories | minimalist-story-mapping |
| Approved design without stories | minimalist-story-mapping |
| Candidate stories without an ordered backlog | minimalist-backlog-refinement |
| Ordered backlog without a sprint goal | minimalist-sprint-selection |
| Selected stories without executable tasks | minimalist-sprint-planning |
| Planned active sprint | minimalist-sprint-execution |
| Increment ready for user decision | minimalist-sprint-review |
| Review complete without adaptation decisions | minimalist-sprint-retrospective |
| Stable repeated workflow with an automation candidate | minimalist-automation |
| Existing artifact already satisfies a gate | skip the earlier skill and record why |

## Routing rules

- Never route directly from a raw request to implementation when the outcome
  or scope is uncertain.
- Never route the whole backlog into execution; route only the selected sprint.
- A mid-sprint request goes to classification before execution continues.
- A failed verification returns to execution or planning according to the cause.
- A rejected, changed, defective, or carried-over story returns to the backlog
  with its history preserved.
- Automation routes only after evidence of repetition and stability.
- If two artifacts disagree, stop and request a decision; do not silently merge
  their meanings.

## Handoff

At every handoff state:

1. name the current artifact;
2. state the gate that passed;
3. state the next artifact or decision required;
4. preserve the route and scope in the project record.

For a trivial fast-route change, use the fast-change template as one concise
verification and handoff record. For a feature or architectural route, use the
artifact contracts and templates resolved from <plugin-root>/references/ and
<plugin-root>/templates/.