sensei

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.

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.

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.

Evaluate what the tests actually prove and what they miss. Use when reviewing a PR's test coverage, when a developer says "I wrote tests", or when you want to challenge the developer to reason about test quality — not just test quantity.

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.

Analyze code for responsibility, boundary, abstraction, code-bloat, and duplicated-knowledge problems. Use when a function or module seems to be doing too many things, when the same business rule appears in multiple places, when the developer asks about SRP, DRY, KISS, code smells, or whether code is too complex, or when reviewing whether a split or abstraction is justified.

Review a code diff or file for correctness, security risks, AI slop, code smells, pattern mismatches, and missing verification — in teaching mode. Use when a developer asks for a code review, "look at this diff", "review my PR", or wants to know whether code is simple, maintainable, or too hacky.

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.

Sensei's automatic context dispatcher. Run this when no specific skill is requested. Inspect git state to detect uncommitted changes, open PRs, branch position, and recent merges — then announce what was found and route to the right skill without waiting for instructions.

Guide a developer through safe, incremental, behavior-preserving refactoring. Use when a developer says "I want to refactor this", "how do I clean this up safely", or "there's tech debt here". If the request changes behavior, route to gameplan or trace first. Do not write the refactored code; help the developer choose the next verified move.

Help a developer write a clear PR description that communicates intent, risks, verification, and reviewer focus. Use before a PR is opened or when the PR description is thin or missing. Reads the diff first, pre-fills what can be observed, then challenges the developer to own the WHY, risks, and verification.

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.