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.
1---2name: using-kisune3description: Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions4---5
6<SUBAGENT-STOP>
7If you were dispatched as a subagent with a specific scoped task, skip this skill — run the assignment.
8</SUBAGENT-STOP>
9
10<EXTREMELY-IMPORTANT>
11If you think there is even a 1% chance a kisune skill might apply to what you are doing, you MUST invoke it via the `Skill` tool.
12
13If 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").
14</EXTREMELY-IMPORTANT>
15
16## Instruction Priority
17
181. **The user's explicit instructions** (CLAUDE.md, direct messages) — highest priority
192. **Kisune skills** — override default behavior where they conflict
203. **Default system prompt** — lowest priority
21
22If CLAUDE.md says "skip TDD for spikes" and `test-driven-development` says "always TDD", follow the user. The user is in control.
23
24## How to Access Skills
25
26Use 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.
27
28## The Rule
29
30**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.
31
32## Decision Flow
33
34```
35User message
36 ↓
37Might any kisune skill apply? ── definitely not ──→ Respond
38 ↓ yes (even 1%)
39Invoke Skill tool
40 ↓
41Announce: "Using <skill> to <purpose>"
42 ↓
43Has a checklist? ── yes ──→ Create TodoWrite todo per item
44 ↓ no
45Follow skill exactly
46 ↓
47Then act / respond
48```
49
50## Red Flags — STOP, You're Rationalizing
51
52| Thought | Reality |
53|---------|---------|
54| "This is just a simple question" | Questions are tasks. Check skills. |
55| "I need more context first" | Skill check BEFORE clarifying questions. |
56| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
57| "I'll quickly check git/files" | Files lack conversation context. Check skills. |
58| "This doesn't need a formal skill" | If a skill exists, use it. |
59| "I remember this skill" | Skills evolve. Read current via `Skill`. |
60| "The skill is overkill" | Simple things become complex. Use it. |
61| "I'll just do this one thing first" | Check BEFORE doing anything. |
62| "This feels productive" | Undisciplined action wastes time. |
63| "I know what that means" | Knowing the concept ≠ following the skill. |
64
65## Kisune Skill Index (22 skills)
66
67**Planning**
68
69| Skill | Triggers |
70|---|---|
71| `spec-driven-planning` | "plan a feature", "create specs", `/dev-workflow:spec`, ambiguous goals |
72| `brainstorming` | "not sure how to approach", "what do you think", before any architectural decision |
73| `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 |
74| `grill-with-docs` | **`/grill-with-docs` only** — grilling that also writes a glossary and ADRs to `docx/` |
75| `domain-modeling` | fuzzy or contested terminology; writing a glossary entry or an ADR |
76| `codebase-design` | designing a module interface, placing a seam, deepening opportunities |
77| `prototype` | "does this state model feel right", "what should this look like" — throwaway code |
78| `investigate` | research a question against primary sources; delegate reading to a background agent |
79
80**Implementation**
81
82| Skill | Triggers |
83|---|---|
84| `spec-driven-implementation` | "implement this", "execute the plan", any `plan.md` or `tasks.md` exists |
85| `test-driven-development` | "write tests", "fix this bug", new feature work |
86| `spawn-agents` | 2+ independent problems (different test files, unrelated bugs); parallel dispatch |
87
88**Quality / Debug**
89
90| Skill | Triggers |
91|---|---|
92| `review` | "review my code", "check this", before opening PR |
93| `security-review` | code touches auth, user input, APIs, secrets, payments |
94| `git-workflow` | "commit", "push", "create PR", any git operation |
95| `completion-validation` | **Before any "done", "tests pass", "ready to commit" claim** — non-negotiable gate |
96| `systematic-debug` | "debug this", flaky test, can't reproduce — 4-mantra discipline (reproduce, trace, falsify, breadcrumbs) + multi-layer investigation |
97| `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 |
98| `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 |
99| `skill-maker` | "create a skill", "edit skill", behavior-shaping changes |
100| `spec-review` | "review the spec", "check the spec", "validate spec" — 3 agents: spec quality, completeness, buildability |
101
102**Comms**
103
104| Skill | Triggers |
105|---|---|
106| `handoff` | **`/handoff` only** — compact this conversation for a fresh agent to pick up |
107| `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` |
108
109## Skill Priority When Multiple Apply
110
1111. **Process skills first** (brainstorming, systematic-debug) — these determine HOW to approach
1122. **Discipline gates next** (completion-validation, test-driven-development) — these enforce non-negotiables
1133. **Implementation skills last** (spec-driven-*, git-workflow) — these guide execution
114
115Examples:
116- "Let's build X" → `brainstorming` → `spec-driven-planning` → `spec-driven-implementation`
117- "Here's my plan, tear it apart" → `grilling` (or the user runs `/grill-with-docs` to also leave a glossary and ADRs behind)
118- "Fix this bug" → `systematic-debug` → `test-driven-development`
119- "Done, ready to commit" → `completion-validation` → `git-workflow`
120
121## Skill Types
122
123**Rigid** (TDD, completion-validation, security-review): Follow exactly. Do not adapt away discipline. "Just this once" = lying.
124
125**Flexible** (brainstorming, systematic-debug): Adapt principles to context.
126
127The skill itself tells you which.
128
129## User Instructions Are WHAT, Not HOW
130
131"Add X" / "Fix Y" / "Implement Z" describes the goal. It does NOT, by itself, authorize skipping the workflow.
132- "Just add a quick fix" → still triggers `test-driven-development` if there's risk
133- "Done, commit it" → still triggers `completion-validation` before the commit
134- "Simple feature, no need to plan" → still triggers `brainstorming` if architecture is non-obvious
135
136The user pushing for speed is not, on its own, permission to skip discipline. Push back ONCE if a shortcut would violate a rigid skill.
137
138### Resolving the priority-vs-discipline tension
139
140The Instruction Priority section says the user wins. The discipline gates say push back. Both are true — here is the rule:
141
1421. **Implicit shortcuts** ("just commit it", "skip the tests", time pressure) → invoke the skill anyway. Goal-language is not opt-out.
1432. **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."
1443. **Never silently skip a rigid skill.** Either the user explicitly opted out (then say so) or they didn't (then run the skill).
145
146This protects user authority and discipline at the same time.
147
148## Even "Trivial" Actions Trigger the Check
149
150There is no "definitely not" escape hatch for tasks that touch the codebase. The 1% rule is a one-way valve:
151- "Just `ls src/`" → check skills first. Most likely none apply, then proceed. Cost: one second of thought.
152- "Read this file" → same.
153- "Run the existing test command" → same.
154
155The check itself is the discipline. Skipping the check because "obviously no skill applies" is exactly the rationalization the Red Flags table forbids.
156
157## On Session Start
158
159When this skill loads at session start, immediately:
1601. Note the skill index above (you don't need to invoke each one — just know they exist).
1612. On the **next user message**, run the decision flow before any other action.
1623. If the user's message clearly maps to a skill (e.g., "plan a feature", "review this", "commit"), invoke it via `Skill` before responding.
xbklairith