responding-to-feedback

name	responding-to-feedback
description	Use when replying to feedback on your work (review comments, manuscript revisions, design critique, criticism)
kind	workflow
audience	knowledge-worker
ai-tools	any
complexity	guided
time	10-30 min
version	1.0.0
source	bundled

Responding to Feedback

What this does

Turns a pile of feedback (comments, edits, critique) into a structured response that addresses each piece explicitly: accept, reject, negotiate, or defer — with reasons.

When to use

• Code review with many comments
• Manuscript revisions from an editor or reviewer
• Design critique session output
• Performance review feedback you need to respond to
• Customer feedback on a delivered product

What you bring (Inputs)

• The piece of work
• The feedback (as a list, or a thread to parse first)
• Your authority (can you accept/reject unilaterally, or do you need to negotiate?)

What you get (Output)

A response that addresses every atom of feedback with a classification and a decision, plus the implementation plan for accepts.

How it works (Steps)

This is a workflow.

Stages

Stage 1: Parse into atoms

Break the feedback into individual atoms — one issue per atom. A comment that says "this is unclear and the example is wrong" is two atoms.

Stage 2: Classify each atom

For each atom, label one of:

• blocker: must address to ship
• suggestion: could improve the work; not required
• question: the reviewer wants info, not a change
• nit: minor stylistic preference
• out-of-scope: belongs in a different conversation

Stage 3: Decide each atom

For each, decide:

• accept: name what you'll change
• reject: name your reason in one sentence (cite the work or the goal, not feelings)
• negotiate: propose a middle ground
• defer: name when you'll address it (next version / next milestone / never)

Stage 4: Draft the response

For each atom, write one short paragraph: classification → decision → reasoning. Group by classification: blockers first.

Stage 5: Tone check

Read the whole response back. Tone target: grateful (without sycophancy), direct, focused on the work not the person.

Stage 6: Update the work

For accepts, do the actual changes. For negotiates that get agreement, do those too. Don't ship the response without doing the work.

Checkpoints

• After Stage 1: every distinct issue is its own atom
• After Stage 2: every atom has a classification
• After Stage 3: every atom has a decision
• After Stage 4: response addresses every atom (no atoms silently dropped)
• After Stage 5: tone is grateful + direct
• After Stage 6: accepted changes are reflected in the actual work

Loop-back conditions

Return to Stage 3 when a negotiation produces a counter that changes the original decision.

Quality bar

• Every atom is addressed (none dropped silently)
• Reject reasons cite the work or the goal, not "I disagree"
• Negotiations propose something concrete, not "let's discuss"
• Tone is grateful + direct (not defensive, not sycophantic)

Variations

• Code review reply: file/line refs per atom; "fixed in commit X" for accepts
• Manuscript revisions: include a separate cover letter summarizing changes
• Design critique: include an updated mock that shows accepts visually
• Performance review reply: address each piece of feedback, but tone shifts to "what I'm doing about it"

Example

Input: Code review with 8 comments on a new feature.

Output (excerpt):

Blockers (2):

• Comment on auth.ts:42 (concurrency bug): Accept. Fixed in commit abc123 with a mutex.
• Comment on api.ts:88 (missing test): Accept. Added test in commit def456.

Suggestions (3):

• Comment on naming getUser → fetchUser: Reject. The codebase uses get* for synchronous-feeling reads (see getOrders); switching one breaks consistency. Keeping as is.
• ...

Nits (2): All accepted; bundled in commit ghi789.

Out-of-scope (1): Comment about refactoring the whole module — agreed it's needed; filed as separate ticket #1234.