sensei-spar
Review Diff
Review code changes for smells, pattern mismatches, correctness risks, bloat, and missing verification — in teaching mode.
Philosophy
A linter catches violations. A mentor explains why they matter.
The goal of this review is not a list of problems. It is a set of learning moments. Each issue should teach a principle the developer can apply to the next PR without guidance.
Before starting
Run /sensei-help first unless all five answers are already available in this conversation.
Use those answers to focus the review. Do not run a second intake unless critical context is still missing.
Specialist consultation
After /sensei-help and before finalizing findings, decide whether a specialist check is warranted.
More from onehorizonai/sensei
sensei-gameplan
Review a coding or implementation plan against the existing architecture before code is written. Use when a developer shares a plan, asks "does this plan make sense?", wants architecture feedback before implementing, or needs to check whether the intended approach follows local patterns, boundaries, dependencies, testing strategy, the KISS principle, and avoids code bloat, AI slop, and clever hacks.
3sensei-help
Start here when you don't know where to start. Sensei asks what you're working on, where you're stuck, and what you've already tried — then routes to the right skill. Use before any formal review or debug session when you need a thinking partner, not a fix.
3sensei-align
Compare a code change against the existing codebase to check pattern alignment. Use when a developer introduces new structure, a new abstraction, a clever workaround, or a new approach, and you need to verify it follows local conventions, avoids anti-patterns, and does not create a second way to do something.
3sensei-reflect
Run a post-merge or post-session reflection to capture what was learned and identify what to practice next. Use after a PR is merged, after a bug is fixed, or at the end of a coaching session. Keep it short enough to review in two minutes.
3sensei-trace
Guide a developer through debugging without jumping to a fix. Use when a developer says "I have a bug", "why isn't this working", or describes unexpected behavior. Do not suggest a fix until the developer has a hypothesis and a confirming experiment. The goal is to teach the debugging process, not to find the bug.
3sensei-tradeoff
Help a developer reason through a design decision by naming options, costs, constraints, reversibility, and what would change the decision. Use when a developer says "should I use X or Y", "help me decide", "what's the tradeoff", or "is this the right architecture". If the decision claims architecture fit, read the closest local precedent before judging. Do not decide for the developer.
3