sensei-align
Pattern Check
Compare a change against the existing codebase patterns, conventions, and architecture decisions.
Philosophy
Many maintainability problems are not technically wrong. They are locally inconsistent.
A new service, abstraction, or module that solves the problem correctly but diverges from the team's approach creates two costs:
- Every future developer has to learn two patterns.
- The codebase loses its internal coherence — the quality of being self-similar enough to be reasoned about as a whole.
Pattern alignment is not about conformity. It is about keeping the codebase legible.
Less is more here too. A new pattern has to earn its place. If the existing code already has a boring solution, prefer that unless the developer can explain why it no longer fits.
Questions to answer
Have we done something similar before?
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-spar
Review a code diff or file for maintainability issues, pattern mismatches, code smells, bloat, AI slop, and risks in teaching mode. Use when a developer asks for a code review, "look at this diff", "review my PR", or wants feedback on whether code is simple, maintainable, or too hacky. Explain the principle behind every issue. End with a question that forces the developer to reason.
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-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