Ticket
Also called Issue · Task
A bounded unit of work with a clear done state, sized so an agent can finish it in one session.
A ticket is one bounded piece of work: a title, enough description to act on, and a definition of done. Issue trackers have used the word for decades; in agentic coding it takes on a second meaning as the natural unit you hand an agent. A ticket is smaller than a spec and larger than a single prompt. It should fit inside one session with room to spare.
Tickets that are too big are the common failure. “Migrate the app to the new auth provider” sounds like a task, but it is a project, and an agent given a project will run until it drifts out of the smart zone, then keep going anyway. Tickets that are too vague fail differently: the agent picks an interpretation and builds it, and you find out at review time.
Slice work into tickets that end in something checkable: a passing test, a green automated check, a screen you can open. Put the acceptance criteria in the ticket itself, so the same text works as the prompt, the handoff artifact, and the review checklist. When an agent runs AFK, one ticket per run keeps failures small and diffs reviewable.
- CodexCloud tasks are ticket-shaped by design; one task, one sandbox, one pull request.
- Claude CodePaste the ticket as the first message, or point the agent at the GitHub issue with
gh issue view. - AntigravityThe manager breaks a request into tasks; keep each one ticket-sized before you approve the plan.
“Can I give it the whole redesign in one go?”
“Split it into tickets first. One screen, one ticket, each with a done condition.”
“That's like twelve runs.”
“Twelve reviewable PRs instead of one you can't read. That's the point.”
Course 01 puts every one of these terms to work: you install Claude Code, run the loop, and ship a real project — permission modes, compaction, hooks and all.
Start Course 01 →