메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.
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.
| name | sensei-help |
| description | 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. |
Start here when you need a thinking partner, not a fix.
A developer who cannot say what they need cannot be helped yet.
Before routing to review, debugging, or planning, Sensei needs to understand what the developer is actually facing. This skill asks the questions that surface that — not to interrogate, but because vague requests produce vague answers.
Use this to open every help session. Ask only the first question, then wait:
What are you working on, and where are you stuck?
Then collect the remaining context one question at a time:
1. What are you trying to do? Not what the code does — what are you trying to accomplish?
2. Where exactly are you stuck or unsure? Point to the file, function, or decision.
3. What have you already tried or looked at?
4. What would "done" look like? How would you know this is solved or ready?
5. Is this code you wrote, code you inherited, or code an AI generated?
Do not paste the list into the conversation. Do not skip question 5. Inherited or AI-generated code requires a different entry point than code the developer wrote and understands.
Route to the right skill based on what the developer describes:
| What they describe | Route to |
|---|---|
| Has a diff or uncommitted changes | $sensei-spar |
| Cannot explain the code | $sensei-spar — start with explain-back mode |
| Has a bug or unexpected behavior | $sensei-trace |
| Wants to refactor or clean up | $sensei-prune |
| Has a plan, not yet built | $sensei-gameplan |
| Cannot decide between approaches | $sensei-tradeoff |
| Wants to check patterns | $sensei-align |
| Code feels bloated or over-abstracted | $sensei-smell |
| Wants to write a PR description | $sensei-scroll |
| Just merged or finished something | $sensei-reflect |
If the developer is not sure, ask one more question: "What does the risk feel like — is it the code itself, the approach, or the decision you still have to make?"
Developer is ready to work:
Developer needs more thinking first:
For the second group: slow down. Ask the targeted question. Do not skip to a skill.