# Example Task Chains

Five ready-to-run chains for testing your orchestrator. Each chain has a name, a sample input, 2–4 sequential prompts, and a defined output schema per step.

Use these to validate that your system can:
- Chain actual task output into the next prompt (not just the original user input)
- Validate output against a schema before proceeding
- Block downstream tasks when an upstream task fails
- Retry with a diagnostic message when a schema check fails

---

## How to Read These

Each step shows:
- **Prompt** — what gets sent to the LLM. `{{input.X}}` refers to the user-provided input at queue submission. `{{task_N.output}}` refers to the actual stored output of a previous task.
- **Output Schema** — what the response must conform to before the next step runs.
- **Why it's here** — what this step is specifically testing in your orchestrator.

---

## Chain 1 — Research Pipeline

**Use case:** A researcher pastes in a dense article or report and wants structured insight extracted across multiple passes.  
**Tests:** Basic sequential chaining, array validation, confidence fields.

**Sample Input (`input.text`):**
```
Recent studies suggest that remote work increases individual productivity by up to 13%, 
though team cohesion metrics decline after 6 months. A 2023 survey of 1,200 companies 
found that 67% plan to maintain hybrid models indefinitely. Critics argue the productivity 
gains are overstated and primarily reflect reduced commute time rather than actual 
output improvements. Some organisations report a 20% increase in output, while others 
note no statistically significant change.
```

---

### Step 1 — Extract Key Claims

**Prompt:**
```
Read the following text carefully and extract every factual claim the author makes.
A claim is any statement presented as fact, including statistics, findings, and assertions.

TEXT:
{{input.text}}

Return your response as a JSON array. Each element must have:
- "claim": the claim in your own words (string)
- "confidence": how confident you are this is a genuine claim in the text, from 0.0 to 1.0 (number)
- "source_quote": the exact phrase from the text this claim is based on (string)
```

**Output Schema:**
```json
{
  "type": "array",
  "minItems": 1,
  "items": {
    "type": "object",
    "required": ["claim", "confidence", "source_quote"],
    "properties": {
      "claim": { "type": "string" },
      "confidence": { "type": "number", "minimum": 0, "maximum": 1 },
      "source_quote": { "type": "string" }
    }
  }
}
```

---

### Step 2 — Identify Conflicts and Weaknesses

**Prompt:**
```
You are reviewing a list of claims extracted from a document.
Your job is to identify: (a) claims that directly contradict each other, and (b) claims that appear unsupported or vague.

CLAIMS:
{{task_1.output}}

Return a JSON object with two keys:
- "conflicts": an array of pairs of conflicting claims with a reason
- "unsupported": an array of claim strings that lack sufficient grounding
```

**Output Schema:**
```json
{
  "type": "object",
  "required": ["conflicts", "unsupported"],
  "properties": {
    "conflicts": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["claim_a", "claim_b", "reason"],
        "properties": {
          "claim_a": { "type": "string" },
          "claim_b": { "type": "string" },
          "reason": { "type": "string" }
        }
      }
    },
    "unsupported": {
      "type": "array",
      "items": { "type": "string" }
    }
  }
}
```

---

### Step 3 — Produce Final Summary

**Prompt:**
```
You have been given the original claims from a document and an analysis of which claims conflict or are unsupported.
Produce a final structured summary a reader can trust.

CLAIMS:
{{task_1.output}}

CONFLICT AND WEAKNESS ANALYSIS:
{{task_2.output}}

Return a JSON object with:
- "summary": a 2–3 sentence plain-English summary of what the document reliably establishes (string)
- "reliable_claims": an array of the claims that appear well-supported (strings)
- "contested_areas": an array of topics where the document's evidence is weak or conflicted (strings)
- "confidence_overall": your overall confidence in the document's findings, from 0.0 to 1.0 (number)
```

**Output Schema:**
```json
{
  "type": "object",
  "required": ["summary", "reliable_claims", "contested_areas", "confidence_overall"],
  "properties": {
    "summary": { "type": "string", "minLength": 50 },
    "reliable_claims": { "type": "array", "minItems": 1, "items": { "type": "string" } },
    "contested_areas": { "type": "array", "items": { "type": "string" } },
    "confidence_overall": { "type": "number", "minimum": 0, "maximum": 1 }
  }
}
```

---

## Chain 2 — Bug Report Triage

**Use case:** A developer pastes a raw bug report and the system classifies it, hypothesises root causes, and generates a structured ticket.  
**Tests:** Strict enum validation (good for triggering retries), code-adjacent input, strict required fields.  
**Retry stress test:** Step 1's `severity` field is an enum — the LLM occasionally returns `"medium"` instead of `"MEDIUM"`. Your retry logic should catch this and include the specific validation failure in the correction prompt.

**Sample Input (`input.text`):**
```
When I click "Export to CSV" on a filtered dataset of more than 500 rows, the page 
freezes for about 10 seconds then shows a blank file download. It works fine with 
fewer than 100 rows. I'm on Chrome 124, Windows 11. The error console shows: 
"Uncaught TypeError: Cannot read properties of undefined (reading 'map')" 
at exportUtils.js line 47. This started happening after last Thursday's deploy.
```

---

### Step 1 — Classify the Bug Report

**Prompt:**
```
You are a senior software engineer triaging a bug report. Read the report carefully and classify it.

BUG REPORT:
{{input.text}}

Return a JSON object with:
- "title": a concise bug title, under 10 words (string)
- "severity": exactly one of: "CRITICAL", "HIGH", "MEDIUM", "LOW" — uppercase, no other values (string)
- "component": the likely component or system area affected (string)
- "error_type": the category of error, e.g. "null reference", "performance", "data corruption" (string)
- "reproducible": whether the bug appears consistently reproducible based on the report (boolean)
- "environment": any environment details mentioned (string or null)
```

**Output Schema:**
```json
{
  "type": "object",
  "required": ["title", "severity", "component", "error_type", "reproducible"],
  "properties": {
    "title": { "type": "string", "maxLength": 80 },
    "severity": { "type": "string", "enum": ["CRITICAL", "HIGH", "MEDIUM", "LOW"] },
    "component": { "type": "string" },
    "error_type": { "type": "string" },
    "reproducible": { "type": "boolean" },
    "environment": { "type": ["string", "null"] }
  }
}
```

---

### Step 2 — Hypothesise Root Causes

**Prompt:**
```
You are reviewing a classified bug report. Generate plausible root cause hypotheses ranked by likelihood.

CLASSIFICATION:
{{task_1.output}}

ORIGINAL REPORT:
{{input.text}}

Return a JSON array of hypotheses. Each hypothesis must have:
- "hypothesis": a specific, technical description of what might be causing this bug (string)
- "likelihood": "HIGH", "MEDIUM", or "LOW" (string)
- "evidence": which part of the bug report supports this hypothesis (string)
- "investigation_step": one concrete thing a developer should check to confirm or rule out this hypothesis (string)
```

**Output Schema:**
```json
{
  "type": "array",
  "minItems": 2,
  "maxItems": 5,
  "items": {
    "type": "object",
    "required": ["hypothesis", "likelihood", "evidence", "investigation_step"],
    "properties": {
      "hypothesis": { "type": "string" },
      "likelihood": { "type": "string", "enum": ["HIGH", "MEDIUM", "LOW"] },
      "evidence": { "type": "string" },
      "investigation_step": { "type": "string" }
    }
  }
}
```

---

### Step 3 — Generate Structured Ticket

**Prompt:**
```
You are creating a structured engineering ticket from a triaged bug report and its root cause analysis.

CLASSIFICATION:
{{task_1.output}}

ROOT CAUSE HYPOTHESES:
{{task_2.output}}

ORIGINAL REPORT:
{{input.text}}

Return a JSON object representing a complete ticket:
- "title": the bug title from classification (string)
- "severity": the severity from classification (string)
- "description": a clean 2–3 sentence description of the bug suitable for an engineering ticket (string)
- "steps_to_reproduce": an ordered array of steps that should reproduce the issue (array of strings)
- "expected_behaviour": what should happen (string)
- "actual_behaviour": what actually happens (string)
- "suggested_investigations": the top 2 investigation steps from root cause analysis (array of strings)
- "labels": an array of relevant labels for this ticket, e.g. ["frontend", "data-export", "regression"] (array of strings)
```

**Output Schema:**
```json
{
  "type": "object",
  "required": ["title", "severity", "description", "steps_to_reproduce", "expected_behaviour", "actual_behaviour", "suggested_investigations", "labels"],
  "properties": {
    "title": { "type": "string" },
    "severity": { "type": "string" },
    "description": { "type": "string", "minLength": 50 },
    "steps_to_reproduce": { "type": "array", "minItems": 1, "items": { "type": "string" } },
    "expected_behaviour": { "type": "string" },
    "actual_behaviour": { "type": "string" },
    "suggested_investigations": { "type": "array", "minItems": 1, "items": { "type": "string" } },
    "labels": { "type": "array", "minItems": 1, "items": { "type": "string" } }
  }
}
```

---

## Chain 3 — Meeting Notes → Action Plan

**Use case:** A team pastes raw meeting notes and the system extracts actions, prioritises them, groups them by owner, and drafts a follow-up message.  
**Tests:** Longest chain (4 steps), output passed across multiple hops, string output in final step (not just JSON).

**Sample Input (`input.text`):**
```
Weekly sync - Tuesday 14th
Attendees: Sarah (PM), Dev (engineering lead), Priya (design), Tom (marketing)

Sarah: We need to ship the onboarding redesign by end of month. Priya, can you get the 
final screens to Dev by Thursday? Priya said yes but flagged she still needs copy from Tom.
Tom said he'll have draft copy ready by Wednesday EOD.

Dev flagged that the API rate limiting fix is blocking two other features. He needs sign-off 
from Sarah to increase the third-party API quota spend. Sarah to check budget and respond by tomorrow.

Tom raised that the launch blog post needs a technical section. Dev agreed to write a 
250-word technical summary by Friday.

Next sync same time next week. Sarah to send invite.
```

---

### Step 1 — Extract Decisions and Action Items

**Prompt:**
```
Read the following meeting notes. Extract every action item and decision made.
An action item has a responsible person and a deliverable. A decision is a conclusion the group reached.

MEETING NOTES:
{{input.text}}

Return a JSON object with:
- "action_items": array of objects, each with "owner" (string), "action" (string), "deadline" (string or null)
- "decisions": array of decision strings
```

**Output Schema:**
```json
{
  "type": "object",
  "required": ["action_items", "decisions"],
  "properties": {
    "action_items": {
      "type": "array",
      "minItems": 1,
      "items": {
        "type": "object",
        "required": ["owner", "action"],
        "properties": {
          "owner": { "type": "string" },
          "action": { "type": "string" },
          "deadline": { "type": ["string", "null"] }
        }
      }
    },
    "decisions": {
      "type": "array",
      "items": { "type": "string" }
    }
  }
}
```

---

### Step 2 — Assign Priority

**Prompt:**
```
You are reviewing a list of action items extracted from a meeting.
Assign a priority to each based on urgency (deadline proximity) and impact (how many other items depend on it).

ACTION ITEMS:
{{task_1.output}}

Return the same action items array with an added "priority" field on each item.
Priority must be exactly one of: "P1", "P2", "P3".
Also add a "priority_reason" field explaining the assignment in one sentence.
```

**Output Schema:**
```json
{
  "type": "array",
  "minItems": 1,
  "items": {
    "type": "object",
    "required": ["owner", "action", "priority", "priority_reason"],
    "properties": {
      "owner": { "type": "string" },
      "action": { "type": "string" },
      "deadline": { "type": ["string", "null"] },
      "priority": { "type": "string", "enum": ["P1", "P2", "P3"] },
      "priority_reason": { "type": "string" }
    }
  }
}
```

---

### Step 3 — Group by Owner

**Prompt:**
```
You have a prioritised list of action items. Reorganise them grouped by owner.

PRIORITISED ACTION ITEMS:
{{task_2.output}}

Return a JSON object where each key is an owner's name and the value is an array of their action items (preserving all fields).
```

**Output Schema:**
```json
{
  "type": "object",
  "minProperties": 1,
  "additionalProperties": {
    "type": "array",
    "items": {
      "type": "object",
      "required": ["action", "priority"],
      "properties": {
        "action": { "type": "string" },
        "priority": { "type": "string" },
        "deadline": { "type": ["string", "null"] },
        "priority_reason": { "type": "string" }
      }
    }
  }
}
```

---

### Step 4 — Draft Follow-Up Message

**Prompt:**
```
You are drafting a post-meeting follow-up message to send to the team.
Use the grouped action items to address each person directly with their specific tasks.
The tone should be professional but direct — this is an internal team message, not a formal document.

GROUPED ACTION ITEMS BY OWNER:
{{task_3.output}}

DECISIONS MADE IN THE MEETING:
{{task_1.output.decisions}}

Return a JSON object with:
- "subject": a short email subject line (string)
- "body": the full message body as a plain text string, using line breaks for readability
```

**Output Schema:**
```json
{
  "type": "object",
  "required": ["subject", "body"],
  "properties": {
    "subject": { "type": "string", "maxLength": 100 },
    "body": { "type": "string", "minLength": 100 }
  }
}
```

---

## Chain 4 — Competitive Feature Analysis

**Use case:** A product manager pastes two product descriptions and the system extracts features from each, then produces a structured comparison.  
**Tests:** Multiple inputs, merging outputs from independent earlier steps into a single downstream prompt, object comparison schemas.

**Sample Input:**
```
input.product_a:
Notion is an all-in-one workspace that combines notes, databases, kanban boards, 
wikis, and calendars. It supports real-time collaboration, rich media embedding, 
and a flexible block-based editor. Teams can build custom workflows using linked 
databases and formula fields. It has an API for integrations and supports 
automations via Zapier and Make.

input.product_b:
Confluence is a team wiki and knowledge management tool built for enterprise teams. 
It integrates natively with Jira, Trello, and the Atlassian suite. Pages support 
templates, inline comments, and structured spaces for organising content by team 
or project. It offers robust admin controls, SSO support, and audit logs for 
compliance use cases.
```

---

### Step 1 — Extract Features from Product A

**Prompt:**
```
Read the following product description and extract a structured list of features.

PRODUCT DESCRIPTION:
{{input.product_a}}

Return a JSON array of feature objects, each with:
- "feature": the feature name (string)
- "category": a category label, e.g. "collaboration", "integration", "content", "admin" (string)
- "description": one sentence describing the feature (string)
```

**Output Schema:**
```json
{
  "type": "array",
  "minItems": 2,
  "items": {
    "type": "object",
    "required": ["feature", "category", "description"],
    "properties": {
      "feature": { "type": "string" },
      "category": { "type": "string" },
      "description": { "type": "string" }
    }
  }
}
```

---

### Step 2 — Extract Features from Product B

**Prompt:**
```
Read the following product description and extract a structured list of features.

PRODUCT DESCRIPTION:
{{input.product_b}}

Return a JSON array of feature objects, each with:
- "feature": the feature name (string)
- "category": a category label, e.g. "collaboration", "integration", "content", "admin" (string)
- "description": one sentence describing the feature (string)
```

*(Same output schema as Step 1)*

> **Orchestrator note:** Steps 1 and 2 have no dependency on each other and can be run in parallel. This is a good test of whether your queue supports optional parallelism for independent tasks.

---

### Step 3 — Produce Structured Comparison

**Prompt:**
```
You have extracted feature lists for two competing products.
Produce a structured competitive comparison.

PRODUCT A FEATURES:
{{task_1.output}}

PRODUCT B FEATURES:
{{task_2.output}}

Return a JSON object with:
- "shared_capabilities": features both products have in some form (array of strings)
- "product_a_only": features present in Product A but not Product B (array of strings)
- "product_b_only": features present in Product B but not Product A (array of strings)
- "product_a_strengths": top 2–3 areas where Product A is clearly stronger (array of strings)
- "product_b_strengths": top 2–3 areas where Product B is clearly stronger (array of strings)
- "recommendation": given no stated use case, which product appears more general-purpose and why (string)
```

**Output Schema:**
```json
{
  "type": "object",
  "required": ["shared_capabilities", "product_a_only", "product_b_only", "product_a_strengths", "product_b_strengths", "recommendation"],
  "properties": {
    "shared_capabilities": { "type": "array", "items": { "type": "string" } },
    "product_a_only": { "type": "array", "items": { "type": "string" } },
    "product_b_only": { "type": "array", "items": { "type": "string" } },
    "product_a_strengths": { "type": "array", "minItems": 1, "items": { "type": "string" } },
    "product_b_strengths": { "type": "array", "minItems": 1, "items": { "type": "string" } },
    "recommendation": { "type": "string", "minLength": 30 }
  }
}
```

---

## Chain 5 — Code Explainer and Documentation Generator

**Use case:** A developer pastes a function or module and the system explains it, identifies risks, and generates structured documentation.  
**Tests:** Code as input, multi-section documentation output, cross-step context passing with technical content.

**Sample Input (`input.code`):**
```python
def process_batch(items, handler, max_retries=3, delay=1.0):
    results = []
    failed = []
    
    for item in items:
        attempt = 0
        success = False
        while attempt < max_retries and not success:
            try:
                result = handler(item)
                results.append({"item": item, "result": result, "attempts": attempt + 1})
                success = True
            except Exception as e:
                attempt += 1
                if attempt < max_retries:
                    time.sleep(delay * attempt)
                else:
                    failed.append({"item": item, "error": str(e), "attempts": attempt})
    
    return {"results": results, "failed": failed, "success_rate": len(results) / len(items)}
```

---

### Step 1 — Explain the Code

**Prompt:**
```
Read the following code and explain what it does in plain English.
Focus on behaviour, not line-by-line description.

CODE:
{{input.code}}

Return a JSON object with:
- "summary": a 2–3 sentence plain English explanation of what this code does (string)
- "inputs": an array of the function's parameters with name, type (inferred), and purpose
- "outputs": description of what the function returns (string)
- "key_behaviours": an array of notable behaviours or design decisions worth flagging (array of strings)
```

**Output Schema:**
```json
{
  "type": "object",
  "required": ["summary", "inputs", "outputs", "key_behaviours"],
  "properties": {
    "summary": { "type": "string", "minLength": 50 },
    "inputs": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["name", "purpose"],
        "properties": {
          "name": { "type": "string" },
          "type": { "type": "string" },
          "purpose": { "type": "string" }
        }
      }
    },
    "outputs": { "type": "string" },
    "key_behaviours": { "type": "array", "minItems": 1, "items": { "type": "string" } }
  }
}
```

---

### Step 2 — Identify Risks and Edge Cases

**Prompt:**
```
You are reviewing a piece of code for potential issues.

CODE:
{{input.code}}

EXPLANATION OF THE CODE:
{{task_1.output}}

Identify risks, edge cases, and potential failure modes.

Return a JSON array of issues, each with:
- "issue": a short title for the issue (string)
- "severity": "HIGH", "MEDIUM", or "LOW" (string)
- "description": what the issue is and when it would occur (string)
- "suggestion": a specific recommendation to address it (string)
```

**Output Schema:**
```json
{
  "type": "array",
  "minItems": 1,
  "items": {
    "type": "object",
    "required": ["issue", "severity", "description", "suggestion"],
    "properties": {
      "issue": { "type": "string" },
      "severity": { "type": "string", "enum": ["HIGH", "MEDIUM", "LOW"] },
      "description": { "type": "string" },
      "suggestion": { "type": "string" }
    }
  }
}
```

---

### Step 3 — Generate Docstring and README Entry

**Prompt:**
```
You are generating documentation for a function. Use the explanation and risk analysis to write complete, accurate documentation.

CODE:
{{input.code}}

EXPLANATION:
{{task_1.output}}

KNOWN RISKS AND EDGE CASES:
{{task_2.output}}

Return a JSON object with:
- "docstring": a complete Python docstring for this function in Google style format (string)
- "readme_entry": a short markdown-formatted README section documenting this function, including a usage example (string)
- "warnings": any usage warnings that should be prominently highlighted, derived from the risk analysis (array of strings, may be empty)
```

**Output Schema:**
```json
{
  "type": "object",
  "required": ["docstring", "readme_entry", "warnings"],
  "properties": {
    "docstring": { "type": "string", "minLength": 100 },
    "readme_entry": { "type": "string", "minLength": 100 },
    "warnings": { "type": "array", "items": { "type": "string" } }
  }
}
```

---

## Quick Reference: What Each Chain Tests

| Chain | Key Orchestration Feature Tested |
|---|---|
| 1 — Research Pipeline | Clean sequential chaining, confidence scoring, summary synthesis |
| 2 — Bug Report Triage | Enum validation → retry stress test, ticket generation from multi-step context |
| 3 — Meeting Notes | 4-step chain, cross-hop output passing (`task_1.output.decisions` in step 4), string output at the end |
| 4 — Competitive Analysis | Independent parallel steps (1 and 2), merging two outputs into step 3 |
| 5 — Code Documentation | Technical content as input, multi-section output, risk analysis feeding into docs |