Write a good task
A [task](../glossary.md#task) is one Markdown file — the [spec](../glossary.md#spec) `kusaw add` checks and queues as a run. Write one change per task, with commands under `## Verification` that prove it worked.
A task is one Markdown file — the spec kusaw add checks and queues as a run. Write one change per task, with commands under ## Verification that prove it worked.
| Step | CLI | Dashboard |
|---|---|---|
| Check the spec and queue a run | kusaw add spec.md | The run appears on Runs once it is queued |
| Watch the factory | kusaw status | Open the factory's Runs list |
kusaw serve has to be running for the queued run to start. kusaw ui opens the Dashboard.
The task file
Front matter, then five sections in this order. The spec check is structural only: it does not call a model.
---
id: demo-json-flag
title: JSON flag
repos: [demo]
---
## Goal
Add a `--json` flag to report so a script can read the result.
## Scope
The report command in the `demo` repo. One flag.
## Acceptance criteria
- [ ] `--json` prints `{"text":"report"}`.
## Verification
- `go test ./...`
## Out of scope
Other flags, renaming report, and changing the default output.idandtitleare required.idis the task id.titleis the short name you see on Runs.- Goal is what and why.
- Scope and Out of scope are the constraints.
- Acceptance criteria is a list of what done looks like.
## Verificationholds commands that prove it works. Each command is a list item whose only text is a command in backticks.repos:names the factory repo labels this task uses. With one repository in the factory you can omit it; with several you have to list them. At most eight. See Multi-repo runs.
One change per task. Two independent flags, or a flag plus a rename, are two tasks.
What makes the spec check ask for more
kusaw add rejects a file that does not match the shape. Each problem is printed as Spec rejected (unclear_spec): plus the reason. Typical reasons:
- Front matter is missing, or it still has
repo:instead ofrepos:. idortitleis missing.- A required section is missing or empty.
## Acceptance criteriahas no list item.## Verificationhas no command (a sentence such as "run the tests" is not a command).- A listed repo is not in
kusaw.yaml, or a command under Verification is not scoped to a repo when the task names more than one.
Fix the file and run kusaw add again. The spec check does not rewrite the file for you.
Before and after (demo)
This before file fails the spec check. It uses repo:, the Goal is vague, and Verification is not a command:
---
id: demo-json-flag
title: JSON flag
repo: demo
---
## Goal
Make report better.
## Scope
The report command.
## Acceptance criteria
- [ ] It works.
## Verification
Run the tests.
## Out of scope
Other flags.kusaw add prints Spec rejected (unclear_spec): for repo: and for Verification. The after file (the task file above) is one change, names repos: [demo], and proves the flag with go test ./....
If it goes wrong
Spec rejected (unclear_spec):— the message after the colon is the fix. Put a real command under## Verification, userepos:(notrepo:), and fill every required section.- The run never leaves queued —
kusaw serveis not running. Start it, or open the factory and check the queue is not Paused. - Verification fails later in the run — the command under
## Verificationis what the factory runs. Fix the command or the code, then requeue or resume.
Glossary
Short definitions of factory terms. Each entry links related terms and the docs page that covers it. Look a term up with `kusaw glossary <term>`.
Review and approve a run
A run waits when the pipeline reaches a [gate](../glossary.md#gate). The run status is `waiting_for_human`. Approve continues the run; reject sends your note back as [feedback](../glossary.md#feedback). Delivery, when it happens, is a local commit. Kusaw never merges or pushes.