The 4 Step Program

A coordinator workflow for orchestrating dockeragents. You delegate, they implement. You enforce the loop until quality is achieved.

⚠️ MANDATORY: GitHub PR Posting

Every code review MUST be posted to GitHub as a PR comment. This is NOT optional.

• The code-reviewer agent MUST post their review to the PR
• A review that is not posted to GitHub means the task has FAILED
• The human needs to see the review on the PR page to evaluate quality before merging
• If the agent reports completion without posting to GitHub, send them back to post it

The Loop

┌─────────────────────────────────────────────────────┐
│                                                     │
│  ┌──────────┐    ┌──────────┐    ┌──────────────┐  │
│  │ 1. FIX   │───►│ 2. REVIEW│───►│ 3. 10/10?   │  │
│  │ (agent)  │    │ (agent)  │    │ (you check) │  │
│  └──────────┘    └──────────┘    └──────┬───────┘  │
│       ▲                                 │          │
│       │                                 │          │
│       │ NO                              │ YES      │
│       └─────────────────────────────────┤          │
│                                         ▼          │
│                                 ┌──────────────┐   │
│                                 │ 4. PRESENT   │   │
│                                 │ (you + URLs) │   │
│                                 └──────────────┘   │
│                                                     │
└─────────────────────────────────────────────────────┘

Step 1: Delegate FIX to Agent

Assign the implementation task to a dockeragent:

assign_task(agent_id, task_description)

The task description MUST include:

• Clear action to perform
• Context (issue numbers, file paths, errors)
• ALL requirements from the issue/task (100% must be implemented)
• Success criteria
• Instruction to self-review using Skill(code-reviewer) and POST to GitHub when done

CRITICAL: 100% Issue Coverage Requirement

When delegating, you MUST:

1. Read the full issue: gh issue view <number>
2. Extract EVERY requirement, acceptance criterion, and edge case
3. Include ALL of them in the delegation prompt
4. Make it clear that 100% of requirements must be implemented

Example delegation:

"Fix the authentication bug in src/auth.ts (Issue #45).

Requirements from issue (ALL must be implemented):

1. Session token expires correctly after 24 hours
2. Refresh token works when session token expires
3. Error message shown when both tokens expire
4. User redirected to login page on auth failure

Success: ALL 4 requirements implemented, tests pass, bug no longer reproducible.

When complete, run Skill(code-reviewer) on your changes, POST the review to GitHub, and report the results with the PR link."

IMPORTANT: The agent MUST ALWAYS create PR for work, or update the existing PR with the work they've done.

CRITICAL: PR Must Link and Close Issues

When creating PR, agent MUST:

1. Use Closes #X or Fixes #X in PR body for each issue being addressed
2. Include "Related Issues" section listing all related issues
3. Verify issue links with gh pr view --json closingIssuesReferences

Example PR body must include:

## Related Issues
- Closes #45 - Auth token expiration bug
- Related to #40 - Auth system improvements

Step 2: Agent Performs REVIEW (MUST POST TO GITHUB)

The dockeragent MUST invoke the code-reviewer skill on their own work:

Skill(code-reviewer)

This triggers the 6-pass ultra-critical methodology:

1. Technical Issues - Runtime failures, type errors, null handling
2. Code Consistency - Style, patterns, naming conventions
3. Architecture - Design, dependencies, complexity, coupling
4. Environment - Compatibility, security, performance risks
5. Verification - Run build, tests, linting - actual commands
6. Synthesis - Overall assessment with suggestion counts

CRITICAL: Review MUST Be Posted to GitHub

The review is NOT complete until it is posted to GitHub as a PR review/comment.

The code-reviewer skill will:

• Analyze the PR changes
• Generate the ultra-critical review
• POST the review to GitHub using mcp__github__create_pull_request_review

The human needs to see the review on the PR page. A local-only review that isn't posted to GitHub is useless - the human won't see it and can't evaluate the quality before merging.

Delegation must include:

"After reviewing, POST your review to GitHub. The human must be able to see your review on the PR page."

The agent reports back with:

• Their review results
• Confirmation that the review was posted to GitHub
• Link to the PR where the review can be seen

IMPORTANT: The agent MUST ALWAYS post the Review as comment on the PR.

Step 3: You CHECK - Is the review 10/10 AND 100% Issue Coverage?

When the agent reports back, evaluate: Is the review 10/10 AND does it cover 100% of issue requirements?

100% Issue Coverage Check (MANDATORY)

BEFORE checking review quality, verify the implementation covers ALL requirements from the original issue/task:

1. Identify ALL requirements from the original issue:

   • Read the issue: gh issue view <number>
   • Extract every acceptance criterion
   • Note every edge case mentioned
   • List every functional requirement

2. Verify each requirement is implemented:

   • ✅ Implemented: Code exists that fulfills this requirement
   • ❌ NOT Implemented: Requirement missing from implementation

3. Coverage must be 100%:

   • If ANY requirement is missing → Send agent back immediately
   • Do NOT proceed to review quality check until coverage is 100%

10/10 Review Quality Check

A 10/10 review means ALL of the following:

• 100% of issue/task requirements implemented (verified above)
• ZERO items in "Suggest Fixing" section
• ZERO items in "Possible Simplifications" section
• ZERO items in "Consider Asking User" section
• ZERO further notes
• All verification commands executed and passing
• DO NOT ACCEPT POTENTIAL WORK IN REVIEW FOR A LATER PR (this is still a suggestion)
• Review MUST be posted to GitHub PR - if not posted, task is incomplete

If NOT 10/10 (any suggestions exist):

Send the agent back to fix:

send_message_to_agent(agent_id, "Review shows X suggestions. Fix all of them, then re-review with Skill(code-reviewer) and POST to GitHub.")

→ Loop back to Step 1

If YES 10/10 (zero suggestions):

→ Proceed to Final Coverage Gate

Step 3.5: FINAL COVERAGE GATE (Before Presenting)

MANDATORY: Before presenting to human, perform one final 100% coverage verification using LINE-BY-LINE requirement checking.

Final Coverage Check Process

Step 1: Extract ALL Requirements from Issue

# Get ALL checklist items from issue
gh issue view <number> --json body --jq '.body' | grep -E "^\- \["

# Also check for requirements in prose (not just checkboxes)
gh issue view <number>

Don't rely on memory - actually parse the issue text.

Step 2: Create Line-by-Line Verification Table

MANDATORY - You MUST create this exact table:

## Issue #X - Full Requirements Check

| Requirement | PR Status | Evidence |
|-------------|-----------|----------|
| [exact text from issue] | ✅ | `file.ts:line` - [implementation] |
| [exact text from issue] | ❌ MISSING | Not found in PR |
| [exact text from issue] | ⚠️ PARTIAL | `file.ts:line` - [what's missing] |
| [exact text from issue] | ⚠️ MANUAL | Requires [runtime/editor] |

Status meanings:

• ✅ = Fully implemented, can cite exact code
• ❌ MISSING = Not implemented at all
• ⚠️ PARTIAL = Partially implemented (counts as NOT done)
• ⚠️ MANUAL = Requires manual verification

Step 3: Calculate Honest Coverage

Implemented (✅ only) / Total Requirements = Coverage %

Be brutally honest:

• ⚠️ PARTIAL = NOT implemented
• ⚠️ MANUAL items that CA