name: speckit-superb-respond description: Code review response protocol. Bridges an installed obra/superpowers receiving-code-review skill. Enforces technical verification before implementing review feedback — no performative agreement, no blind fixes. Pairs with speckit.superb.critique as the implementer counterpart. compatibility: Requires spec-kit project structure with .specify/ directory metadata: author: github-spec-kit source: superb:commands/respond.md

Respond — Receiving Code Review Feedback

Type: Superpowers-adapted command Skill origin: obra/superpowers receiving-code-review Invocation: Standalone command. Call after receiving output from speckit.superb.critique or any external code review.

Step 1 — Resolve Installed Skill

Look for receiving-code-review/SKILL.md in this exact order:

1. ./.agents/skills/receiving-code-review/SKILL.md
2. ~/.agents/skills/receiving-code-review/SKILL.md

If the workspace and global copies both exist, use the workspace copy.

If no readable file is found, STOP:

ERROR: Optional superpowers skill `receiving-code-review` not found.
Run /speckit.superb.check for diagnostics.

Report the source you resolved before continuing:

Using installed skill: receiving-code-review
Source: [workspace|global]
Path: [resolved path]

Step 2 — Bind Spec-Kit Context

1. Read the review feedback (from critique output, PR comments, or user-provided review):

   $ARGUMENTS
   

2. Read spec.md — the spec is the authority, not the reviewer's opinion.
3. Read tasks.md — understand what was intended to be built.
4. If any review item is unclear, STOP and ask for clarification on ALL unclear items before implementing any fix. Do not partially implement.

Step 3 — Triage Review Items

For each review item, classify and verify:

## Review Response

| #   | Item      | Severity                 | Verdict               | Reasoning          |
| --- | --------- | ------------------------ | --------------------- | ------------------ |
| 1   | [summary] | Critical/Important/Minor | Accept/Reject/Clarify | [technical reason] |
| 2   | [summary] | ...                      | ...                   | ...                |

Verdict rules:

• Accept — item is technically correct for this codebase and aligns with spec.
• Reject — item is wrong, breaks existing behavior, violates YAGNI, or conflicts with spec. Push back with technical reasoning.
• Clarify — item is ambiguous. Ask before implementing.

Step 4 — Implement Accepted Items

Follow this strict order:

1. Critical issues first (spec violations, security, correctness)
2. Important issues (missing behavior, architectural problems)
3. Minor issues (naming, style, minor improvements)

For each accepted item:

• Make ONE change
• Run the full test suite
• Verify no regressions
• Commit with a descriptive message referencing the review item

Step 5 — Report

After all accepted items are implemented:

## Review Response Complete

**Accepted and fixed:** [N] items
**Rejected with reasoning:** [M] items
**Pending clarification:** [K] items

### Rejections

- Item [#]: [one-line technical reason]

### Test Evidence

[Full test suite output — N tests, N passing, 0 failing]

Push-Back Protocol

When rejecting a review item, provide:

1. The specific technical reason (not "I disagree")
2. Evidence — code, tests, or spec references that support the current implementation
3. Spec alignment — does the spec require what the reviewer suggests?

If the reviewer's suggestion conflicts with spec.md, the spec wins unless the user explicitly overrides.