How to Find Gaps in an AI-Generated Plan Before You Use It
The plan AI hands you reads clean and complete — until you try to execute it and hit the missing rollback, the unnamed owner, the decision nobody made. Here's how to run a separate gap-review pass that surfaces what's missing, risky, or unclear before you act on it.
Get the Completeness Review PromptWhen a plan looks complete but hides what will break it
You ask the AI for a database migration plan and it hands back five clean, numbered steps: export the data, transform it to the new schema, import it, switch the app over, monitor for errors. It reads like a plan you could start on Monday. Then you look at it the way the person who has to run it would: nothing says whether writes are frozen while you export, so the import could be missing everything that changed mid-migration. Step four flips the app to the new database with no way back if it fails. "Monitor for errors" names no one and no threshold. The plan isn't wrong — it's incomplete in exactly the places that decide whether it works, and those places are invisible because a smooth numbered list reads as finished.
That's the trap this guide is about. An AI-generated plan is written to read coherently, and coherence is what makes it look done — but the model produces a plausible sequence of steps, not the questions someone executing it would ask. The fix is to not act on the plan straight away, but to run it through a separate gap-review pass first: a pass whose only job is to surface what's missing, risky, unowned, or undecided, before any of it becomes a problem you're discovering live. A gap review makes those holes visible, which is genuinely valuable. It flags likely gaps for you to judge, though — it doesn't prove the plan is complete, and it isn't a sign-off that the plan is safe to run.
Why AI-generated plans look finished but aren't
A model writes a plan that hangs together, and a plan that hangs together looks complete — but hanging together and covering everything are different things, and the gaps hide in the difference. The model optimizes for a sequence that reads well, not for the failure branches and hidden decisions an executor runs into. Five patterns leave a good-looking plan full of holes:
- It writes the happy path. The steps that work if nothing goes wrong get spelled out; the what-if-this-fails branches — the rollback, the retry, the fallback — simply aren't there.
- Assumptions stay implicit. A frozen database, a locked schema, an available owner — assumed in the model's head, never written into the plan, so never surfaced as something to confirm.
- Owners and decisions dissolve. No step says who does it, and the moments that need a human to stop and decide — an irreversible cutover, a scope call — pass by as ordinary steps.
- Risks come out generic. "Monitor for errors" instead of "watch the row counts and page the DB lead if the source and target don't match" — a gesture at risk rather than a usable one.
- The plan can't flag what it doesn't know. A gap is an absence, and absences don't announce themselves — a missing step leaves no mark on the page for you to notice.
Step 1: Restate what the plan is for and what it's up against
A gap only exists relative to what the plan needed to cover, so before you review anything, write down — separately from the plan — the goal it has to reach, the constraints it operates under, and what "done safely" actually means here. For the migration, that's things like: zero data loss, a downtime window the business can accept, and a way back if the cutover fails. That short statement is the yardstick the review measures against.
Skip it and the review floats free — the model flags "gaps" that are really just things you already decided or deliberately left out, and you can't tell a real omission from a non-issue. This step is yours to write; no tool knows what "ready" means for your particular plan. It takes a couple of minutes and it's what turns a vague "look for problems" into a review that can actually separate a missing rollback from a step you dropped on purpose.
Step 2: Ask AI to find the gaps — not to "improve the plan"
The request you make decides what you get back. "Improve this plan" returns a rewritten plan — longer, different, and carrying its own fresh set of invisible gaps. "Find the gaps" returns a list of what's missing that you can act on deliberately. So ask the model to act as a reviewer with one job: surface the missing assumptions, the unnamed owners, the hidden dependencies, the absent risks, the undefined success criteria, the skipped decisions, and the edge cases — and to flag them, not fix them.
The Handoff Completeness Review Prompt is that gap-review anatomy already written down. It's built to check a project handoff for what's missing, and it returns exactly the shape a plan review needs: a completeness read, a present/partial/missing checklist across decisions, assumptions, dependencies, and risks, the questions to answer before anyone continues, and a ready/not-ready verdict — under a hard rule to name gaps and never invent fills. Point it at your plan instead of a handoff package and the same structure surfaces a plan's holes. For a review you'll run on every plan, the System Prompt Generator can stand up a reusable "plan reviewer" persona — a must-do list (find what's missing) and, just as important, a must-not-do list that forbids it from rewriting the plan or approving it, so it only ever flags with a question. Both build the reviewer; the actual reviewing happens when you run the prompt in your own AI assistant.
Step 3: Classify each gap so you can act on it
"Here's what's missing" as a flat list is a start, but a gap you can act on needs structure: where it sits in the plan, what kind of gap it is (a missing assumption, a hidden dependency, an unclear owner, an absent risk, a skipped decision, an undefined success criterion, an unhandled edge case), why it matters — what actually breaks if it stays — the question it raises, a suggested fix, an owner, and a severity. Ask for the review as that table, so the high-severity gaps rise to the top and each one arrives carrying the question you'd have had to answer anyway.
The Production Readiness Review resource is a worked example of that shape in a neighboring domain: it reviews a code change against readiness checks, tags each finding by severity, reports only the items that fail, and ends with a go/no-go plus the minimal set of fixes that would flip it. The domain is code, but the structure is the one to borrow — severity on every gap, and a verdict that comes with the specific changes that would clear it, rather than a vague "needs more work."
Step 4: Separate the real gaps from the false alarms, then build a before-you-start checklist
An AI reviewer surfaces candidates, and not every candidate is a real gap. Some are things you settled elsewhere, some are deliberately out of scope, some are non-issues in your context. So the review's output is a list to triage, not a verdict to obey: go through it and mark each item a real gap, already handled, or won't-fix — the yardstick from Step 1 is what makes that call quick. This triage is the difference between a review that sharpens the plan and one that just adds noise to it.
The real gaps then become a before-you-start checklist — the concrete questions that must be answered and the decisions that must be made before the plan is safe to run: is the schema locked, who signs off the cutover, what's the rollback, how do you know the import succeeded. The Feature Request Template resource shows the positive version of what you're checking for — a well-formed spec already carries testable acceptance criteria, an explicit out-of-scope boundary, and an "open questions before implementation" section. Those are three of the very things a gap review hunts for by their absence, so the template doubles as a picture of what a plan looks like once the gaps are closed.
Step 5: Know what the review proves — and what it doesn't
A gap review makes missing decisions and risks visible, and that is real value — but it's also the edge of what it does. It doesn't prove the plan is complete: a reviewer can miss a gap the same way the planner did. A flagged risk isn't a verified one; it's a candidate to check, not a confirmed defect. And the honest core of it: an AI reviewing an AI-generated plan is not an independent second pair of eyes — the reviewer and the planner share most of the same blind spots, so a clean review means "no gaps this pass caught," not "no gaps."
So the gap report is input to your decision, never the decision itself. You judge which gaps are real, whether the plan is ready, and whether to run it — and for anything with real consequences, the second opinion that actually counts comes from a person, not another model pass. If you want the report itself to stay consistent and machine-readable across plans, the AI Output Validator can confirm your gap report is well-formed — that the fields are present and it parses — but be clear on its limit: it checks the report's shape, never whether the gaps it lists are correct or whether the plan is safe to use.
Common mistakes
A few habits let a plan's real holes stay hidden:
- Asking to "improve the plan." A rewrite buries the fixes and smuggles in new gaps; ask for the gaps as a list you can triage.
- Trusting a coherent plan. A smooth numbered list reads as finished — but a plan can read perfectly and still skip the steps that decide whether it works.
- Reviewing with no yardstick. A gap only exists relative to what the plan needed; write the goal and constraints first or the review can't tell a real omission from a deliberate one.
- Treating every flagged gap as real. The reviewer surfaces candidates; you decide which are real, which are already handled, and which are out of scope.
- Glossing the human-decision gaps. The gaps that need a person to decide — a cutover, a scope call — belong on the checklist as decisions to make, not as a suggested-fix line to accept.
- Reading the gap report as approval. It's the input to your call, not a sign-off — the reviewer flags, you decide whether the plan is ready.
A worked example: a database migration plan
Say the AI gives you the migration plan below. It looks complete. Here's the gap review that surfaces what a coherent five-step list left out, with one gap classified in full and the before-you-start checklist the real gaps become.
A coherent-looking migration plan and the gap review that surfaces what it left outAI-GENERATED PLAN (looks complete):
1. Export data from the old system.
2. Transform records to the new schema.
3. Import into the new database.
4. Switch the app to the new database.
5. Monitor for errors.
GAP REVIEW (what a coherent list left out):
- no data-freeze / downtime window -> import may miss writes made during export
- schema not confirmed locked -> step 2 depends on a schema that could move
- no rollback for step 4 -> the cutover is irreversible if the new DB fails
- no success criteria for step 3 -> "imported" is undefined (row counts? checksums?)
- unmapped records not handled -> edge case: records that don't fit the new schema
- "monitor for errors" names no owner -> monitor what, and who acts?
ONE GAP, CLASSIFIED:
location: between steps 3 and 4
type: missing decision point + missing rollback
why: step 4 is irreversible; a bad import with no rollback loses data
question: what's the rollback if the new DB fails validation, and who signs off cutover?
fix: add step 3a — validate the import (row counts + checksums), define rollback,
get a named cutover sign-off before step 4
severity: high owner: DB lead real gap? yes
BEFORE-YOU-START CHECKLIST (the real gaps, as decisions to make):
[ ] data freeze / downtime window agreed? [ ] rollback path defined and tested?
[ ] new schema locked? [ ] import success criteria defined?
[ ] cutover sign-off owner named? [ ] unmapped-record handling decided?Where this fits in NewPrompt
There isn't a workflow or project on NewPrompt that owns plan gap-review, and that fits what it is — not a stage in a build but a pass you run on a finished plan before you act, whether that's a launch plan, a migration, or a content calendar. The nearest formalized cousin is a single step tucked inside the project-handoff workflow, where a package gets checked for missing decisions and risks before the next person picks it up: the same completeness-review move, pointed at a handoff rather than a plan. For a plan of your own the parts are small — a review prompt that hunts for what's absent, a reviewer persona you can reuse across plans, a report shape that sorts the gaps by severity. What none of that settles is whether the plan is actually ready: the reviewer surfaces candidates, and deciding which are real, and whether to proceed, is the judgment that stays with whoever has to live with the plan once it runs.