4-step-program

What this skill does

# 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:
```markdown
## 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

```bash
# 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:

```markdown
## 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 C