Imported from xbklairith/kisune (dev-workflow/skills/using-kisune/SKILL.md). Install upstream with npx skills add xbklairith/kisune --skill using-kisune. Copyright stays with the author.

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").

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 (22 skills)

Planning

Skill	Triggers
`spec-driven-planning`	"plan a feature", "create specs", `/dev-workflow:spec`, ambiguous goals
`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-docs to 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-development if there's risk
"Done, commit it" → still triggers completion-validation before the commit
"Simple feature, no need to plan" → still triggers brainstorming if 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 Skill before responding.

using-kisune

About