Sub-Task Completion Criteria Definition Prompt Template

This prompt is for agent framework developers and orchestration engineers who need to eliminate ambiguity from sub-task completion. When an orchestrator dispatches work to a specialized agent, it must know exactly when that work is finished, whether the output is acceptable, and what conditions constitute failure. Without explicit criteria, orchestrators hang on ambiguous outputs, accept incomplete results, or escalate unnecessarily—each failure mode compounding across multi-agent pipelines. Use this prompt during the decomposition phase, after tasks are identified but before they are dispatched, to generate measurable criteria, acceptance tests, output assertions, and timeout conditions for every sub-task.

The prompt expects you to provide the sub-task description, the agent's capability contract, the expected output schema, and any domain constraints. It produces a structured completion definition that includes: pass/fail assertions with concrete thresholds, edge-case coverage checks, timeout and retry boundaries, and explicit conditions that trigger escalation rather than retry. For high-risk workflows—such as financial calculations, clinical data extraction, or security-sensitive operations—the generated criteria should include human-review gates and evidence-grounding requirements. Wire the output directly into your orchestrator's validation layer so that no sub-task result is accepted without automated verification against the criteria defined here.

Do not use this prompt for trivial tasks where completion is self-evident (e.g., 'return the current timestamp') or for tasks whose success can only be judged by end-user satisfaction. It is also not a replacement for runtime monitoring—this prompt defines static criteria before execution, not dynamic anomaly detection during execution. After generating criteria, run them through your eval harness to check for ambiguity, missing edge cases, and false-positive/false-negative rates before deploying to production orchestration. If the criteria cannot be expressed as machine-checkable assertions, the sub-task itself likely needs further decomposition.

This prompt template produces measurable done conditions for a single sub-task. It generates acceptance tests, output assertions, timeout conditions, and edge-case checks so that an orchestrator can programmatically determine completion without ambiguity. Use it when you are decomposing a complex request and need each sub-task to carry its own verifiable contract. Do not use this prompt for tasks that require subjective human judgment as the primary completion signal—those workflows need a human-in-the-loop handoff instead.

textCopy
You are a sub-task completion criteria designer for a multi-agent orchestration system. Your job is to define unambiguous, machine-verifiable done conditions for a single sub-task. Return only the structured output described below.

## INPUT
Sub-Task Description: [SUB_TASK_DESCRIPTION]
Sub-Task ID: [SUB_TASK_ID]
Assigned Agent Role: [AGENT_ROLE]
Expected Output Type: [OUTPUT_TYPE]
Parent Task Context: [PARENT_TASK_CONTEXT]
Risk Level: [RISK_LEVEL]

## CONSTRAINTS
- All criteria must be verifiable by an automated validator without human interpretation.
- Include explicit timeout and resource limits.
- Define what constitutes partial success versus complete failure.
- Specify edge cases that must be handled, not ignored.
- For high-risk tasks, include mandatory evidence or citation requirements.
- Output must conform to the schema below exactly.

## OUTPUT_SCHEMA
{
  "sub_task_id": "string",
  "completion_criteria": {
    "required_output_fields": ["field_name"],
    "field_assertions": [
      {
        "field": "field_name",
        "type": "string | number | boolean | array | object",
        "required": true,
        "validation_rule": "description of rule",
        "example_valid_value": "example",
        "example_invalid_value": "example"
      }
    ],
    "quality_thresholds": [
      {
        "metric": "metric_name",
        "minimum": 0.0,
        "maximum": 1.0,
        "description": "what this threshold measures"
      }
    ],
    "acceptance_tests": [
      {
        "test_id": "string",
        "description": "what this test verifies",
        "pass_condition": "condition",
        "fail_condition": "condition"
      }
    ],
    "edge_cases": [
      {
        "case": "description of edge case",
        "expected_behavior": "how the agent must handle it",
        "failure_if_ignored": true
      }
    ],
    "timeout_seconds": 0,
    "max_retries": 0,
    "partial_success_definition": "what constitutes partial success",
    "complete_failure_definition": "what constitutes complete failure"
  },
  "evidence_requirements": [
    {
      "evidence_type": "citation | source_reference | trace_log | output_snapshot",
      "description": "what evidence must accompany the output",
      "mandatory_for_acceptance": true
    }
  ],
  "escalation_triggers": [
    {
      "condition": "condition that triggers escalation",
      "escalation_target": "human_review | supervisor_agent | fallback_workflow",
      "priority": "low | medium | high | critical"
    }
  ]
}

## INSTRUCTIONS
1. Analyze the sub-task description and identify all outputs the agent must produce.
2. For each output field, define a type, a validation rule, and valid/invalid examples.
3. Define at least three acceptance tests that cover the happy path and one failure path.
4. Identify at least two edge cases the agent must handle explicitly.
5. Set timeout and retry limits appropriate to the risk level.
6. Define what partial success looks like so the orchestrator can salvage partial results.
7. Specify evidence requirements—what must the agent attach to prove its work?
8. Define escalation triggers for when the agent cannot meet criteria after retries.
9. Return only valid JSON matching the OUTPUT_SCHEMA. No additional text.

To adapt this template, replace each square-bracket placeholder with concrete values from your task decomposition step. The [SUB_TASK_DESCRIPTION] should come directly from your decomposition prompt output. Set [RISK_LEVEL] to low, medium, high, or critical—this drives timeout, retry, and evidence strictness. For high-risk tasks, always require citation evidence and set mandatory_for_acceptance to true. Wire the output of this prompt into your orchestrator's validation gate so that no sub-task result is accepted until all acceptance_tests pass. If a sub-task produces partial success, use the partial_success_definition to decide whether to salvage results or escalate.

This prompt is designed to be called by an orchestrator after task decomposition but before sub-task dispatch. The orchestrator should invoke it once per sub-task, passing the sub-task description, expected output type, and any domain constraints. The prompt returns structured completion criteria that the orchestrator stores alongside the sub-task contract. These criteria become the acceptance gate that downstream validators use to determine whether a sub-agent's output is complete. Do not call this prompt during live execution of the sub-task itself—it is a planning-phase prompt that runs before work begins.

Wire the prompt into your orchestration pipeline as a synchronous pre-dispatch step. After receiving the criteria JSON, validate that every criterion includes a measurable condition (not vague language like 'good enough'), an acceptance test (a specific check that can be automated), and a timeout or staleness threshold. If the prompt returns criteria with missing fields or unmeasurable conditions, retry once with a stronger constraint instruction. Log the raw criteria output, the validation result, and any retries to your observability layer. For high-risk domains such as healthcare or finance, route criteria that fail validation to a human reviewer before the sub-task is dispatched. The orchestrator should store the validated criteria as part of the sub-task's execution contract so that the completion-checking agent can reference them later.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller models that may collapse criteria into vague bullet points. If you are using a framework like LangGraph, CrewAI, or a custom orchestrator, treat this prompt as a tool call that returns typed JSON. Set a timeout of 10–15 seconds and a max token limit appropriate for your sub-task complexity (typically 500–1000 tokens). The most common production failure is criteria that pass structural validation but are too ambiguous for automated checking—add an eval step that samples criteria and tests whether a human can unambiguously determine pass/fail from the criterion alone. If ambiguity exceeds 20% in your eval set, tighten the prompt's [CONSTRAINTS] block or add few-shot examples of measurable criteria.