Procedure Decomposition Prompt Template

This prompt is designed for workflow automation and SOP systems. Its job is to take a high-level procedural instruction, such as 'How do I provision a new user in the staging environment?' and decompose it into a sequence of smaller, independently answerable sub-questions. Each sub-question should map to a specific section of your internal documentation, runbook, or knowledge base. Use this prompt when a single retrieval query is insufficient to cover all the steps, conditions, and exceptions in a standard operating procedure. The output includes a completeness check to verify that the generated sub-questions collectively address every stage of the original procedure.

The ideal user is a platform engineer or RAG architect building an internal assistant that must guide employees through multi-step operational workflows. Required context includes the full text of the procedure or a clear description of the workflow, plus any known documentation section titles or taxonomy that the sub-questions should reference. This prompt works best when your knowledge base is already chunked by procedure step, policy section, or runbook entry. If your documentation is unstructured or narrative-heavy, pair this prompt with a retrieval step that surfaces relevant sections before decomposition. The prompt expects a [PROCEDURE] input, an optional [DOCUMENTATION_MAP] listing available sections, and a [CONSTRAINTS] block specifying output format and completeness requirements.

Do not use this prompt for simple factual lookups, single-step instructions, or questions answerable from one document chunk. Avoid it when the procedure is undocumented or when the sub-questions would require reasoning beyond retrieval, such as generating novel troubleshooting steps not present in the knowledge base. For high-risk operational procedures such as security incident response, access control changes, or financial operations, always route the generated sub-questions through a human review step before execution. The decomposition itself is not the action; it is the plan that must be verified. If your workflow involves chained dependencies where one sub-question's answer changes the next question, consider the Multi-Hop Question Splitting Prompt instead. For diagnostic or troubleshooting workflows, the Diagnostic Question Decomposition Prompt provides a structured tree approach better suited to ruling out causes.

This template is designed for workflow automation and SOP systems where a complex 'how-to' instruction must be broken into discrete, independently answerable steps. Each sub-question targets a specific piece of evidence from your documentation, enabling a RAG system or agent to gather information stepwise. Use this when a flat retrieval query fails to capture the sequential dependencies of a multi-step procedure.

codeCopy
SYSTEM: You are a procedure decomposition engine. Your task is to break a high-level procedural instruction into a sequence of actionable sub-questions. Each sub-question must be independently answerable from a single documentation section. The sequence must cover all critical steps of the original procedure.

INPUT PROCEDURE: [PROCEDURE_TEXT]

AVAILABLE DOCUMENTATION SECTIONS (for context): [DOCUMENTATION_INDEX]

OUTPUT_SCHEMA:
{
  "sub_questions": [
    {
      "id": "string (e.g., 'sq-1')",
      "question": "string (the self-contained sub-question)",
      "target_section": "string (predicted documentation section)",
      "depends_on": ["string (id of prerequisite sub-question, or empty)"],
      "expected_evidence_type": "string (e.g., 'step_instruction', 'parameter_value', 'safety_warning')"
    }
  ],
  "completeness_check": {
    "original_steps_identified": ["string (list of steps extracted from the procedure)"],
    "coverage_gaps": ["string (any steps not addressed by sub-questions, or empty)"]
  }
}

CONSTRAINTS:
- Generate only questions that can be answered by the provided documentation sections.
- Preserve the sequential order of the procedure. Mark dependencies explicitly.
- If a step requires a specific parameter or value, the sub-question must ask for it.
- The completeness check must honestly report any gaps.

USER: Decompose the following procedure: [PROCEDURE_TEXT]

To adapt this template, replace [PROCEDURE_TEXT] with the full natural-language instruction you need to decompose. Replace [DOCUMENTATION_INDEX] with a list of available document titles or section headers from your knowledge base; this grounds the decomposition and prevents the model from inventing steps that don't exist in your source material. For high-stakes operational procedures where missing a step could cause failure, add a human review step after decomposition to validate the completeness check before any sub-questions are executed against retrieval.

The Procedure Decomposition Prompt is designed to be called as a single-turn generation step within a larger workflow automation or SOP system. The application layer is responsible for providing the high-level procedure text as [PROCEDURE] and the optional [DOCUMENTATION_INDEX] (a list of available document titles or section headings). The model's output is a structured JSON array of sub-questions, each with a target_document field. The application should not present these sub-questions directly to an end user; instead, it should use them as retrieval queries against the specified documents in a RAG pipeline or as sequential steps for an agent to execute.

After receiving the model's JSON output, the harness must validate the structure before proceeding. Check that the output is valid JSON, that it contains a sub_questions array, and that each element has the required fields: step_number (integer), sub_question (string), target_document (string), and expected_evidence (string). If the [DOCUMENTATION_INDEX] was provided, validate that every target_document value matches an entry in the index; flag any hallucinated document names for human review or automatic retry. Implement a completeness check by prompting the model a second time with the original procedure and the generated sub-questions, asking it to confirm whether all procedural steps are covered. If coverage is below a threshold (e.g., 90%), trigger a retry with a more explicit instruction to ensure no steps are missed.

For production deployment, choose a model with strong JSON mode and instruction-following capabilities. Set temperature to 0 or a very low value (0.1) to maximize deterministic, structured output. Implement a retry loop with up to 3 attempts if JSON parsing fails or if the completeness check fails. Log every decomposition request, the raw output, validation errors, and the final accepted sub-question set for auditability. In high-stakes environments such as healthcare or industrial procedures, always route the final decomposition to a human reviewer before any automated execution begins. Avoid using this prompt for safety-critical procedures where a missed step could cause harm without mandatory human-in-the-loop approval.