What issue relations are
A relation connects two issues with a directional dependency: issue A blocks issue B. The agent worker respects this constraint at the moment it polls for work. If issue B is in theTodo queue but it is blocked by issue A, the worker skips issue B and moves on. Once issue A reaches a completed or cancelled state, issue B becomes eligible and the worker picks it up on the next poll cycle.
This is useful any time one piece of work must land before another can safely begin — for example, a database migration that must run before the API layer that depends on the new schema, or a shared utility module that must exist before the features that import it.
How blocking works
The enforcement happens at the worker level, not the UI level. The Gentic API filters out issues that have unresolved blockers when it responds to the worker’s poll. This means:- You can move a blocked issue to
Todoat any time — it simply will not be executed until the blocker clears. - The home screen shows a Blocked badge on any issue that has an unresolved blocker, so you can see the dependency state at a glance.
- A blocker is considered resolved when its status is
completedorcancelled.
How to add a relation
Navigate to the issue that should wait for another issue to finish first. This is the downstream issue — the one that is blocked.
Relation directions at a glance
| Direction | Meaning | Effect |
|---|---|---|
| This issue is blocked by issue A | Issue A must complete before this issue runs | Worker skips this issue until A is completed or cancelled |
| This issue blocks issue B | This issue must complete before issue B runs | Worker skips issue B until this issue is completed or cancelled |
How to remove a relation
Open either issue in the relation and scroll to the Relations section. Click the remove (×) icon next to the relation you want to delete. The relation is removed immediately and the blocked issue becomes eligible for the worker on its next poll.Example: sequencing a multi-step feature
Imagine you are building a new notifications system. You might create the following issues and link them in sequence:- Add
notificationstable migration — no blockers, runs first. - Implement
NotificationsService— blocked by issue 1. Runs after the migration lands. - Add notifications API endpoints — blocked by issue 2. Runs after the service exists.
- Build notifications UI panel — blocked by issue 3. Runs last, once the API is available.
Issue relations only affect the agent worker’s execution order. You can still manually change an issue’s status or reset the agent at any time regardless of its blocked state. Use the Blocked badge on the home screen as a reminder, not a hard lock on your own actions.

