# Meta Prompting > > **Meta-Suite doctrine (overrides anything below).** Never ask the user clarifying questions — - Skill: `manutej/meta-prompting` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add manutej/meta-prompting` - Raw SKILL.md: https://api.skillmd.com/api/skills/manutej/meta-prompting/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: manutej (https://skillmd.com/u/manutej) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/manutej/meta-prompting --- > **Meta-Suite doctrine (overrides anything below).** Never ask the user clarifying questions — > infer what you need from the request, choose sensible defaults, and state your assumptions in one > line before proceeding. Never surface category theory, functors, monads, morphisms, or other > typed-formalism vocabulary to the user; keep that machinery internal and reveal it only if the > user explicitly asks to review the internal work. Keep all user-facing output in plain language. # Meta Prompting Based on **"Meta Prompting for AI Systems"** (Zhang, Yuan, Yao — arXiv:2311.11482, ICLR 2024 BGPT Workshop) and its `meta-prompting/meta-prompting` reference implementation. ## What this skill is for A **meta-prompt** specifies the *formal structure* of how to solve an entire category of tasks — the syntax, the typed slots, the reasoning procedure, the output contract — **without** content-specific examples. Few-shot prompting shows the model *what* to think (concrete solved instances); meta-prompting shows it *how* to think (a reusable, example-agnostic blueprint). This is more token-efficient, more robust, and composes cleanly. Your job here is **not** to solve the user's task. It is to operate one level up: take an input task and **emit the meta-prompt that solves the whole category that task belongs to**. You are mapping the *meta-meta-prompt space* — the space of procedures that generate valid meta-prompts. Trigger this skill whenever the value is in a reusable structure rather than a one-shot answer: designing a system prompt, a prompt template, a reasoning harness, an agent persona, or any "make me a prompt for X-type problems." ## The one idea to hold onto > **Meta Prompting is a functor.** It maps the *category of tasks* to the *category of prompts*, preserving structure: if a task decomposes into sub-tasks, the meta-prompt decomposes into composable sub-prompts. So your first move is always to find the task's structure, because the prompt's structure is the image of it. Get the decomposition right and the prompt writes itself. A second idea makes it self-improving: > **Recursive Meta Prompting (RMP) is a monad.** An LLM can generate and then refine its *own* meta-prompt. Model the refinement as a Writer monad: each pass appends an *edit script* to an accumulating history, and nested refinements collapse into one coherent edit trace. In practice: draft → critique → emit edit script → apply → repeat until stable. Read `references/theory.md` for the functor/monad/type-theory grounding and the paper's benchmark results. Read it when the user wants the conceptual justification, asks about category theory, or you need the multi-modal typed-slot schema. ## The procedure: task → meta-prompt Work through these five steps. They ARE the functor — each step lifts one piece of task structure into prompt structure. ### 1. Identify the task category (not the instance) Look past the specific instance the user gave you to the **category** it represents. "Solve 3x+7=22" → the category is *single-variable algebraic equations*, or more usefully *step-by-step mathematical reasoning with a verifiable final answer*. The meta-prompt must serve the whole category, so name the category explicitly and state what varies across instances (the free variables) and what stays fixed (the invariant structure). ### 2. Decompose into typed sub-decisions Break the category's solution into the sequence of sub-decisions any instance requires, and **assign each a type**. Treat every design decision as a typed term, never an ad-hoc value: - inputs as typed slots — `Problem: str`, `Diagram: image/png`, `Constraints: list[str]` - intermediate decisions as typed terms — `Plan: list[Step]`, `Subproblems: list[Problem]` - the output as a typed contract — `FinalAnswer: LaTeX`, `Result: json{...}` Typing is what guarantees compositionality and lets the structure transfer across modalities (text, image, audio, code). See the multi-modal `` pattern in `references/theory.md`. ### 3. Specify the reasoning procedure State the *process* the model should follow over those slots — the "how to think," kept abstract and example-free. E.g. "Begin with 'Let's think step by step.' Decompose into sub-problems. Solve each. Compose. Verify against the original constraints." Procedure, not worked examples. If the category is better served by emitting a *program* than by reasoning in prose (as Game-of-24 is solved by generating one Python solver), say so — meta-prompts can direct the model to write code that handles every instance at once. ### 4. Bind the slots with rules and an output contract Write the rules that connect the slots: ordering, what must reference what, invariants ("every claim cites a search result"), and the exact output format. A resolved slot is **immutable downstream** — later parts inherit it unchanged unless an explicit named refinement (a morphism) transforms it. Make the output contract unambiguous so the result is machine-checkable. ### 5. Render the meta-prompt in a clean structural format Emit the meta-prompt as an explicit schema. **XML tags or JSON skeletons** work best because they make the typed slots and their nesting legible to the model. Keep it example-agnostic: the finished meta-prompt should contain *zero* solved instances — only slots, rules, and procedure. The two canonical shapes: **JSON-skeleton style** (good for reasoning tasks with a fixed output shape): ``` Integrate step-by-step reasoning under the following structure: { "Problem": "[question to be answered]", "Solution": { "Step 1": "Begin with 'Let's think step by step.'", "Step 2": "Break the reasoning down clearly and logically.", "Step 3": "End with the final answer in $\\boxed{...}$." }, "Final Answer": "[final answer]" } ``` **XML-schema style** (good for personas, multi-slot or multi-modal tasks): a `` block (role + typed instructions) plus a `` block defining the slot tree the model fills. The user's design-artifact meta-prompt in `references/meta-meta-prompt.md` is a full worked example of this shape. ## Recursive refinement (RMP) — when to loop For high-stakes or fuzzy tasks, don't ship the first draft. Run the monad loop, typically **3–5 passes**: 1. **Draft** the meta-prompt via the five steps. 2. **Critique** it against the category: Does it cover every instance, not just the user's example? Any leaked specifics? Any untyped slot? Any unbound rule? Is the output contract checkable? 3. **Emit an edit script** — a concrete, named list of changes (this is the Writer-monad log; keep the running history so refinements compose rather than thrash). 4. **Apply** and repeat until the edit script comes back empty (a fixpoint) or you stop improving. The synthesis example in `references/meta-meta-prompt.md` is explicitly designed to be looped this way — its render-and-verify structure is the monad made concrete for design artifacts. ## The generator template (the meta-meta-prompt) `references/meta-meta-prompt.md` contains a ready-to-use **meta-meta-prompt**: a prompt you can hand any task to and get back a valid meta-prompt, plus the full design-artifact synthesis example that composes this skill with the `generative-ui` skill. Read it when the user wants the reusable generator itself, or wants the design/UI synthesis. ## Quality checklist before you ship a meta-prompt - **Example-agnostic:** no solved instances anywhere — only slots, rules, procedure. - **Typed:** every input, intermediate, and output is a named typed slot. - **Compositional:** sub-tasks map to sub-prompts; structure mirrors the task. - **Bound:** rules connect the slots; the output contract is unambiguous and checkable. - **Category-complete:** it serves the whole category, verified against instances *other* than the one the user gave you. - **Lean:** every line earns its place; prefer explaining *why* a constraint matters over piling on rigid MUSTs. ## Common failure modes - **Overfitting to the example instance** — the single most common error. You write a "meta"-prompt that only really works for the one problem the user showed you. Always test it mentally against 2–3 *different* instances of the category. - **Smuggling in few-shot examples** — if you find yourself writing a fully solved example, you've dropped back to few-shot. Convert it into a slot + rule instead. - **Untyped, ad-hoc slots** — values like "put the answer here" with no type. Name the type. - **Unbound slots** — slots with no rule saying how they relate or what order they resolve in. - **Solving the task instead of structuring it** — if your output answers the user's specific question, you've collapsed back to level zero. Stay one level up.