Crash Log to Minimal Reproduction Steps Prompt

This prompt is designed for mobile and desktop QA engineers, SDETs, and developers who need to convert raw crash reports, stack traces, and system logs into a single, reliable, minimal reproduction scenario. The core job-to-be-done is to eliminate the back-and-forth clarification that typically follows a crash report by producing a structured output that isolates the exact preconditions, step sequence, and environment fingerprint required to trigger the crash. The ideal user has access to the full crash log, knows the application's basic architecture, and needs a test-ready procedure—not a root cause analysis or a code fix.

Use this prompt when you have a crash log with a clear exception type and stack trace, but the steps to reproduce are unknown, incomplete, or buried in verbose system logs. It is most effective for deterministic crashes (e.g., null pointer exceptions, index out-of-bounds errors) where the failure signature is consistent. Do not use this prompt for non-deterministic or performance-related issues such as ANRs caused by thread starvation, memory pressure without a specific allocation site, or race conditions that require probabilistic reproduction. The prompt assumes the crash log contains enough signal to infer a user journey; if the log only contains a generic SIGSEGV with no application frames, the output will be low-confidence speculation and should be flagged for human review.

Before using this prompt, ensure you have sanitized any personally identifiable information (PII) or authentication tokens from the crash log. The prompt works best with symbolized or de-obfuscated stack traces; if you only have minified or obfuscated traces, run them through your symbol server or ProGuard mapping first. The output is a structured reproduction procedure, not a finished automation script. After generating the steps, you must manually reproduce the crash at least once to validate the procedure before attaching it to a defect report or handing it off to a developer. If the reproduction fails, use the 'Reproduction Reliability' eval criteria in the full playbook to diagnose whether the environment fingerprint, dependency isolation, or step sequence is incomplete.

This prompt template is designed to be copied directly into your AI harness, test runner, or evaluation pipeline. It accepts a raw crash log and optional context, then outputs a structured reproduction scenario with preconditions, step sequences, and environment fingerprints. Every placeholder is enclosed in square brackets—replace them with your application's variables before sending the request to the model.

textCopy
You are a QA engineer specializing in crash reproduction. Your task is to convert the provided crash log into a minimal, reliable reproduction scenario.

## INPUT
[CRASH_LOG]

## ADDITIONAL CONTEXT (OPTIONAL)
[APP_VERSION]
[DEVICE_OR_OS]
[USER_ACTIONS_BEFORE_CRASH]
[KNOWN_ISSUES]

## OUTPUT SCHEMA
Return a JSON object with the following fields:
{
  "crash_signature": "<exception type and primary message>",
  "preconditions": ["<list of required states, configurations, or data before the crash can occur>"],
  "reproduction_steps": [
    {
      "step_number": 1,
      "action": "<precise user or system action>",
      "expected_behavior": "<what should happen if the system is working correctly>",
      "observed_behavior": "<what the crash log indicates actually happened>"
    }
  ],
  "environment_fingerprint": {
    "os_version": "<from log or inferred>",
    "device_model": "<from log or inferred>",
    "app_version": "<from log or inferred>",
    "memory_pressure": "<low|medium|high|unknown>",
    "network_condition": "<wifi|cellular|offline|unknown>"
  },
  "minimal_dependency_isolation": ["<list of services, permissions, or background processes that appear necessary for reproduction>"],
  "confidence": "<high|medium|low>",
  "assumptions": ["<explicit assumptions made when the log was ambiguous>"],
  "missing_information": ["<questions that must be answered before reproduction can be confirmed>"],
  "recommended_next_steps": ["<investigative actions, additional logging to enable, or related components to examine>"]
}

## CONSTRAINTS
- If the crash log contains a stack trace, extract the failing module, exception type, and the last application frame before the crash.
- Reproduction steps must be numbered, sequential, and self-contained—another engineer should be able to follow them without reading the original log.
- Do not invent steps or preconditions not supported by the log. If the log is ambiguous, state assumptions explicitly in the assumptions field.
- If the log suggests a race condition or timing-dependent crash, note this in the confidence field and recommend repeated attempts.
- For mobile crashes, include memory pressure and background state if available.
- If the crash involves a third-party SDK or library, flag it in minimal_dependency_isolation.
- Set confidence to "low" if fewer than 3 application frames are present or if the exception message is generic.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace [CRASH_LOG] with the raw text from your crash reporting tool (Firebase Crashlytics, Sentry, BugSnag, or custom logs). Populate [APP_VERSION], [DEVICE_OR_OS], and [USER_ACTIONS_BEFORE_CRASH] from your ticketing system or user report. The [FEW_SHOT_EXAMPLES] placeholder should contain 1–2 annotated crash-to-reproduction pairs that demonstrate your team's expected level of detail and format conventions. Set [RISK_LEVEL] to "high" if the crash affects payment, authentication, or data loss paths—this should trigger mandatory human review of the output before it enters your defect tracker. For production use, validate the output JSON against the schema before accepting it; reject any response where reproduction_steps is empty or confidence is "low" without explicit missing_information entries.

This prompt is designed to be called programmatically as part of a defect intake pipeline. When a crash report arrives—typically via an error monitoring system like Sentry, Crashlytics, or a custom logging endpoint—the raw log payload is injected into the [CRASH_LOG] placeholder. The prompt expects a structured JSON output that can be parsed and ingested by your test management system (e.g., TestRail, Xray, or a custom QA database). The primary integration point is a serverless function or microservice that receives the crash event, formats the prompt, calls the LLM API, validates the output, and writes the resulting reproduction scenario to the defect tracker.

Validation is critical before accepting the model's output. Implement a JSON schema validator that checks for the required fields: preconditions, reproduction_steps (as a non-empty array), crash_signature, and environment_fingerprint. Each step in reproduction_steps must contain a step_number, action, and expected_result. If validation fails, retry the prompt once with the validation error appended to the [CONSTRAINTS] field, instructing the model to fix the specific schema violation. After two failed validation attempts, route the crash log to a human QA engineer for manual reproduction drafting. Log every attempt—including the raw prompt, model response, validation errors, and final outcome—for prompt observability and regression testing.

For model choice, use a model with strong instruction-following and structured output capabilities, such as gpt-4o or claude-3-5-sonnet. Set temperature to 0.1 to minimize variance in reproduction step phrasing while preserving enough flexibility to handle diverse crash signatures. If your crash logs contain sensitive data (user IDs, file paths, memory addresses), redact them before prompt injection using a PII scrubbing step. The environment_fingerprint field should be extracted deterministically from the crash metadata (OS version, app build number, device model) rather than generated by the model, then passed into the prompt via the [ENVIRONMENT_METADATA] placeholder to ensure accuracy. Never let the model hallucinate environment details from the log alone.

Finally, integrate the output into a human review queue. Even with schema validation, a QA engineer should confirm that the reproduction steps are minimal, the preconditions are realistic, and the crash signature matches known issue patterns. Use the reproduction_reliability score from the model's output to prioritize review: scores below 0.7 should be flagged for deeper investigation. Once approved, the reproduction scenario can be linked to the originating crash event in your monitoring tool, creating a bidirectional trace from crash to test case. Avoid using this prompt for crashes that involve race conditions, memory corruption without a clear stack trace, or hardware-specific failures—these require interactive debugging, not static log analysis.