Metaprompt

Metaprompt

A prompt written by feel, without checking what actually works for the specific model and harness that will run it, tends to either under-specify (missing a technique that model responds well to) or over-specify (re-stating things the harness already guarantees, which dilutes attention). This skill treats prompt-writing as a small research task with three required inputs, not a one-shot creative exercise.

When to use this

• Writing a prompt, system message, or agent instructions meant to run on a specific model inside a specific harness — most valuably when that combination differs from the one currently running this conversation (you can't rely on your own default behavior as a stand-in for how the target will behave).
• The user asks to "write a prompt for X model" or "write the system prompt for this agent" and names or implies a target model/harness.

Instructions

1. Get all three required inputs

• Goal — what should the resulting prompt make the model do?
• Target model — the specific model/family (e.g. "Claude Opus 4.8," "GPT-5.2," "Gemini 3 Pro"). Techniques differ meaningfully even within one vendor's lineup — don't accept "an LLM" as an answer.
• Target harness — what will actually run this prompt: Claude Code, Codex CLI, a custom agent loop, the raw API, a chat UI, something else. This determines what the harness already handles for you vs. what the prompt must spell out.

If any is missing or ambiguous, ask before drafting — a prompt optimized for the wrong model/harness combination isn't a safe default to fall back on.

2. Research before writing — don't rely on memorized specifics

Model and harness idioms change as often as the models themselves ship. Before drafting:

• Look up the target model's current official prompting guidance (WebSearch/ WebFetch its vendor's docs). If a skill already available in this environment is specifically authoritative for that model/vendor (for example this repo's own claude-api skill for Claude/Anthropic), prefer it over general web search.
• Look up the target harness's own conventions and docs (a harness-specific instructions-file format, its tool-calling conventions, what context it injects automatically).
• Treat anything you already "know" about a model's quirks as a hypothesis to verify, not a fact to assert — this is exactly the staleness this skill exists to avoid.

references/research-checklist.md lists the categories to investigate for the model and the harness — deliberately not a list of hardcoded facts, since those go stale.

3. Apply what you found

• Model-specific: structuring conventions the model responds to (XML tags, markdown, JSON), how it handles extended/visible reasoning, how literally it follows instructions, anything relevant to the goal around refusals/safety framing.
• Harness-specific: what the harness already provides automatically (tool definitions, cwd/git context, sandboxing, available tools) — don't re-specify it, that's redundant and dilutes the prompt. What output format the harness expects and parses. Where the harness's own extension points are (system prompt vs. user message vs. a dedicated config/instructions file).

The harness guide is the authority on what to omit, not just what to add.

4. Assemble, then self-review before delivering

Draft the complete prompt, then check it against:

• Is the goal unambiguous to someone with zero other context?
• Are format instructions precise and actually match what the harness parses?
• Does it redundantly restate anything the harness already guarantees?
• Any internal contradictions between sections?
• Is it as concise as the goal allows — a bloated prompt degrades attention as much as a vague one does?

Full checklist in references/research-checklist.md.

5. Deliver three things

1. The ready-to-paste prompt, in a code block.
2. Parameter recommendations if applicable (reasoning/thinking effort, temperature, and similar) for the target model.
3. One sentence naming the key model- or harness-specific technique that shaped this prompt — so the user understands why it's written this way, not just what to paste.

Reference files

• references/research-checklist.md — what to look up per model and per harness, and the pre-delivery self-review checklist.