task-workflowlisted

# task-workflow Follow this workflow for every non-trivial task. ## Steps 1. **Scope** — state what you're changing and why in one sentence before touching any code. If one sentence can't hold it — 3+ plans' worth of work, or more than one mergeable PR — the request is an epic, not a task. Stop here and run `epic-workflow` to decompose it; it hands each unit back to this workflow one at a time. 2. **Spec gate** (non-trivial features only) — write and get approval for a spec before implementing. Skip for: bug fixes, copy changes, config tweaks, changes ≤20 lines of logic. If the request doesn't contain enough information to fill the spec's required sections (What / Inputs-outputs / Edge cases / Security considerations / Testing strategy) with confidence, ask up to 3 targeted clarifying questions before drafting the spec — never fill the gaps with silent assumptions and present an approved-looking spec built on them. Use the default format below unless the user explicitly asks for a "full spec" / "AI-friendly spec" / "spec-driven" spec — then use the full spec format instead. There is exactly one other way the full format gets used: run `model-router`'s capability scoring (its Steps 1–2 only) against the *described* scope before drafting — the files the request implies, passed via `--paths`, since no `PLAN.md` exists yet — and if it scores the `deep` tier, offer the full format once with the rubric's rationale and use whichever the user picks. A `standard` or `q