Versatile Prompt Engineering (Cross-Model)

# Meta prompting & modular/decomposed prompting

## Definitions & distinctions (supported)
- **Metaprompting / metaprompt**: a higher-level instruction that structures/governs how an AI model processes prompts. It emphasizes **frameworks guiding prompt interpretation** rather than issuing only specific commands.
- **Meta prompting (advanced technique)**: AI models generate, refine, or analyze other prompts to improve flexibility/effectiveness.
- Meta prompting is described as focusing on **prompt structure and logic** rather than only content.

## Claimed capabilities / takeaways (supported)
- **Metaprompting frameworks**: provide structured guidance to enhance reasoning/adaptability.
- **Autonomous prompt optimization**: enables models to autonomously create/optimize prompts, aiming for improved accuracy/reliability and scalability.

## Modular / decomposed prompting concepts (supported)
From the research pack:
- **Decomposed Prompting**: breaks complex tasks into simpler sub-tasks, enabling task-specific prompt optimization and improved performance.
- **Modularization for code generation**: applies modular reasoning steps to decompose programming problems, improving LLM-based code generation performance.
- **Chatbot modules (MPC)**: uses pre-trained LLMs as individual modules for long open-domain conversations, aiming for long-term consistency/flexibility comparable to fine-tuned models without additional training.
- **Empathic Prompting**: integrates non-verbal cues (e.g., facial expressions) into multimodal LLM conversations to respond appropriately to users’ emotional states.
- Other modular frameworks in specialized domains (e.g., FlexKalmanNet combining AI + Kalman filtering; Jupyter integration): demonstrate modular AI components enhancing task performance.

## Practical implication for prompt design (non-prescriptive, derived from takeaways)
- When task complexity is high, prefer prompt designs that **decompose** the work into smaller sub-tasks with clearer, task-specific guidance.
- For prompt optimization workflows, consider using **meta-prompts** as templates/frameworks that guide the model’s prompt generation/refinement process.

## Warning on coverage
- The supplied sources provide conceptual takeaways but do not enumerate exact metaprompt syntax, nor a complete step-by-step algorithm for metaprompting. Use the above definitions/takeaways as guidance, not as an executable recipe.

# Prompt engineering frameworks & prompt construction (cross-model)

## Core best practices (supported)
- Use the latest model for optimal performance (OpenAI guidance; also echoed as “use the most recent and capable models”).
- Put instructions at the beginning of the prompt and separate them from the context using delimiters (e.g., triple quotes `"""`).
- Be clear and specific to avoid ambiguity.
- Iterate: start with an initial prompt, review the response, and refine based on the output (OpenAI Help Center).
- Use examples to guide output format/style (few-shot prompting). Claude guidance additionally suggests using **3–5 relevant and diverse examples**.

## Structured prompt scaffolds

### COSTAR (from Parloa)
- **Context, Objective, Style, Tone, Audience, Response**.

### RAPTOR (from Raptor prompt engineering)
- Six core elements: **Role, Aim, Parameters, Tone, Output, Review**.
- Includes a **feedback loop** for continuous improvement of prompt effectiveness.

### Role + blocks template (from multiple sources; compiled)
Use this kind of structure as a starting point (OpenAI prompt guidance provides a “suggested prompt structure”):

- **Role:** 1–2 sentences defining the model’s function, context, and job.
- **Personality:** tone/demeanor/collaboration style.
- **Goal:** user-visible outcome.
- **Success criteria:** what must be true before final answer.
- **Constraints:** policy/safety/business/evidence/side-effect limits.
- **Output:** sections + length + tone.
- **Stop rules:** retry/fallback/abstain/ask/stop conditions.

## Examples & formatting steering (supported)
- Few-shot prompting: include relevant examples to guide output.
- Claude-specific formatting: structure instructions/context/examples using consistent **XML tags** for clarity.
- Output formatting should be controlled by explicitly specifying the expected response format.

## Iteration/optimization loop (supported)
- After each response, review whether the output meets:
  - clarity/specificity requirements
  - success criteria
  - constraints
  - requested output format
- Refine and re-run until the prompt reliably produces acceptable results (OpenAI iterative refinement; RAPTOR review/feedback loop).

## Claude-specific operational guidance (supported)
- Usage limit best practices:
  - Plan conversations: combine related questions to reduce message count.
  - Be specific and concise to minimize follow-ups.
- When creating skills:
  - Keep skills focused (concise skills targeting specific tasks).
  - Provide clear descriptions for when/how the skill should be used.

## GPT-5.x prompt shaping notes (supported by prompt guidance excerpt)
- GPT-5.5: prefers **shorter, outcome-first prompts** vs process-heavy stacks; describe what good looks like, constraints, available evidence, and final-answer contents.
- Keep personality and collaboration-style instructions short: they should shape UX/behavior but should not replace clear goals, success criteria, tool rules, or stopping conditions.
- Preamble for perceived responsiveness: for streaming/tool-heavy tasks, start with a short visible preamble acknowledging the request and stating the first step.

---
name: versatile-prompt-engineering-master-skill
description: "Teaches the agent how to craft sophisticated, high-impact prompts for major LLMs (e.g., Claude, GPT, Perplexity) using structured prompt scaffolds, outcome-first steering, few-shot examples, explicit success/constraints/stop rules, and meta-prompting/modular prompting workflows. Use when the user asks for improved prompts like: \"rewrite this prompt\", \"make a better prompt for Claude/GPT/Perplexity\", \"create a prompt template\", \"use COSTAR/RAPTOR\", \"add role/personality/goal/success criteria/output/stop rules\", \"produce an XML-tagged prompt\", \"help me design a prompt\", \"optimize my prompt\" or when the user provides a draft prompt and requests higher accuracy, better formatting, fewer follow-ups, or an iteration/feedback loop. Trigger on keywords: prompt template, prompt rewrite, COSTAR, RAPTOR, stop rules, success criteria, few-shot, XML tags, metaprompt, modular prompting, decomposed prompting, outcome-first, structured output contract."
---
Prompt engineering for cross-model LLM performance

Workflow
1) Collect inputs: ask for (a) target model/platform (Claude/GPT/Perplexity/unspecified), (b) task type, (c) desired output format/sections, (d) constraints (tone, length, policies), (e) available context/data, (f) success criteria and “done” definition.
2) Build an outcome-first instruction block placed at the beginning, separated from context with clear delimiters. Include: Role, Goal, Success criteria, Constraints, Output contract, and Stop rules.
3) If the user’s task is complex, decompose: split into 2–6 sub-tasks and add per-sub-task guidance (what to produce, what to verify). Keep the decomposition in the prompt, not as extra conversation steps.
4) Add few-shot examples only when they clarify formatting/style/edge cases. Provide 3–5 diverse examples when the host model is Claude-style formatting sensitive.
5) If the user requests Claude compatibility, wrap instruction/context/examples using consistent XML tags and keep tags stable across rewrites.
6) Add an explicit stopping gate: define when the model must stop (e.g., after providing required sections + any required citations/evidence; or when missing evidence is detected).
7) Add missing-evidence behavior: specify whether to (a) ask a targeted question, (b) proceed with minimal sufficient evidence, or (c) return an explicit error object—based on the user’s requirement.
8) Optimize for efficiency: combine related questions, minimize “process-heavy” instructions, and keep persona/collaboration blocks short. If tools/search are involved, include a small retrieval budget stopping condition and citation/grounding constraints.
9) Perform an iteration loop: after generating the improved prompt, self-check against success criteria, constraints, output contract, and stop rules. If any are missing, rewrite once to fix them.
10) Return two artifacts: (a) “Final prompt” ready to paste, and (b) “What I changed” as a short bullet list.

Read [references/prompt-engineering-frameworks.md](references/prompt-engineering-frameworks.md) when constructing COSTAR/RAPTOR/role+blocks, examples, delimiters, and explicit stop rules.
Read [references/meta-prompting-and-modular-prompting.md](references/meta-prompting-and-modular-prompting.md) when the user requests metaprompting or modular/decomposed prompt design.
Read [references/gpt5x-prompting-steering-rules.md](references/gpt5x-prompting-steering-rules.md) when optimizing for GPT-5.x style steering (outcome-first, stopping conditions, missing evidence behavior, structured output contracts, retrieval/citation rules).

Examples (input/output clarifiers)
- Input: “Rewrite my prompt to get JSON only.” Output: improved prompt includes a strict output contract (“Return ONLY valid JSON matching schema… no extra text”) and a stop rule (“Stop after JSON is produced or return error object if schema info is missing”).
- Input: “Make it work for Claude.” Output: prompt uses consistent XML tags for Role/Goal/Context/Examples/Output contract.
- Input: “Hard task: summarize + critique + extract requirements.” Output: decomposed prompt with separate substasks and per-subtask success criteria.

Constraints / edge cases
- If the user omits the required output format or success criteria, ask 1–3 targeted questions before finalizing the prompt.
- Never invent schemas, citations, or source links. If citations are required, instruct the model to cite only from retrieved sources and stop when evidence is sufficient.
- Do not over-specify process steps. Only add “ALWAYS/NEVER” for true invariants (output contract, stop rules, safety/grounding constraints).
- Keep persona/collaboration instructions short; goals/success/constraints/output contract must lead.