If you have read our article on how AI memory actually works, you already know the fundamental problem: every LLM call is stateless. The model does not remember you, does not remember your project, and does not carry context from one conversation to another. Everything it "knows" is either injected into the context window by the platform or provided by you in the current session.
A metaprompt is the practical answer to that problem.
What is a metaprompt?
A metaprompt is a structured prompt generated by one AI context window for use in another. It is not a system prompt, which is set by the platform. It is not a casual opening message where you type "hey, help me build a thing." It is a deliberately constructed block of context that bridges two stateless systems that have no awareness of each other.
The simplest version of the workflow looks like this: you describe what you are working on to a conversational AI (Claude Chat, ChatGPT), which already has some memory context from your previous sessions. You ask it to generate a detailed prompt that captures everything a fresh AI session would need to know in order to help you. You review and edit that output, then paste it into a different tool (Claude Code, Codex, a new chat session, or any other LLM-powered environment) as the opening message.
You are the bridge. The first context window has conversational history and platform memory but no access to your codebase. The second context window has access to your files and can execute code but knows nothing about you or your goals. The metaprompt is how you transfer the relevant knowledge from one to the other without manually writing a specification document from scratch every time.
Why this matters more than it seems
People sometimes underestimate how much context they are leaving on the table when they start a coding session or a new conversation with a vague prompt. They type something like "help me add authentication to my app" and then spend the next fifteen exchanges clarifying their tech stack, their existing patterns, their constraints, and their preferences. Each of those clarification rounds costs tokens and eats into the context window, and by the time the model actually understands the task, a significant portion of your available context has been consumed by back-and-forth that could have been front-loaded.
A metaprompt eliminates that ramp-up entirely. Instead of drip-feeding context over a dozen turns, you hand the model a complete picture on the first message. The model's first response is already informed, aligned with your conventions, and working within your constraints. You skip the part where the AI asks what framework you are using, what your file structure looks like, and whether you prefer one approach over another.
This is especially important for coding agents like Claude Code or Codex, which operate in your terminal and can read, edit, and execute files. These tools are powerful, but they start every session cold. A well-crafted metaprompt is the difference between the agent immediately understanding your project architecture and the agent spending its first several actions orienting itself by reading random files.
What belongs in a metaprompt
A good metaprompt is not a brain dump. It is a curated transfer of the context that will actually affect the model's behavior and output quality. There is a meaningful difference between "here is everything about my project" and "here is what you need to know to complete this task well."
Project scope and current state. What are you building? What stage is it at? What was the last thing you were working on? This grounds the model so it does not start suggesting foundational decisions you made months ago.
Tech stack and conventions. Your language, framework, database, deployment target, and any strong opinions about how code should be written. If you use NestJS with a specific module structure, say so. If you prefer nullish coalescing over logical OR for defaults, say so. If you have a pattern for error handling, describe it. The model will default to generic best practices unless you tell it otherwise.
Constraints and boundaries. What should the model not do? This is often more important than what it should do. If you do not want it refactoring unrelated code, restructuring your file tree, or introducing new dependencies without asking, state that explicitly. Models are eager to "help" in ways that can be destructive if they do not understand the boundaries.
The specific task. What do you actually need done right now? Be precise. "Add Stripe webhook handling for subscription events, using the existing event bus pattern in src/events" is a metaprompt-quality task description. "Help me with payments" is not.
Behavioral instructions. How do you want the model to work? Should it ask before making changes? Should it write tests alongside implementation? Should it explain its reasoning or just produce code? These preferences vary by person and by task, and stating them up front prevents friction later.
The editing step
Don't skip this part, because this is what matters most.
When you ask a conversational AI to generate a metaprompt, it will produce something reasonable based on what it knows about you and your project. But "reasonable" is not the same as "correct." The conversational AI is working from platform memory, which as we established in the previous article is a lossy summary of your actual history. It may include details that are outdated, miss constraints that matter for this specific task, or frame the project in a way that no longer reflects your current thinking.
You are the quality gate. Read the generated metaprompt before you send it. Remove anything that is wrong or irrelevant. Add anything that is missing. Adjust the framing if the emphasis is off. This editing step usually takes a couple of minutes, and it is the highest-leverage time you can spend before starting a coding session, because every downstream interaction with the agent will be shaped by what you provide in that opening message.
Skipping this step is how you end up with an agent that confidently builds the wrong thing for twenty minutes before you notice.
When to use a metaprompt
Metaprompts are not necessary for every interaction. If you are asking a quick question, running a one-off script, or doing something simple enough to describe in a sentence, just type your prompt directly. The overhead of generating and editing a metaprompt is not worth it for trivial tasks.
They become valuable when you are starting a non-trivial coding session in a fresh context, switching between tools (from chat to a coding agent, or from one agent to another), working on a project with established conventions that the model would not infer from the codebase alone, or onboarding a new tool into an existing workflow where the defaults will not match your needs.
The general principle: if you would spend more than five minutes answering the model's clarifying questions at the start of a session, you should be using a metaprompt instead.
A practical example
Suppose you are building a SaaS platform with a NestJS backend, a Next.js frontend, and PostgreSQL. You have been discussing the architecture in Claude Chat over the past week, and now you need to implement webhook handling in Claude Code.
Without a metaprompt, you open Claude Code and type: "Add Stripe webhook handling." The agent will look at your codebase, make some inferences, and start building something. It might get the general shape right, but it might also introduce patterns that conflict with your existing architecture, miss your error handling conventions, or put files in the wrong place.
With a metaprompt, you first ask Claude Chat: "Generate a metaprompt for Claude Code. I need to implement Stripe webhook handling for subscription lifecycle events. Include our tech stack, the event bus pattern we discussed, the error handling approach, and the testing requirements." Claude Chat produces a structured prompt based on your conversation history and platform memory. You review it, fix any inaccuracies, add the specific Stripe events you care about, and paste it into Claude Code.
The agent's first action is already aligned with your architecture. You skip the clarification phase entirely and go straight to implementation.
Metaprompts and context files
If you are using a tool that supports persistent context files (CLAUDE.md in Claude Code, or AGENTS.md in Codex), you might wonder whether metaprompts are redundant. They are not, but they serve different purposes.
Context files are persistent, project-level documentation that the agent reads at the start of every session. They contain information that is always relevant: your tech stack, your coding conventions, your file structure, your preferences, etc. They are the equivalent of an employee handbook.
Metaprompts are task-specific and ephemeral. They contain the context needed for this particular session: what you are building right now, what decisions have been made, what constraints apply to this specific piece of work. They are the equivalent of a project brief.
The best workflow uses both. The context file handles the baseline ("this is a TypeScript monorepo with these patterns"), and the metaprompt handles the specifics ("today we are implementing this feature, with these constraints, building on these decisions from earlier conversations").
The underlying principle
Every technique in this article reduces to the same insight from our piece on AI memory: LLMs are stateless functions, and the quality of their output is directly proportional to the quality of their input context. A metaprompt is just a disciplined way of making sure that input context is as complete and accurate as possible, even when you are working across multiple tools that share no state with each other.
The people who get the most out of AI tools are the ones who invest a few minutes at the start of each session making sure the model has what it needs to do the job right on the first pass.