Help us improve
Share bugs, ideas, or general feedback.
Writes prompts, system instructions, agent directives, and skill descriptions using outcome-first goals plus directional positive verbs. Useful for authoring instructions for LLMs.
npx claudepluginhub kingbootoshi/directional-prompting --plugin directional-promptingHow this skill is triggered — by the user, by Claude, or both
Slash command
/directional-prompting:directional-promptingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Two layers, both required.
Crafts or updates LLM prompts from first principles by discovering goals, constraints, and context through targeted questions. Use for new prompts, updates, or reviews.
Structures Claude prompts using behavior/task/knowledge zones, XML tagging, and tone registers for skills, agents, modes, complex tasks, tools, and code generation.
Applies prompt engineering standards for writing prompts, agent instructions, SKILL.md files, system prompts, Task tool prompts, and LLM-to-LLM content.
Share bugs, ideas, or general feedback.
Two layers, both required.
Layer 1 — Outcome. Open with a block that names the destination. The goal, what "done" looks like, when to stop, the true invariants. This is the frame.
Layer 2 — Direction. Inside that frame, every sentence names the path forward with positive verbs. "Trace", "build", "use", "read", "return", "ask", "check". The correct behavior is described so clearly and completely that the wrong behavior has no room to exist.
Outcome without direction reads as wishful — the model knows where to go but not how to step. Direction without outcome wanders — the model walks crisp paths to nowhere. Both layers together: a model that knows the destination and walks toward it on every token.
Modern frontier models (Claude Opus 4.7, GPT-5.5) follow instructions literally. The Claude 4.7 guide: "Positive examples showing how Claude can communicate with the appropriate level of concision tend to be more effective than negative examples or instructions that tell the model what not to do." The GPT-5.5 guide: "GPT-5.5 is strongest when the prompt defines the target outcome, success criteria, constraints, and available context, then lets the model choose the path."
Both labs converge on the same shape. Name the destination. Name the path. Skip the prohibitions.
Every non-trivial prompt opens with this:
Goal: <one sentence>
Success means:
- <required output element 1>
- <required output element 2>
- <constraint: format, tone, length, schema>
Stop when: <explicit stopping condition>
Optional fourth field for agentic prompts:
Constraints: <only the true invariants — safety, required output fields, hard limits>
Rules for the block:
Inside the outcome frame, every sentence pulls forward.
| Anti-pattern (plants the wrong action) | Directional (plants the right action) |
|---|---|
| Don't make assumptions. | Read the file before answering. |
Avoid using any types. | Type every parameter and return value explicitly. |
| Don't write tests that mock everything. | Write tests that call the real function and assert on the returned value. |
| Don't be verbose. | Answer in one or two sentences. |
| Avoid hallucinating APIs. | Look up the library's API with Exa before calling it. |
| Don't skip the research step. | Run qmd query and read the top three hits before writing. |
| Try not to break existing tests. | Run bun test after every edit and keep all tests green. |
| Don't use em dashes or emojis. | Use hyphens or colons for punctuation breaks. Use plain text. |
| Avoid creating unnecessary files. | Edit the existing file at <path>. |
When reviewing a prompt or skill, scan for these tokens and rewrite each occurrence:
don't, do not, never, avoid, refrain, instead of, rather than, not allowed, prohibited, forbidden, won't, shouldn'tEach match is a prompt smell. Rewrite as the positive replacement. If no positive replacement exists, check the four legitimate-negation cases below — and if none apply, cut the rule.
Four narrow cases:
bun test, not npm test — this project runs on Bun." The negation clarifies; the positive verb still leads.console.log in production code" is crisper than "use the logger" (which logger? where? always?). When the negative is narrower than any positive paraphrase, keep it.Outside these four, the negation is the smell.
Before (no outcome block, mostly negatives, 7 don'ts):
You are a code reviewer. Don't be too harsh. Don't nitpick formatting.
Avoid making assumptions about the author's intent. Never approve code
with obvious bugs. Don't suggest changes that aren't actionable. Try
not to be vague. Avoid emojis.
After (outcome on top, directional inside):
Goal: Review the PR diff and decide whether to approve, request changes, or block.
Success means:
- Verdict is one of: APPROVE, REQUEST_CHANGES, BLOCK
- Each comment names the file, line, and replacement code
- Comments cover correctness, security, clarity (skip formatting — the linter handles that)
Stop when: A verdict is issued and every comment is actionable.
Focus on bugs you can reproduce, security boundaries, and unclear logic.
Ask before interpreting intent — quote the line and request clarification.
Block merges on reproducible bugs. Write in plain text.
Same constraints, half the length. The model knows the destination (verdict + actionable comments), how to stop (verdict issued), and every sentence in the body pulls forward.
A coding agent reads its system prompt on every turn. A negation that plants the wrong concept gets re-planted dozens of times per session. A vague outcome lets the agent's notion of "done" drift turn-by-turn.
Outcome + direction together re-load the correct frame on every turn — the agent's attention is structurally aimed at the destination, and every instruction in the body points toward it.
When writing or auditing any of the following, run this skill:
For each draft: