Use when transforming NEVER/DON'T statements into ALWAYS/DO patterns. Provides 20+ before/after examples, decision tree for tone selection, and psychology-backed guidance for effective LLM instruction design.
This skill inherits all available tools. When active, it can use any tool Claude has access to.
Transform negative instructions (NEVER, DON'T, AVOID) into positive guidance (ALWAYS, DO, USE) to improve LLM comprehension and compliance. Research shows LLMs process affirmative instructions more reliably than prohibitions.
Use when the instruction is absolute and applies in all cases.
| Before (Negative) | After (Positive) |
|---|---|
| NEVER edit files without reading them first | ALWAYS use Read tool before Edit or Write |
| DON'T create new files unnecessarily | ALWAYS prefer Edit for existing files in codebase |
| NEVER commit without checking status | ALWAYS run git status and git diff before commits |
| DON'T use relative paths | ALWAYS use absolute paths in tool calls |
| NEVER skip error handling | ALWAYS validate tool outputs and handle errors |
| DON'T run commands interactively | ALWAYS use non-interactive flags (git add ., not git add -i) |
| NEVER hardcode templates in skills | ALWAYS externalize templates to templates/ subdirectory |
Transform "don't do X" into "do Y instead" with clear alternatives.
| Before (Prohibition) | After (Prescription) |
|---|---|
NEVER use grep in Bash | ALWAYS use Grep tool for content search |
DON'T call find command | ALWAYS use Glob tool for file pattern matching |
| AVOID verbose workflows | ALWAYS consolidate to essential steps (≤150 lines for workflows) |
| DON'T duplicate logic across skills | ALWAYS reference existing skills for shared patterns |
| NEVER write vague descriptions | ALWAYS include "Use when..." triggers and file types in descriptions |
| DON'T include full implementations | ALWAYS use pseudocode or 5-10 line examples; externalize full templates |
| AVOID running dependent commands in parallel | ALWAYS chain sequential commands with && in single Bash call |
Convert warnings into actionable safeguards.
| Before (Warning) | After (Guidance) |
|---|---|
| NEVER commit secrets | ALWAYS exclude .env, credentials.json from commits; warn if user requests |
| DON'T force push to main/master | ALWAYS check branch before force operations; warn user if targeting main |
| AVOID amending pushed commits | ALWAYS verify commit is unpushed (git status) before --amend |
| NEVER skip pre-commit hooks | ALWAYS run hooks unless user explicitly requests --no-verify |
| DON'T update git config | ALWAYS preserve existing git configuration |
| AVOID destructive operations | ALWAYS confirm with user before irreversible git commands (hard reset, force push) |
Use when instruction depends on context or judgment.
| Before (Recommendation) | After (Recommendation) |
|---|---|
| Try not to use emojis | Use emojis only when user explicitly requests them |
| Avoid creating documentation | Create documentation files only when user explicitly asks |
| Don't be too proactive | Commit changes only when user explicitly requests a commit |
| Avoid long responses | Prefer concise responses; use tables and lists over prose |
| Don't assume requirements | When unclear, ask user to clarify before proceeding |
| Avoid speculation | Verify assumptions by reading existing code or asking user |
Define what to do within proper boundaries.
| Before (Boundary) | After (Boundary) |
|---|---|
DON'T modify files outside .claude/skills/ | Write exclusively to .claude/skills/ (use agent-author for agents) |
| NEVER exceed 150 lines for workflow skills | Keep workflow skills ≤150 lines, utility skills ≤100 lines |
| DON'T create PRs without pushing | Push to remote with -u flag before creating PR with gh pr create |
| AVOID reading unnecessary files | Read only files relevant to the current task |
| DON'T run commands without description | Provide clear 5-10 word description for every Bash command |
START: What is the instruction's nature?
│
├─ Absolute rule (always/never applies)?
│ └─ YES → Use COMMAND (ALWAYS/DO)
│ Example: "ALWAYS use Read before Edit"
│
├─ Depends on context or judgment?
│ └─ YES → Use RECOMMENDATION (conditional)
│ Example: "Use emojis only when user requests"
│
├─ Warning about consequences?
│ └─ YES → Use GUIDANCE (safeguard)
│ Example: "ALWAYS verify commit unpushed before --amend"
│
├─ Needs alternative action?
│ └─ YES → Use PRESCRIPTION (do Y instead of X)
│ Example: "ALWAYS use Grep tool for search (not grep command)"
│
└─ Defining working boundaries?
└─ YES → Use BOUNDARY (scope definition)
Example: "Write exclusively to .claude/skills/"
Before:
NEVER commit changes without user permission
DON'T use cat, grep, or find commands
AVOID being proactive with git operations
After:
ALWAYS wait for explicit user request before creating commits
ALWAYS use Read, Grep, and Glob tools (not bash equivalents)
Commit only when user explicitly asks; ask first if unclear
Before:
name: example-skill
description: Validates code (DON'T use for config files)
## What Not to Do
- Never run without reading files
- Don't create new files unnecessarily
After:
name: example-skill
description: Use when validating .tsx and .ts code files (use config-validator for config files)
## Workflow
1. ALWAYS read target file with Read tool before validation
2. ALWAYS prefer Edit for existing files; use Write only for new files
Before:
// DON'T run this command on uncommitted changes
// NEVER use without checking git status first
After:
// ALWAYS run git status before executing this command
// Use only on committed changes; commit pending work first
Before:
## Rules
- NEVER edit files in .claude-plugin/
- DON'T commit without testing
- AVOID creating unnecessary files
After:
## Workflow Standards
- ALWAYS use agent-author for .claude-plugin/ modifications
- ALWAYS run validation before commits (see Verify principle)
- ALWAYS prefer editing existing files over creating new ones
When refactoring negative instructions:
Cognitive Load:
LLM Training Bias:
Clarity:
Compliance:
Studies in human-computer interaction show affirmative framing improves:
While LLMs differ from humans, similar patterns emerge in prompt engineering research (see: Constitutional AI, RLHF optimization studies).
Anti-Pattern 1: Vague Positivity
❌ ALWAYS write good code
✅ ALWAYS validate inputs before processing (use zod for runtime validation)
Anti-Pattern 2: False Equivalence
❌ DON'T use cat → ALWAYS avoid cat
✅ DON'T use cat → ALWAYS use Read tool for file contents
Anti-Pattern 3: Missing Context
❌ ALWAYS commit changes
✅ ALWAYS commit only when user explicitly requests (ask first if unclear)
skill-author - Uses positive framing when writing skill specificationsagent-author - Uses positive framing when writing agent promptscommand-author - Uses positive framing in command documentationA well-framed instruction has: