Agents use the ready command to find issues that are unblocked and available to work on.
1
Check for ready work
Copy
> User: Can you work on what's ready?⏺ Agent: I'll check what issues are ready to work on.⏺ plugin:sudocode:sudocode - ready (MCP)() ⎿ { "ready": { "issues": [ { "id": "i-yy9c", "title": "Implement EditorService for detection and launching", "priority": 1 }, { "id": "i-78fl", "title": "Add .sudocode/config.local.json to .gitignore", "priority": 2 } ] } }
2
Agent prioritizes work
Copy
⏺ Agent: I found 2 ready issues. Since i-yy9c has higher priority (P1),I'll work on implementing the EditorService.
What makes an issue “ready”:
Status is open (not in_progress or closed)
No blocking dependencies (all blockers are closed)
Appears in the ready queue in priority order
The ready command automatically filters out blocked work, so agents can trust that everything returned is safe to claim.
Before claiming an issue, agents will review context as needed to understand requirements and relationships.
1
Get issue details
Copy
⏺ plugin:sudocode:sudocode - show_issue (MCP)(issue_id: "i-yy9c") ⎿ { "id": "i-yy9c", "title": "Implement EditorService for detection and launching", "content": "Create backend service that detects and launches editors...", "status": "open", "priority": 1, "relationships": { "outgoing": [ { "to_id": "s-7mug", "relationship_type": "implements" } ], "incoming": [] }, "tags": ["backend", "editor-service"] }
2
Review the spec
Copy
⏺ Agent: Let me check the spec this implements to get more context.⏺ plugin:sudocode:sudocode - show_spec (MCP)(spec_id: "s-7mug") ⎿ { "id": "s-7mug", "title": "Open in IDE - Global User Preference", "content": "## Goals\n\nSingle-click launch of worktree in user's preferred editor...", ... }
Why review context:
Understand what the issue implements (linked specs, issues, feedback)
When an issue implements a spec, agents will provide feedback before closing the issue. This creates a record of what was accomplished and helps improve specs.
1
Document implementation results
Copy
⏺ plugin:sudocode:sudocode - add_feedback (MCP)( issue_id: "i-yy9c", to_id: "s-7mug", type: "comment", content: "## Implementation Complete\n\nSuccessfully implemented the EditorService backend service...\n\n### What Was Accomplished\n\n1. **EditorService Class**\n - ✅ Complete service implementation\n - ✅ Configuration management\n - ✅ Editor detection for 6 editor types\n\n2. **Security & Validation**\n - ✅ Path validation\n - ✅ Command injection prevention\n\n3. **Unit Tests**\n - ✅ 24 comprehensive tests\n - ✅ All tests passing\n\n### Design Decisions\n\n- Used detached processes to avoid blocking\n- Auto-detection uses first available editor\n\n### Evidence of Completion\n\n```bash\nnpm test -- editor-service.test.ts\n✓ 24 tests passed\n```" )
Feedback types:
comment - Implementation results, what was built (most common)
suggestion - Spec needs updates based on learnings
request - Need clarification or spec is incomplete
What to include in feedback:
Requirements met from the spec
Design decisions made during implementation
Challenges encountered and how they were resolved
Evidence of completion (test results, screenshots)
Detailed feedback helps users understand what was built and helps future agents learn from implementation experience.
Issues follow a defined status lifecycle:Valid transitions:
open → in_progress (claiming work)
in_progress → closed (completing work)
open → blocked (discovered blocker before starting)
in_progress → blocked (discovered blocker during work)
blocked → open (blocker resolved, issue becomes ready again)
When a blocker is resolved, the issue returns to open status and appears in the ready() queue. An agent must then claim it again by setting status: in_progress.
