SOP Automation Task Breakdown Prompt

This prompt is designed for workflow automation agents that must ingest a standard operating procedure (SOP) document and produce a machine-readable, executable task list. Use it when you need to bridge the gap between human-written procedural documentation and an autonomous agent execution engine. The ideal user is a platform engineer, operations lead, or agent architect building a supervised autonomy system where the SOP is the source of truth and the output must be auditable. The prompt forces the model to preserve all SOP branches, identify steps that require human judgment, flag decision points, and map each automatable step to a known tool or API.

You should reach for this prompt when the SOP document is stable, well-structured, and represents the canonical procedure. The prompt works best with procedures that contain explicit conditional logic (if-then branches), approval gates, and references to specific systems or tools. It is less effective on vague narrative documents, training guides, or documents that assume significant implicit knowledge. Before using this prompt, you must provide a complete tool manifest so the model can map steps to real capabilities rather than hallucinating tool names. The output is a structured task graph, not a free-text summary, so your application harness must be prepared to parse, validate, and execute the resulting JSON.

Do not use this prompt for real-time incident response where the procedure is being authored on the fly, for documents that are primarily legal or compliance narratives without executable steps, or when the downstream execution environment cannot enforce the human-approval gates the prompt identifies. If your SOP contains steps that are inherently unsafe to automate (physical safety actions, irreversible financial transactions, clinical decisions), you must configure the harness to route those steps to a human review queue regardless of the model's classification. The next section provides the copy-ready prompt template you can adapt with your own SOP content, tool definitions, and risk policies.

This prompt template is the core instruction set you will paste into your agent harness. It is designed to receive a full SOP document and produce a machine-readable task breakdown that an orchestrator can execute. The template uses square-bracket placeholders that you must replace with your specific SOP content, available tool definitions, and the desired output schema before sending it to the model. The quality of the output depends directly on how precisely you define the [TOOLS] and [OUTPUT_SCHEMA] sections.

codeCopy
You are an expert workflow automation analyst. Your task is to convert the provided Standard Operating Procedure (SOP) into a structured, executable task list.

## SOP CONTENT
[SOP_DOCUMENT]

## AVAILABLE TOOLS
You have access to the following tools. Map each automatable step to exactly one tool from this list. Do not invent tools.
[TOOLS]

## OUTPUT FORMAT
Return a single JSON object conforming to this schema:
[OUTPUT_SCHEMA]

## DECOMPOSITION RULES
1. Preserve all branches, conditional logic, and decision points from the SOP.
2. For each step, determine if it is: **automatable**, **requires_human_approval**, or **manual_only**.
3. For automatable steps, assign a specific tool from the `[TOOLS]` list and define the required arguments.
4. For steps requiring human approval, insert an explicit `human_approval_gate` task with review criteria and a timeout action.
5. Flag any step that references a capability not present in the `[TOOLS]` list as `blocked` and explain the missing capability.
6. Maintain the original execution order and dependencies. Identify steps that can run in parallel.

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, start by replacing [SOP_DOCUMENT] with the full text of your procedure. The [TOOLS] placeholder must be replaced with a structured description of your available functions, their parameters, and their side effects—this is the single most important factor in preventing the model from hallucinating unavailable capabilities. The [OUTPUT_SCHEMA] should be a strict JSON schema definition, including required fields like task_id, description, status, assigned_tool, and depends_on. Use the [CONSTRAINTS] block to enforce domain-specific rules, such as "never automate a step that modifies a production database without a human approval gate." The [EXAMPLES] block should contain one or two few-shot examples of a correctly decomposed SOP fragment to anchor the model's behavior. Set [RISK_LEVEL] to high if the SOP involves financial transactions, PII, or irreversible actions; this signals the model to be more conservative with automation decisions. After generating the task list, always validate the output against your schema and check for any blocked steps that require new tool development before the workflow can be fully automated.

This prompt is designed to be the first stage in a multi-step automation pipeline. It takes a raw SOP document as input and produces a structured task list, but the output is not yet executable. The harness must validate the decomposition, bind each subtask to available tools, and insert approval gates before any irreversible action. Treat the prompt output as a plan proposal, not a final execution script.

Implement the harness as a chained workflow: (1) Load the SOP text and inject it into the [SOP_DOCUMENT] placeholder along with the [TOOL_CATALOG] of available automation capabilities. (2) Call the model and parse the JSON output. (3) Run a structural validator that checks for required fields (task_id, description, decision_points, automation_feasibility, tool_mapping, human_approval_required) and rejects malformed records. (4) For each task marked automation_feasibility: true, verify that the tool_mapping references a tool that actually exists in the provided catalog; flag any hallucinated tools. (5) For tasks marked human_approval_required: true, insert a synchronous approval step into the execution graph that pauses the workflow until a human reviewer signs off. (6) Run a branch-coverage check: compare the set of decision points in the output against the original SOP's conditional branches and flag any missing paths. Log all validation failures with the specific task ID and failure reason before proceeding.

Model choice matters here. Use a model with strong structured-output capabilities and a context window large enough to hold the full SOP plus the tool catalog. For SOPs longer than ~8,000 tokens, chunk the document by section, run the prompt on each section independently, then merge the task lists with a deduplication pass. Set temperature=0 or very low to maximize consistency across runs. Implement retry logic: if the JSON parse fails or the validator rejects more than 20% of tasks, retry once with the validation errors injected into the [CONSTRAINTS] field as explicit correction instructions. If the second attempt still fails, escalate to a human operator with the partial output and error log. Never execute a partially validated task list in production.