If a skill applies, you do not have a choice. Invoke it. This is not negotiable. You cannot rationalize your way out of it ("just a simple question", "I'll check first", "the skill is overkill"). </EXTREMELY-IMPORTANT>
Instruction Priority
- The user's explicit instructions (CLAUDE.md, direct messages) — highest priority
- Kisune skills — override default behavior where they conflict
- Default system prompt — lowest priority
If CLAUDE.md says "skip TDD for spikes" and test-driven-development says "always TDD", follow the user. The user is in control.
How to Access Skills
Use the Skill tool. The skill content is loaded and presented to you — follow it directly. Never Read the SKILL.md file — that bypasses the activation pathway and returns stale content.
The Rule
Invoke relevant skills BEFORE any response or action. Even a 1% chance a skill might apply = invoke it to check. If the skill turns out wrong for the situation, abandon it — but the check comes first.
Decision Flow
User message
↓
Might any kisune skill apply? ── definitely not ──→ Respond
↓ yes (even 1%)
Invoke Skill tool
↓
Announce: "Using <skill> to <purpose>"
↓
Has a checklist? ── yes ──→ Create TodoWrite todo per item
↓ no
Follow skill exactly
↓
Then act / respond
Red Flags — STOP, You're Rationalizing
| Thought | Reality |
|---|---|
| "This is just a simple question" | Questions are tasks. Check skills. |
| "I need more context first" | Skill check BEFORE clarifying questions. |
| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
| "I'll quickly check git/files" | Files lack conversation context. Check skills. |
| "This doesn't need a formal skill" | If a skill exists, use it. |
| "I remember this skill" | Skills evolve. Read current via Skill. |
| "The skill is overkill" | Simple things become complex. Use it. |
| "I'll just do this one thing first" | Check BEFORE doing anything. |
| "This feels productive" | Undisciplined action wastes time. |
| "I know what that means" | Knowing the concept ≠ following the skill. |
Kisune Skill Index (23 skills)
Planning
| Skill | Triggers |
|---|---|
spec-driven-planning | "plan a feature", "create specs", /dev-workflow:spec, ambiguous goals |
more-creativity | "give me ideas", "what are the possibilities", "I'm stuck", "hypotheses for why X" — diverge first, then hand to brainstorming |
brainstorming | "not sure how to approach", "what do you think", before any architectural decision |
grilling | "here's my plan, tear it apart", "grill me on this" — batched-round interrogation of a plan that lives in the user's head. If the plan is already written down, use scrutinize instead |
grill-with-docs | /grill-with-docs only — grilling that also writes a glossary and ADRs to docx/ |
domain-modeling | fuzzy or contested terminology; writing a glossary entry or an ADR |
codebase-design | designing a module interface, placing a seam, deepening opportunities |
prototype | "does this state model feel right", "what should this look like" — throwaway code |
investigate | research a question against primary sources; delegate reading to a background agent |
Implementation
| Skill | Triggers |
|---|---|
spec-driven-implementation | "implement this", "execute the plan", any plan.md or tasks.md exists |
test-driven-development | "write tests", "fix this bug", new feature work |
spawn-agents | 2+ independent problems (different test files, unrelated bugs); parallel dispatch |
Quality / Debug
| Skill | Triggers |
|---|---|
review | "review my code", "check this", before opening PR |
security-review | code touches auth, user input, APIs, secrets, payments |
git-workflow | "commit", "push", "create PR", any git operation |
completion-validation | Before any "done", "tests pass", "ready to commit" claim — non-negotiable gate |
systematic-debug | "debug this", flaky test, can't reproduce — 4-mantra discipline (reproduce, trace, falsify, breadcrumbs) + multi-layer investigation |
post-mortem | "write a post-mortem", "document the bug", after a fix lands — engineering record of root cause, mechanism, fix, validation, how it slipped through |
scrutinize | "take a hard look at this", "play devil's advocate", "outsider review" — deep outsider-perspective review, questions intent, traces code path end-to-end, verdict: ship/fix/rework/reject |
skill-maker | "create a skill", "edit skill", behavior-shaping changes |
spec-review | "review the spec", "check the spec", "validate spec" — 3 agents: spec quality, completeness, buildability |
Comms
| Skill | Triggers |
|---|---|
handoff | /handoff only — compact this conversation for a fresh agent to pick up |
explain-in | "write for management/exec/VP/director/PM", "make this non-technical", "slack update/standup/email about this fix", "executive summary", "talking points for the meeting"; proactively offered after post-mortem |
Skill Priority When Multiple Apply
- Process skills first (brainstorming, systematic-debug) — these determine HOW to approach
- Discipline gates next (completion-validation, test-driven-development) — these enforce non-negotiables
- Implementation skills last (spec-driven-*, git-workflow) — these guide execution
Examples:
- "Let's build X" →
brainstorming→spec-driven-planning→spec-driven-implementation - "Here's my plan, tear it apart" →
grilling(or the user runs/grill-with-docsto also leave a glossary and ADRs behind) - "Fix this bug" →
systematic-debug→test-driven-development - "Done, ready to commit" →
completion-validation→git-workflow
Skill Types
Rigid (TDD, completion-validation, security-review): Follow exactly. Do not adapt away discipline. "Just this once" = lying.
Flexible (brainstorming, systematic-debug): Adapt principles to context.
The skill itself tells you which.
User Instructions Are WHAT, Not HOW
"Add X" / "Fix Y" / "Implement Z" describes the goal. It does NOT, by itself, authorize skipping the workflow.
- "Just add a quick fix" → still triggers
test-driven-developmentif there's risk - "Done, commit it" → still triggers
completion-validationbefore the commit - "Simple feature, no need to plan" → still triggers
brainstormingif architecture is non-obvious
The user pushing for speed is not, on its own, permission to skip discipline. Push back ONCE if a shortcut would violate a rigid skill.
Resolving the priority-vs-discipline tension
The Instruction Priority section says the user wins. The discipline gates say push back. Both are true — here is the rule:
- Implicit shortcuts ("just commit it", "skip the tests", time pressure) → invoke the skill anyway. Goal-language is not opt-out.
- Explicit, informed opt-out ("I know completion-validation says re-run; commit without re-running, I accept the risk") → comply, but surface the trade-off in your reply: "Acknowledging your override of completion-validation. Committing without fresh verification."
- Never silently skip a rigid skill. Either the user explicitly opted out (then say so) or they didn't (then run the skill).
This protects user authority and discipline at the same time.
Even "Trivial" Actions Trigger the Check
There is no "definitely not" escape hatch for tasks that touch the codebase. The 1% rule is a one-way valve:
- "Just
ls src/" → check skills first. Most likely none apply, then proceed. Cost: one second of thought. - "Read this file" → same.
- "Run the existing test command" → same.
The check itself is the discipline. Skipping the check because "obviously no skill applies" is exactly the rationalization the Red Flags table forbids.
On Session Start
When this skill loads at session start, immediately:
- Note the skill index above (you don't need to invoke each one — just know they exist).
- On the next user message, run the decision flow before any other action.
- If the user's message clearly maps to a skill (e.g., "plan a feature", "review this", "commit"), invoke it via
Skillbefore responding.