Skip to main content
Back to Prompt Library
Build the complete application

Implementation brief

Inspect the original prompt language first, then copy or adapt it once you know how it fits your workflow.

Linked challenge: Build a Service Incident Response Agent

Format
Code-aware
Lines
72
Sections
11
Linked challenge
Build a Service Incident Response Agent

Prompt source

Original prompt text with formatting preserved for inspection.

72 lines
11 sections
No variables
1 code block
## Who Uses It
An on-call engineer investigating service degradation.

## What You Will Build
Build an agent that combines alerts, metrics, logs, and deployment history into an incident timeline. Recommend a recovery plan, request approval, and verify recovery in a local service simulator.

## Inputs
- Alert feed
- Metrics and log records
- Deployment history and runbook

## Workflow
1. Group related alerts into an incident.
2. Build a timeline and compare plausible causes.
3. Present a runbook action for approval.
4. Execute the approved action in the simulator and check recovery.

## Interface
An incident console with evidence links, an approval button, recovery charts, and a downloadable incident report.

## Working Demo
Explain the deployment-linked incident, request rollback approval, simulate recovery, and produce a cited timeline.

## Deliverables
- A working local application with the specified review interface.
- Source code, dependency lockfile, and setup commands.
- A recorded end-to-end demo using the supplied starter data.
- Example outputs, action logs, and automated tests.

## Starter Data
These fictional records are a small development fixture, not a production dataset. Implement the mock services described in the brief.

```json
{
  "request": "Investigate checkout latency.",
  "deployments": [
    {
      "id": "D1",
      "service": "checkout",
      "minute": 5
    }
  ],
  "metrics": [
    {
      "minute": 4,
      "latency_ms": 120
    },
    {
      "minute": 6,
      "latency_ms": 900
    }
  ],
  "logs": [
    {
      "id": "L1",
      "minute": 6,
      "text": "New checkout release exhausts its connection pool."
    }
  ],
  "runbook": {
    "action": "rollback_D1",
    "requires_approval": true,
    "recovery_limit_ms": 200
  },
  "simulator_after_rollback_ms": [
    150,
    140,
    130
  ]
}
```

## Constraints
Use mock service controls. Do not connect production cluster credentials.
Choose an available model that supports your implementation. Record its identifier and version.

## Evaluation
Review the complete application, not only the starter-case answers.
- The timeline references D1 and L1.
- No rollback occurs before approval.
- Recovery is reported only after all three supplied recovery readings pass.
Add one normal case, one incomplete-input case, and one failure-recovery case.

Adaptation plan

Keep the source stable, then change the prompt in a predictable order so the next run is easier to evaluate.

Keep stable

Preserve the source structure until you know which part of the prompt is actually driving the result quality.

Tune next

Change domain facts, examples, and tool context first before you rewrite the instruction scaffold.

Verify after

Validate one failure mode at a time so prompt changes stay attributable instead of getting noisy.