Generating Workflow Decomposition Meta Prompts
YAML--- name: generating-workflow-decomposition-meta-prompts description: Generates layered meta-prompts that instruct an LLM to decompose complex workflows into atomic tasks, compile modular prompt libraries, and produce extraction pipelines from raw source documents. Use when asked to build atomic task specifications, YAML prompt brick libraries, workflow decomposers, SOP extraction packs, or master toolkits that unify multiple prompt-engineering layers into one system. --- # Generating Workflow Decomposition Meta-Prompts
When a user presents a multi-layered system (e.g., "atomic tasks," "workflow inventories," "prompt libraries," "extraction sources") and asks for meta-prompts to generate deliverables, produce one self-contained meta-prompt per deliverable, each in its own code block, following this canonical skeleton:
[SYSTEM / META-PROMPT: <DELIVERABLE NAME>]
ROLE: <Hyper-specific expert persona with named specializations>
OBJECTIVE: <One-paragraph statement of exactly what artifact will be produced,
naming every sub-item (all 10 tasks, all 5 phases, etc.) explicitly>
<DOMAIN-SPECIFIC RULES / CRITERIA>
(numbered, testable, unambiguous — e.g., atomicity rules, YAML variable syntax,
prompt anatomy stages)
EXECUTION INSTRUCTIONS or DELIVERABLE SPECIFICATION:
<exact output structure, with literal headings/schema the target LLM must fill in>
CONSTRAINTS:
<negative constraints: no preamble, no placeholders, no conversational padding,
no partial/truncated output>
Never write the deliverable itself — write the prompt that generates the deliverable.
Progress:
- Step 1: Identify each requested deliverable (A, B, C... or named items)
- Step 2: For each, define the expert ROLE with 2-3 named specializations
- Step 3: Write OBJECTIVE naming every concrete sub-item to be covered (no vague "etc.")
- Step 4: Encode domain rules as falsifiable criteria (atomicity tests, schema rules, anatomy stages)
- Step 5: Specify exact output structure — literal markdown/YAML/JSON skeleton with placeholder syntax defined
- Step 6: Add hard constraints banning preambles, placeholders, truncation, and meta-commentary
- Step 7: Wrap each meta-prompt in its own plaintext code block, labeled distinctly
- Step 8: If a "merge/master" deliverable is requested, write it as an orchestrator meta-prompt that references the outputs of the others by name
- Name every sub-item explicitly in the OBJECTIVE. "All 10 tasks" is weak; list them by verb-first identifier. This prevents the target LLM from truncating or summarizing.
- Give the acid test, not just a description. For atomicity, decomposition, or extraction rules, phrase criteria as a checklist the LLM can self-verify against (e.g., "no conjunction 'and' in the task definition," "exactly one input type maps to one output type").
- Force literal schema skeletons. For YAML/JSON deliverables, embed the actual skeleton (with comments marking what goes where) inside the meta-prompt so structure is non-negotiable.
- Separate cognitive tasks from system actions. Any decomposer meta-prompt must explicitly instruct stripping API calls, uploads, notifications, and navigation into an "Orchestrator Actions" bucket — this is the single most common failure mode in workflow decomposition.
- Standardize variable syntax once, reuse everywhere. Pick one convention
(e.g.,
${variable_name}and${variable_name:default}) and repeat it verbatim across every meta-prompt that touches templating. - End every meta-prompt with hard constraints, minimum:
- No conversational preamble/postamble
- No placeholders like
# TODOor[Insert here] - No truncation — full non-abbreviated output required
- Pure technical/structured output only
- For a "master toolkit" or "merge" deliverable, write it as a meta-prompt whose job is to consume the outputs of the other meta-prompts and unify them — reference them by letter/name rather than re-deriving their content.
Example 1:
Input: "Write a meta-prompt that generates an atomic task spec sheet for these 10 tasks: [list]"
Output: A [SYSTEM / META-PROMPT: ATOMIC TASK SPEC COMPILER] block with ROLE (Principal AI
Systems Architect), OBJECTIVE listing all 10 verb-first task names, ATOMICITY ENFORCEMENT RULES
(single I/O type, zero branching, isolated testability, verb-first naming), a DELIVERABLE
SPECIFICATION with exact headings (Task Label, Functional Scope, Input/Output Schema, Edge Cases,
Failure Flags, Test Vector), and CONSTRAINTS banning preamble.
Example 2:
Input: "I need a meta-prompt that turns any workflow into atomic tasks."
Output: A [SYSTEM / META-PROMPT: WORKFLOW-TO-ATOMIC-TASK DECOMPOSER] block with an "Atomicity
Acid Test" (5 numbered falsifiable criteria), EXECUTION INSTRUCTIONS (analyze objective → split
system vs cognitive actions → inventory sub-transformations → audit → compile), and an OUTPUT
STRUCTURE section with literal markdown headings including a Mermaid diagram requirement for data
flow.
Example 3:
Input: "Combine everything into one master meta-prompt."
Output: A [SYSTEM / META-PROMPT: MASTER TOOLKIT COMPILER] block whose OBJECTIVE explicitly states
it ingests the outputs of the prior meta-prompts (named A–E) and unifies them into one indexed
playbook with consistent schemas, deduplicated prompts, and working cross-references — written as
an orchestration/merge instruction, not a restatement of the earlier content.
- Vague objectives. Writing "decompose the workflow into tasks" instead of naming exact task identifiers or listing all N items — invites incomplete or truncated output.
- Missing the system/cognitive split. Forgetting to strip API calls, file writes, and notifications out of "atomic tasks" causes hybrid tasks that violate single-responsibility.
- Undefined variable syntax. Leaving template variables unspecified leads to inconsistent
{var}vs${var}vs<var>usage across generated YAML. - Allowing placeholders. Not explicitly banning
[Insert prompt here]or# TODOlets the target LLM ship lazy, incomplete deliverables. - Conflating the meta-prompt with the deliverable. The meta-prompt must never contain the actual filled-in atomic task specs or YAML content — only the instructions to produce them.
- Omitting verification artifacts. Skipping test vectors / unit-test pairs makes the resulting spec unfalsifiable and hard to integrate into CI.