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
- How a task is built, synced, and archived like any other change
- 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"Like the brief, the task skill resolves its argument against your board. A bare name that matches a board item adopts that item and seeds the planning from its description, while a phrase with spaces is treated as a description for a fresh change.
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.
Only the planning differs. After that a task is a change like any other. You build it, sync it if it changed a capability, and archive it, the same way you finish a feature.
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.
Building a task
A feature has a
build command. A task does not, because its workflow.md is self-contained. It carries the steps, the rules each one needs, and the checks to run between them. You build a task by pointing your agent at the workflow:
Implement changes/lucid-v22-upgrade/workflow.md
The agent works through the steps in order. When it finishes, the change is ready to sync and archive.
When a task changes a capability
Most open-ended work preserves behavior, such as a migration, a cleanup, or a refactor. Once it is done, you archive it.
Some tasks change what a capability does. When the planning turns up a step that changes product behavior, the skill asks about the affected capability and records the change, just as a brief does for a feature. That record is what carries the task through sync into your canonical state. If a change needs the depth of a full product interview, run brief instead; the task skill keeps the quick path quick.
What the task skill produces
The skill writes workflow.md into the change folder, holding a summary, the invariants and blast radius of the work, and the ordered steps for the agent to follow. A task that changes a capability also gets a behavior delta, the same kind a brief produces.
Like the other planning skills, the task skill is read-only while planning. It inspects the codebase but writes no application code.
Next steps
- Once a task is built, promote any capability change with the Sync skill, then file it with Archive.
- 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.