Workstreams & Tasks
Long-lived context, delivered in Task-shaped slices
Work in Specbench has two grains. A workstream is a long-lived thread for an area of work — it holds the context. A Task is one coherent slice of change inside it — it's what actually lands. Workstreams explain why; Tasks deliver.
Workstreams
A workstream is a thread work keeps returning to — "Checkout flow", "Identity & access", "Pricing model". Every spec edit is made inside one, so no change ever arrives without context. Each workstream carries its framing:
- Description — what this thread of work is about.
- Goals — what done looks like, at the level of intent.
- Out of scope — what's deliberately excluded, so the boundary is a decision rather than an accident.
The framing is part of the record: when a Task's spec is published, its workstream's framing rides along as a Markdown narrative in the repository.
Selecting a workstream scopes what you see: the shared spec (Main) plus that workstream's in-flight changes, layered on top. Other workstreams' unmade decisions never leak into yours — isolation holds until a Task completes and its changes merge to Main.
Workstreams are Active while work returns to them, can be marked Done when the thread is genuinely finished, and can be archived when they were a false start. They're deliberately coarse: a workstream is a place, not a ticket. Most projects need a handful, not dozens.
Tasks
Inside a workstream, work is sliced into Tasks. A Task scopes the artefacts it covers — a statement of intent that gives its changes view its shape: the diff between what Main says and what this Task proposes.
Lifecycle
- Open — work in progress. Edits made in the workstream accumulate against the Task.
- Ready — submitted for agreement. The spec slice is complete and waiting on the team's yes.
- Done — agreed. The Task's changes merge onto Main and become part of the shared spec. This is the only way changes reach Main.
- Abandoned — the slice isn't happening; its changes never land.
Conflicts
Two Tasks can touch the same artefact. Specbench surfaces the conflict when it matters — at the point a Task's changes would land — and asks a person to resolve which version wins, rather than silently merging or silently dropping either side.
Publishing
Once a project has a repository connected, a Task can publish the agreed spec into it as files behind a pull request — see Publishing the spec. Publishing is always a deliberate, human act on a Task; nothing publishes automatically.