Fix Prompt Generation

# Judge LLM Fix Prompt Generation

**Purpose:** Judge-specific action verbs, suppression cases, template fields, and worked example for the `## LLM Fix Prompt` block that pairs each consensus-level Judge finding with a paste-ready instruction prompt for the receiving agent (typically Builder).
**Read when:** Judge has shipped a VERIFIED finding (3/3 CONFIRMED, 2/3 LIKELY, or 1/3 grounded CANDIDATE that survived FILTER) and the finding warrants downstream action rather than escalation to a specialist.

> Universal authoring rules and prompt structure: `_common/LLM_PROMPT_GENERATION.md`.
> This file documents only Judge-specific verbs, suppression cases, template fields, and an example.

## Contents

- When Judge emits a Fix Prompt vs suppresses
- Judge action verbs
- Verb selection heuristic
- Judge-specific suppression cases
- Per-finding fix prompt template (Judge-specific fields)
- Worked example

---

## When Judge Emits a Fix Prompt vs Suppresses

Judge is review-only — it does not ship code. The Fix Prompt is the bridge between Judge's report and the receiving agent (Builder, Atlas, etc.). Pair it with every shipped consensus-level finding; suppress it for nit-only output and for findings escalated to a specialist that owns its own remediation prompt.

| Situation | Action |
|-----------|--------|
| Finding is CONFIRMED (3/3) or LIKELY (2/3) and warrants a fix in the same PR | Emit Fix Prompt with `APPLY-FIX` (or appropriate scoped verb) → Builder |
| Finding is grounded CANDIDATE (1/3 verified by Judge main context read) | Emit Fix Prompt with `APPLY-FIX` if HIGH-confidence after grounding; otherwise `INVESTIGATE-FURTHER` |
| Finding requires significant rework (design or approach is wrong) | Emit Fix Prompt with `REWRITE` → Builder + Atlas |
| PR is fundamentally wrong; restart from spec rather than patch | Emit Fix Prompt with `REVERT-AND-RESTART` → Builder + Scribe/Accord |
| Review identifies need for API or contract change | Emit Fix Prompt with `BREAKING-FIX` → Builder + Guardian + Launch |
| Review confidence MEDIUM; need to verify finding before changing code | Emit Fix Prompt with `INVESTIGATE-FURTHER` → Builder (investigation mode) or Judge re-entry with more engines |
| Finding flagged but not blocking; advisory only | Emit Fix Prompt with `DOWNGRADE` → Builder (advisory, no enforcement) |
| Finding is nit-only / style-only (no behavioral concern) | **Suppress Fix Prompt.** Note `Fix prompt N/A — nit-level feedback only; author's discretion.` |
| Security smell detected during review | **Suppress Fix Prompt** — escalate to Sentinel (Sentinel owns remediation prompt) |
| Refactoring suggestion, no bug | **Suppress Fix Prompt** — route to Zen (Zen owns refactoring) |
| Single-engine finding without consensus and grounding inconclusive | **Suppress Fix Prompt** — require consensus before action |

The Fix Prompt is required for every consensus-level finding that ships in the main findings list. Silent omission breaks downstream Builder expectations.

---

## Judge Action Verbs

Each fix prompt declares one verb at the top of `# Your task`.

| Verb | When to use | Receiving agent |
|------|-------------|----------------|
| `APPLY-FIX` | Confirmed bug/issue in PR, scoped fix in same PR (HIGH confidence, multi-engine consensus) | Builder (PR author) |
| `REWRITE` | Implementation needs significant rework — design or approach is wrong | Builder + Atlas |
| `REVERT-AND-RESTART` | PR is fundamentally wrong; restart from spec rather than patch | Builder + Scribe/Accord |
| `BREAKING-FIX` | Review identifies need for API or contract change | Builder + Guardian + Launch |
| `INVESTIGATE-FURTHER` | Review confidence MEDIUM; need to verify finding before changing code | Builder (in investigation mode) or Judge re-entry with more engines |
| `DOWNGRADE` | Finding flagged but not blocking; author should consider but may defer | Builder (advisory only — no enforcement) |

---

## Verb Selection Heuristic