{"id":53868,"plugin_id":"plugins_6ac84bac80b081918c305a1574fbd186","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-24T13:55:15.189Z","digest":"c61f459b747f65690db49411f8c1c0cd9b2b0415c3a58b8f48b7e42473b93fcd","against":null,"payload":{"description":"Conducts and responds to code review — reviewing a change for correctness, design, and risk, and evaluating review feedback received on your own work. Use this before merging, when asked to review a diff or pull request, when review feedback has arrived and needs acting on, or when feedback seems wrong and needs a reasoned response rather than compliance.","included_files":[],"name":"code-review","skill_md_contents":"---\nname: code-review\ndescription: Conducts and responds to code review — reviewing a change for correctness, design, and risk, and evaluating review feedback received on your own work. Use this before merging, when asked to review a diff or pull request, when review feedback has arrived and needs acting on, or when feedback seems wrong and needs a reasoned response rather than compliance.\n---\n\n# Code review\n\nTwo directions, one skill: reviewing, and being reviewed.\n\n## Reviewing\n\nRead the diff against what the change is *for*, not against your preferences. Order matters — spend\nattention where damage is expensive:\n\n1. **Correctness** — does it do what it claims, including at the boundaries and on the error path?\n2. **Blast radius** — what else consumes this? Signature and schema changes are the ones that break\n   things far away.\n3. **Security and data** — untrusted input, authorization, anything logged or persisted.\n4. **Tests** — do they pin the new behavior, or do they pass regardless?\n5. **Design** — will this shape hold under the next change?\n6. **Style** — last, and only where a linter cannot.\n\nSay which category each comment is, and whether it blocks. A review that mixes a data-loss bug with\na naming preference in one undifferentiated list wastes the author's judgment.\n\n## Receiving\n\nFeedback is a report of a reader's experience, and that part is always valid — if the reviewer\nmisread it, the code is misleading. The proposed remedy is a separate thing and may be wrong.\n\n- **Verify before implementing.** A suggestion that would break behavior gets a reply, not a commit.\n- **Disagreeing is fine; ignoring is not.** Answer every comment: changed, or why not.\n- **Do not batch-accept.** Applying every suggestion without judgment is how good code becomes\n  incoherent.\n- Where a reviewer is factually wrong, show the evidence — the test, the spec, the failing case —\n  rather than asserting.\n\n## Never\n\n- Approve your own work, or a change you authored under another name.\n- Leave a blocking comment without saying what would unblock it.\n- Rewrite the author's approach in a review comment. Propose it, and let them decide.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}