A useful code review points to a real failure and explains how to verify it. It should not turn a short snippet into a list of imagined defects.
Provide the boundary around the code
Include the relevant handler, the data it accepts, how identity is established, and what happens when a dependency fails. Replace secrets, customer data, and internal addresses with safe examples. A model cannot assess a route’s authorization just from its function name.
Ask for findings with evidence
Choose a code-review skill and an approach for testing edge cases. Require the trigger, affected behavior, and smallest reproducible example for each finding. Ask the reviewer to distinguish confirmed issues from questions about missing context.
Validate in your own environment
Read the proposed changes before applying them. Run the relevant tests, confirm that the example reproduces the issue, and check for new failure modes. Copy the compiled review prompt into your chosen AI chat. Read its response there, then validate any proposed code in your own environment.
Take this into your next prompt
Reproducible evidence is more useful than a long list of generic warnings.
A WORKED EXAMPLE
From a request to a recipe.
See how a user’s brief and multiple skill tiles work together.
01 · Sample request
Review a fictional authenticated order endpoint that appends {id: randomUUID(), userId, itemId} to an in-memory list on every POST. Explain what happens if a client retries after losing the response. Suggest a fix and a practical test plan. Ask about missing persistence details.
02 · Selected skills
CodingPerform a code reviewStep 1
Visual ThinkingSeparate a subject into labeled componentsStep 2
Testing & Quality AssuranceCreate a practical test planStep 3
Your prompt recipe3 selected
1Perform a code review
2Separate a subject into labeled components
3Create a practical test plan
03 · A possible result
WORKED EXAMPLE · STRUCTURED TEXT
A retry creates a second order
Code-review finding · Supported by the supplied behavior
</>Duplicate request · Correctness finding
01
Trigger
Send the same POST twice after simulating a lost first response.
REPRODUCE
02
Observed design
Each call creates a new ID and appends a new order. The caller may receive two orders for one intended action.
IMPACT
03
Proposed change
Bind an idempotency key to the account and payload; atomically store the first result.
FIX DIRECTION
04
Verification
Concurrent identical requests create one order. Reusing a key with a changed payload is rejected.
TEST · NOT YET RUN
Open question: what persistence layer and transaction guarantees are available? The final implementation depends on that boundary.
Prepared example for the request and recipe shown. Copy the compiled prompt and paste it into your preferred AI chat. The tools available there determine whether you receive graphics, diagram instructions, or structured text.
See the compiled prompt
TASK
Review a fictional authenticated order endpoint that appends {id: randomUUID(), userId, itemId} to an in-memory list on every POST. Explain what happens if a client retries after losing the response. Suggest a fix and a practical test plan. Ask about missing persistence details.
DELIVERY STANDARD
Deliver the requested work itself, with the most useful result first. Use a deliberate hierarchy, concise section headings, readable spacing, and concrete details. Use tables for genuine comparisons, numbered steps for sequences, and checklists for actions when they improve usability. Preserve continuous prose for emails, stories, speeches, translations, and other narrative deliverables. Honor explicit length, tone, style, medium, and exact-format requirements; valid JSON, CSV, code-only, or final-only requests must not gain an introduction, decorative formatting, or extra commentary. Avoid a wall of undifferentiated text, ornamental filler, invented metrics, and generic advice. Use the supplied facts, show material assumptions, and check labels, calculations, citations, and internal consistency before returning the result. Never imply an artifact was rendered, a test was run, or a source was consulted unless that happened.
Treat the selected skills as one coherent brief. Style, tone, persona, critique, and editing selections modify the main deliverable; they do not each require a separate essay or artifact. Combine compatible visual approaches into a unified composition. Give genuinely different requested deliverables clear boundaries, and follow the selected recipe resolution where requirements conflict. Match each section to its audience and purpose, and remove repeated material. Use available creation or rendering tools for a finished visual, chart, slide deck, workbook, or other requested artifact. If the necessary tool or input is unavailable, disclose the specific limitation and provide a clearly labeled, usable production alternative rather than presenting a text description as the finished artifact.
APPROACH
1. Perform a code review
Review only the provided code or behavior. For each supported finding give its trigger, impact, and reproduction steps. Separate confirmed issues from questions about missing implementation details.
2. Separate a subject into labeled components
Identify the main entities and separate the subject into labeled components. Explain each component’s role, its boundaries, and its relationship to the others. Keep labels consistent across the diagram and its explanation.
3. Create a practical test plan
Create a practical test plan with setup, action, expected behavior, and a clear pass or fail condition. Include the relevant error or concurrency cases and never claim that unrun tests have passed.
QUALITY CHECK
Use specific, useful language. State material assumptions and uncertainties. If essential information is missing, ask a focused question before proceeding. Do not invent facts, results, or completed actions.
