Requesting code review
Use when completing tasks, implementing major features, or before merging to verify work meets requirementsFrom its SKILL.md
npx -y skills add brandonfla/bearpaws --skill requesting-code-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.3 KB, as published. Nobody here has run it
<skill>
<purpose>
Dispatch bp:code-reviewer subagent to catch issues before they cascade. The reviewer gets crafted context for evaluation — never your session's history.
</purpose>
<triggers>
<rule>Use after each task in subagent-driven development.</rule>
<rule>Use after completing a major feature or before merge to main.</rule>
<rule>Use when stuck (fresh perspective) or after fixing complex bugs.</rule>
</triggers>
<process>
<step>**Get git SHAs** — `BASE_SHA=$(git rev-parse HEAD~1)` (or `origin/main`), `HEAD_SHA=$(git rev-parse HEAD)`.</step>
<step>**Dispatch bp:code-reviewer subagent** — Use Task tool with code-reviewer type. Fill placeholders: `{WHAT_WAS_IMPLEMENTED}`, `{PLAN_OR_REQUIREMENTS}`, `{BASE_SHA}`, `{HEAD_SHA}`, `{DESCRIPTION}`.</step>
<step>**Validate adversarial structure** — Review MUST contain all four named gates: (1) **Failure Mode Enumeration** with ≥3 concrete scenarios, (2) **What would have to be true for this to be wrong** steel-manning, (3) **What I didn't check and why** mapping blind spots, (4) **Break Attempts** documented as "Tried: X — Y". Vague is rejection-worthy: a "Tried" line without a `—` separator and outcome, or a failure mode without a specific code reference. If any gate is missing or vague, send back: "Review incomplete — missing [gate]. Redo."</step>
<step>**Act on feedback** — Fix Critical immediately. Fix Important before proceeding. Note Minor for later. Push back if reviewer is wrong (with technical reasoning).</step>
</process>
<rules>
<rule>Never skip review because "it's simple".</rule>
<rule>Never proceed with unfixed Critical or Important issues.</rule>
<rule>Never accept a review missing adversarial gates — a review without break attempts is not a review.</rule>
<rule>If reviewer is wrong: push back with code/tests that prove it.</rule>
</rules>
Integration
- Subagent-Driven Development — review after EACH task
- Executing Plans — review after each batch (3 tasks)
- Ad-hoc — review before merge or when stuck