Foundations
In the prior essay, I argued that metaprompting creates leverage on prompt construction. A good metaprompt helps turn rough, messy, human intent into a structured assignment that a large language model can actually execute. This essay moves from why to how.
The Prompt Generator metaprompt below is the first prompt in my SIYOM Metaprompt Pack. Its job is not to write the final report, article, dossier, critique, or strategy memo. Its job is to design the prompt that will get the conversation started by guiding the downstream work. In other words, it helps create the assignment before asking the model to do the assignment. The Generic Prompt Generator is useful when a task is vague, underspecified, or needs to be converted into an execution-ready prompt; it is designing the assignment, not doing the assignment.
That distinction matters. Most people do not think in prompt architecture. We think in context-laden fragments: “I need to understand this company,” “help me prepare for this meeting,” “turn these notes into something board-ready,” “pressure-test this argument,” “summarize this long thread,” or “I know what I mean, but I do not know how to ask for it.”
A Prompt Generator metaprompt is useful because it accepts that messy starting point and converts it into a more disciplined structure. It helps the user surface and resolve ambiguity by specifying the role, task, purpose, audience, context, constraints, process, and output expectations before the model begins the substantive work.
What the Prompt Generator Metaprompt Is For
I use a Prompt Generator metaprompt when I know what I want in human terms but have not yet translated that intention into a model-executable assignment. Good output needs structured input.
For example, “research this company” is not a serious assignment. It does not say who is asking, why the research matters, what decision the output should support, what sources should be used, what level of confidence is required, or what the final deliverable should look like. A Prompt Generator metaprompt can take that weak starting point and turn it into something more usable: a company research prompt with identity inputs, requesting-party context, report purpose, source requirements, epistemic constraints, and a defined output contract.
The metaprompt does not remove the human from the loop. The user still needs to read the generated prompt and ask: Does this reflect what I meant? Does it include the right context? Is the scope right? Is the output format useful? Is anything missing? But the metaprompt dramatically reduces the cognitive overhead of building that structure from scratch every time.
The SIYOM Prompt Style: Prompting as Assignment Design
The SIYOM prompt style treats prompts as assignments, not wishes. A weak prompt often assumes the model will infer the user’s knowledge base and intent. A stronger prompt makes the assignment explicit. It says who the model should be for this task, what the user wants, what context matters, what evidence standards apply, what the model should not do, and what the finished output must contain.
That is why the SIYOM house structure is deliberately repetitive in certain places. It includes input blocks, an execution guardrail, task definition, system role, mission, operating principles, process steps, constraints, output contract, final output requirement, and a clear “BEGIN” instruction. The goal is not ornamental structure. The goal is to reduce predictable failure modes: vague answers, wrong audience, invented context, role confusion, missing caveats, unsupported claims, and outputs that are plans rather than deliverables. The SIYOM style does not exist to “make the prompt longer.” It exists to “make the assignment harder to misunderstand.”
Some of this repetition is necessary. Humans carry context in overlapping layers: goal, audience, concern, use case, desired artifact, unstated standard of quality, and implicit constraints. Asking for those things in slightly different ways often surfaces useful information that a single generic “what do you want?” question would miss. Some repetition may also simply be excess scaffolding. These prompts are living tools, not sacred objects. Use what helps, cut what does not, and revise as the models change.
It is also worth noting that some parts of the SIYOM style make more obvious sense in the later creator, validator, and Red Team prompts than they do in the Prompt Generator itself. That is expected. The Prompt Generator is partly a teaching prompt: it has to know the architecture well enough to generate downstream prompts that use the architecture appropriately.
Below is the logic behind each major section.
Prompt Design Inputs: Start With What the Human Knows
The prompt begins with top-loaded input fields. These are the raw materials the metaprompt uses before designing the downstream prompt.
The key fields include the primary objective, downstream prompt type, subject or entity, available identifiers or source materials, desired deliverable, intended audience, citation requirements, and constraints. Good inputs do not need to be polished, but they do need to be concrete enough to give the model traction.
A weak input says: “Research this company.” A better input says: “Create a Deep Research prompt for a private-company report on this startup before I meet the founder. I want to understand potential partnership fit, client potential, and major risks. Use public sources only and cite non-trivial claims.”
That second version gives the metaprompt something to work with.
Optional Inputs: Useful Context Without Overbuilding
Optional inputs include preferred model or runtime environment, geography, time horizon, tone, length, and format. They are optional because they are not necessarily necessary, but if you know the answers, they can make a material difference in the quality of the output.
A prompt designed for a quick standard-chat answer should not look like a prompt designed for a long Deep Research report. A prompt for a board memo should not sound like a classroom explainer. A prompt for current market analysis should handle recency differently from a prompt about a stable historical concept.
The point is proportionality. High-stakes work deserves structure. Lightweight work should not be buried under unnecessary machinery.
Requesting Party Inputs: Who Is Asking Changes What Is Useful
The same facts can imply different next actions depending on who is asking. A health system executive, venture investor, founder, board member, consultant, regulator, or product leader may all ask about the same organization and need different things from the answer. One may care about strategic fit. Another may care about risk. Another may care about partnership potential. Another may care about evidence quality.
The Requesting Party section brings perspective into the prompt. It helps prevent generic analysis by clarifying whose context, goals, constraints, and incentives matter. This is especially important in healthcare, life sciences, policy, strategy, diligence, and relationship-driven work. “Tell me about this company” produces information. “Tell me what this company means for this specific decision, from this specific vantage point” produces utility.
Prompt Purpose Inputs: Why the Work Exists
Purpose is different from topic. The topic might be a company, a person, a policy, a technology, a meeting, or a document. The purpose explains what the work is for. Is the output meant to prepare for a meeting? Support a board discussion? Evaluate a partnership? Produce a publishable essay? Validate a draft? Critique an argument? Design a workflow?
A prompt without purpose often creates just content. A prompt with purpose can create insight.
How Much Do You Actually Need to Input?
Less than the form may suggest. You can run the metaprompt without filling in every input block, Requesting Party field, or Purpose field. The input sections are there to invite useful context, not to create a bureaucratic obstacle. In practice, I recommend scanning the fields and answering whatever is easy, obvious, or already in your head. If you do not know an answer, leave it blank. If you already answered something in a prior field, write “See prior answer.”
The point is not to complete a form perfectly. The point is to surface enough context for the metaprompt to build a better assignment. The more useful context you provide, the more tailored the downstream prompt is likely to be. But the metaprompt should still be able to proceed from rough, incomplete, or even garbled human intent. When essential ambiguity remains, it should ask the minimum necessary clarifying questions rather than force the user through a long interrogation.
Execution Guardrail Instructions: Read Before Acting
Models are eager completers. If the first few lines of a prompt suggest a task, the model may start executing before fully absorbing the rest of the instruction set.
The execution guardrail is a small but important pause. It tells the model not to begin yet, to read the full prompt first, and to ask only the minimum necessary clarifying questions if essential information is missing.
This does not guarantee compliance. But it does give the model an explicit instruction to process the full assignment before acting. In complex prompts, this can matter a lot.
Task Instructions: The One Thing the Model Must Do
The Task section defines the core assignment. For the Prompt Generator, the task is not “help me think about prompting.” It is more precise: design and return a single, consolidated, execution-ready prompt based on the provided inputs. If essential ambiguity remains, ask the minimum necessary clarifying questions instead.
That is the key discipline. The model gets two permitted output paths: ask clarifying questions or produce the complete prompt. It should not drift into commentary, partial advice, or a loose outline. The task section is where execution begins.
System Role Instructions: Who the Model Should Be for This Task
The system role gives the model a functional identity. In the Prompt Generator metaprompt, the model is not asked to be a generic assistant. It is asked to be a prompt generator specializing in high-fidelity, low-hallucination, execution-ready prompts aligned to the SIYOM house standard.
That role matters because different tasks require different behavior. A creator should create. A validator should audit. A Red Team analyst should critique. A prompt generator should design the assignment.
A good role is not theatrical. It is not “you are the world’s greatest expert.” It is a practical alignment device. It tells the model what kind of work it is doing and what standard it should apply.
Mission Instructions: What Success Looks Like
The Task says what to produce. The Mission says what the output must accomplish. For the Prompt Generator, success means more than producing any prompt. The generated prompt should be clear, immediately usable, low-hallucination, appropriately role-separated, context-sensitive, identity-aware where necessary, and aligned to the true downstream objective.
A model can technically satisfy a task while failing the mission. It can generate a prompt that looks polished but omits purpose, blurs creation and validation, ignores source requirements, or produces the wrong kind of deliverable. The Mission section helps prevent that by defining the deeper standard of success.
Operating Principles Instructions: The Behavioral Constitution
Operating Principles are the behavioral rules that govern how the model should perform the task. In the Prompt Generator, they include minimal necessary clarification, no invented inputs, artifact intent, identity sensitivity, context-aware prompt design, execution specificity, house-standard alignment, epistemic discipline, role separation, and runtime fit.
These principles are not generic virtues. Each one is meant to prevent a known failure mode. “Minimal Necessary Clarification” prevents the model from over-interviewing the user. “No Invented Inputs” prevents it from filling gaps with assumptions. “Artifact Intent Is First-Order” prevents it from treating a validation prompt like a creator prompt. “Role Separation” prevents it from collapsing author, validator, and critic into one muddled workflow.
Operating principles are how judgment gets encoded into the workflow. They do not give the model judgment. They make the model’s behavior easier for the human to inspect, correct, reject, and approve.
Process Instructions: The Stepwise Method
The Process section gives the model an order of operations. The Prompt Generator begins with context alignment and true objective. That is deliberate. Before building a downstream prompt, the model needs to interpret what the user is really trying to accomplish, what kind of artifact or action is needed, whether the task is creation, validation, critique, or design, and whether Requesting Party or Purpose materially changes the prompt.
Only after that does it identify blocking ambiguities, select input blocks, define role and mission, build operating principles, build the downstream process, define constraints, and return the final prompt. This sequencing reduces the risk that the model jumps straight to synthesis before understanding the assignment.
Complex work fails when the model answers too soon. A process section slows the work down just enough to improve it.
Constraints & Prohibitions Instructions: What Not To Do
A serious prompt should not only say what the model should do. It should also say what the model must not do. The Prompt Generator prohibits invented facts, identifiers, sources, or user intent. It prohibits overcomplicating simple tasks. It prohibits under-specifying high-stakes tasks. It prohibits merging independent validation or critique roles into creator prompts unless explicitly requested.
This matters because many AI failures are not failures of language. They are failures of boundary. The model produces something fluent, but outside the lane. Constraints and prohibitions define the lane.
Output Contract Instructions: What the Answer Must Look Like
The Output Contract defines the shape of the deliverable. For the Prompt Generator, there are only two acceptable outcomes. If essential ambiguity remains, the model should return a short statement that clarification is required and a numbered list of the minimum necessary clarifying questions. Otherwise, it should return exactly one fully formatted, execution-ready prompt.
That is what makes the output usable. A vague answer can be interesting. A good output contract makes the answer operational.
Final Output Requirement and BEGIN Instructions: Closing the Loop
The final output requirement reinforces what must happen now. It tells the model to either ask the minimum necessary clarifying questions and stop, or produce the complete final prompt. It also prohibits analysis, notes, rationale, or fragments.
The “BEGIN” instruction may seem simple, but it matters. It closes the assignment and tells the model to start under the rules just established. A good prompt should not end by introducing new ambiguity. It should end by removing it.
The Full Prompt Generator Metaprompt
With that architecture in mind, here is the full Prompt Generator metaprompt. I use it when I have a rough objective but want a more disciplined downstream prompt before beginning substantive work.
This is a public-facing version. It includes visual separators that distinguish the sections where the user can provide input from the sections that contain the prompt machinery. It also includes a few generic defaults. Those defaults are not sacred; they are starting points.
It should be adapted, not worshipped. The point is not that this is the final possible form of a metaprompt. The point is that it demonstrates a reusable architecture for turning vague intent into structured work.
PROMPT GENERATOR (LOW-HALLUCINATION, VERIFIABLE)
USER INPUT SECTIONS — FILL IN WHAT YOU CAN
Fill in what is easy and useful. Leave blanks where appropriate. If a prior answer already covers a field, write “See prior answer.”
PROMPT DESIGN INPUT (MANDATORY)
Primary Objective or Question:
Requested Downstream Prompt Type (if known):
Default if left blank:
Unknown.
Allowed values:
– Finished Artifact Production
– Audit / Validation
– Critique / Red Team
– Task / System Design
– Unknown
Subject / Entity / Topic:
Available Identifiers, URLs, Attachments, or Source Materials:
Desired Deliverable:
Default if left blank:
One execution-ready prompt.
Intended Audience:
Default if left blank:
Educated professional audience unless otherwise specified.
Accuracy / Citation Requirements:
Default if left blank:
Do not fabricate facts. Cite non-trivial factual claims where applicable.
Special Constraints or Prohibitions:
Default if left blank:
Ask clarifying questions only if ambiguity would materially impair the result.
OPTIONAL INPUTS
Preferred Model or Runtime Environment:
Default if left blank:
Standard ChatGPT unless Deep Research or another environment is specified.
Examples, not exhaustive:
– ChatGPT
– Deep Research
Geography / Time Horizon:
Preferred Tone / Length / Format:
Default if left blank:
Clear, practical, professional.
REQUESTING PARTY (OPTIONAL BUT STRONGLY ENCOURAGED)
Individual / Organization:
Role / Context:
Relevant Goals or Interests (optional):
PROMPT PURPOSE (OPTIONAL BUT STRONGLY ENCOURAGED)
Primary Use Case:
Specific Objective (optional):
PROMPT INSTRUCTIONS — DO NOT EDIT UNLESS CUSTOMIZING THE PROMPT
EXECUTION GUARDRAIL
Do not generate the final prompt yet.
First read and internalize all instructions below before proceeding.
If essential information is missing, ask the minimum necessary clarifying questions before generating the final prompt.
TASK
Design and return a single, consolidated, execution-ready prompt based on the provided inputs.
The sole output of this task must be either:
– the minimum necessary clarifying questions, if essential ambiguity remains, or
– the finished execution-ready prompt itself.
SYSTEM ROLE
You are a Prompt Generator specializing in high-fidelity, low-hallucination, execution-ready prompts aligned to the SIYOM house standard.
Your work supports:
– finished artifact generation,
– audit and validation workflows,
– critique and red-team workflows,
– and task or system design.
You optimize for clarity, rigor, execution specificity, and prompt usability.
MISSION
Transform the user’s goal into a prompt that:
– is structurally clear and immediately usable,
– minimizes hallucination and unsupported claims,
– preserves appropriate role separation,
– includes context, identity, and purpose handling where relevant,
– matches the true objective of the downstream task,
– and produces the right deliverable rather than a vague or partial substitute.
OPERATING PRINCIPLES
1. Minimal Necessary Clarification
Ask only the minimum number of clarifying questions required to avoid material error.
If the prompt can be produced safely and usefully without more input, do not ask additional questions.
2. No Invented Inputs
Do not invent:
– facts,
– identifiers,
– user goals,
– source materials,
– constraints,
– audience assumptions,
– or output requirements.
If information is missing but non-blocking, leave a placeholder or explicitly frame it as optional.
3. Artifact Intent Is First-Order
Determine whether the downstream prompt is intended to:
– design a task or system,
– produce a finished artifact,
– audit or validate an existing artifact,
– or critique / red-team an existing artifact.
This decision must shape the structure, tone, and constraints of the final prompt.
4. Identity Sensitivity
If the downstream task depends on a uniquely identifiable individual or organization, the final prompt must include a top-loaded identity input block and appropriate identity-handling instructions.
If identity ambiguity would materially degrade output quality, require additional identifiers before generating the final prompt.
5. Context-Aware Prompt Design
If usefulness depends on who will use the downstream artifact and why, include top-loaded sections for:
– REQUESTING PARTY
– PURPOSE
Do not force these sections into prompts where they add no meaningful value.
6. Preserve Execution Specificity
Do not over-abstract.
For high-stakes, structured, or publication-grade tasks, the downstream prompt must include:
– explicit execution steps,
– required sections,
– section-level expectations,
– and clear completion standards.
For lightweight tasks, use the lightest structure that still preserves clarity, accuracy, and execution fidelity.
Do not rely on the downstream model to “know what good looks like.”
7. House-Standard Alignment
Where appropriate, design the downstream prompt using this structure:
– top-loaded input block(s)
– EXECUTION GUARDRAIL
– TASK
– SYSTEM ROLE
– MISSION
– OPERATING PRINCIPLES
– PROCESS
– CONSTRAINTS & PROHIBITIONS
– OUTPUT CONTRACT
– FINAL OUTPUT REQUIREMENT
– specialized fail-soft section if needed
– BEGIN
Use this structure when it improves clarity, control, and execution fidelity.
8. Epistemic Discipline
When the downstream task requires factual rigor, design the prompt to enforce, where appropriate:
– separation of Verified Fact, Inference, and Unknown,
– inference anchoring,
– confidence labeling for inferences, synthesized claims, and uncertain facts,
– no fabricated precision,
– no narrative leaps,
– competing interpretations where ambiguity exists,
– and transparent handling of uncertainty and missing data.
9. Role Separation
Do not collapse creator, validator, and critic roles unless the user explicitly wants a combined prompt.
By default:
– creator prompts create,
– validator prompts audit,
– red-team prompts critique.
10. Runtime Fit
If a target environment is specified, optimize the prompt accordingly.
Examples:
– Deep Research prompts should enforce complete artifact production,
– standard-chat prompts may be lighter,
– audit-only prompts should not generate new content,
– critique prompts should not rewrite the source artifact unless explicitly instructed.
PROCESS
Step 0 – Context Alignment & True Objective
Interpret the user’s real goal, not just their phrasing.
Determine:
– what the downstream prompt is meant to accomplish,
– what kind of artifact or action is actually needed,
– whether the prompt is for creation, validation, critique, or design,
– and whether REQUESTING PARTY or PURPOSE materially affects the prompt design.
Step 1 – Identify Blocking Ambiguities
Determine whether essential ambiguity remains around:
– subject identity,
– deliverable type,
– intended use,
– required source materials,
– or success criteria.
If essential ambiguity exists, ask only the minimum necessary clarifying questions and stop.
Step 2 – Select the Required Input Blocks
Include only the top-loaded input sections actually needed for the downstream task.
Possible blocks include:
– IDENTIFICATION INPUT
– REQUESTING PARTY
– PURPOSE
– SOURCE MATERIALS / PROVIDED INPUTS
– task-specific input sections
Do not add sections mechanically.
Step 3 – Define the Downstream Role and Mission
Create a system role and mission that match the real task.
The role should reflect:
– what kind of work is being done,
– what rigor is required,
– and what counts as success.
Step 4 – Build the Downstream Operating Principles
Include only the principles necessary for the downstream task, but preserve rigor.
For high-stakes artifact-producing prompts, prefer:
– explicit verification rules,
– uncertainty handling,
– epistemic discipline,
– and role separation.
For simpler prompts, remain proportionate.
Step 5 – Build the Downstream Process
Define a stepwise process that is specific enough to constrain execution.
For structured artifacts, include:
– context alignment,
– identity handling where relevant,
– research / analysis steps,
– synthesis steps,
– and self-check steps where appropriate.
Do not use vague instructions where the user needs a reliable deliverable.
Step 6 – Define Constraints and Output Contract
Specify:
– what the downstream system must not do,
– what the final deliverable must include,
– and what “complete” means.
The output contract must be explicit enough that the prompt can be pasted directly into ChatGPT or Deep Research without further rewriting.
Step 7 – Return the Final Prompt
If no essential ambiguity remains, return exactly one fully formatted, execution-ready prompt and nothing else.
CONSTRAINTS & PROHIBITIONS
– Do not return commentary about the prompt unless explicitly requested.
– Do not invent facts, identifiers, sources, or user intent.
– Do not use XML-style output blocks unless explicitly requested.
– Do not overcomplicate simple tasks with unnecessary roles, inputs, or sections.
– Do not under-specify high-stakes or structured tasks.
– Do not merge independent validation or critique roles into creator prompts unless explicitly requested.
– Do not return a partially formed prompt when a complete one can be produced.
OUTPUT CONTRACT
If essential ambiguity remains, return:
1. A short statement that clarification is required
2. A numbered list of the minimum necessary clarifying questions
Otherwise, return exactly one fully formatted, execution-ready prompt that:
– is ready to paste into ChatGPT or Deep Research,
– follows the SIYOM house standard where appropriate,
– includes top-loaded inputs when useful,
– uses clear section headers,
– and is complete enough to run without additional rewriting.
FINAL OUTPUT REQUIREMENT
Either:
– ask the minimum necessary clarifying questions and stop, or
– produce the complete final prompt now.
Do not return analysis, notes, rationale, or prompt fragments.
BEGIN
First determine whether essential clarification is required.
If yes, ask the minimum necessary clarifying questions and stop.
If no, produce the complete execution-ready prompt now.
How I Actually Use This
In practice, I do not begin with perfect inputs. I begin with the same kind of messy human intent everyone else has. I might know that I need to prepare for a meeting, evaluate a company, critique an argument, write a thought piece, clean up a transcript, or consolidate a long thread. I may not yet know the exact structure of the prompt that should govern the work.
So I give the rough intent to the Prompt Generator. It returns a structured downstream prompt. Then I read that prompt carefully. I check the role, purpose, assumptions, constraints, and output contract. If it misunderstood me, I revise it. If it captured the task well, I run it. The metaprompt is not the workflow. It is the front door into a better workflow.
For high-stakes work, the downstream output still needs review. If the prompt produces a company report, I may run a Validator. If it produces an argument, I may run a Red Team critique. If it creates a draft, I may revise manually. The point is not to automate responsibility away. The point is to structure the work so responsibility can be exercised more clearly with appropriate division and specialization of labor: use AI where AI works best, code where code works best, and people where people work best.
Make It Yours
Do not treat this prompt as sacred text. Use it, test it, break it, shorten it, adapt it, and make it work for your own workflows. Nothing about LLMs is carved in stone right now. That is sometimes their greatest strength and sometimes their greatest annoyance. Models change, interfaces change, and techniques that once felt essential may later become unnecessary.
The right posture is not prompt worship. It is disciplined experimentation. If a section helps, keep it. If it creates friction without improving output, modify it. If the model has improved enough that a piece of scaffolding is no longer useful, retire it. The goal is not fidelity to my architecture. The goal is better work.
What This Does Not Solve
A metaprompt does not eliminate hallucination. It does not guarantee that sources are real, current, or correctly interpreted. It does not replace subject-matter expertise. It does not make model output deterministic. It does not remove the need for human review.
Prompts can sound good but miss the real intent. That is why the user must always read the generated prompt before running it.
Why This Matters for Leaders
Organizations do not need a thousand one-off prompts floating around Slack, Teams, Notion, and Google Docs. They need reusable ways to define work, capture context, specify evidence standards, protect human judgment, and review outputs before reliance.
Prompt architecture is a small but important part of AI operating model design. It sits between human intent and machine execution. Done poorly, it creates confusion at scale. Done well, it helps teams move faster without pretending that speed is the same as judgment.
Better Prompts Are Better Workflows
The best prompts are not magic words. They are structured assignments. A Prompt Generator metaprompt helps build those assignments faster, more consistently, and with less cognitive waste. It lets the human start with rough intent and end with something clearer, more explicit, and more executable.
-Marc d. Paradis
About the Author: Marc d. Paradis’ professional journey is a fusion of academic rigor with real-world impact. He began his career over 30 years ago as an academic molecular neurobiologist, instilling in him a deep respect for critical thinking and the scientific method.
Transitioning into industry, he held leadership roles that bridged data and healthcare: as Vice President of Data Strategy at Northwell Health, Marc leveraged one of the world’s most diverse clinical data sets to drive patient-centered innovation via a $100M partnership with Aegis Ventures, launching multiple AI-centered startups; and as Vice President & Dean of Data Science University at Optum, he spearheaded the training of thousands of professionals in practical, product-centric AI, data-driven decision making, and ethical data practices. In each role, he fostered cultures of curiosity, critical thinking, and collaboration – precursors to the Constructive Inquiry ethos.
About SIYOM Consulting: Founded by Marc d. Paradis, SIYOM Consulting is a boutique advisory specializing in Data and AI Strategy for Healthcare and Life Sciences. We help health-system executives, pharma innovators and investors identify, evaluate and execute on high-value data and AI opportunities.
Responsible Use and Disclaimer: This essay and the prompt shared in it are provided for educational and informational purposes only. They are not legal, financial, medical, investment, compliance, or professional advice. No prompt can eliminate hallucination, bias, omission, outdated information, source failure, or user error. Outputs generated with this or any other prompt should be reviewed by a qualified human before being relied upon, published, or used in consequential settings. Models, interfaces, and tools also change. Prompting practices should be treated as living artifacts. Test them, revise them, and retire them when they stop serving the work.