Skip to main content

Syntax

Description

The blocked command identifies issues that cannot proceed because they’re waiting on other work to complete. These are issues that:
  • Have status open, in_progress, or blocked
  • Are not archived
  • Have at least one active “blocks” relationship where the blocker is still open
This command is essential for:
  • Identifying bottlenecks in your project
  • Understanding project dependencies
  • Prioritizing work to unblock others
  • Finding issues that need attention
Blocked issues cannot be started or progressed until their blocking dependencies are resolved. Use this command to understand what’s preventing progress.

How “Blocked” is Determined

An issue is considered blocked when:
1

Active status

The issue has status IN ('open', 'in_progress', 'blocked')Closed issues are excluded even if they have blocking relationships.
2

Not archived

The issue must not be archived (archived = 0)
3

Has active blockers

The issue has at least one “blocks” relationship where:
  • The relationship points FROM this issue TO a blocker
  • The blocker issue has status open, in_progress, or blocked
If all blockers are closed, the issue is no longer considered blocked.

Blocked Issues View

The command queries the blocked_issues database view:
This ensures only issues with active blockers are shown.

Examples

Find Blocked Issues

List all blocked issues:

No Blocked Issues

When all issues are unblocked:

JSON Output

Get detailed information about blocked issues:
The JSON output includes:
  • blocked_by_count - Number of issues blocking this one
  • blocked_by_ids - Comma-separated list of blocker IDs

Output Format

Blocked issues are displayed with:
  • Issue ID (cyan) - The unique identifier
  • Title - Issue description
  • Reason - Current status (usually “blocked” or “open”)
Issues are sorted by:
  1. Priority (descending) - Highest priority first
  2. Created date (descending) - Older issues first

Finding What Blocks an Issue

To see detailed blocker information:
The “Incoming Relationships” with type “blocks” show what’s blocking this issue.

Common Workflows

Identify Bottlenecks

1

Find blocked issues

2

Review each blocker

For each blocked issue, check details:
Note the incoming “blocks” relationships
3

Prioritize blockers

Focus on completing the blocking issues:
4

Complete blockers

Work on and close the blocking issues
5

Verify unblocked

ISSUE-007 should no longer appear

Unblock High-Priority Work

1

Find blocked high-priority issues

2

Identify their blockers

3

Complete blocker

4

Update blocked issue

Weekly Bottleneck Review

Regular review to prevent blocked work piling up:

Understanding Blocker Relationships

Why Issues Become Blocked

Scenario: ISSUE-007 depends on ISSUE-005 being completed firstSetup:
Result: ISSUE-007 is blocked until ISSUE-005 is closed
Scenario: Testing can’t start until implementation is doneSetup:
Result: ISSUE-011 blocked until ISSUE-010 complete
Scenario: Deployment needs both testing and documentationSetup:
Result: ISSUE-015 blocked until BOTH are complete
Scenario: Chain of dependenciesSetup:
Result:
  • ISSUE-002 blocked by ISSUE-001
  • ISSUE-003 blocked by ISSUE-002
  • ISSUE-003 indirectly blocked by ISSUE-001

Unblocking Issues

To unblock an issue, complete its blockers:
1

Find the blockers

Look for “Incoming Relationships” with type “blocks”
2

Complete each blocker

3

Verify unblocked

ISSUE-007 should no longer appearCheck ready work:
ISSUE-007 should now be ready if status is ‘open’

Blocked vs Ready

blocked

Cannot proceed
  • Has active blockers
  • Waiting on dependencies
  • May have status ‘blocked’
  • Shows bottlenecks

ready

Can start now
  • No active blockers
  • Status is ‘open’
  • Available for work
  • Shows opportunities
An issue is either blocked OR ready, never both:
  • Blocked = has dependencies
  • Ready = no dependencies

Scripting Examples

Find Critical Blocked Work

Identify high-priority blocked issues:

Blocker Dependency Report

Show what blocks what:

Auto-prioritize Blockers

Automatically increase priority of blockers:

Monitor Block Duration

Track how long issues have been blocked:

Common Questions

The “blocks” relationship is explicitly defined, not based on actual work capability. If you can work on it independently:
  1. Consider if the blocker relationship is necessary
  2. Remove the relationship if not needed:
Yes technically, but not recommended. The relationship exists for a reason - usually technical or logical dependencies. Working on a blocked issue may lead to:
  • Rework when blocker completes
  • Conflicts or compatibility issues
  • Wasted effort
Use issue show:
Look for “Incoming Relationships” with type “blocks”
This creates a deadlock where nothing can proceed. To detect:
Check if issues block each other. Resolve by removing one relationship or completing one issue first.
The current blocked command only shows issues. Specs can have blocking relationships, but aren’t included in this command’s output.
The count shows issues with active blockers. Some blockers may have been closed recently, causing the counts to update.

Troubleshooting

Cause: Database inconsistencySolution:
This should not happen - an issue should be either blocked OR ready, never both.
Cause: Other blockers still open, or database not refreshedSolution:
  1. Check all blockers:
  2. Sync database:
Cause: May include archived or old issuesSolution: Check individual issues:
Archive if no longer relevant:
Cause: Over-use of blocking relationshipsSolution: Review relationships and remove unnecessary ones. Focus on true dependencies only.

ready

Find ready work

status

Project status overview

issue show

View blocker details

link

Create blocking relationships

issue update

Update issue status

Next Steps

1

Find blocked issues

2

Review blockers

3

Prioritize blockers

4

Complete blocker work

Work on and close blocking issues
5

Verify unblocked

Previously blocked issues should now appear as ready

Relationships Concept Guide

Learn more about dependency modeling and blocking relationships