Commands overview

Seven user-invocable skills, plus one internal utility. Depth of capture is the skill you pick — there are no flags anywhere. Every argument is optional: the autocomplete shows the hint below, and running a skill bare is the normal case (it drafts from the chat, or asks).

Command	Argument	In brief
/task:grill	[topic]	Pre-capture interrogation: stress-tests a plan one question at a time, keeps a decision-plus-rationale ledger, ends with a pre-mortem, routes to the right capture skill. Writes nothing. Needs no config.
/task:to-task	[<roadmap-slug>[#N] | context]	Fixes the chat (or a roadmap item) into .task/task/<slug>.md — Description only, no Plan. The lightest capture.
/task:to-plan	[<slug> | <roadmap-slug>[#N] | context]	Fixes the chat (or a roadmap item) into .task/task/<slug>.md with Description + Plan (and Tests when policy calls for it). The deepest one-task capture.
/task:to-roadmap	[initiative]	Fixes a multi-task initiative into .task/roadmap/<slug>.md — a phase-grouped backlog of ready-to-pick-up items.
/task:to-architecture	[<roadmap-slug> | initiative]	Fixes an initiative's technical shape — components, interfaces between items, per-item sketches — into a roadmap's ## Architecture section, writing the roadmap too when none exists yet.
/task:to-spec	[decision area]	Fixes load-bearing technical decisions into a standalone .task/spec/<slug>.md, cited by tasks/roadmaps via a Spec: header.
/task:roadmap-to-workflow	[<roadmap-slug>]	Autopilot over an approved roadmap: invokes the plugin's shipped Workflow driver, which runs unchecked items in dependency-ordered waves — parallel planning, then serialized implement-and-review per item.
validate (utility)	task | roadmap | spec | all	Optional format checker for .task/ artifacts. Not a slash command, not a gate.

The next-step footer

Every capture skill ends its output with a copy-pasteable → Next: … line naming the artifact path explicitly, e.g. implement .task/task/<slug>.md. The path is the handle, so there's nothing else to remember.

One file per task; a roadmap is a backlog of items

Each capture produces exactly one .task/task/<slug>.md, where <slug> is both the filename and the identity — no task-id, no umbrella folder. A roadmap (.task/roadmap/<slug>.md) groups several such items into one initiative. A spec (.task/spec/<slug>.md) is a standalone file of technical decisions that tasks and roadmaps point at with a Spec: header. See .task/ layout for the full shapes.