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.