Use when rewriting, sharpening, or producing a prompt for Claude or another current frontier model. Sets standing rules for getting better LLM output through better prompts. Loaded by /kanso-task; not directly invoked by the user.
Scanned 5/27/2026
Install via CLI
openskills install blakecyze/kanso---
name: kanso-prompting
description: Use when rewriting, sharpening, or producing a prompt for Claude or another current frontier model. Sets standing rules for getting better LLM output through better prompts. Loaded by /kanso-task; not directly invoked by the user.
user-invocable: false
---
# kanso-prompting
Standing rules for prompting current frontier models — primarily Claude 4.x (Opus 4.7, Sonnet 4.6, Haiku 4.5). These principles apply to any prompt this session produces, including prompts being constructed on the user's behalf.
The single governing principle: **a prompt earns its length the same way code does**. Every clause must do work. Specificity beats verbosity; clarity beats cleverness; structure beats hope.
## The prompting taxonomy
### 1. Lead with the desired outcome
State what the model should produce, in what shape, for what audience, before any context. Don't bury the ask under preamble.
Bad: `I've been working on this codebase for a while and I noticed that the auth module has some issues, particularly around session handling, and I was wondering if maybe you could take a look...`
Good: `Audit src/auth/session.ts for race conditions in session creation. Report findings as a numbered list with file:line references.`
### 2. Explain the *why*, not just the *what*
Reasons let the model generalise correctly to cases you didn't spell out. Without the why, it follows the letter and misses the spirit.
Bad: `Never use ellipses.`
Good: `Never use ellipses — the output will be read aloud by a TTS engine that can't pronounce them.`
### 3. State what to do, not what to avoid
Negative-only instructions trigger the behaviour they warn against and leave a vacuum where positive guidance should be. Replace every "don't" with a "do".
Bad: `Don't use markdown.`
Good: `Write in flowing prose paragraphs.`
### 4. Front-load the full task in turn one
For coding and agentic work, ambiguous first turns produce worse results than a single dense first turn. Specify task, scope, constraints, and definition of done upfront. Don't rely on follow-up turns to recover.
### 5. Show, don't tell — examples beat description
Two or three concrete examples steer the model more than a paragraph of instruction. Use diverse examples that cover edge cases, not three rewrites of the same shape.
### 6. Structure complex prompts with tags
When a prompt mixes instructions, context, examples, and input, wrap each in tags: `<instructions>`, `<context>`, `<examples>`, `<input>`. Cuts the misinterpretation rate on anything non-trivial.
### 7. Long context: documents first, question last
Put large reference material at the top of the prompt; put the actual question at the bottom. Wrap each document in `<document>` with `<source>` and `<document_content>` subtags. Measured uplift on long-context retrieval.
For analysis over long documents, ask the model to extract grounded quotes before reasoning: `First extract relevant passages into <quotes>, then answer using only what's there.`
### 8. Match the prompt's voice to the desired output
Markdown-dense prompts produce markdown-dense replies. Plain-prose prompts produce plain-prose replies. Terse prompts produce terse replies. The prompt is a tone sample whether you intend it or not.
### 9. Ask for action when you want action
`Suggest changes` produces suggestions. `Make these edits` produces edits. `Review this and recommend` produces a memo. The verb sets the artefact.
### 10. Build in self-checks for high-stakes output
`Before finishing, verify each step against the constraints in <criteria>` catches a meaningful fraction of errors in code and reasoning tasks. Cheaper than a second prompt.
### 11. Chain rather than ask for the moon in one shot
Draft → critique against criteria → refine. Three small prompts beat one large one whenever the steps are inspectable. Use single-shot only when the task is genuinely indivisible.
### 12. Use the system prompt to set role and stance
Even one sentence (`You are a senior reviewer who flags only blocking issues`) sharpens tone, scope, and what gets surfaced. Don't waste it on filler.
## Claude 4.x — what changed
The current generation responds to prompts differently from Claude 3.x. Stale 3-era prompt scaffolding now degrades output.
- **Instruction following is more literal.** The model no longer silently generalises an instruction from one item to all similar items. If you want it applied broadly, say so explicitly.
- **Drop the aggressive language.** `CRITICAL`, `YOU MUST`, ALL CAPS, and triple exclamation marks now over-trigger and cause worse output, not better. Use normal declarative voice.
- **Drop the anti-laziness scaffolds.** Force-thorough, force-tools, "do not stop until" preambles were necessary on older models and are now noise.
- **Verbosity self-calibrates.** Short on simple tasks, long on open-ended ones. If you need a specific length, prompt with a positive example rather than a word count.
- **General reasoning instructions beat prescribed step plans.** `Think thoroughly before answering` outperforms a hand-written checklist in most cases. The model's reasoning is often better than what you'd prescribe.
- **Default voice is more direct and less validation-forward.** Fewer emoji, less "great question". If you want warmth, ask for it.
- **Prefill is unavailable from 4.6+.** Use structured outputs or system-prompt guidance instead.
- **If reasoning is shallow, raise effort before adding prompt scaffolding.** The effort parameter does more than re-prompting can.
## Anti-patterns
- Vague one-liners (`make it better`, `clean this up`) with no success criteria.
- Stacking contradictions (`be thorough but concise`, `be creative but conservative`) and leaving the model to pick.
- Negative-only instructions with no positive replacement.
- ALL-CAPS emphasis or `CRITICAL:` flags — degrades on current models.
- Long document pasted *after* the question instead of before it.
- Stale Claude 3-era anti-laziness boilerplate copied forward.
- Asking `can you suggest` when you want edits made.
- Treating clarifying turns as a substitute for a precise first turn in agentic workflows — each clarifying turn costs context and momentum.
- Burying the ask under preamble. The first sentence is the highest-leverage sentence.
## Positive defaults
- Start with the verb. `Audit`, `Refactor`, `Write`, `Explain`.
- Name the artefact. `…as a numbered list`, `…as a single commit message`, `…as a diff`.
- Name the audience. `…for a senior reviewer`, `…for a new contributor`.
- State the stopping condition. `Stop after the report; do not edit files.`
- Give two examples when shape matters more than description.
## The kanso test for a prompt
Before sending: would another engineer, given only this prompt and no context from your head, produce something close to what you want? If not, the prompt is incomplete. Add the missing piece — don't hope the model fills it.
No comments yet. Be the first to comment!