Skip to main content
Issue relations let you describe dependencies between coding tasks so the agent host executes them in the right order. When one issue blocks another, Gentic automatically holds the blocked issue in the queue until its dependency is completed or cancelled — no manual coordination required.

​
What issue relations are

A relation connects two issues with a directional dependency: issue A blocks issue B. The agent host respects this constraint at the moment it polls for work. If issue B is in the Todo queue but it is blocked by issue A, the host skips issue B and moves on. Once issue A reaches a completed or cancelled state, issue B becomes eligible and the host 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.
Break large features into multiple focused issues and use blocking relations to sequence them. Smaller issues give the agent a tighter scope, produce cleaner pull requests, and are easier to review. A chain of three well-scoped issues almost always produces better results than one monolithic issue.

​
How blocking works

The enforcement happens at the host level, not the UI level. The Gentic API filters out issues that have unresolved blockers when it responds to the host’s poll. This means:
  • You can move a blocked issue to Todo at any time — it simply will not be executed until the blocker clears.
  • The issue detail page shows a Blocked badge when an issue has an unresolved blocker.
  • A blocker is considered resolved when its status is completed or cancelled.

​
How to add a relation

​
Relation directions at a glance

​
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 host on its next poll.

​
Manage relations from an AI assistant

Relations are not web-app-only. If you have connected the MCP server, your assistant can read and edit them directly with four tools: list_issue_relations, list_issue_relation_candidates, add_issue_relation, and delete_issue_relation. This is the fastest way to wire up a chain of issues you just created in bulk:
“Create the four notifications issues, then make each one blocked by the previous one.”
See the Tools reference for parameters and return shapes.

​
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:
  1. Add notifications table migration — no blockers, runs first.
  2. Implement NotificationsService — blocked by issue 1. Runs after the migration lands.
  3. Add notifications API endpoints — blocked by issue 2. Runs after the service exists.
  4. Build notifications UI panel — blocked by issue 3. Runs last, once the API is available.
Each issue has a tight, well-defined scope. The agent works through them in order, and each pull request builds cleanly on the previous one.
Issue relations only affect the agent host’s execution order. You can still manually change an issue’s status or retry the agent regardless of its blocked state. The Blocked badge is a reminder, not a hard lock on your own actions.