Task

A task is the Markdown file you add: a title, what to change, and how to check it. The file is the spec for one run.

What it isCopy Anchor Link

A task is the Markdown file you add. It is the work you want done: a title, what to change, and a Verification section the factory can run. You write it, or you grow it from an idea with intake. Either way the file is the contract for one run.

The title is the name you will see on the run. The body says what to change — a goal, a scope, acceptance criteria, and what is out of scope. Verification is a list of commands in backticks. Those commands are how the factory checks the work, not a note to yourself.

One task can touch several repositories. When the factory has more than one checkout, the file names the labels this task uses. A change that has to land in two repos at once is still one task. A task that only needs one repo names that repo, or omits the list when the factory has only one.

What you seeCopy Anchor Link

The file looks like other Markdown you already write: a short header with an id and a title, then headings. A typical task has Goal, Scope, Acceptance criteria, Verification, and Out of scope. Verification is the section the factory depends on. With several repos, commands sit under a heading per repo so each checkout has its own checks.

You add the file with kusaw add. That checks the structure and queues a run. In the CLI the task id is how you talk about later runs of the same work. In the Dashboard the title is what you scan on the runs list.

The demo ships sample tasks, such as adding a --json flag, so you can see the shape without inventing a spec. Those files live with the demo factory. Your own tasks live wherever you keep them; you pass the path to kusaw add. Inbox folders and schedules, when you turn them on, queue a task file the same way.

You do not edit the copy of the task that a run is already using in order to steer that run. If the work was wrong, you change the file and add it again, or you requeue with a note. The run's evidence is how you judge what happened, not a second copy of the spec.

What you decideCopy Anchor Link

You decide the title, the scope, and the checks. Tight scope and a command you already trust (tests, a build, a script) make a run you can judge. Vague acceptance criteria and no Verification section make a run that cannot tell you if it finished.

You decide which repos the task touches. Name every checkout this change must land in. Leave out repos this task must not touch. One task is one change-set, not a backlog.

You decide when the file is ready to add. Intake can help you write it; kusaw add still needs a file that passes the structural check. You decide what is out of scope so the run does not wander.

Where to go nextCopy Anchor Link

Meet a task as a Markdown file you open in the editor, as the path you pass to kusaw add, and as the title on a run in the Dashboard.

• Run — what happens after you add the file
• Multi-repo runs — naming repos and scoping Verification
• Install — add a spec once a factory is running
• Delivery — the commit that file is meant to produce