Synopsis
A first response is rarely the final result. Prompting 102 uses a short revision loop: inspect the answer, identify the failure, correct the prompt, compare the revision, and verify the parts that matter.
Start with Prompting 101 if you have not yet written a prompt with a clear task, context, constraints, and output format.
The revision loop
Use the same sequence each time:
- Inspect the answer against the original request.
- Name the specific failure.
- Add or correct only the information needed to fix it.
- Compare the revision with the first answer.
- Verify important facts, calculations, code, or commands independently.
Do not restart with a completely different prompt unless the original task was wrong. Small corrections make it easier to see which instruction changed the result.
Inspect before you revise
Classify the problem before asking for another answer.
Missing information
The response omits a required section, case, or fact.
The answer does not cover rollback. Add a Rollback section with the
conditions that should stop the change.
Wrong assumption
The response assumes a platform, audience, date, or constraint that you did not specify.
You assumed Linux. The target system is OpenBSD 7.8. Revise only the
commands and platform-specific explanation.
Unsupported claim
The response states a fact without enough evidence.
List the factual claims that depend on an external source. For each claim,
provide a primary source or mark it as unverified.
Wrong format
The content may be usable, but the structure does not match the request.
Keep the content, but return it as a table with the columns Risk, Evidence,
Impact, and Mitigation.
Use a correction prompt
A correction prompt should identify the defect, preserve the useful parts, and define the revised output.
Problem:
The answer recommends three commands without explaining their effect.
Keep:
Keep the diagnosis and the order of the steps.
Correct:
For each command, explain what it reads or changes. Mark destructive
commands with WARNING. Add a verification command after each change.
Output:
Return the revised procedure only.
This is more dependable than asking the system to "make it better."
Add examples when a rule is hard to describe
Examples help when the required tone, classification, or format is easier to demonstrate than explain.
Classify each support message as Billing, Access, Bug, or Other.
Examples:
"I was charged twice" -> Billing
"My password reset link expired" -> Access
"The export button does nothing" -> Bug
Now classify the following messages. Return one label and one short reason
for each message.
Use examples that cover different cases. Do not provide several examples that all teach the same narrow pattern.
Split complicated work
One large prompt can hide mistakes. Split work when later steps depend on earlier decisions.
For a report, use this order:
- Extract the relevant facts.
- Check the extracted facts against the source.
- Group the facts into sections.
- Draft the report.
- Edit for length and tone.
For code, use this order:
- Reproduce and describe the failure.
- Identify assumptions about the environment.
- Propose the smallest change.
- Review the diff.
- Run tests in the intended environment.
The model can help with each step. It cannot replace the source check or the test run.
Ask for uncertainty directly
Do not ask for confidence as a bare percentage. A number without evidence is not useful. Ask which parts depend on missing or uncertain information.
Separate the answer into:
Known:
Facts supported by the supplied material.
Assumed:
Assumptions needed to complete the task.
Unknown:
Questions the supplied material does not answer.
This format exposes gaps you can resolve with better input or an external source.
Compare alternatives
When there is no single obvious answer, request alternatives under the same criteria.
Compare two approaches to this migration.
Use the criteria Downtime, Rollback, Operator effort, Data risk, and Cost.
State which facts are missing. Do not recommend an option until after the
comparison table.
Check that both alternatives receive the same level of scrutiny. A comparison is weak when one option is detailed and the other is a sketch.
Verify the result
The verification method depends on the task.
| Result | Verification |
|---|---|
| Factual summary | Compare each important claim with the supplied source. |
| Current product information | Check the vendor's current documentation. |
| Calculation | Recalculate with a separate tool or method. |
| Code change | Review the diff, run tests, and check edge cases. |
| System command | Read the manual, use a safe test environment, and plan rollback. |
| Written draft | Compare it with the brief and check names, dates, and quotations. |
Verification is part of the task. Do not treat it as an optional final polish.
Know when to stop
Stop revising when the answer meets the stated requirements and passes the required checks. More prompting can add noise or undo a correct result.
Stop immediately when:
- The task requires access the system does not have
- The available source material cannot answer the question
- A safe decision requires a qualified person
- The system continues to invent facts after being corrected
- The cost of checking the output exceeds the value of using it
Revision checklist
Before using the result, confirm that:
- The task is still the task you intended
- New assumptions are visible
- Required sections are present
- Important claims have sources or are marked unverified
- Calculations, code, and commands have been checked separately
- The final format matches its intended use
Continue with a specialist Guide
Use Prompt Engineering for Code for code review and debugging, Prompt Engineering for Images for visual briefs, Prompt Engineering for System Administration for change plans, or Prompt Engineering for Creative Writing for drafting and revision.