Incident Triage & Root-Cause Prompt Template

Convert logs, stack traces, diffs and metrics into ranked hypotheses, a minimal reproducible checklist, and an immediate fix plan

What You'll Get

Ranked root-cause hypotheses with confidence percentages and evidence mappings to logs/diff/metrics

A prioritized, minimal reproducible checklist with exact commands, request bodies/URLs, env vars and expected failure signals

A prioritized minimal fix plan including file/region targets, estimated patch size, owner role, effort estimate, rollback criteria and risk check

Minimal patch suggestions (pseudo-diff / single-line changes) with one-line rationale and verification command

Automated and manual verification tests (exact commands/test names), success criteria and observability checks

Three immediate next-action tasks (owner, priority, effort, exact commands or dashboard links) suitable for runbooks

How to Use

1Collect the required inputs exactly as listed in the template: code snippets + file paths, error logs/stack traces, recent deploy diff, metrics snapshot, environment matrix, steps already tried, constraints, and repo root/CI context.

2Copy-paste the provided single-block prompt into ChatGPT (or compatible model). Replace only the placeholders with the collected artifacts. Do not modify the prompt structure or ordering.

3Choose the desired output format when pasting (the template supports Markdown output) and execute. If any required input is missing, the assistant will return the minimal exact artifacts or commands needed to continue.

4Use the output sections verbatim in incident tickets, PR descriptions, or runbooksâ€”each item contains exact commands and rollback criteria for immediate action or automation.

Tip â€” Prioritize smallest-change fixes first

When multiple hypotheses have similar confidence, apply the smallest, lowest-risk code or config change first (single-line guards, config toggles, feature flags). The template forces minimal diffs and includes rollback criteria and quick verification commands to validate impact before broader changes.

Works Best With

Use this prompt when you have concrete artifacts from a recent incident or risky PR

Include exact code snippets and file paths (controllers, middleware, DB config) rather than broad descriptions

Attach recent deploy diff or patch hunks that changed behavior

Provide error logs + full stack traces (with file:line) and metrics snapshot (errors/sec, p95 latency, DB connections)

State environment matrix and constraints (hotfix-only, no infra changes) to keep recommendations actionable

Prefer small, reproducible examples (curl commands, test payloads, docker-compose or k8s commands) so the assistant can produce exact repro steps

Prompt Template

# Developer Productivity Prompt Blueprint (use EXACT section order)

## Goal
- Produce an engineering-grade diagnosis from logs, stack traces, recent deploy diff, and metrics that yields: ranked root-cause hypotheses (with confidence %), a prioritized minimal reproducible checklist (exact commands/requests/env/data), and three immediate next-action tasks with owner roles and estimated effort. Deliver a minimal patch plan and verification tests that are safe under given constraints.

## Inputs
- Required inputs:
  - code snippets and relevant file paths
  - error logs and stack traces
  - recent deploy diff (files changed, key hunks)
  - metrics snapshot (errors/sec, latency, throughput, resource signals)
  - environment matrix (OS, runtime, versions, config)
  - steps already tried and their results
  - constraints (e.g., no refactor, hotfix only, rollback allowed)
  - repo context (repo root, CI pipeline, test harness)
- If any required input is missing, the prompt must list the minimal missing artifacts and precise commands/queries or files needed to proceed (no broader discovery).

## Prompt
Paste the following as a single copy-paste prompt into the target assistant. It must be executed verbatim; replace only the placeholders with the provided artifacts.

Inputs provided: programming stack: {{programming_stack}}  
Repo context and entry points: {{repo_context}}  
Error logs and stack traces: {{error_logs}}  
Recent deploy diff (summary or patch): {{recent_diff}}  
Metrics snapshot and alerts: {{metrics_snapshot}}  
Constraints and policies (e.g., no refactor, rollback allowed): {{constraints}}  
Desired output format (choose one: checklist / stepwise-plan / rubric): {{desired_output_format}}

Task: From the inputs above, perform an engineering-grade incident analysis and remediation plan. Output the sections listed in the required Output Format exactly and in the given order. Produce concise, ordered, actionable items only. Prioritize minimal-change fixes that meet the constraints.

Requirements (must produce):
- Assumptions / Unknowns: list anything you could not verify from the inputs, with the exact minimal artifact or command to resolve each unknown.
- Likely root causes: produce a ranked list (highest â†’ lowest) of root-cause hypotheses. For each hypothesis include: short description, confidence percentage, supporting evidence from the provided inputs, and how this hypothesis explains the observed metrics/logs/diff.
- Reproducible checklist (minimal): exact steps to reproduce the failure end-to-end in a dev or staging environment. For each step include precise commands, request payloads/URLs, environment variables or seed data, expected observable failure, and any safety notes.
- Fix plan (prioritized, minimal): a short list of concrete steps to resolve the highest-probability cause first. For each step include the required change, exact files or code region (path + function/hunk), estimated patch size (lines), owner role (e.g., backend-dev, SRE), estimated effort (hours), and rollback criteria.
- Patch suggestions: show minimal diff-like guidance (pseudo-diff or single-line change suggestions) that can be applied as a hotfix or quick test. Do not introduce large refactors. If a code snippet is required, include only the minimal lines to change and a one-line rationale.
- Test / verification checklist: automated and manual tests to validate the fix. For each test include exact commands or test names to run, success criteria, and observability checks to verify no regressions.
- Three immediate next-action tasks: for runbooks/triage. For each task include owner role, priority, estimated effort, and exact command(s) or dashboard link to execute.

Additional instructions:
- Do not assume any files or behavior not present in the provided {{repo_context}} or {{recent_diff}}. If you need to speculate, mark it clearly as speculative and give the minimal evidence required to elevate confidence.
- Prefer the smallest possible code/data changes that address the failure. Avoid scope creep or full refactors unless explicitly permitted in {{constraints}}.
- For each recommended code change include a short risk assessment (low/medium/high) and a short verification step.
- If the inputs are insufficient to produce a reproducible checklist, return the minimal list of artifacts/commands (exact file paths, logs, environment dumps) needed and stop.
- Return the final output in the chosen {{desired_output_format}} while preserving the required section order.

Produce ONLY the structured output (no narrative). Use bullet lists and numbered ordered steps where appropriate.

## Output Format
Output:
  1) Assumptions/Unknowns  
  2) Likely root causes (ranked)  
  3) Fix plan (steps)  
  4) Patch suggestions  
  5) Test/verification checklist

Each item must contain acceptance criteria and a short risk check.

## Guardrails
- Do not assume unseen files or infrastructure. If an inference is required, label it "Speculative" with the exact artifact that would confirm it.
- Prefer minimal diffs; propose single-file or single-function changes before broader ones.
- Avoid solutions that violate {{constraints}}.
- Do not propose database schema changes or major library upgrades unless metrics and diff indicate they are necessary and allowed by {{constraints}}.
- Always include rollback criteria and one quick verification command per proposed change.

## Examples
- Mini root-cause + fix excerpt:
  - Root cause (rank #1): Null pointer when user.profile is missing after recent auth change â€” Confidence 78% â€” Evidence: stack trace shows NPE at UserController.getProfile referencing user.profile; recent_diff included auth token propagation change in auth/middleware.js.  
  - Minimal patch suggestion: In controllers/user.js change "user.profile.id" to "user.profile?.id ?? null" and add an explicit 400 when profile absent. Risk: low. Verification: reproduce by curl POST to /login with token X and run unit test user_profile_absent.

Variables

Usage Notes

Not for

â€¢ Generating full design/architecture documents, major refactors, or schema migrations unless explicitly allowed in constraints

â€¢ Automated production rollouts â€” the template produces human-reviewable hotfixes and runbook steps, not automated destructive commands

â€¢ Legal/compliance advice or remediation that requires policy decisions beyond technical fixes

Do not include

â€¢ Do not include hypothetical infrastructure not present in provided repo_context or recent_diff; the prompt will ask for missing artifacts instead

â€¢ Avoid adding broad refactors or large library upgradesâ€”this template prioritizes minimal, verifiable changes

â€¢ Do not include fabricated metrics, percentages, or case study claims; confidence scores must be tied to provided evidence or marked speculative

Incident Triage & Root-Cause Prompt Template

Produce an engineering-grade, minimally invasive incident diagnosis: ranked root-cause hypotheses (with confidence %), an exact reproducible checklist (commands/requests/env/data), prioritized minimal fix steps, and three immediate triage tasks.

Turn this into a working asset in minutes.

Import into Workspace to auto-fill variables, adapt output style, and iterate with OctiAI's prompt editor.

Auto-fill & personalize from your inputs

AI-assisted edits: tone, structure, constraints

Attach context so outputs stay consistent

Iterate and save versions

What you'll get

Output format

Markdown

Best used when

When working on template or detailed.

Avoid when

Generating full design/architecture documents, major refactors, or schema migrations unless explicitly allowed in constraints

Made for

What to fill in

Use the guidance below to complete each placeholder with the right level of detail.

Programming Stack