OctiAI

Categories

Performance Audit Template — Traces, Flamegraphs & Metrics

Markdown-ready prompt template that converts traces, flamegraphs, time-series metrics and a short architecture diagram into a ranked, testable performance audit.

What You'll Get

How to Use

Prioritize low-risk validation first

Start with non-invasive measurement steps (short production-safe profiling windows, read-only explain plans, synthetic load tests) to raise hypothesis confidence before applying any behavioral change. Example: sample production traces at 50Hz for 2 minutes across affected hosts, then run the same synthetic k6 scenario with 5-10% of peak VUs in staging.

Works Best With

Best used when you can provide at least one of each: traces, a flamegraph/cpu profile, and the repo diff or SQL used by the slow path.

Prompt Template


# Developer Productivity Prompt Blueprint

## Goal
- Produce a one-shot, engineering-grade performance audit for a service: ranked bottleneck hypotheses, prioritized measurement/benchmark steps to validate them, quick-win optimizations with estimated impact and confidence, and a long-term optimization roadmap including required instrumentation additions and rollback criteria.

## Inputs
- Artifacts to analyze: traces, flamegraphs, service metrics (time-series), and a short architecture diagram.
- Operational context: runtime stack, deployment topology, relevant repo path or commit.
- Constraints and non-goals (e.g., no breaking behavioral changes, no large refactor).
- Desired output format: checklist, ordered plan, or rubric.
- If any of the above are missing, the prompt will request the minimal artifacts needed to proceed (specific files, time ranges, or example traces).

Provide these inputs before running the prompt:
- Stack description: {{stack_description}}
- Repo root or commit path: {{repo_root_relative_path}}
- Artifact file paths (one per line):
  {{artifact_files_list}}
- Constraints list: {{constraints_list}}
- Desired output format: {{desired_output_format}}

## Prompt
You are an expert performance engineer. Analyze the provided artifacts and produce a structured performance audit for the service identified by the repository path {{repo_root_relative_path}} running on {{stack_description}}. The artifacts available are:
{{artifact_files_list}}

Constraints to honor: {{constraints_list}}.
Return the final results in the following style: {{desired_output_format}}. Do not invent or assume unseen files or metrics; if data is missing, explicitly list the minimal missing artifacts required to validate each hypothesis.

Required deliverables (produce each section exactly as labeled in the "Output Format" below):
- For each hypothesis include: short title, root cause statement, evidence from artifacts (cite file names and line/time ranges), confidence (high/med/low), estimated customer impact (p50/p95 latency, throughput, or cost delta), and next measurement step to validate.
- Diagnosis steps must be actionable and ordered. Each step must include: command or test to run, expected outcome, acceptance criteria, estimated time, and rollback/risk check.
- Quick-win optimizations must include: patch-level changes (diff-sized suggestions), estimated impact (quantitative when possible), confidence, and any trade-offs.
- Long-term roadmap must list prioritized changes, required instrumentation additions, expected deliverables per sprint, and fallbacks.

Produce these sections:
1) Assumptions/Unknowns — list what you are assuming and what is missing.
2) Likely root causes (ranked) — 3-7 ranked hypotheses with the details above.
3) Fix plan (stepwise) — short-term validation steps, quick wins, and staged rollout plan; include acceptance criteria and rollback plan for each stage.
4) Patch suggestions — minimal code/config diffs or config toggles with exact lines or files to change (or pseudo-diff), and risks.
5) Test/verification checklist — concrete tests, benchmark commands, target metrics, and monitoring queries/alert changes to validate fixes.

Additional rules for your analysis:
- Prefer minimal diffs and low-risk changes first; label any change that may alter behavior.
- Prioritize hypotheses that explain high-impact metrics (p95 latency, error rate, tail CPU).
- For each measurement step, include exact commands, flags, or sampling rates (e.g., "run k6 with X VUs for 5m hitting /api/checkout" or "profile production sampling at 50Hz for 2 minutes using perf flamegraph from host A").
- Provide estimated effort for each fix (hours) and a confidence band (low/med/high).
- For instrumentation additions, specify exact metrics/spans/tags to add and suggested retention/aggregation (histogram buckets, percentiles).
- Provide a short risk checklist for common failure modes (regression, data loss, increased costs) and mitigations.
- If you cannot reach high confidence for a top hypothesis, propose the minimal reproducible benchmark that would do so.

If any required artifact is missing, first output a short list of "Missing artifacts" with precise file names, time ranges, or example commands to capture them, then stop.

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

Each numbered section must be present and clearly labeled. Use bullet lists and short ordered steps. Include acceptance criteria and risk checks inline with each step.

## Guardrails
- Do not assume unseen files or metrics; explicitly call out missing artifacts.
- Prefer minimal diffs; avoid scope creep and large refactors unless justified by measurable ROI.
- Mark any change that can change behavior as "behavioral change" and require an explicit rollback and test coverage.
- Avoid speculative estimates without citing artifacts; flag low-confidence items.
- When recommending production profiling, require a short sampling window and a recording plan to avoid cost surprises.

## Examples
- Mini example:
  1) Assumptions/Unknowns: assuming p95 spikes at 12:00-12:15, missing raw span traces for that window.
  2) Likely root causes (ranked): 1) DB query full-table scan under load — evidence: flamegraph shows 40% time in query_x; confidence: high.
  3) Fix plan (steps): Run explain analyze on the query (command and acceptance: explain shows index usage; est 1h); add index as quick win if validated with <15% write-cost.
  4) Patch suggestions: Add index on table.col (provide ALTER TABLE statement), update ORM model index annotation.
  5) Test/verification checklist: load test hitting endpoint with original and patched DB (k6 script) verifying p95 reduced by ≥30% and no >5% increase in write latency.

Variables

Usage Notes

Not for

Do not include

Performance Audit Template — Traces, Flamegraphs & Metrics

Produce an engineering-grade, prioritized performance audit: ranked bottleneck hypotheses, measurement steps to validate, quick-win patches with estimated impact, and a long-term optimization roadmap with instrumentation changes.

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.

What you'll get

Output format

Markdown

Best used when

Avoid when

Sign in to save, like, or rate this prompt.

Made for

What to fill in

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

Stack Description

Provide the key details needed for this variable.

Repo Root Relative Path

Provide the key details needed for this variable.

Artifact Files List

Provide the key details needed for this variable.

Constraints List

Provide the key details needed for this variable.

Desired Output Format

Provide the key details needed for this variable.

Rules

Canonical Examples

Input: Performance audit request for orders-service (Java Spring Boot + Postgres) running on k8s. Provided artifacts: traces/trace_2026-01-15-12-00.json (sampled traces around spike), flamegraphs/flame_12_00.svg, prometheus/prom-metrics-12-00.prom (12:00-12:30), architecture/orders-arch.png. Constraints: no breaking behavioral changes, short rollout window, prefer low-risk fixes. Desired output: ordered plan/checklist.

Loading result...

Failed to load output.


1) Assumptions/Unknowns: lists missing raw slow query logs and sample sizes. 2) Likely root causes: DB full-table scan, ORM N+1 on order items, CPU contention in JSON serialization. 3) Fix plan: ordered diagnosis commands and quick index + query fixes with rollback. 4) Patch suggestions: ALTER TABLE .. INDEX, change JPA fetch join, datasource pool config. 5) Tests: k6 scripts, psql EXPLAIN, production pprof sampling.

Why it works: This example mirrors a common production perf triage: traces + flamegraph + metrics let an engineer form ranked hypotheses, then produce exact commands (EXPLAIN ANALYZE, k6, perf/pprof) and minimal diffs (index, connection pool tuning). The output focuses on verifiable measurement steps and low-risk patches.

Input: Regression triage for pricing-api (Go service + Redis) after PR #482. Provided artifacts: pr_diffs/pr_482.diff, ci/bench/pr-482-bench.log (bench outputs), flamegraphs/flame_pr482.svg, prometheus/metrics-pr482.prom. Constraints: must avoid downtime, aim for minimal hotfix. Desired output: checklist + review comments + minimal fix plan.

Loading result...

Failed to load output.


Sections: 1) Assumptions/Unknowns (missing pprof capture); 2) Likely root causes ranked (regex heavy computation in price rules; deep copy per request; Redis hot key); 3) Fix plan including a hotfix and staged rollout; 4) Patch suggestions with exact Go diffs; 5) Tests and monitoring updates (go bench, pprof, PromQL alerts).

Why it works: This example demonstrates converting a PR diff and CI bench results into actionable hypotheses (CPU/regex mis-use, expensive deep-copy), targeted review comments, quick patch diffs, and verification commands (go test -bench, pprof). It's realistic for engineers using code assistants during PR reviews and incident triage.

Works Best With

Best used when you can provide at least one of each: traces, a flamegraph/cpu profile, and the repo diff or SQL used by the slow path.