reporter-protocol

Files (1)

• SKILL.md

SKILL.md (first lines)

# Reporter — Operational Protocol

<overview>
The reporter agent reads the structured findings JSON produced by the analyzer and the reviewer verdict supplied via dispatch context (parsed by the orchestrator from the reviewer's terminal output), renders a comprehensive markdown code review report with sections for issues found and the review verdict, and writes the final output to `{ROOT}/output/parity-test-f-review-report.md`. It is the final step of the parity-test-f Sequential pipeline (Pattern 1) on Tier 1d (Codex CLI). The quality bar is: the output markdown must be human-readable and contain both required sections without truncation or placeholder text.
</overview>

## Protocol

<protocol>

### 1. DISCOVER

1. Read inputs from the orchestrator dispatch context:
   - `findings_path`: path to `findings.json` written by the analyzer.
   - `reviewer_verdict`: verdict string from the reviewer (`approved` / `approved_with_concerns` / `rejected`), parsed by the orchestrator from the reviewer's terminal-output REVIEWER VERDICT block.
   - `reviewer_completeness_score`: completeness score from the reviewer.
   - `reviewer_missing_categories`: comma-separated missing categories from the reviewer (or "none").
   - `reviewer_notes`: reviewer notes text (or "none").
   - `output_path`: path where the final markdown report must be written (always `{ROOT}/output/parity-test-f-review-report.md`).
   - `state_path`: path to `pipeline-state.json` for status updates.
   - `run_id`: current run identifier.
   - `root`: resolved scope root.
2. Verify `findings_path` exists and is valid JSON. If the file does not exist: emit `BLOCKED` with message: "Analyzer findings not found at `{findings_path}`. The analyzer step may have failed."
3. Parse the findings JSON. If JSON is malformed: emit `BLOCKED` with message: "Analyzer findings at `{findings_path}` are not valid JSON."
4. Confirm `reviewer_verdict` is supplied and is one of `approved` / `approved_with_concerns` / `rejected`. If absent or unrecognized: emit `BLOCKED` with message: "Reviewer verdict not supplied in dispatch context. The reviewer step may have failed."

### 2. PROCESS

Render the markdown code review report using the following template (populated from parsed findings and verdict):

```markdown
# Code Review Report — parity-test-f

> Generated by the parity-test-f pipeline (Tier 1d — Codex CLI)
> Source diff: `{findings.diff_path}`
> Total issues found: {findings.issue_count}
> Review verdict: {reviewer_verdict}

## Issues Found

{If findings.issues is non-empty, group by category and render:}

### Null Checks

{For each issue where category = "null_check":}
- **[{issue.severity}]** `{issue.location}` — {issue.description}

{If no null_check issues:}
- No null check issues detected.

### Error Handling

{For each issue where category = "error_handling":}
- **[{issue.severity}]** `{issue.location}` — {issue.description}

{If no error_handling issues:}
- No error handling issues detected.

### Naming

{For each issue where category = "naming":}
- **[{issue.severity}]** `{issue.location}` — {issue.description}

{If no naming issues:}
- No naming issues detected.

## Review Verdict

| Field | Value |
|---|---|
| Verdict | {reviewer_verdict} |
| Completeness Score | {reviewer_completeness_score} |
| Missing Categories | {reviewer_missing_categories} |

{If reviewer_notes is non-empty and not "none":}
**Reviewer Notes:** {reviewer_notes}

{If reviewer_notes is empty or "none":}
**Reviewer Notes:** No additional notes.
```

Ensure:
- `## Issues Found` section is present and contains all three category subsections.
- `## Review Verdict` section is present with the verdict table.
- No section is left entirely blank or contains placeholder text.
- The header block accurately reflects `findings.diff_path`, `findings.issue_count`, and `reviewer_verdict`.

### 3. DELIVER

1. Create the `{root}/output/` directory if it does not exist.
2. Write the rendered markdown to `output_path` using the Write tool.
3. Update `pipeline-state.json`:
   - Set `phases[2].status` = `"completed"`.
   - Set `phases[2].outputs` = `[output_path]`.
   - Set top-level `status` = `"completed"`.
   - Set `completed_at` = current ISO-8601 timestamp.
4. Emit terminal status:
   - `DONE` — report written successfully; both required sections present; verdict is `"approved"`.
   - `DONE_WITH_CONCERNS` — report written but reviewer verdict is `"approved_with_concerns"` or `"rejected"` (surface the verdict and reviewer_notes to the orchestrator).
   - `BLOCKED` — findings file missing/malformed or `reviewer_verdict` not supplied; output not written.

</protocol>

<invariants>
- ALWAYS write the output to exactly `{ROOT}/output/parity-test-f-review-report.md` — never a different path.
- ALWAYS include `## Issues Found` and `## Review Verdict` sections in the output.
- NEVER write partial output — if rendering fails mid-way, do not write the file; emit BLOCKED.
- NEVER hardcode platform paths — use only the `root` value supplied in the dispatch context.
- ALWAYS update `pipeline-state.json` phases[2] and top-level status after writing.
- Emit exactly one terminal status: DONE / DONE_WITH_CONCERNS / BLOCKED.
</invariants>

From gustavo-meilus/superpipelines, MIT.

More from gustavo-meilus/superpipelines