Write useful tickets

A useful ticket gives the agent enough context to start and gives you a clear way to judge the result. Aim for one change you can review as a unit.

State what success looks like

Include the desired behavior, the relevant part of the repository, constraints, and checks. For example:

Add a health-check endpoint.

Outcome: GET /health returns HTTP 200 with {"status":"ok"}.
Context: follow the existing HTTP handler and router conventions.
Scope: do not change authentication or add dependencies.
Validation: add a handler test and run the existing test suite.

Replace the example’s paths and behavior with facts from your project. An explicit boundary is especially helpful when a small feature sits near a larger refactor.

Create from prose or a file

For a short task:

dg ticket "Add a health-check endpoint" \
  'Add GET /health returning HTTP 200 with {"status":"ok"}. Follow existing router conventions, add a handler test, and do not change authentication.'

For a longer plan, save the prose in a file and import it:

dg ticket "Add a health-check endpoint" --body-file health-check-plan.md

Running dg ticket with no arguments opens your configured $EDITOR to compose the title and body. A title alone requires --no-body; supplying a body is usually more useful for agent work.

Creation can start work immediately

If you want to prepare several tickets before any starts, run dg pause first. This pauses scheduling for the whole instance and lets existing runs finish. Resume with dg start when the tickets and dependencies are ready.

Refine a queued ticket

You can edit the title or prose while the ticket is QUEUED:

dg edit 42 --body-file revised-plan.md
dg edit 42 --title "Add a public health-check endpoint"

Use dg show 42 to read an existing ticket. dg ticket always creates work; it is not a lookup command.

If the task has already run, use the review workflow to continue its session. For work that naturally has several reviewable stages, create dependent tickets.

Reduce repeated exploration

Keep a short repository map in the instruction file your chosen agent reads (ie. AGENTS.md or CLAUDE.md): major directories, build and test commands, conventions, and useful entry points. In each ticket, identify the affected area when you know it.

This can reduce the amount of context an agent must discover, but it does not enforce a token budget. Delegator records aggregate usage reported by agents; it does not calculate billing or impose a spending limit.

Have your agent write tickets

Since delegator is installed locally on your machine, have your agent write the ticket. This pattern works well when you are brainstorming a path forward with your agent. Once you’ve decided on a direction, instruct your agent to file tickets using dg ticket.

Reference: dg ticket, dg edit.