Receive Feedback

Receive Feedback

Overview

Process code review feedback with verification-first discipline. No performative agreement. Technical correctness over social comfort.

The orchestrator verifies and applies fixes under a strict per-item contract. If the agent supports subagents, each valid item is fixed by a dedicated subagent dispatched in parallel; otherwise the orchestrator applies the same fixes sequentially itself, one item at a time, under the identical Fix-Quality Contract — producing identical output.

Quick Reference

┌─────────────┐     ┌──────────────┐     ┌──────────────────────┐
│   VERIFY    │ ──▶ │   CONFIRM    │ ──▶ │   APPLY FIXES        │
│ (tool-based)│     │ ("launch     │     │ (one fix per valid   │
│             │     │  fixes for   │     │  item — parallel     │
│             │     │  1,2,3?")    │     │  subagents if        │
│             │     │              │     │  supported, else     │
│             │     │              │     │  sequential)         │
└─────────────┘     └──────────────┘     └──────────────────────┘

Core Principle

Verify, confirm once, then apply the fixes for the chosen set.

If a bug is valid, it gets fixed. Full stop. No deferral, no excuses. When subagents are available, one subagent fixes each item in parallel; otherwise the orchestrator fixes each item sequentially under the same contract.

When To Use

• Receiving code review from another LLM session
• Processing PR review comments
• Evaluating CI/linter feedback
• Handling suggestions from pair programming

Workflow

1. Verify every item against the current codebase (tools, not memory). 2. Classify each item as VALID (must fix) or INVALID (reject with evidence).

• Truly unparseable items get one clarification question. That is the only escape.

3. Print a short summary: invalid items with evidence, valid items numbered. 4. Ask exactly one prompt: launch fixes for 1,2,3? (list every valid item's number — the default proposal is always the full valid set). 5. Resolve the user's reply:

• Confirmation (y, yes, go, ok, do it, lgtm, or just ↵) → dispatch the full proposed set.
• A comma/space-separated list of numbers (e.g. 1,3 or 1 3 4) → dispatch only those numbers. They must be a subset of the proposed valid set. Items the user omits are NOT marked deferred — they are simply not run this round.
• no / cancel / stop → halt without dispatching.
• Anything else → re-print the prompt once; do not invent a new disposition.

6. Apply the fix for each chosen item under the Fix-Quality Contract. If the agent supports subagents, dispatch one subagent per chosen item in parallel (the orchestrator does not edit files itself in this branch); otherwise apply each fix sequentially yourself, one item at a time, following the same contract. Either branch must produce identical results. 7. Collect the per-item results and emit the final response table.

Forbidden Behaviors

These are non-negotiable. The orchestrator may not:

• Ask the user which items to fix. The only question allowed is launch fixes for <numbers>?, where <numbers> defaults to the full valid set. (The user may override by replying with their own subset of numbers — that is a user override, not an agent question.)
• Claim an issue is pre-existing. If a reviewer found it on this PR, it is in scope.
• Claim an issue is out of scope for the PR. If the bug exists on this branch, the PR owns it.
• Defer a valid item to "later", a "backlog", a "follow-up PR", or a "future ticket".
• Use any reasoning — risk, complexity, time, churn, "minor", "cosmetic", "edge case" — to avoid fixing a valid item.
• Bundle multiple fixes together. One valid item = one isolated fix (one subagent when supported, one focused sequential pass otherwise).
• When subagents are available, edit code directly in the orchestrator — delegate each fix to a subagent instead.

A valid bug raised by a code or security reviewer must be fixed. There is no other option.

Hard Gates

Do not advance to the next gate until its pass condition is true. Details live in VERIFICATION.md, EVALUATION.md, and RESPONSE.md.

Gate 1 — Verification evidence (per item)

1. Locate the referenced code or behavior (read the file, search the codebase, run the relevant test, or another check from VERIFICATION.md). 2. Record the outcome: VALID (claim holds and is actionable) or INVALID (claim fails), with an artifact (file path and line range, command/test result, or short quoted tool output — not paraphrase alone). 3. If unparseable, mark NEEDS CLARIFICATION with the specific question. Do not invent a disposition.

Pass when: Every item has VALID / INVALID / NEEDS CLARIFICATION plus an artifact. Fail (stop): Proceeding without an artifact, or downgrading a VALID item to "skip" / "defer" / "pre-existing" / "out of scope".

Gate 2 — Single batch confirmation

1. Print the invalid items (with rejection evidence) and the valid items (numbered). 2. Ask the single prompt: launch fixes for <comma-separated numbers>? — <numbers> MUST be the full valid set. Do not pre-narrow it. 3. Accept the user's reply per the Workflow resolution rules: confirmation → full set; subset of numbers → that subset only; refusal → halt.

Pass when: The user confirms or supplies a subset of the proposed numbers, and the chosen set is locked in writing before Gate 3. Fail (stop): Proposing a narrowed default, asking "which would you like to fix?", or proposing to defer any valid item.

Gate 3 — Apply fixes for the chosen set

1. Each chosen item gets exactly one isolated fix carrying: the original feedback text, the verification artifact, the file/line target, and the Fix-Quality Contract. 2. If the agent supports subagents, dispatch one subagent per item in a single block so they run in parallel, and do not edit files in the orchestrator. Otherwise, apply each fix sequentially yourself, one item at a time, under the identical contract.

Pass when: Every item in the user-chosen set has been fixed under the contract (one subagent each when supported, or one focused sequential pass each otherwise). Fail (stop): Bundling fixes, or skipping any item the user actually chose.

Gate 4 — Response artifact (batch)

1. After subagents return, fill the structured template in RESPONSE.md. 2. The response has exactly two sections: Implemented and Rejected. There is no Deferred section. 3. Valid items the user explicitly excluded from this round get a single line under the table — Not run this round: <numbers> (user-excluded) — and nothing else. Do not label them deferred or out of scope.

Pass when: Every item appears in Implemented or Rejected with file:line citations, and any user-excluded valid items are listed verbatim under the table. Fail (stop): Shipping a summary that omits an item, lacks evidence on a rejection, or invents a "Deferred" bucket.

Command Workflow

Invoke the receive-feedback skill with a feedback file path as its argument.

1. Read the feedback file at $ARGUMENTS 2. Parse individual feedback items, whether numbered, bulleted, or freeform 3. Verify each item per VERIFICATION.md 4. Confirm via single launch fixes for <numbers>? prompt 5. Apply the fix for each valid item — one subagent each if subagents are supported, otherwise one sequential pass each 6. Produce the response summary defined in RESPONSE.md

Expected Feedback File Format

1. Remove unused import on line 15
2. Add error handling to the API call
3. Consider using a generator for large datasets
4. Fix typo in variable name: `usr` → `user`

Freeform prose is also acceptable; extract actionable items from the text.

Fix Dispatch Template

When fixing an item — whether dispatching a subagent or doing it sequentially yourself — the fix brief MUST include:

• The original feedback text (verbatim).
• The verification artifact: file path, line range, and what was confirmed.
• The exact change required, or "implement the reviewer's suggestion as written" if the reviewer specified one.
• The fix-quality contract below, applied to every fix (copied verbatim into each subagent prompt when subagents are used).

Fix-Quality Contract (apply to every fix)

You are fixing one code review finding. Hard requirements:

1. Make the fix. Do not defer. Do not declare anything out of scope.
   Do not call anything pre-existing. If you discover the fix needs to
   touch adjacent code to be correct, touch it.

2. The fix must be clean and architectural — idiomatic for the language
   and the file's surrounding patterns. Read enough of the
   surrounding module to match its conventions before editing.
   No inline hacks, no band-aids, no "minimum to make it green".

3. Do NOT over-engineer. No new abstractions, no speculative
   generality, no helper layers, no config knobs. Solve the actual
   reported problem. If three lines are right, write three lines.

4. Write NO comments unless a future reader would be genuinely
   confused without one (a non-obvious invariant, a workaround for a
   specific upstream bug, a hidden constraint). Never write comments
   that restate what the code does. Never write headers, banners,
   "fix:" markers, or "// added for review feedback" notes.
   Excessive comments are a defect — do not produce them.

5. Run the project's typecheck / lint for the file you touched if a
   command is obvious from the repo. Report what you ran.

6. Report back: the resulting diff, the file:line of the change, and
   one sentence on what you changed and why.

When dispatching subagents, use a general-purpose subagent unless a domain-specific one is clearly better.

Example

Invoke the receive-feedback skill with a feedback file path:

receive-feedback reviews/pr-123-feedback.md

Reads the file, verifies each item, prints invalid/valid summary, asks launch fixes for 1,3,4?, and on confirmation fixes items 1, 3, and 4 — three subagents in parallel if supported, otherwise three sequential fixes under the same contract.

Files

• VERIFICATION.md - Tool-based verification workflow
• EVALUATION.md - Classification rules (VALID / INVALID / NEEDS CLARIFICATION)
• RESPONSE.md - Structured output format
• references/skill-integration.md - Using with code-review skills

Evaluation Rules

Binary Classification

Every feedback item is exactly one of:

There is no fourth bucket. There is no "Deferred". There is no "Out of scope". There is no "Pre-existing".

Prohibited Reasoning

The following are NOT valid reasons to downgrade a VALID item or move it out of the fix queue:

• "This is pre-existing." — If the reviewer found it on this PR, it is in scope.
• "This is out of scope for the PR." — If the bug exists on this branch, the PR owns it.
• "We can fix this in a follow-up." — No. Fix it now.
• "This is minor / cosmetic / an edge case." — Irrelevant. A valid bug is a valid bug.
• "This would be too much churn." — Irrelevant.
• "The reviewer lacks context." — If you can prove that with a verification artifact, the item is INVALID. If you cannot, it is VALID.
• "YAGNI." — Only applies when verification proves the code or feature has zero consumers; then the item is INVALID with evidence, not deferred.

If you find yourself reasoning toward any of the above, stop and ask: did verification actually disprove the claim? If no, the item is VALID and must be dispatched to a subagent.

Evaluation Order

Within the verification pass, work top-to-bottom through the feedback list. Do not reorder by perceived priority — the user sees the same numbering the reviewer used.

When To Reject (INVALID)

Reject only with a concrete verification artifact:

• Suggestion targets code that does not exist on this branch (cite path).
• Symbol the reviewer wants removed is referenced (cite Grep hit at file:line).
• Bug the reviewer reports does not reproduce (cite the test or script output).
• Suggestion contradicts an established codebase pattern documented in a beagle skill (cite the skill and the existing usage).

A rejection without an artifact is not a rejection — it is deferral in disguise. Treat it as VALID.

Anti-Patterns

Skill Integration

Using Code-Review Skills for Verification

When feedback relates to a specific technology, load the relevant skill to verify against established codebase patterns.

Skill Lookup Table

Integration Workflow

1. Identify domain - What technology does the feedback concern? 2. Load skill - Load the matching <skill-name> skill from the relevant beagle plugin 3. Cross-reference - Does feedback align with skill guidance? 4. Resolve conflicts - If feedback contradicts skill, flag for discussion

Conflict Resolution

If reviewer feedback conflicts with skill guidance:

Skill says: [pattern from skill]
Reviewer says: [contradicting suggestion]

Flag: "Feedback conflicts with established pattern. Discuss before implementing."

Codebase patterns (captured in skills) take precedence over external opinions.

Response Format

Pre-Dispatch Summary (before the confirmation prompt)

Print invalid items with evidence, then valid items numbered, then the single prompt.

### Invalid (rejected with evidence)
| # | Item | Evidence |
|---|------|----------|
| 2 | Remove `validate_user` | Called at `middleware.py:45` |
| 5 | Switch to generator | Input is <1KB read once at startup (`config.py:12`) |

### Valid (will be fixed by subagents)
| # | Item | Target |
|---|------|--------|
| 1 | Null check on session | `src/auth.py:42` |
| 3 | Rename `data` → `user_data` | `src/utils.py:15` |
| 4 | Typo `usr` → `user` | `src/models.py:88` |

launch fixes for 1,3,4?

The confirmation line is the entire prompt and must list every valid item's number. Do not pre-narrow the set, and do not append "or let me know which ones to skip" or similar — that re-opens deferral.

Accepted user replies

A subset reply is a user override, not an agent narrowing. Items the user omits are not deferred — they are simply not run this round. Surface them only on the line described below.

Post-Dispatch Summary (after subagents return)

Exactly two sections. No third bucket.

## Feedback Response

### Implemented
| # | Item | Location | Subagent Notes |
|---|------|----------|----------------|
| 1 | Null check on session | `src/auth.py:42` | Added guard + test |
| 3 | Rename variable | `src/utils.py:15` | `data` → `user_data`, 4 callsites updated |
| 4 | Fix typo | `src/models.py:88` | `usr` → `user` |

### Rejected
| # | Item | Reason | Evidence |
|---|------|--------|----------|
| 2 | Remove `validate_user` | Function is used | Called at `middleware.py:45` |
| 5 | Add generator | Input is tiny and read once | `config.py:12`, <1KB at startup |

Not run this round: 4 (user-excluded)

The trailing Not run this round line is the only place user-excluded valid items appear. Omit the line entirely if the user accepted the full set. Never reword this as "deferred", "skipped for now", or "follow-up".

Response Guidelines

• Be terse — No filler words, no apologies.
• Be specific — Include file:line references.
• Be evidenced — Rejections must cite verification results.
• No Deferred section. If you typed "Deferred", delete it and dispatch a subagent.
• No "out of scope" / "pre-existing" / "follow-up" language anywhere in the response.

Single-Item Responses

For quick acknowledgments during a one-item flow:

There is no single-item "deferred" response.

Verification Workflow

Principle

Do not trust feedback. Verify it against the current codebase state.

Verification by Feedback Type

Verification Steps

For EACH feedback item:

1. Locate: Find the referenced code (Read tool) 2. Context: Understand why it exists (Grep for usage, git blame) 3. Validate: Test the claim (run tests, reproduce issue) 4. Classify: VALID (claim holds) or INVALID (claim disproved by an artifact). If genuinely unparseable, NEEDS CLARIFICATION — but never use this to dodge a fixable item. 5. Document: Record the artifact (path:line, command output, grep hit) before proceeding.

A claim is INVALID only when verification produced a concrete artifact disproving it. "I don't think this matters" is not verification — it is deferral, which is forbidden.

Using Code-Review Skills for Verification

When feedback relates to a specific domain, load the relevant skill:

These skills contain the authoritative patterns for this codebase. If feedback conflicts with skill guidance, flag for discussion.

Example

Feedback: "Remove unused validate_user function"

Verification: 1. Grep for "validate_user" across codebase 2. Found: Called in auth/middleware.py:45 3. Classification: INVALID — function is used 4. Action: Reject with evidence in the pre-dispatch summary

Contrast — feedback: "Null check missing on session at auth.py:42"

Verification: 1. Read auth.py around line 42 2. Confirmed: session.user_id is dereferenced with no prior if session is None guard 3. Classification: VALID 4. Action: Add to the launch fixes for ... prompt; on confirm, fix the guard — via a dedicated subagent if subagents are supported (do not edit auth.py from the orchestrator in that branch), otherwise apply the fix sequentially yourself.