54 lines
1.6 KiB
Markdown
54 lines
1.6 KiB
Markdown
---
|
|
name: receiving-code-review
|
|
description: Evaluate review feedback technically before acting; fix correct items and push back on incorrect ones with codebase evidence
|
|
permalink: opencode-config/skills/receiving-code-review/skill
|
|
---
|
|
|
|
# Receiving Code Review Feedback
|
|
|
|
## Core Workflow
|
|
|
|
When feedback arrives, follow this order:
|
|
|
|
1. **Read fully** before reacting.
|
|
2. **Understand the actual requirement** (restate it or ask a clarifying question).
|
|
3. **Verify against codebase reality** (current behavior, constraints, tests, compatibility).
|
|
4. **Decide whether feedback is correct for this codebase**.
|
|
5. **Then act**: implement the fix, or push back with technical reasoning.
|
|
|
|
## Guardrails
|
|
|
|
- Do not use performative praise or agreement.
|
|
- Do not promise fixes before verification.
|
|
- If any feedback is unclear, clarify first instead of partially implementing items you do understand.
|
|
|
|
## Processing Multi-Item Feedback
|
|
|
|
Apply items in this order:
|
|
|
|
1. Clarifications first.
|
|
2. Blocking/security issues.
|
|
3. Simpler items.
|
|
4. Complex items.
|
|
|
|
Test each change as you go.
|
|
|
|
## When to Push Back
|
|
|
|
Push back when a suggestion is incorrect for this codebase, breaks existing behavior, or ignores known constraints.
|
|
|
|
Push back style:
|
|
- Keep it technical and specific.
|
|
- Reference concrete code/tests/constraints.
|
|
- Propose a safer alternative when possible.
|
|
|
|
## When Feedback Is Correct
|
|
|
|
Implement the fix and report the concrete change.
|
|
|
|
Keep acknowledgments factual and concise; let verified code changes demonstrate agreement.
|
|
|
|
## Bottom Line
|
|
|
|
Technical correctness comes first: verify, decide, then fix or push back.
|