Order work with dependencies

Dependencies express an actual requirement: a ticket must wait until earlier work is merged and accepted. Delegator will bypass blocked tickets and pick up the first non-blocked ticket from the queue.

Split at review boundaries

Suppose a feature needs an endpoint, a client that calls it, and documentation of the finished behavior:

Endpoint ── merged and accepted ──▶ Client ── merged and accepted ──▶ Guide

Each step should leave the repository in a useful, testable state. Avoid splitting a single inseparable change into tasks that cannot be reviewed independently.

Link tickets as you create them

From the target repository:

endpoint_id=$(dg ticket create "Add the status endpoint" \
  "Implement the agreed status endpoint and its handler tests.")

client_id=$(dg ticket create "Display service status" \
  "Use the new status endpoint in the client and test success and error states." \
  --after "$endpoint_id")

guide_id=$(dg ticket create "Document service status" \
  "Document the endpoint and the client behavior with a short example." \
  --after "$client_id")

dg ticket map "$guide_id"

The endpoint can start immediately. The client waits until the endpoint ticket is DONE, and the guide waits until the client ticket is DONE. Merge each result into the project’s intended branch before accepting it so subsequent work starts from the integrated changes.

Link tickets across projects

Dependencies are project-agnostic and will be enforced across projects. For example, you may have a backend and frontend repo. In the example above, the endpoint will be ticketed in the backend repo and the client work will be ticketed in the frontend repo. Links between these tickets will still be enforced even though they are in two different projects.

Wait for more than one prerequisite

Use repeated --after arguments or a comma-separated list. For an existing queued ticket:

dg ticket depend 42 --after 17 --after 23
dg ticket map 42

These IDs are illustrative; substitute the tickets in your queue. Both prerequisite tickets must reach DONE before ticket 42 is eligible.

To remove a dependency from a queued ticket:

dg ticket depend 42 --after 17 --remove

Remove a link only when the prerequisite is no longer needed. A failed or cancelled prerequisite does not release its dependents automatically.

Inspect and reprioritize

dg ticket map ID shows the connected dependency graph. dg ticket map ID --mermaid produces Mermaid source you can paste into a diagram viewer or engineering document.

ID can be any ticket in the dependency graph. Using the example above, dg ticket map 42, dg ticket map 17 and dg ticket map 23 will all output the same view.

dg ticket move ID top moves a queued ticket to the top of its list, but it must still satisfy its dependencies and capacity limits. If work appears stuck, inspect queue troubleshooting.

Have your agent write tickets and assign dependencies

One pattern that works well when breaking down large features is first using your agent to align on the design direction. Once that is settled, ask your agent to break down the design into focused tickets and create with dg ticket create and assign dependencies. State of the art agents should be able to handle this and setup the dependencies correctly.

Reference: dg ticket depend, dg ticket map, dg ticket move.