Prompt Optimizer Skill
Creating or improving prompts
Agents skip steps or ignore instructions
Instructions lack enforcement
Output format is inconsistent
Reviewing any instruction document or prompt
Strengthening agent-operational text without changing business/domain logic
CRITICAL - FORBIDDEN at ALL times:
Changing good parts that already work
Changing the existing logic/intent of prompts
Making changes before understanding the prompt
Leaving weak words in critical sections
Outputting without validation
Over-strengthening soft guidance
Skipping gates or checkboxes
Bloating prompts - target line count increase <10%; if >10%, MUST document a one-line justification in VALIDATE
Triple Lock:
STATE:
You MUST preserve working logic AND follow all gates in order
FORBID:
FORBIDDEN: Altering intent without user approval
FORBID:
FORBIDDEN: Skipping steps or gates
REQUIRE:
REQUIRED: Validate all changes before output AND complete all checkboxes
Violation invalidates optimization. Start over if violated.
FORBIDDEN tools during optimization:
Direct file/system modification that bypasses quality gates
Any tool usage that executes code or commands unrelated to prompt optimization
Tools that skip the READ→UNDERSTAND→RATE→FIX→VALIDATE flow
ALLOWED tools:
Read-only file access (to read prompt files)
Safe file edit/write capability (ONLY after VALIDATE step passes)
Clarification question capability (for user clarification)
Text output (all phases)
Compatibility note (REQUIRED):
Map capability names to the active runtime's tool names.
Example aliases: read-only file access = Read/ReadFile/localGetFileContent; safe file edit/write = Write/StrReplace/ApplyPatch.
Execution Flow
READ → UNDERSTAND → RATE → FIX → VALIDATE → OUTPUT
↓ ↓ ↓ ↓ ↓ ↓
GATE GATE GATE GATE GATE GATE
Step
Action
Gate Requirement
FORBIDDEN Until Gate Passes
1
READ
the prompt completely
All checkboxes checked
Analysis, changes
2
UNDERSTAND
what the prompt does
Understanding output produced
Rating, fixes
3
RATE
each part for issues
Issues table produced
Fixing issues
4
FIX
issues by severity
All Critical/High fixed
Validation
5
VALIDATE
against checklist
All REQUIRED checks pass
Output
6
OUTPUT
optimized document
Format followed exactly
N/A
CRITICAL:
You MUST complete each gate before proceeding. DO NOT skip steps.
Adaptive Mode Selector (REQUIRED)
Mode
Use When
Allowed Compression
Non-negotiables
Fast Path
Short/single-purpose prompt, low ambiguity, <=3 logical parts, no unresolved unknowns
READ+UNDERSTAND may be combined; RATE+FIX may be compacted into one section if issues table is still produced
VALIDATE and intent-preservation checks are ALWAYS required
Full Path
Multi-section prompt, high ambiguity, >=4 logical parts, conflicting constraints, or Critical/High risk
No compression. Execute each gate separately
All gates and templates required
Mode selection rules (REQUIRED):
IF
any unknown blocks progress, conflicting instructions exist, or Critical/High issues are likely →
THEN
use Full Path.
IF
prompt is simple and unambiguous with low risk →
THEN
Fast Path is allowed.
IF
uncertain which mode applies →
THEN
default to Full Path.
Minimum Execution Profile (Very Small Tasks)
IF
task is very small and unambiguous →
THEN
use Fast Path with concise outputs.
MUST:
preserve intent, perform a minimal issue scan, and pass VALIDATE before output.
MUST:
follow selected output variant format.
IF
ambiguity, conflict, or High/Critical risk appears →
THEN
escalate to Full Path immediately.
Global enforcement baseline:
global_forbidden
and VALIDATE are source-of-truth constraints for every gate; gate sections focus on step-specific requirements.
Step 1: READ
STOP. DO NOT proceed to analysis.
Pre-Conditions
User provided prompt/file to optimize
Path is valid and readable
Actions (REQUIRED)
MUST read the input file completely
MUST note the document type and purpose
MUST count approximate line count
Gate Check
Verify before proceeding:
File read completely (no skipped sections)
Document type identified
Line count noted
FORBIDDEN
Making ANY changes before reading
Skipping sections
ALLOWED
Read-only file access only
Text output to confirm reading
On Failure
IF
file unreadable →
THEN
ask user for correct path
IF
file empty →
THEN
ask user to provide content
Step 2: UNDERSTAND
STOP. DO NOT proceed to rating. Understand what this prompt does first.
Pre-Conditions
Step 1 (READ) completed
File content in context
Actions (REQUIRED)
MUST identify the
goal
- what is this prompt supposed to achieve?
MUST identify
logical parts
- break down into sections/phases/steps
MUST identify
flow
- how do the parts connect?
MUST document understanding in output format below
Output Format (REQUIRED)
Understanding
**
Goal:
**
[What the prompt achieves]
**
Logical Parts:
**
1.
[Part name] - [purpose]
2.
[Part name] - [purpose]
...
**
Flow:
**
[How parts connect]
Assumptions & Unknowns (REQUIRED if prompt is underspecified)
Assumptions & Unknowns
**
Assumptions (temporary - proceeding with these):
**
-
[Assumption 1] - Impact if wrong: [consequence]
**
Unknowns (MUST ask before proceeding):
**
-
[Unknown 1] - Why critical: [reason]
**
Clarification needed:
**
Yes/No
IF
Unknowns exist →
THEN
STOP and ask user before proceeding to RATE.
Gate Check
Verify before proceeding:
Goal clearly stated
All logical parts identified
Flow documented
Understanding output produced
Reflection
Did I understand the intent correctly?
Did I identify all logical parts?
IF
you are uncertain about your understanding →
THEN
re-read before proceeding. DO NOT guess.
FORBIDDEN
Proceeding without understanding the goal
Making changes based on assumptions
ALLOWED
Text output (understanding summary)
Re-reading file if needed
On Failure
IF
intent unclear →
THEN
ask user for clarification
IF
multiple interpretations →
THEN
present options and WAIT for user choice
Step 3: RATE
STOP. DO NOT fix anything yet. Rate each logical part for issues first.
Pre-Conditions
Step 2 (UNDERSTAND) completed
Understanding output produced
Issue Categories (MUST check all)
Category
What to Look For
Severity
Weak Words
"consider", "might", "could", "may", "should" in critical sections
Critical
Missing Enforcement
Rules without FORBIDDEN/ALLOWED
High
Ambiguous Instructions
"do some", "handle", "process" without specifics
High
Referential Ambiguity
"it", "this", "that", "above", "below" without clear antecedent
High
Missing Output Format
Expected outputs without templates
Medium
Missing Gates
Phase transitions without checkpoints
Medium
Duplication
Same logic/rule repeated in multiple places (not just examples)
Medium
Verbose/Bloat
Sections >20 lines that could be tables; prose without constraints
Medium
Emoji as Instructions
Emojis used as commands instead of strong words
Medium
Redundancy
Same example repeated, unnecessary variations
Low
Low Density
Explanations that don't constrain behavior
Low
Rating Output (REQUIRED)
Issues Found
|
Part
|
Issue
|
Severity
|
Fix Needed
|
|
|
|
|
|
|
[Part name]
|
[Description]
|
Critical/High/Medium/Low
|
[What to do]
|
Gate Check
Verify before proceeding:
All logical parts rated
Weak word scan completed
Issues table produced
Severity assigned to each issue
FORBIDDEN
Fixing issues before completing rating
Ignoring critical issues
Skipping weak word scan
ALLOWED
Text output (issues table)
Re-reading parts for rating
On Failure
IF
no issues found →
THEN
MUST double-check with weak word scan
IF
scan still clean →
THEN
document "No issues found" and proceed
Weak Word Reference
Weak Word
Context
Replacement
consider, might, could, may
Critical section
MUST
,
REQUIRED
consider, might, could, may
Optional guidance
Remove or keep with "optionally"
should, prefer
Critical section
MUST
should, prefer
Soft guidance
Keep as-is
do some, handle, process
Any
Specify exact action: "Run X", "Call Y"
as needed, if necessary
Any
IF
[condition] →
THEN
[action]
feel free to, you can
Required action
Remove entirely, use
MUST
feel free to, you can
Optional action
"Optionally, you may..."
CRITICAL:
Weak words in FORBIDDEN/MUST/NEVER sections MUST be replaced.
Step 4: FIX
STOP. Fix issues in priority order: Critical → High → Medium → Low.
Pre-Conditions
Step 3 (RATE) completed
Issues table produced
Fix Priority (MUST follow order)
Critical first
- Weak words in MUST/FORBIDDEN contexts
High next
- Missing enforcement, ambiguous instructions
Medium
- Missing output formats, missing gates
Low last
- Redundancy, density (only if value added)
Command Strength Hierarchy
Strength
Keywords
Use For
Absolute
NEVER, ALWAYS, MUST, FORBIDDEN, CRITICAL
Non-negotiable rules
Stop
STOP, HALT, DO NOT proceed, WAIT
Gates/checkpoints
Required
REQUIRED, MANDATORY
Essential steps
Soft
should, prefer
Optional guidance only
Triple Lock Pattern (REQUIRED for Critical Rules)
1. STATE: "You MUST X"
2. FORBID: "FORBIDDEN: Not doing X"
3. REQUIRE: "REQUIRED: Verify X complete"
Reasoning Block (CONDITIONAL REQUIRED Before Changes)
REQUIRED when:
Full Path is active, OR
Fast Path has any Critical/High issue.
Optional when:
Fast Path has only Medium/Low issues; include one-line rationale instead.
Before making changes (when required), produce a
block:
<
reasoning
1.
**
Current state:
**
[What exists now]
2.
**
Goal:
**
[What we are trying to achieve]
3.
**
Approach:
**
[Why this specific change]
4.
**
Risk:
**
[What could go wrong]
</
reasoning
Gate Template (When Adding Gates)
<
[name]_gate
**
STOP. DO NOT proceed. [What to verify]
**
Pre-Conditions
[
] [
Previous step completed
]
Actions (REQUIRED)
1.
[Action]
Gate Check
**
Verify before proceeding:
**
-
[
] [
Condition
]
FORBIDDEN
[What not to do]
ALLOWED
[What is permitted]
On Failure
**
IF
**
[condition] →
**
THEN
**
[recovery]
</
[name]_gate
Gate Check
Verify before proceeding:
All Critical issues fixed
All High issues fixed
Medium/Low addressed or documented as skipped
Reasoning requirement satisfied (block produced OR Fast Path low-risk rationale documented)
FORBIDDEN
Over-strengthening soft guidance (keep "should" for optional items)
Changing logic that already works
Adding unnecessary complexity
Skipping Critical/High issues
Bloating: >10% line increase without explicit justification in VALIDATE
ALLOWED
Text output (draft fixes)
Iterating on fixes
On Failure
IF
over-strengthening detected →
THEN
revert and re-assess using RATE step criteria
IF
unsure if logic changed →
THEN
compare before/after intent
Step 5: VALIDATE
STOP. DO NOT output yet. Validate all fixes against checklist.
Pre-Conditions
Step 4 (FIX) completed
All Critical/High issues addressed
Validation Checklist (MUST complete all)
REQUIRED checks:
No weak words in critical sections
Critical rules use MUST/NEVER/FORBIDDEN
No conversational filler
No conflicting instructions
Logical flow preserved
Original intent preserved
Triple Lock applied to critical rules
Line count target met (<10%) OR justified exception documented
Any >10% increase includes one-line reason linked to required gate/clarity fixes
Additional checks (if applicable):
Gates have Pre-Conditions, Gate Check, FORBIDDEN, ALLOWED, On Failure
Outputs have format specifications
IF/THEN rules for decision points
Referential Clarity (MUST check):
No ambiguous pronouns or positional references without explicit antecedent
All entities have stable names (same term throughout)
Steps/outputs referenced by name, not position
All cross-references are unambiguous
No implicit "the" references without clear antecedent
XML tags are optional; use only for attention-control needs (Markdown remains default)
Reflection (REQUIRED)
MUST answer these questions:
Would I trust this prompt to execute reliably?
What's the weakest remaining section?
Did I change any original intent? (MUST be NO)
IF
weakness identified →
THEN
fix or document as limitation
IF
intent changed →
THEN
STOP and revert. Return to UNDERSTAND step.
Definition of Done (DoD) - Fast Final Gate
ALL must be true before OUTPUT:
Single execution path (no ambiguous branches)
All inputs/outputs explicitly defined
All decision points use IF/THEN
No orphan references (every "it/this" resolved)
Gate Check
Verify before proceeding:
All REQUIRED checks pass
Reflection questions answered
No intent changes
FORBIDDEN
Outputting without completing validation
Skipping checklist items
Proceeding with failed checks
Using XML tags outside attention-control needs (Markdown remains default)
ALLOWED
Text output (validation results)
Returning to FIX step
On Failure
IF
validation fails →
THEN
return to FIX step
IF
intent changed →
THEN
return to UNDERSTAND step
Step 6: OUTPUT
STOP. Verify VALIDATE step passed before outputting.
Pre-Conditions
Step 5 (VALIDATE) completed
All REQUIRED checks passed
No intent changes confirmed
Output Format (REQUIRED - select variant by user intent)
Selection rule (REQUIRED):
IF
user requests complete rewritten document →
THEN
use Variant A.
IF
user requests minimal edits/delta only →
THEN
use Variant B.
IF
user does not specify →
THEN
default to Variant A.
Common report header (REQUIRED for both variants):
Optimization Complete
Summary
**
Issues Found:
**
[N]
-
**
Fixes Applied:
**
[N]
-
**
Intent Preserved:
**
Yes
Changes Made
|
Category
|
Count
|
Examples
|
|
|
|
|
|
Command Strengthening
|
[N]
|
[Brief example]
|
|
Gates Added/Fixed
|
[N]
|
[Brief example]
|
|
Redundancy Removed
|
[N]
|
[Brief example]
|
Variant A - Full Document (default):
Optimized Document
[Full optimized content]
Variant B - Patch-Style Delta (minimal edits):
Patch-Style Delta
|
Section
|
Before
|
After
|
Why
|
|
|
|
|
|
|
[Section name]
|
[Old text]
|
[New text]
|
[Reason]
|
FORBIDDEN
Deviating from selected output variant
Outputting without validation pass
Omitting required deliverable (full document for Variant A, patch-style delta for Variant B)
ALLOWED
Safe file edit/write capability to save optimized content
Text output (summary + document)
On Failure
IF
format deviates →
THEN
regenerate output
IF
user requests changes →
THEN
return to FIX step
Reference: Instruction Precedence
When rules conflict, follow this precedence (highest wins):
Priority
Category
Examples
Notes
1 (highest)
Safety/Tool Restrictions
FORBIDDEN tools, NEVER actions
Always wins
2
User explicit request
"I want X", "Do Y"
Overrides defaults
3
FORBIDDEN/MUST rules
"FORBIDDEN: changing logic"
Overrides preferences
4
Skill defaults
Default behaviors, templates
Baseline
5 (lowest)
Soft guidance
"prefer", "consider"
Yields to all above
Resolution rule:
When two rules conflict, the higher priority wins. Document the conflict and resolution.
Reference: Conflict Resolution Micro-Protocol
Use this protocol when instructions conflict:
Detect
- Name the two conflicting instructions explicitly.
Resolve
- Apply precedence table (highest priority wins).
Document
- Add one-line note: "Conflict: [A] vs [B] -> Resolved by [priority N rule]".
Continue
- Proceed using the resolved instruction only.
FORBIDDEN:
Proceeding while both conflicting instructions remain active.
Reference: Context Patterns
State Summaries (Context Retention)
Use concise summaries only when needed to preserve context:
Goal
Progress
Next step
Blockers (if any)
Conditional requirement:
Full Path: produce a state summary at each phase transition or context shift.
Fast Path: produce a state summary only when context shifts materially.
Reference: High-Value vs Low-Value Content
Keep (High Value)
Remove/Reduce (Low Value)
Tables with explicit actions
Explanatory prose without constraints
Imperative verbs (STOP, VERIFY, EXECUTE)
Repeated examples (keep 1-2)
FORBIDDEN/ALLOWED lists
Long paragraphs that can be tables
IF/THEN decision rules
Hedging language in critical rules
Markdown default + optional XML for attention control
Emoji used as instructions (unless required by output)
Quick Reference
Use this only as a mnemonic; gate sections are source of truth.
Need
Pattern
Stop/Checkpoint
STOP. DO NOT proceed.
+
Gate Check
Mandatory action
REQUIRED: You MUST [action]
Prohibited action
FORBIDDEN: [action]
Decision logic
IF [condition] → THEN [action]
Critical rule hardening
Triple Lock: STATE + FORBID + REQUIRE
Common Mistakes
Mistake
Why It Fails
Fix
Over-strengthening soft guidance
"prefer" → "MUST" breaks optional flexibility
Keep "should/prefer" for truly optional items
Using "it/this/that"
Agent loses context, applies fix to wrong element
Name every entity explicitly
Changing working logic
User trusted original behavior
FORBIDDEN: If the logic works, don't touch it
Overusing XML tags
Noise and style drift without reliability gain
Keep Markdown default; use XML only for attention control