Task automation with meta-prompts means using one prompt to write, structure and check the prompts that do your recurring work, instead of hand-writing a new prompt every time. You describe the task once (its inputs, steps, rules and what a good result looks like), a meta-prompt turns that into a reusable task prompt with placeholders, and you run that task prompt on each new input, by hand or from a script. The payoff is consistency: the same task gets done the same way every week, and when it goes wrong you fix one template instead of many ad-hoc prompts.
This guide walks through one complete example, from a vague recurring task to a tested, scheduled prompt, with every prompt shown in full. It assumes you know what a basic prompt is; if the concept of meta-prompting is new, the explainer on meta-prompting covers the background.
What “meta-prompt” means in practice
A meta-prompt is a prompt whose output is another prompt, or a plan for a set of prompts. The term is used in two related ways, and it helps to keep them apart.
- Prompt generation. You give a model a task description and it writes a well-structured prompt for that task. OpenAI’s Playground does this with its Generate feature, and OpenAI’s prompt generation guide says the feature is built on meta-prompts that encode prompt-engineering best practices, and publishes their text. This is the sense used for task automation in this article.
- Model-as-conductor. In the research paper Meta-Prompting: Enhancing Language Models with Task-Agnostic Scaffolding, Suzgun and Kalai describe a single model that breaks a problem into subtasks, hands each to a fresh “expert” instance of itself with tailored instructions, and then combines and checks the results. That is closer to an agent architecture than to a reusable template.
For automating your own recurring work, the first sense is the practical one. The second explains why a meta-prompt that splits work into steps with separate instructions tends to beat one giant instruction: each step gets focused instructions and its own check.
The four parts every task prompt needs
A task prompt that can run unattended has four parts, and the meta-prompt’s job is to make sure none is missing.
| Part | What it contains | What breaks without it |
|---|---|---|
| Role and goal | Who the output is for and what decision or action it supports. | The model optimizes for a generic reader; output is correct but not useful. |
| Steps | The ordered sequence of sub-tasks (extract, analyze, write). | Steps get merged or skipped; analysis happens after conclusions are already written. |
| Constraints per step | Rules, formats, length, what to do when data is missing. | Silent guessing, inconsistent formats between runs. |
| Verification | A checklist the output must pass before it is returned. | Errors reach the reader; nobody knows a rule was broken. |
These four parts are what the original version of this article called the pillars of a meta-prompt. They still hold. What has changed is how much of the work you can hand to the model: current models are good at drafting all four parts from a plain description, as long as you supply the facts only you know.
Step 1: describe the task in plain language
The task description is your input to the meta-prompt, and its quality sets the ceiling for everything after it. Write it as you would brief a new colleague. The running example here is invented for illustration: a weekly summary of website analytics for a small marketing team.
Task: Every Monday I export last week's site analytics as CSV (columns: date, page, sessions, avg_engagement_seconds, conversions) and write a short summary for our marketing team's Slack channel.
Readers: 4 marketers. They want to know what changed, why it might have changed, and whether to do anything.
What a good summary has:
- Top-line totals vs the previous week, with % change.
- The 3 pages with the biggest change in sessions (up or down).
- Any page with conversions but falling engagement.
- At most 2 suggested actions, each tied to a number.
Rules I care about:
- Never claim a cause as fact; phrase causes as "possible".
- If the CSV is missing a column or a day, say so at the top.
- Under 200 words. Slack formatting (bold with *asterisks*, no tables).
Things that have gone wrong when I did this by hand:
- Comparing to the wrong week.
- Reporting tiny pages with big % swings (5 sessions to 15 = +200%).The last section is the most valuable and the one people leave out. Past mistakes are exactly the constraints a generic prompt would never think of.
Step 2: the meta-prompt that writes the task prompt
The meta-prompt below turns any task description like the one above into a reusable task prompt. It also makes the model ask questions before writing, because a confident template built on a wrong assumption is worse than no template.
You design reusable prompts for recurring business tasks. The prompt you write will be run every week on new input, sometimes by a script with no human watching, so it must be complete and unambiguous.
<task_description>
[paste the task description]
</task_description>
Phase 1 - Questions.
Before writing anything, list up to 5 questions whose answers would change the prompt (e.g. thresholds, definitions, edge cases). Then stop and wait for my answers.
Phase 2 - Write the task prompt, after I answer. It must contain, in this order:
1. Role and goal: who reads the output and what they use it for.
2. Input section with XML-style placeholders for every variable input, e.g. <csv>{{CSV}}</csv>, <week_start>{{WEEK_START}}</week_start>.
3. Numbered steps. Analysis steps come before writing steps. Each step states its own rules.
4. Rules for missing or malformed input: what to report and whether to continue.
5. Output format, with a short example of the exact shape (not real content).
6. A verification checklist the model must run against its draft before returning it. If any check fails, it fixes the draft; if it cannot, it adds a line starting "CHECK FAILED:" at the top.
Phase 3 - Explain.
After the prompt, give a short list mapping each rule in the prompt to the part of my description it came from. Mark any rule you added that I did not ask for, with the reason.Why the meta-prompt is built this way
- “Run by a script with no human watching” pushes the model toward explicit handling of edge cases instead of conversational hedging.
- The question phase catches the ambiguities you did not notice. For the analytics task, a good answer set includes “What is the minimum sessions for a page to be considered?” and “Is the week Monday-Sunday?”.
- Placeholders in XML-style tags keep variable input clearly separated from instructions, which matters when input is pasted automatically and may contain text that looks like instructions. The guide on delimiter prompting covers why.
- “CHECK FAILED” gives a machine-readable failure signal. A script can look for that string and alert you instead of posting a bad summary.
- The explanation phase lets you audit the generated prompt quickly and spot rules the model invented. Some added rules are good; you should still know they are there.
Step 3: what the generated task prompt looks like
After answering the questions (in this example: ignore pages under 100 sessions in both weeks; weeks run Monday to Sunday; the previous week’s CSV is supplied too), a generated task prompt would look broadly like the following. Your output will differ in wording; what matters is that the structure matches.
You write the weekly analytics summary for a 4-person marketing team. They read it in Slack on Monday morning to decide whether anything needs action this week.
<this_week>{{THIS_WEEK_CSV}}</this_week>
<last_week>{{LAST_WEEK_CSV}}</last_week>
<week_start>{{WEEK_START}}</week_start>
Steps:
1. Validate input. Both CSVs must have columns date, page, sessions, avg_engagement_seconds, conversions, and 7 distinct dates. this_week dates must start on week_start; last_week must be the 7 days before. Record any problem.
2. Compute totals for sessions and conversions in each week and the % change.
3. Exclude pages with fewer than 100 sessions in both weeks. For remaining pages, compute session change. Pick the 3 with the largest absolute change.
4. Find pages with conversions > 0 this week whose avg_engagement_seconds fell more than 20% vs last week.
5. Draft up to 2 actions, each referencing a specific number from steps 2-4.
6. Write the summary.
Output format (Slack, under 200 words):
*Week of {{WEEK_START}}*
[input problems, if any]
*Totals:* ...
*Biggest movers:* ...
*Watch:* ...
*Suggested actions:* ...
Verification - check before returning:
- Every number appears in or is computed from the CSVs.
- No cause is stated as fact (use "possible", "may").
- No page under the 100-session threshold is mentioned.
- Word count under 200.
- The weeks compared match week_start.
If a check fails and cannot be fixed, start the output with "CHECK FAILED: [which check]".Notice that both of the past mistakes from the task description became explicit rules: the week check in step 1 and the session threshold in step 3. That is the meta-prompt doing its job. The 20% engagement threshold in step 4 is the kind of value the model may add on its own; the explanation phase would flag it, and you decide whether to keep it.
Step 4: test the task prompt before trusting it
Testing means running the generated prompt on a small set of inputs whose correct output you already know, including deliberately broken ones. A meta-prompt can write a good template, but nothing guarantees it is correct until you check.
| Test input | Expected behavior |
|---|---|
| A normal week you already summarized by hand | Same totals and movers as your manual version. |
| CSV with one day missing | Problem reported at the top; summary still produced or clearly marked. |
| last_week CSV from the wrong week | Week mismatch reported; no comparison presented as valid. |
| A tiny page jumping from 5 to 40 sessions | Page not listed among movers. |
| A week with no meaningful change | Short summary that says so, no invented actions. |
The last test catches a common habit: models asked for “up to 2 actions” tend to produce two. If yours does, tighten the rule to “only if a number justifies it; otherwise write ‘No action needed'”. Once the prompt passes, keep these inputs as a regression set and rerun them whenever you edit the prompt or switch models; the walkthrough on building a regression test suite with promptfoo shows how to automate that.
One caution about the verification checklist inside the prompt: a model checking its own output catches some errors (word count, forbidden phrasing, a missing section) much more reliably than others (a wrong calculation it already made). For anything numerical, have a script compute the numbers and pass them in, and let the model do the writing.
Step 5: automate the run
Automation means filling the placeholders and calling the model without you in the loop. There are three levels, and most tasks should stay at the lowest one that saves you real time.
- Saved template, manual run. Store the task prompt in a project or custom instructions feature of your chat tool, paste the week’s files and read the output before posting. Most of the consistency benefit, almost no setup.
- No-code workflow. A tool such as Zapier or Make fetches the export, fills the placeholders, calls the model API and posts a draft to a private channel for approval.
- Scheduled script. A small script on a schedule fills the template, calls the API, checks for “CHECK FAILED” and only then posts. The guide to scheduling a recurring Claude API call with cron covers the mechanics.
At levels 2 and 3, keep a human approval step for anything sent to customers or posted publicly, and log every input and output so you can trace a bad result to its cause.
Chaining task prompts into a pipeline
For larger jobs, a meta-prompt can design a chain of task prompts instead of one: for example, analyze sales data, then identify likely root causes for the biggest changes, then write an executive summary from the first two outputs. Add this to the meta-prompt’s Phase 2 when a task has clearly separate stages:
If the task has stages that need different instructions or could be checked separately, write one task prompt per stage instead of one combined prompt. For each stage, state:
- its input (raw data or the named output of an earlier stage),
- its output format, which must be what the next stage expects,
- its own verification checklist.
Then write a one-paragraph run order describing which stage feeds which.Separate stages make failures easier to locate: if the executive summary is wrong, you can see whether the analysis stage or the writing stage introduced the error. This is the same principle behind prompt chaining, with the meta-prompt designing the chain for you.
Where meta-prompt automation goes wrong
- Skipping the question phase. The model fills gaps with plausible defaults, and those defaults become permanent rules in a template that runs every week.
- Trusting self-verification for facts and arithmetic. Self-checks are useful for format and rules. Compute numbers in code, and verify facts against sources.
- Never revisiting the template. Data columns change, team needs change, models get replaced. Keep the prompt in version control or a dated document and rerun the test set after any change.
- Automating a task that is not stable yet. If you still change how you do the task every week, a template locks in this week’s version. Do it by hand with the meta-prompt a few times first.
- Generating a prompt for a task you cannot describe. A meta-prompt amplifies the clarity of your description. If you cannot say what a good result looks like, neither can the generated prompt.
The shift that makes this worthwhile is small but real: you spend your effort describing the task and judging the results, and the repetitive middle runs the same way every time.
