Plan Step Dependency Validation Prompt Template

This prompt is for workflow engine developers and agent architects who need to verify that a generated plan's execution order is correct before any step runs. It takes a raw plan with step descriptions and available tool definitions, then analyzes the sequence for missing prerequisites, circular dependencies, and opportunities for safe parallelization. The output is a corrected dependency graph with explicit rationale for every edge, suitable for feeding into an execution orchestrator or a human review gate. Use this when the cost of a deadlocked or out-of-order execution is high, such as in multi-tool agent workflows, data pipeline orchestration, or infrastructure provisioning sequences.

The ideal user has already generated a plan—either from a planning model or a template—and has a manifest of available tools with their input/output contracts. The prompt requires three concrete inputs: a list of plan steps with unique identifiers and descriptions, a tool manifest specifying each tool's required inputs and produced outputs, and any known execution constraints such as rate limits or state preconditions. Without these, the dependency analysis will be shallow and may miss critical ordering violations. The prompt is designed to catch structural errors that static plan reviews miss, such as a step that consumes an output from a tool that hasn't executed yet, or a pair of steps that deadlock by waiting on each other's results.

Do not use this prompt when the plan is trivial (fewer than three steps with no shared state), when tool contracts are undocumented or purely side-effect-based, or when you need runtime dynamic scheduling rather than static dependency analysis. This prompt validates the abstract execution graph, not the runtime behavior of individual steps. It will not catch semantic errors where a step uses the right tool but with wrong parameters, nor will it detect that a tool's output format has changed since the manifest was written. For those problems, pair this with a pre-execution completeness review or a postcondition validation prompt. After running this prompt, feed the corrected dependency graph into your execution orchestrator and consider adding a human approval gate if the plan includes irreversible actions or high-cost tool calls.

This prompt template is designed to be pasted directly into your planning validation module. It instructs the model to analyze a provided execution plan for dependency errors—such as missing prerequisites, circular dependencies, and missed parallelization opportunities—and to output a corrected dependency graph with clear rationale. The placeholders allow you to inject the specific plan data, output format requirements, and operational constraints of your agent framework.

textCopy
You are a plan validation engine. Your task is to analyze the provided execution plan and its steps to detect dependency errors.

INPUT PLAN:
[PLAN_JSON]

CONSTRAINTS:
- Available tools and their schemas: [TOOL_MANIFEST]
- Hard constraints (e.g., max parallel steps, latency budget): [CONSTRAINTS]

ANALYSIS INSTRUCTIONS:
1. Parse the input plan and extract all steps, their declared inputs, and their declared outputs.
2. Identify missing prerequisites: steps that consume an input not produced by any prior step or provided as an initial input.
3. Identify circular dependencies: cycles in the step dependency graph.
4. Identify parallelization opportunities: steps with no mutual dependencies that can be executed concurrently.
5. For each issue found, generate a concise rationale explaining the problem.

OUTPUT SCHEMA:
You must output a single valid JSON object with the following structure:
{
  "plan_id": "string",
  "is_valid": boolean,
  "issues": [
    {
      "type": "missing_prerequisite" | "circular_dependency" | "missed_parallelization",
      "severity": "critical" | "warning",
      "description": "string",
      "affected_steps": ["step_id"],
      "rationale": "string"
    }
  ],
  "corrected_dependency_graph": {
    "steps": [
      {
        "step_id": "string",
        "depends_on": ["step_id"],
        "can_parallelize_with": ["step_id"]
      }
    ]
  }
}

If the plan is valid and has no issues, return an empty issues array and the original dependency graph as the corrected graph.

To adapt this template, replace the square-bracket placeholders with your system's live data. [PLAN_JSON] should be the full, structured representation of the generated plan. [TOOL_MANIFEST] is critical for detecting missing prerequisites; provide the complete list of available functions with their input and output schemas. [CONSTRAINTS] should include any execution environment rules, such as a maximum number of parallel workers. After receiving the output, your harness must validate the JSON structure and check that every affected_steps reference matches a real step ID from the input plan. For high-risk workflows where an invalid plan could cause data loss or unauthorized actions, route any output with is_valid: false to a human review queue before execution begins.

This prompt is not a conversational assistant; it is a deterministic validation gate that should run after a plan is generated but before any step is executed. In a production agent architecture, you will typically call this prompt inside a planning module that produces a structured plan object. The prompt expects that plan as its primary input and returns a corrected dependency graph. The implementation harness must therefore parse the plan, inject it into the prompt template, call the model, and then apply the corrected graph to the execution queue. Treat the output as a machine-readable artifact, not a human summary.

To wire this into an application, start by defining a strict input schema for the plan you will pass to the prompt. The plan should be a JSON object containing at minimum a list of steps, each with a unique step_id, a description, and an optional depends_on array of prerequisite step IDs. Before calling the model, validate that every depends_on reference points to an existing step_id to avoid cascading errors. After receiving the model's response, parse the corrected dependency graph and run a post-validation check: confirm that all step IDs in the original plan appear in the output, that no circular dependencies exist in the corrected graph, and that any steps marked for parallelization do not share a transitive dependency. If the model's output fails these structural checks, retry once with a more constrained prompt that includes the validation error. If it fails again, log the full input, output, and error context for human review and block execution.

For model choice, prefer a model with strong reasoning and structured output capabilities. If your agent framework supports tool calling, you can enforce the output schema by providing a tool definition that matches the expected dependency graph structure. This reduces parsing errors and makes validation failures easier to detect. In high-stakes workflows—such as agents that mutate production infrastructure, financial records, or patient data—always route the corrected dependency graph through a human approval step before execution begins. Log every invocation of this prompt, including the input plan, the raw model output, the parsed graph, and the result of post-validation checks. This audit trail is essential for debugging planning failures and for demonstrating governance to reviewers.