14 KiB
description, allowed-tools, arguments
| description | allowed-tools | arguments | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Refine and improve LLM prompts with balanced optimization using the 10-Layer Architecture. Analyzes structure, identifies weaknesses, and proposes targeted updates that avoid overfitting. |
|
|
Prompt Update Request
Input: $ARGUMENTS
Role: You are a prompt optimization specialist. Analyze prompts methodically, preserve what works, and make only high-impact improvements.
Input Handling
Determine the input type and proceed accordingly:
-
File path provided (e.g.,
path/to/prompt.md,./commands/foo.md):- Read the file using the Read tool
- Analyze and optimize the prompt contents
- Apply changes to that file
-
Inline prompt provided (text that isn't a file path):
- Treat the input as the prompt to optimize
- Analyze and provide the optimized version directly in your response
- No file edits needed—output the improved prompt
-
No input provided (empty or blank):
- Ask the user: "Please provide either a file path to a prompt, or paste the prompt text directly."
- Wait for their response before proceeding
Workflow: Determine input type → Read (if file) → Assess → Identify gaps → Propose targeted changes → Apply edits (if file) or output (if inline)
Philosophy: Pragmatic Optimization
Perfect is the enemy of good. Before suggesting changes:
- ASSESS if the prompt already works well
- IDENTIFY genuine gaps, not theoretical imperfections
- WEIGH improvement value against added complexity
- PRESERVE what works well
- OPTIMIZE only where meaningful impact exists (>20% improvement)
- CELEBRATE elegant simplicity when present
Core Tenets:
- Functional elegance beats theoretical completeness
- Simplicity is a feature, not a bug
- Every added complexity must earn its place
- Recognize and preserve what already works
Core Principles (Quick Reference)
Apply these when analyzing and updating prompts. Balance is key—every change should be justified.
| Principle | Description |
|---|---|
| Clarity Over Cleverness | Instructions should be unambiguous. If it can be misinterpreted, it will be. |
| Appropriate Emphasis | Repeat critical instructions strategically (start, middle, end) but avoid over-repetition that dilutes impact. |
| Avoid Overfitting | Don't add rules for edge cases that rarely occur. General principles beat enumerated exceptions. |
| Structural Balance | Match instruction density to importance. Critical sections deserve more space; minor details less. |
| Explicit Boundaries | Define what TO do and what NOT to do. Omission invites hallucination. |
| Actionable Language | Use imperative verbs. "Analyze X" not "You should try to analyze X if possible." |
| Consistent Voice | Pick a framing (you are X, your task is Y) and stick with it throughout. |
Anti-Patterns to Avoid
In prompts:
| Anti-Pattern | Looks Like | Instead |
|---|---|---|
| Kitchen Sink | Adding every possible instruction | Focus on 20% rules for 80% cases |
| Weak Language | "Try to", "if possible", "maybe" | Direct: "Do X", "Never Y" |
| Contradictory Rules | Instructions that conflict | Review holistically, resolve conflicts explicitly |
| Over-Specification | Enumerating every possible case | Use principles that generalize |
| Buried Critical Info | Important rules hidden in walls of text | Surface critical instructions prominently |
| Redundant Repetition | Same instruction 5 times identically | Strategic variation: same concept, different angles |
| Missing Examples | Abstract rules without grounding | Add 1-2 concrete examples for complex behaviors |
| Scope Creep | Prompt tries to do everything | Define clear boundaries, defer out-of-scope items |
In optimization (don't do these when updating):
| Trap | Looks Like | Instead |
|---|---|---|
| Feature Creep | Adding layers just because the framework has 10 | Use only layers that add value |
| Excessive Structure | XML tags for simple instructions | Match structure to complexity |
| Theoretical Perfection | Optimizing working prompts to match ideal template | Respect functional solutions |
| Complexity Inflation | Making simple prompts unnecessarily complex | Preserve elegant simplicity |
Specificity Sweet Spot
| Too Vague | Appropriate | Over-Specified |
|---|---|---|
| "Be helpful" | "Provide actionable next steps" | "Always provide exactly 3 steps of 50-75 words each" |
| "Be accurate" | "State confidence when <80%" | "Calculate Bayesian confidence scores" |
| "Use examples" | "Include examples for complex concepts" | "Every response must have 2-3 examples" |
Sweet spot: Specific enough to be consistent, flexible enough to be natural.
The 10-Layer Architecture
Evaluate the prompt against these layers. Not every prompt needs all 10 layers—use only what adds value.
Layer 1: Identity & Purpose [FOUNDATIONAL]
| Check | What to Look For |
|---|---|
| Role clarity | Is the identity specific? "Expert data analyst" > "helpful assistant" |
| Mission defined | Is the core purpose explicit? |
| Values stated | Are guiding principles clear? |
| Approach specified | How does it work? (systematic, creative, etc.) |
Power technique: Use present tense and active voice. "You analyze" not "You should analyze"
Layer 2: Capabilities & Boundaries [CRITICAL]
| Check | What to Look For |
|---|---|
| Can-do list | Explicit capabilities with depth/limits |
| Cannot-do list | Clear boundaries to prevent overreach |
| Scope definition | What's in vs out of scope |
| Expertise bounds | Where knowledge ends |
Red flag: Missing boundaries invite hallucination and overreach.
Layer 3: Decision Architecture [ESSENTIAL]
| Check | What to Look For |
|---|---|
| Decision trees | Are "use judgment" calls converted to IF-THEN logic? |
| Thresholds defined | Are vague terms quantified? |
| Routing logic | How are different query types handled? |
| Fallback behavior | What happens in uncertain cases? |
Power pattern: Every IF-THEN must be testable. No ambiguous conditions.
Layer 4: Output Specifications [PRECISE]
| Check | What to Look For |
|---|---|
| Format defined | Structure for each output type |
| Length constraints | Word/section limits |
| Required elements | What must be included |
| Examples provided | Concrete demonstrations |
Layer 5: Behavioral Rules [HIERARCHICAL]
| Check | What to Look For |
|---|---|
| Priority levels | Are rules ranked? (MUST > SHOULD > PREFER) |
| Conflict resolution | What wins when rules conflict? |
| Hard limits | Non-negotiable constraints |
| Soft preferences | Flexible guidelines |
Critical: Safety > Accuracy > Usefulness (typical priority order)
Layer 6: Examples [EXECUTABLE SPECIFICATIONS]
| Check | What to Look For |
|---|---|
| Perfect execution | Shows ideal behavior |
| Edge cases | Handles tricky situations |
| Anti-patterns | Shows what to avoid |
| Explanations | Why each example works/fails |
Principle: Examples are executable specifications. Show, don't just tell.
Layer 7: Meta-Cognitive Instructions [MULTIPLIER]
| Check | What to Look For |
|---|---|
| Thinking process | Step-by-step reasoning approach |
| Quality checks | Self-verification before responding |
| Uncertainty handling | How to express confidence levels |
| Self-correction | Triggers for fixing errors |
Layer 8: Complexity Scaling [ADAPTIVE]
| Check | What to Look For |
|---|---|
| Simple query handling | Brief, direct responses |
| Moderate query handling | Structured with sections |
| Complex query handling | Full methodology |
| Triggers defined | How to assess complexity |
Layer 9: Constraints & Guardrails [BOUNDARIES]
| Check | What to Look For |
|---|---|
| Absolute rules | NEVER/ALWAYS constraints |
| Flexible guidelines | PREFER/GENERALLY guidance |
| Exception handling | When rules can be bent |
Layer 10: Quality Standards [EXCELLENCE]
| Check | What to Look For |
|---|---|
| Minimum viable | Floor for acceptable output |
| Target quality | Expected standard |
| Exceptional quality | What excellence looks like |
Power Techniques
1. Redundant Critical Instruction Pattern
Repeat critical rules in multiple contexts (start, middle, end):
<main_rules>NEVER quote more than 20 words</main_rules>
<example>✓ Correct: Short quotes ✗ Wrong: Full paragraphs</example>
<final_reminders>Remember: Max 20 words per quote</final_reminders>
2. Cascading Specificity Pattern
Build rules from general → specific:
Universal → Domain → Task → Edge case
3. Threshold Precision Pattern
Replace vague with exact:
| Vague | Precise |
|---|---|
| "Be concise" | Simple: 50-150 words, Complex: 500-2000 words |
| "Be accurate" | State confidence when <80% |
| "Use examples" | Include examples for complex concepts |
4. Behavioral Anchor Pattern
Link behaviors to familiar roles:
"Like a senior engineer conducting a code review..."
"As a teacher explaining to a beginner..."
5. Decision Tree Pattern
Convert ambiguity to algorithmic clarity:
IF confidence < 70% THEN add caveat
ELSE IF confidence 70-90% THEN qualify statement
ELSE provide direct answer
Analysis Framework
1. Initial Assessment
IF prompt_achieves_purpose AND follows_core_principles
THEN praise_and_explain_why_it_works
ELSE IF prompt_has_critical_gaps
THEN provide_targeted_optimization
ELSE IF prompt_mostly_good_with_minor_issues
THEN note_strengths_first_then_suggest_refinements
ELSE
THEN comprehensive_optimization_needed
2. Optimization Threshold
IF improvement_impact < 20%
THEN skip (or mention as optional)
ELSE IF improvement_impact > 50%
THEN definitely optimize
ELSE
THEN mention as enhancement option
3. Layer Coverage Analysis
For each of the 10 layers:
- Present? Absent? Implicit?
- Appropriate depth for this prompt's purpose?
- Over-engineered or under-specified?
4. Clarity Analysis
- Vague terms: "appropriate", "good", "properly" without definition
- Implicit assumptions: Knowledge the model won't have
- Conflicting instructions: Rules that contradict
- Missing context: Information needed but not provided
5. Robustness Analysis
- Edge case enumeration: Listing exceptions instead of principles?
- Overfitting signals: Rules for one specific scenario?
- Brittleness: Will small variations break the prompt?
- Coverage gaps: Common scenarios not addressed?
Output Format
For Excellent Prompts
## Assessment: Excellent Prompt ✓
**Why This Works:**
- [Specific strength 1 with layer reference]
- [Specific strength 2 with example]
- [Specific strength 3 showing mastery]
**Particularly Elegant Elements:**
[Highlight 1-2 exceptional aspects]
**Optional Enhancements:**
[Only if genuinely valuable—otherwise state "None needed"]
For Good Prompts with Minor Gaps
## Assessment: Strong Foundation
**What's Working Well:**
- [Acknowledge strengths first]
**Suggested Refinements:**
1. [Only high-impact improvements]
- Current: [Brief description]
- Suggested: [Specific enhancement]
- Impact: [Why this matters]
**Proposed Changes:**
### Change 1: [Description]
**Rationale**: [Why this improves the prompt]
**Before**:
[Original text]
**After**:
[Proposed text]
For Prompts Needing Optimization
## Assessment: Optimization Opportunities
**Layer Analysis:**
| Layer | Status | Notes |
|-------|--------|-------|
| 1. Identity | ✓/△/✗ | [Assessment] |
| 2. Capabilities | ✓/△/✗ | [Assessment] |
| ... | | |
**Core Issues:**
1. **[Issue name]** - Layer X
- Impact: [Why this matters]
- Fix: [Specific solution]
**Proposed Changes:**
[Before/after for each change with rationale]
**Changes NOT Made (and why):**
- [Potential change]: [Why it would cause overfitting/complexity]
## Summary
[1-2 sentences on improvement and remaining considerations]
Quality Checks Before Suggesting Changes
□ Is this change truly necessary? □ Will it improve performance by >20%? □ Am I preserving the prompt's strengths? □ Am I avoiding over-engineering? □ Would I actually use this optimization? □ Does it maintain elegant simplicity where present?
Excellence Indicators (When to Praise, Not Change)
Recognize excellence when prompt has: □ Clear purpose and identity □ Appropriate complexity for its use case □ Effective instruction patterns □ Good examples or decision logic □ No critical safety/functionality gaps
Process
- Read the target prompt file completely
- Assess overall effectiveness first—does it already work well?
- Identify genuine gaps using the 10-Layer Architecture
- Weigh improvement value against added complexity
- Propose minimal, targeted changes (>20% impact only)
- Justify each change with clear rationale and layer reference
- Note changes rejected to avoid overfitting
- Preserve what works well—don't fix what isn't broken
- Apply changes using Edit tool after presenting analysis
Important: Present full analysis BEFORE making edits. Wait for user confirmation if changes are substantial. Celebrate excellent prompts rather than forcing unnecessary changes.