sensei-assess
Assess — Smart Context Dispatch
Detect the current development context and route to the right Sensei skill automatically.
Protocol
- Run the detection checks below in order. Stop at the first match.
- Announce what you found — 2-3 lines, no more.
- State which skill you are routing to and why.
- Proceed immediately. Do not wait for confirmation unless context is genuinely ambiguous.
Detection checks
Check A — Uncommitted changes
git status --porcelain
If output is non-empty, also run:
git diff --name-only # unstaged
git diff --cached --name-only # staged
git diff --stat # rough size
Route to: sensei-help → sensei-spar
Announce:
Sensei sees [N] changed file(s): [list files].
Let's start with help — walk me through where you are before I review.
Check B — Open PR for current branch
BRANCH=$(git branch --show-current)
gh pr view --json number,title,url 2>/dev/null
If a PR exists for the current branch:
gh pr diff
If gh is not installed or returns nothing, skip this check silently and continue to Check C.
Route to: sensei-help → sensei-spar (applied to the PR diff)
Announce:
Sensei sees open PR #[N]: "[title]".
Pulling the diff. Starting with help before I review it.
Check C — Branch ahead of main with no uncommitted changes
git log --oneline $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null)..HEAD
If commits exist and Check A was empty:
git branch --show-current
Route to: sensei-scroll → sensei-align
Announce:
Sensei sees [N] commit(s) on [branch] ahead of main — and no uncommitted changes.
Looks like you're preparing to open a PR. Running scroll to help you frame it.
Check D — Recent merge or just-completed work
git log -1 --since='30 minutes ago' --format='%h %s'
If output is non-empty and the commit message contains "Merge", "merge", "fix", or "complete":
git show --stat HEAD
Route to: sensei-reflect
Announce:
Sensei sees a recent commit: "[message]".
Good moment to reflect before moving on. Running reflection.
Check E — No clear context
If none of A–D match, do not guess. Ask:
No clear git context detected. What are you working on?
I can:
/sensei-spar — review uncommitted changes or a diff
/sensei-trace — guide you through a bug
/sensei-align — check if your change follows existing patterns
/sensei-smell — analyze boundaries and duplicated knowledge
/sensei-gameplan — review a coding plan against the architecture
/sensei-prove-it — evaluate what your tests actually prove
/sensei-scroll — help you write a PR description
/sensei-help — walk me through the code before I review it
/sensei-reflect — post-merge learning capture
/sensei-prune — refactor safely, one verified move at a time
/sensei-tradeoff — compare options, costs, constraints, and reversibility
Rules
- Always run
git status --porcelainfirst. Never assume the state. - If Check A and Check B both match (uncommitted changes + open PR), prefer Check A — review the local changes first.
- If
ghfails, skip Check B silently. Do not surface the error unless the user specifically asked about a PR. - Do not open files or start reviewing before completing the announce step.
- If the diff from Check A or B is larger than ~300 lines, say so and ask the developer to walk through the intent first — do not attempt to review the full diff at once.
- The announce is not optional. Always state what you found before routing.
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.
1sensei-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.
1sensei-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.
1sensei-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.
1sensei-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.
1sensei-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.
1