Agent-Skills.md

Agent Skills: Receive Feedback

Process external code review feedback with technical rigor. Use when receiving feedback from another LLM, human reviewer, or CI tool. Verifies claims before implementing, tracks disposition.

UncategorizedID: existential-birds/beagle/receive-feedback

Repository

existential-birds/beagle
existential-birdsLicense: Apache-2.0
202

Install this agent skill to your local

pnpm dlx add-skill https://github.com/existential-birds/beagle/tree/HEAD/plugins/beagle-core/skills/receive-feedback

Skill Files

Browse the full folder contents for receive-feedback.

Download Skill

Loading file tree…

plugins/beagle-core/skills/receive-feedback/SKILL.md

Skill Metadata

Name
receive-feedback
Description
Process external code review feedback with technical rigor. Use when receiving feedback from another LLM, human reviewer, or CI tool. Verifies claims before implementing, tracks disposition.

Receive Feedback

Overview

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

The orchestrator verifies and dispatches. It never edits files itself. Every valid item is fixed by a dedicated subagent spawned in parallel.

Quick Reference

┌─────────────┐     ┌──────────────┐     ┌──────────────────────┐
│   VERIFY    │ ──▶ │   CONFIRM    │ ──▶ │   DISPATCH FIXES     │
│ (tool-based)│     │ ("launch     │     │ (one subagent per    │
│             │     │  fixes for   │     │  valid item, run in  │
│             │     │  1,2,3?")    │     │  parallel)           │
└─────────────┘     └──────────────┘     └──────────────────────┘

Core Principle

Verify, confirm once, then dispatch subagents. The orchestrator does not fix.

If a bug is valid, a subagent fixes it. Full stop. No deferral, no excuses.

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. Spawn one subagent per chosen item, all in a single message so they run in parallel. The orchestrator MUST NOT call Edit / Write / NotebookEdit for any fix.
  7. Collect subagent 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.
  • Edit code directly. Every fix is performed by a spawned subagent.
  • Bundle multiple fixes into one subagent. One valid item = one subagent.

A valid bug raised by a code or security reviewer must be fixed by a subagent. 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, Grep, tests, 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 — Parallel subagent dispatch

  1. In a single tool-use block, spawn one Agent per item in the user-chosen set. Each subagent gets: the original feedback text, the verification artifact, the file/line target, and the Fix-Quality Contract.
  2. The orchestrator does not call Edit, Write, or NotebookEdit during this gate.

Pass when: Every item in the user-chosen set has a corresponding subagent invocation in the same message. Fail (stop): Fixing inline, serializing the subagents, 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

Use this skill from the /receive-feedback command or by invoking it directly with a feedback file path.

  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. Dispatch one subagent per valid item in a single message
  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.

Subagent Dispatch Template

When spawning a fix subagent, the prompt 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, copied verbatim into every subagent prompt.

Fix-Quality Contract (paste into every subagent prompt)

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.

Use subagent_type: "general-purpose" unless a domain-specific agent is clearly better.

Example

/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 spawns three subagents in parallel to fix items 1, 3, and 4.

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