task-decomposer

Task Decomposer

Translate any form of human intent into fully-formed TASK-NNN entries. The approved output serves as the scope gate — /orchestrator G1 then runs as a fast-path confirm (scope unchanged?), not a re-grill.

Input types

For a ticket, fetch the description first (ask the user to paste if credentials are missing — never block on env vars). For an epic, resolve the flag to docs/epic/EPIC-NNN-<slug>.md (match on id, else slug, else the INDEX.md row) and read it before grilling. Check docs/epic/archive/ before concluding it does not exist — a closed epic is archived there (§11) and resolving only the live directory would report a finished epic as never-created, sending the owner to /lean-doc-generator epic to re-open work that is already done. A match in archive/ is a closed epic: say so, and note that new work toward that outcome opens a new epic rather than reopening this one — its Outcome, Scope-Out and Open questions are already-settled context, so re-asking them is the interview a resolved epic exists to prevent. Decompose only the slice the owner names, never the whole epic at once: an epic spans sprints by definition, and a Plan holds ~12 tasks. No epic doc for that name → it is not an epic yet; say so and offer /lean-doc-generator epic (nameable outcome) or --fog (not yet nameable). Never create the epic here — creation is the generator's job; this skill consumes.

Procedure

1. Clarify — the grill (freeform / ticket only) — ambiguity is cheapest to kill at intake. Decisions form a dependency tree; work it in rounds by frontier. The frontier is every decision whose prerequisites are already settled — ask all of it at once as one AskUserQuestion popup (each option with a recommended answer), then recompute the frontier from the answers. The discriminator is dependency, not count: batching dependent questions is what produces vague answers, because the user must guess at inputs they have not given yet; batching independent ones costs nothing and saves a round-trip. Stop when the frontier is empty — every branch visited, nothing silently assumed. Finding facts is your job, never the user's: an unresolved fact is a prerequisite in the tree, not a question — resolve it yourself (for mature / unfamiliar code, recon via the Explore agent — existing impl + tests + deps → a tight brief in its own context, a cheap-tier sonnet pass; the grill itself stays on the session model. Tier map → CONTEXT.md). Only the branch downstream of an open exploration waits; the rest of the frontier proceeds. Moves:
   • Challenge the glossary — a term conflicts with CONTEXT.md? Surface it: "your glossary says X, you seem to mean Y — which?"
   • Sharpen fuzzy language — replace an overloaded word ("account", "user") with a precise canonical term; feed a newly-pinned term straight to /lean-doc-generator (glossary), don't batch.
   • Invent edge-case scenarios — concrete cases that force the boundaries between concepts to be made explicit.
   • Cross-reference code — a claim contradicts the code? Surface the contradiction.
   • A design that must be felt, or a high-stakes fork — don't resolve it here: record it on the task (assumes:) so G2 routes to /prototype / /council.