From daydream-dictation
Run a structured gap analysis on any design document or project folder. Use when asked to check what's missing, find gaps, or review completeness of a design.
How this skill is triggered — by the user, by Claude, or both
Slash command
/daydream-dictation:dd-gap-analysisThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
A standalone skill that analyzes design documents for gaps, missing coverage, and open work. This skill has no dependency on the Daydream Dictation process — it works on any set of documents at any time. A user might invoke it during a Phase 2 session, run it cold on a project they haven't touched in weeks, or use it as the first step when picking up an unfamiliar document.
A standalone skill that analyzes design documents for gaps, missing coverage, and open work. This skill has no dependency on the Daydream Dictation process — it works on any set of documents at any time. A user might invoke it during a Phase 2 session, run it cold on a project they haven't touched in weeks, or use it as the first step when picking up an unfamiliar document.
Resolve the target project:
$ARGUMENTS names a project, find its folder$ARGUMENTS is a path, use it directlydd-current-dictation-project for the active projectRead the project's documents:
Daydream-<Slug>.md — the main design documentTODO-<Slug>.md — the to-do listPrompts-<Slug>.md — tail of the prompts log (last 20–30 entries for recent context)Not all project folders follow this exact naming. If the folder uses different filenames, look for a root document that serves as the main design doc (e.g., Overview-*.md) and use whatever documentation is present. Adapt to the folder's structure rather than skipping analysis because filenames don't match.
Answer each of the seven questions below. For each one, give concrete findings — not generic advice. Quote specific sections, name specific gaps, reference specific TODOs.
After answering all seven, write a summary of actionable items and offer to address them.
Are there systems, features, or areas that have been mentioned or implied but not yet documented? Are there sections that feel thin or underspecified? Look for things the user talked about in prompts that never made it into the document.
Review TODO-<Slug>.md. Which items remain unresolved? Scan the Prompts log and the design document for to-do items that were mentioned but never added to the TODO file. Report any discrepancies.
Beyond what's missing — where does the existing design feel unclear, inconsistent, or underdeveloped? What could be strengthened? Look for contradictions between sections, vague language that would block implementation, or areas where the user changed their mind but the document wasn't fully updated.
Identify anything that an agent picking up this design document would find ambiguous or underspecified. What decisions would they have to make on their own because the document doesn't answer them? If the project has a DecisionTrace-<Slug>.md, check whether it covers the technical decisions needed to implement the design. Does the document call out open decisions? Does the user want to make them now? If no Decision Trace exists and the project has enough technical complexity to warrant one, note that.
For any interactive or playable system: are the player controls fully defined? Are all inputs accounted for across all relevant states? Skip this question if the project is not interactive.
If the project has a StringTable-<Slug>.md or other localization files, check for completeness: are there strings missing translations for any supported language? Are there strings referenced in the design doc that don't have string table entries? If gaps exist, ask: should translation happen now, or is it deferred? Skip this question if the project has no localization.
Catch-all for anything not covered above — missing asset lists, undefined edge cases, unresolved working names, placeholder items ([Item N — not yet documented]), or anything else that would block a complete implementation.
For each question, respond with:
End with a numbered list of all actionable items sorted by severity, and ask the user which ones to tackle.
The gap analysis is a signal that the design is complete enough to hand off. By the time all seven questions are answered satisfactorily, you should be confident that an implementing agent has everything it needs, and that the user has touched every part of the design before moving on. If significant gaps remain, say so clearly. If the design looks solid, tell the user it's ready.
npx claudepluginhub ecnassianer/daydream-dictation --plugin daydream-dictationReviews design artifacts (proposals, specs, designs, tasks) for internal consistency, gaps, and cross-artifact alignment before implementation.
Analytically scans a written artifact (spec, PRD, user stories) for blind spots: unstated assumptions, missing actors, failure modes, ambiguous terms, missing acceptance criteria, edge cases, and dependencies. Emits a categorized, severity-sorted shadow report.
Reviews design and implementation docs from analysis-process for document quality, internal consistency, and technical soundness before implementation-process.