Coding & Software

Exact prompt

Investigate the flaky test below using evidence before recommending a change.

Project context:
{{project_context}}

Failing test and observed output:
{{test_output}}

Constraints:
{{constraints}}

Work in this order:
1. Separate confirmed observations from hypotheses.
2. Identify the smallest reliable reproduction you can attempt.
3. Trace shared state, timing, ordering, environment, and cleanup risks that could explain the intermittency.
4. State the most likely root cause and the evidence for it, or say the evidence is insufficient and name the next discriminating check.
5. Propose the smallest root-cause fix without weakening the assertion or hiding the failure.

Return:
- reproduction notes;
- observations and ruled-out hypotheses;
- root cause or next discriminating check;
- proposed patch;
- focused verification steps.

Do not claim the issue is fixed unless the focused verification succeeds.

Replace before use

Project context{{project_context}}

Relevant language, framework, test runner, environment, and recent changes.Example: Astro 6 with Vitest 4 on Windows and Linux CI

Test output{{test_output}}

The failing test, error text, frequency, and any useful logs.Example: The test fails about once in 20 CI runs with a timeout

Constraints{{constraints}}

Boundaries the investigation and fix must respect.Example: Do not increase retries or raise the timeout

Exact prompt

Review the code change below against its stated requirements and the available evidence.

Change context:
{{change_context}}

Requirements and acceptance criteria:
{{requirements}}

Diff or changed code:
{{diff}}

Verification already performed:
{{verification_evidence}}

Review instructions:
1. Check behavioral correctness and requirement coverage before commenting on style.
2. Trace inputs, outputs, error paths, state changes, and compatibility risks.
3. Identify security, privacy, accessibility, and performance concerns only when they are supported by this change.
4. Distinguish blocking defects from optional improvements.
5. Do not invent missing repository behavior; name any evidence you still need.

Return findings ordered by severity. For each finding, provide the affected location, the failure scenario, why it matters, and a focused correction. If there are no actionable findings, say so instead of manufacturing one. End with remaining test gaps and an overall assessment.

Replace before use

Change context{{change_context}}

The purpose of the change and relevant repository conventions.Example: Add server-side validation to an existing signup flow

Requirements{{requirements}}

The expected behavior and acceptance criteria.Example: Reject malformed email addresses without changing valid submissions

Diff or changed code{{diff}}

The patch or focused code to review.

Verification evidence{{verification_evidence}}

Tests, checks, screenshots, or manual results already collected.Example: Unit tests pass; browser flow has not been checked

Exact prompt

Create a production-ready implementation plan for the feature below. Ground every step in the supplied repository context.

Feature request:
{{feature_request}}

Repository context:
{{repository_context}}

Constraints:
{{constraints}}

Acceptance criteria:
{{acceptance_criteria}}

Planning instructions:
1. Restate the user-visible outcome and identify any unresolved requirement.
2. Map the change onto existing modules and conventions before proposing new abstractions.
3. Break the work into dependency-ordered slices that can be implemented and verified independently.
4. For each slice, name exact paths or components established by the supplied context; otherwise identify what must be inspected before naming them. Include the tests to add first and the observable completion evidence.
5. Include data migration, compatibility, accessibility, security, performance, rollout, and rollback work only when relevant.
6. Separate automated verification from external or manual checks.

Return assumptions, architecture notes, ordered implementation tasks, risks with mitigations, and a final definition of done. Do not claim a requirement is satisfied without a corresponding verification step.

Replace before use

Feature request{{feature_request}}

The desired user outcome and scope.Example: Add exportable saved searches to the dashboard

Repository context{{repository_context}}

Relevant structure, existing behavior, dependencies, and project conventions.

Constraints{{constraints}}

Technical, product, schedule, or compatibility boundaries.Example: No new backend service and no breaking database changes

Acceptance criteria{{acceptance_criteria}}

Observable conditions that define a successful implementation.

Exact prompt

Design focused tests for the behavior change below. Prefer tests that observe public behavior over tests coupled to implementation details.

Behavior change:
{{behavior_change}}

System context:
{{system_context}}

Known risk areas:
{{risk_areas}}

Available test tools:
{{test_tools}}

Build the test plan in this order:
1. Define the contract that must hold before and after the change.
2. List the smallest happy-path, boundary, invalid-input, error-path, and regression cases that provide distinct evidence.
3. Identify state, timing, concurrency, accessibility, security, and compatibility cases only where the system context makes them relevant.
4. For each case, state the setup, action, expected observation, and why the case is not redundant.
5. Recommend the lowest test layer that can prove each behavior reliably.
6. Call out any behavior that still requires browser, device, integration, or human verification.

Return a prioritized test matrix, required fixtures, likely sources of flakiness, and the minimum passing evidence for release.

Replace before use

Behavior change{{behavior_change}}

The new or modified behavior to prove.Example: A failed upload can be retried without selecting the file again

System context{{system_context}}

Relevant architecture, current behavior, and dependencies.

Risk areas{{risk_areas}}

Known regressions, edge cases, or critical workflows; enter 'None known' when there are none.Example: Duplicate submissions, interrupted networks, and stale UI state

Test tools{{test_tools}}

The test frameworks, fixtures, and environments available.Example: Vitest, Playwright, and a local API stub

Exact prompt

Help triage the production incident below without treating assumptions as confirmed facts.

Incident summary:
{{incident_summary}}

Observed evidence:
{{observations}}

Recent changes:
{{recent_changes}}

Operational constraints:
{{operational_constraints}}

Triage instructions:
1. Summarize the confirmed impact, affected scope, and timeline from the supplied evidence.
2. Separate observations, hypotheses, and unknowns.
3. Rank hypotheses by impact and evidence, then name the fastest safe check for each.
4. Propose reversible stabilization options before invasive remediation.
5. Define monitoring signals that would confirm recovery or expose further damage.
6. Identify the information and owners needed for escalation.

Return an immediate action list, hypothesis table, stabilization decision points, communication facts, and follow-up investigation steps. Recommend actions rather than executing production changes. Require explicit authorization, monitoring, and a rollback path for every production change.

Replace before use

Incident summary{{incident_summary}}

The reported symptoms, start time, and known user impact.Example: Checkout errors increased after 14:05 UTC and affect some card payments

Observed evidence{{observations}}

Logs, metrics, alerts, traces, and confirmed operator observations.

Recent changes{{recent_changes}}

Deployments, configuration changes, migrations, or dependency events near the incident; enter 'None known' when there are none.

Operational constraints{{operational_constraints}}

Authorization, availability, recovery, and communication boundaries.Example: Rollback requires incident commander approval; preserve current logs