--- slug: ai-scan-finds-spec-gaps title: "How to Use AI Scan to Find Gaps in Your Spec Before You Build" excerpt: "AI Scan PRD review catches missing acceptance criteria, vague data references, and unassigned features before you waste credits on a broken export." primaryKeyword: "AI scan PRD" publishedAt: 2026-06-02 readingTimeMin: 6 author: "Robert Boylan" tags: - draftlytic - ai-scan - prd - app-planning - ai-coding-tools --- You've answered the questions, shaped the features, dragged them into priority order. The spec looks solid from where you're sitting. Then you hit Generate on the PRD export, paste it into Cursor or Lovable, and the first thing the AI does is ask a clarifying question about something you thought you'd covered. That gap you just hit was there before you exported. It just wasn't visible. AI Scan is a feature built for exactly that moment, except it catches the gap before you export, not after. Run it on your spec, get a short list of things worth fixing, apply them, and then export something the AI coding tool can actually work with. The whole thing takes about two minutes and costs 30 credits. Here's how it works, what it actually flags, and when it's worth running. ## The five things AI coding tools silently assume when your spec is vague When you hand an AI coding tool a spec with missing pieces, it doesn't stop and ask. It fills in the blanks. And the fills are plausible, which is why you don't notice them until you're four prompts deep and something is wrong. The five most common silent assumptions: **"This feature is done when it exists."** If your feature has no acceptance criteria (the specific, observable conditions for "done"), the AI decides for itself what done looks like. A confirmation modal you didn't ask for. A loading state that blocks the tap you wanted. A streak counter that reloads the page instead of updating in place. **"Any data reference that sounds plausible is fine."** If your feature says "show the user's history" and you haven't named the data model, the AI invents field names. `user_id`, `userId`, `ownerId`. Different every time. Then your codebase has three different names for the same thing. **"This app is free."** If there's no revenue or products section in your spec, the AI builds an app with no billing relationship. You'll notice this at prompt seven when you're trying to retrofit Stripe into a codebase that never expected it. **"Everyone can access everything."** If your features aren't assigned to product tiers (Free, Pro, etc.), the AI treats the whole app as one tier. Feature-gating gets hard to add later. Much harder than getting it right the first time. **"A vague requirement means do what looks good."** This is the catch-all. "Should feel fast," "nice onboarding," "easy to use" — the AI interprets these in whatever direction its training data points. That direction is usually fine, and usually not what you had in mind. AI Scan checks for these patterns. Not all of them, and not perfectly, but well enough to find the issues worth fixing before you export. ## What Scan actually checks in your PRD The scan runs against your full project spec, the same thing that becomes the exported PRD. It looks for four categories of issues: **Missing acceptance criteria.** Any feature with no AC gets flagged. This is the most common flag and usually the most useful one. There's a longer post on [what good acceptance criteria look like for AI coding tools](/blog/acceptance-criteria-for-ai-coders) if you want the full picture. **Ambiguous data references.** Features that mention data in terms the AI will have to invent: "the user's list," "their settings," "the history." Scan flags these when they don't map to anything named in your data model section. **Unassigned features.** If your project has products or tiers defined but a feature has no product assignment, Scan flags it. This is easy to miss when you're building the spec — you add a feature late, forget to assign it, and the AI treats it as universally available. **PRD best-practice gaps.** Broader structural issues: sections that are present but too thin to be useful, requirements written in aspirational terms rather than observable ones ("should be responsive" vs. specifying breakpoints), or audience descriptions vague enough that the AI will ignore them. The scan doesn't rewrite anything. It gives you a numbered list of fixes it recommends and lets you decide which ones to apply. ## Side-by-side: weak spec, scan output, and what a clean scan looks like Here's a realistic example. Say you're building a simple habit tracker and your spec includes this feature: > **Daily check-in** > A quick interaction to log that a habit happened. Should be fast. This feature will generate at least two Scan flags. First, there are no acceptance criteria: what does "fast" mean, what happens when you tap again, does it work offline? Second, the phrase "log that a habit happened" references data that isn't named anywhere in your spec. After Scan flags it, you might end up with something like this: > **Daily check-in** > A one-tap interaction to log that today's habit happened. > > **Acceptance criteria** > > - A single primary button on the home screen marks today as done > - Tapping again undoes it without a confirmation prompt > - Streak count updates immediately with no full reload > - Works offline and syncs when connection returns Now the AI has something to check itself against. The confirmation modal? That breaks criterion two. It removes it. The reload-on-tap? Criterion three rules it out. The spec does the enforcement so your prompts don't have to. A clean scan is brief. A couple of structural notes at most, maybe no flags at all if you've been thorough. When you hit a clean scan, that's the moment to export. You know the spec is solid enough to work with. If you want to see what [a well-structured PRD export looks like](/blog/inside-an-exported-prd), that post covers every section in detail. ## Applying fixes: one at a time or all at once When Scan gives you a list of fixes, you have two options. **One by one.** Click any fix to see what it proposes, then apply it individually. Good when you want to review each change before it goes in, or when a fix touches a part of the spec you have strong opinions about. **Batched.** You can queue up to 8 fixes and apply them in a single AI edit. This is faster and burns slightly fewer credits than applying them one at a time. It's the better option when the fixes are clearly right and you trust them without review. A single scan and a batch fix application runs around 30 credits for the scan plus the edit cost. That's cheap compared to the alternative: exporting a spec with known gaps, getting confused output from your AI tool, and spending an hour debugging which prompt to fix. Both Scan and the PRD Workshop (Draftlytic's separate chat-based refinement space) run on the same backend, so the quality of the analysis is the same either way. The difference is context: Scan is targeted at finding specific structural gaps in a complete spec, while the Workshop is for open-ended refinement and iteration. Use Scan when your spec feels done and you want a sanity check before export. ## Where Scan won't help you Scan is not a judgment on whether your idea is good. It doesn't know if you're building the right thing. It doesn't check whether your feature list is coherent, whether your data model makes sense for what you're trying to do, or whether your target audience description is accurate. It also won't catch everything structural. A spec can pass a clean scan and still be missing things that matter. Scan checks against a set of known patterns: missing AC, ambiguous data references, unassigned features. It can't tell you that your onboarding flow has three steps where two would be better, or that two of your features are actually the same feature described twice. The taste calls, the naming decisions, the "should this be one feature or three" questions: those are yours. Scan handles the mechanical gaps, the kind that can be checked with a rule, the kind that an AI tool will silently fill in with a plausible wrong answer if you don't fix them first. Think of it as a pre-flight checklist for your spec. You still have to fly the plane. ## Running Scan before you export Scan is available on paid Draftlytic plans. From any project, there's a "Scan with AI" button near the export options. It runs in under a minute. You get the flag list, pick what to apply, and you're done. If you're on the free tier and considering upgrading, the question is simple: how much of your time is a 30-credit spec check worth compared to debugging vague AI output after the fact? For most people who've hit that wall once, the math is easy. Before you paste anything into Cursor, Lovable, Bolt, or wherever you're building: run the scan. The spec you export is the context your AI coding tool works from for the whole project. Starting clean is worth two minutes.