---
name: loom-review-response
description: "Use when incoming human, audit, PR, worker, or external feedback is multi-item, unclear, disputed, scope-changing, or technically questionable and needs verification, pushback, implementation, or disposition."
---

# loom-review-response

Review response is a feedback-handling playbook.

It turns incoming comments into checked technical work instead of blind acceptance,
performative agreement, or untracked follow-up.

## Core Dependency

Use `loom-core` first. This playbook composes `loom-tickets`, `loom-audit`,
`loom-evidence`, `loom-specs`, `loom-research`, `loom-constitution`, and
`loom-retrospective`.

Incoming feedback is input to judgment. It is not automatically a durable record
fact.

## Use This Playbook When

Use this playbook when:

- a human gives multi-item feedback
- an audit finding needs disposition
- PR comments or external review suggestions arrive
- a worker reviewer challenges implementation or evidence
- feedback seems plausible but may not fit the codebase
- unclear feedback could lead to wrong implementation if guessed

Skip it for trivial local comments that can be fixed immediately without changing
scope, behavior, evidence, or ticket state.

## Route

Use this route:

```text
collect -> clarify -> verify -> classify -> act -> prove -> disposition
```

## Collect

Gather the feedback as concrete items.

For each item, preserve:

- source of feedback
- linked file, line, record, evidence, audit finding, or PR comment
- requested change or concern
- affected ticket `ACC-*`, spec `REQ-*` or `SCN-*`, if any
- whether the item blocks closure

Use `loom-audit` when feedback or verdict should remain durable.

## Clarify

Do not implement feedback you do not understand.

Before acting, determine:

- what change is being requested
- whether multiple items are related
- whether the feedback asks for behavior, evidence, docs, cleanup, or policy change
- whether there is an explicit acceptance or spec impact
- whether operator approval is needed

If any material item is unclear, ask a targeted clarification before starting work.

Do not partially implement clear items if unclear related items could change the
right approach.

## Verify

Check feedback against source reality.

Useful checks:

- inspect the cited code or record
- search for actual usage before adding or removing behavior
- run a focused check when the claim is testable
- compare against spec, ticket scope, and existing decisions
- check compatibility, platform, version, and migration constraints
- inspect evidence limitations when feedback challenges proof

When source facts are uncertain, route to `loom-research` before implementation.

## Classify

Classify each item:

- accept and fix now
- accept but split to follow-up ticket
- request clarification
- reject with evidence or source reality
- accept as residual risk in the ticket
- route to spec, research, constitution, evidence, or audit
- out of scope for the current ticket

Do not let review comments silently expand the ticket.

## Act

Implement accepted feedback one coherent item or cluster at a time.

Prioritize:

- blocking correctness, security, data, or acceptance gaps
- simple uncontroversial fixes
- evidence gaps
- more complex refactors or design changes

Run checks after each material cluster when failures would be easier to localize.

When feedback is wrong, push back with technical evidence and route the decision to
the ticket or audit record when durable.

## Prove

Before claiming feedback is handled:

- run fresh verification for changed behavior or records
- update evidence when closure or audit depends on it
- update affected ticket state, acceptance notes, and journal
- update audit finding disposition when applicable
- note what was not verified

Do not cite a reviewer's agreement as proof of implementation correctness.

## Disposition

Record final disposition where future agents will look:

- ticket for scoped work state, accepted risk, follow-up, and closure
- audit for durable findings and verdict changes
- specs for behavior contract changes
- evidence for observed proof or challenge
- research for source-backed uncertainty or rejected paths
- constitution for policy or precedent
- knowledge after retrospective for reusable feedback-handling lessons

## Done Means

The review response pass is done when:

- feedback items are understood and classified
- accepted items are implemented or routed
- rejected items have technical rationale
- fresh verification supports handled claims
- ticket and audit disposition match the actual state