Open-ended tasks
The task skill is the alternative track of the
Flow workflow. In this guide, you will learn:
- What kind of work the task skill is for
- How it differs from the blueprint, assert, and build trio
- What the task skill produces
Overview
Not every change is a user-facing feature. Migrating from one package to another, restructuring a folder, or applying a refactor across many files is real work, but it has no user journey to interview and no obvious set of tests to plan first.
The task skill plans this kind of work. It takes a description of the job, breaks it into ordered steps, and writes a single self-contained workflow document that an agent then executes.
You invoke it with a change name, and optionally a description of the work:
/flow-task lucid-v22-upgrade "migrate the app to Lucid v22"How it differs from the feature track
The feature track ( brief, blueprint, assert, build) is shaped around a user journey. A migration does not have one. Interviewing for "what the user sees" makes no sense, and there is no surface to write functional tests against.
So the task skill replaces that trio with a single output. Instead of a blueprint, a test plan, and a build, an open-ended change gets one workflow.md. A change carries either a blueprint or a workflow, never both.
The task skill accepts its input either as a brief, if one exists for the change, or as a plain description you pass on the command line.
How the planning works
The skill classifies the task, such as a package migration or a cross-cutting refactor, then runs a discovery pass over the affected code and the relevant harness docs. It builds a picture of the current shape and the invariants that must not break.
It then decomposes the work into ordered steps, small enough to verify and large enough to be meaningful, sequenced so the codebase stays working between them where possible. Quality-gate steps are placed between groups of steps to keep a broken type or lint error from carrying forward.
One detail sets the workflow document apart. Each step embeds the harness rules it depends on, copied in verbatim, rather than pointing at a doc to go read. The agent that later executes the workflow works from workflow.md alone, and an embedded rule cannot be skipped the way a referenced one can.
What the task skill produces
The skill writes workflow.md into the change folder. It carries a summary, the invariants and blast radius of the work, and the ordered steps, each with its embedded harness rules and the decisions it covers. An agent reads that document to carry out the work.
Like the other planning skills, the task skill is read-only while planning. It inspects the codebase but writes no application code.
Next steps
- For user-facing features, use the feature track instead, starting with the Brief skill.
- Read the Knowledge base guide to understand the harness docs the workflow embeds.