Skip to content
Spec{0}

Tasks and verifications

Tasks and verifications look similar at a glance — both are short rows you check off — but they answer different questions.

Tasks: what to do

A task names a unit of work. The list is flat and ordered; the agent works top to bottom.

Each task has:

  • A title and a short description.
  • A status: pending → in-progress → completed (or skipped).
  • A required flag. Optional tasks can be skipped without blocking submit.

The agent uses spec0_next_task to walk the list, marks each in-progress before starting, completed when done. Recorded commits can be attributed to one or more completed tasks — that’s the link between the spec and the git history.

Verifications: how to prove it

A verification is a check the work must clear before the card can ship.

Each verification has:

  • A title — what’s being checked.
  • A description — how to check it.
  • An evidenceKind: text, attachment, or either.
  • A required flag. Required verifications block submission until addressed.

When the agent finishes the work, it addresses each verification — pasting command output for a text item, uploading a screenshot or video for an attachment item.

Why both?

Tasks describe the build. Verifications describe the proof. A card with thorough tasks but no verifications is a wishlist; a card with verifications but no tasks is a guessing game. Most cards need both.

A good rule: every meaningful slice of work should have at least one verification that tells the reviewer how to confirm it landed.

Editing after creation

You can add, remove, reorder, or edit tasks and verifications while the card is in Drafts or Inbox. Once a card is in Doing or later, structural edits require an edit lock and only the agent’s tooling can rearrange tasks.