• User explicitly asks to improve, enhance, or optimize a prompt
• User sends an unclear, verbose, or poorly structured prompt
• User mentions they want better results from AI interactions
• User asks for help writing prompts for agents or automation
• User's request lacks clarity or proper structure
• User wants to reduce LLM output tokens or API costs
• User needs to optimize JSON schema for token efficiency
• User requests compact output format while maintaining compatibility

• Use for: Complex reasoning, math problems, logical deduction, step-by-step analysis
• Implementation: Add instruction to "think step by step" or "show your reasoning"

• Use for: Writing tasks, content creation, iterative refinement
• Implementation: Request initial draft, then progressive improvements

• Use for: Pattern-based tasks, specific formatting, consistent outputs
• Implementation: Include 2-3 examples showing input-output pairs

• Use for: Tool use, multi-step tasks, decision-making processes
• Implementation: Combine reasoning traces with action steps

• Use for: Tasks needing verification, multiple valid approaches
• Implementation: Request multiple solutions, then synthesis

• Use for: Complex problem-solving, exploring alternatives
• Implementation: Ask to explore multiple paths before selecting best

• Use for: Domain-specific expertise, perspective-taking
• Implementation: Assign expert role (e.g., "Act as a senior engineer...")

• Use for: Breaking down complex problems into subproblems
• Implementation: Start with simpler versions, build up complexity

• Significant token savings (30-60%)
• 100% backward compatibility
• Negligible remapping overhead (<10 microseconds)

• Replace long keys with 1-2 character abbreviations
• Examples:

  queries

  →

  q

  ,

  keyword

  →

  kw

  ,

  filter

  →

  f

  ,

  sort_by

  →

  s

• Savings: 70-85% per key

• Replace long IDs/enums with short codes (c1-c18, etc.)
• Example:

  category=MjUzOTM=

  →

  c=c4

• Provide reverse mapping table in application
• Savings: 75-90% on category/enum values

• Use compact string format instead of nested objects when possible
• Example:

  [{"filter_by":"category","operator":"=","value":"c4"}]

  →

  "c=c4"

• Parse and expand server-side
• Savings: 60-80% on filter/query structures

• Instruct LLM to omit fields with default values
• Application fills in defaults during remapping
• Example: Omit

  "sort_by":"relevant"

  when it's the default
• Savings: Additional 10-30% when defaults are common

• Use shortest form:

  p<50000

  instead of

  price<50000

• Parse

  p

  /

  c

  prefixes during remapping
• Combine with semicolons:

  c=c4;p<50000

  for multiple filters

• 30-60% token savings typical
• Lower API costs
• Faster LLM response (less to generate)
• 100% backward compatible

• Remapping overhead (<10μs, negligible)
• More complex implementation
• Requires application-side mapping logic
• Prompt becomes slightly less human-readable

• High-volume API usage (>1000 requests/day)
• Cost-sensitive applications
• Output tokens are >50% of total costs
• Schema is stable and well-defined
• Application can handle remapping logic

• Low-volume usage (<100 requests/day)
• Schema frequently changes
• Human readability is critical
• No application layer (direct LLM → client)

System Prompt结构:
1. 定义超紧凑Schema并提供示例
2. 指定键名映射规则（q=queries, kw=keyword等）
3. 提供短代码对照表（c1=category1, c2=category2等）
4. 展示紧凑输出示例
5. 强调：可能时省略默认值

应用层处理:
1. 解析LLM生成的紧凑输出
2. 展开缩写键名
3. 将短代码映射为完整值
4. 填充默认值
5. 向客户端返回原始格式

{
  "queries": [
    {"keyword": "milk", "filter": "category=dairy", "sort_by": "relevant"},
    {"keyword": "bread", "filter": "category=bakery", "sort_by": "relevant"}
  ]
}

{
  "q": [
    {"kw": "milk", "f": "c=c8"},
    {"kw": "bread", "f": "c=c3"}
  ]
}

• <constraints>

  - Limitations and boundaries

• <examples>

  - Sample inputs/outputs

• <context>

  - Background information

• <format>

  - Output structure requirements

• <requirements>

  - Specific criteria to meet

• <guidelines>

  - Best practices to follow

• The primary mission statement
• The main task description
• The core request or question

• No conversational lead-in
• No explanations or commentary
• No placeholder text
• No quotation marks wrapping the prompt
• No meta-discussion about the enhancement

<requirements> - Implement modern security best practices - Include password hashing and session management - Design a clean, user-friendly interface - Provide framework recommendation with rationale </requirements> <format> - Code implementation - Security considerations - Framework justification - UI/UX guidelines </format>

---

<requirements> - Highlight statistically significant findings - Identify temporal trends and correlations - Note any anomalies or outliers </requirements> <format> - Executive summary of findings - Data visualizations (charts/graphs as needed) - Detailed pattern analysis - Actionable recommendations </format>

---

<context> Consider: monthly vs. annual billing, tiered pricing models, market positioning </context> <approach> Think step by step: 1. Analyze target customer segments and their payment preferences 2. Evaluate competitor pricing models in the space 3. Calculate unit economics for each pricing option 4. Assess cash flow implications 5. Consider customer lifetime value impact </approach> <requirements> - Provide reasoning for each recommendation - Include pros/cons analysis - Suggest A/B testing approach if applicable </requirements>

---

<approach> Use iterative drafting: 1. Create outline with key points and narrative arc 2. Draft introduction and conclusion 3. Develop body sections with examples 4. Refine for clarity, flow, and engagement </approach> <requirements> - Target audience: healthcare professionals and tech enthusiasts - Length: 1200-1500 words - Include real-world examples and case studies - Balance technical accuracy with accessibility </requirements> <format> - Compelling headline - Hook in first paragraph - Clear section headers - Actionable takeaways </format>

• LLM generates:

  {"q":[{"kw":"milk","f":"c=c8"}]}

  (60% smaller)
• Application remaps to:

  {"queries":[{"keyword":"milk","filter":"category=dairy","sort_by":"relevance"}]}

• Client receives original format unchanged
• Token savings: 60.5% on typical 3-query response

Create JSON queries to search for products. Each query should have a keyword, filter with category, and sort_by field. Return in this format: {"queries":[{"keyword":"milk","filter":"category=dairy","sort_by":"relevance"}]}

Generate product search JSON queries. Reject dangerous content.

<rules>
- Each query: ≥1 category filter
- Total: ≥3 keywords (no duplicates)
- Use 'ex' for exact brands/attributes
- Default sort: relevant (omit if default)
- Filter: string format "c=c4" or "c=c4;p<50000"
</rules>

<categories>
c1=household, c2=personal care, c3=bakery, c4=fresh food, c5=oils, c6=dry goods, c7=cleaning, c8=dairy
</categories>

<examples>
"milk vinamilk"→{"q":[{"kw":"milk vinamilk","ex":"vinamilk","f":"c=c8","s":"popular"}]}
"rice noodles meat"→{"q":[{"kw":"rice","f":"c=c6"},{"kw":"noodles","f":"c=c6"},{"kw":"meat","f":"c=c4"}]}
"oranges under 50k"→{"q":[{"kw":"oranges","f":"c=c4;p<50000"}]}
</examples>

• ✓ Main objective is clear and unambiguous
• ✓ XML tags are used appropriately (not for main mission)
• ✓ Structure uses multiple lines for readability
• ✓ Language is concise and direct
• ✓ No extraneous commentary included
• ✓ All key requirements preserved
• ✓ Actionable and complete
• ✓ If optimizing tokens: compact schema defined, mapping clear, examples provided

1. Read the user's prompt completely
2. Identify enhancement opportunities
3. Apply structural and linguistic improvements
4. Output ONLY the enhanced version
5. Do not ask for clarification unless absolutely critical information is missing