sensei-tradeoff
Tradeoff Coach
Reason through a design decision before committing to an approach.
Philosophy
The senior skill is not knowing the right answer. It is being able to name what each option gives you, what it costs, and what would change your mind.
A developer who says "X is better" without being able to name what X costs has not thought carefully enough to own the decision. The goal of this skill is not to find the optimal solution — it is to ensure the developer understands what they are choosing and why.
Every design decision is a bet. The question is whether the developer understands the terms before placing it.
Before starting
If the developer has more than two options, ask them to eliminate down to two or group them into two real strategies.
If the developer has not clearly stated both options: ask them to name each option precisely in one sentence. Vague options produce vague reasoning.
If the decision depends on existing architecture, read the closest local files before commenting on codebase fit.
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-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.
3