From sensei
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.
npx claudepluginhub onehorizonai/sensei --plugin senseiThis skill uses the workspace's default tool permissions.
Review code changes for smells, pattern mismatches, correctness risks, bloat, and missing verification — in teaching mode.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Guides code writing, review, and refactoring with Karpathy-inspired rules to avoid overcomplication, ensure simplicity, surgical changes, and verifiable success criteria.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Share bugs, ideas, or general feedback.
Review code changes for smells, pattern mismatches, correctness risks, bloat, and missing verification — in teaching mode.
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.
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.
After /sensei-help and before finalizing findings, decide whether a specialist check is warranted.
Consult only when:
Use one strongest match, or at most two if they cover clearly different risks. Do not consult a specialist just because the skill exists.
Useful matches:
$golang-pro, $go-concurrency-patterns, $golang-patterns$vercel-react-best-practices, $vercel-composition-patterns$python-anti-patterns, $python-pro, $python-design-patterns$supabase-postgres-best-practices$langgraph-code-review, $langgraph-architectureDo not consult a specialist for tiny changes, generic style issues, or changes you can already review confidently from local evidence. Use the specialist as a checklist, not a delegate. Fold a specialist finding into the normal Smell items only when it is grounded in the actual diff, file path, test gap, or local pattern. Name the specialist only if it changed the feedback.
Review in this priority order:
/sensei-align if needed.)/sensei-smell if needed.)Do not nitpick style unless it affects clarity or breaks team conventions.
For each issue found:
Smell: [Name of the smell or principle]
Plain English: [One sentence a non-technical builder can understand]
Where: [File path, line number or range]
Evidence: [Specific behavior, dependency, test gap, or code path that makes this real]
Why it matters: [Concrete consequence — not theoretical]
Possible direction: [One or two options, not a prescription]
Question for you: [One question the developer must reason through]
End every review with:
Security check:
[No obvious security-sensitive surface touched / Surface touched and evidence reviewed / Security risk to resolve]
What you did well:
[Specific things that show good judgment — never skip this section]
To practice next time:
[One or two targeted skills, linked to a maturity level]
If no substantive issues are found, say that clearly and still name any residual risk or verification gap.