Writing good tickets

Make the outcome clear

A useful objective describes a result you can check. “Customers can reset a forgotten password” is more useful than “Improve authentication”. Put background in Context and hard boundaries in Constraints.

Acceptance criteria are separate, testable statements. Say what evidence would convince you, including error cases and checks that must pass. Do not treat a worker's confidence as proof.

Choose the required outcome

A development ticket can require a pull request opened with checks passing. Other supported outcomes include a merge, deployment, report, artifact or a performed operation, each with its own required evidence. Choosing an outcome does not grant approval to deploy, delete data, change credentials, spend money or send external communications.

Use playbooks for repeated rules

Brand and project playbooks supply shared instructions in every ticket context. Keep project commands, review expectations and approval rules there. Saving creates a new version. If context changes during work, the worker must read it and submit against the current versions. You review differences explicitly.

Project knowledge suggestions group similar stored findings across at least three distinct tickets. They are attributed worker reports, not verified facts. Nothing updates the playbook until you review and save in its editor. Dismissed suggestions stay hidden unless matching findings recur on three additional tickets.

Dependencies and scope

Use Depends on when another ticket must finish first. Open dependencies prevent Ready, claim and acceptance. Adding a dependency while a run is working blocks the ticket but does not stop that run. Blocking loops are refused. Batches group work; their planning order does not enforce dependencies. A separate Dependency order view puts prerequisites first.

You can paste or upload a Markdown ticket list in a project's import screen. Review and edit the preview before confirming; tickets are created in Backlog, optionally in a new batch.

Recommend a worker or model

A recommendation is guidance unless Required is selected. Required recommendations match the worker type and model saved by you on the worker, ignoring a model declared by the session. A ticket with no requirement remains available to every scoped worker. Session model reports are still recorded on runs for reporting.

See reviewing results for how criteria become a human decision.