Stats
Actions
Tags
From daydream-dictation
Explains the Daydream Dictation process to users. Activates when the user asks how to use Daydream Dictation, asks about the three phases, wants tips for dictation sessions, asks what they should be doing in the workflow, or needs help with version control during the review cycle. Does not activate for general voice-typing or dictation-tool questions (e.g. comparing Wispr Flow to built-in voice typing) — those are tooling questions, not workflow questions.
How this skill is triggered — by the user, by Claude, or both
Slash command
/daydream-dictation:dd-teachThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A guided onboarding skill that teaches users how to use the Daydream Dictation process. Rather than expecting the user to read documentation, explain the workflow interactively — contextualized to the user's experience level and current situation.
A guided onboarding skill that teaches users how to use the Daydream Dictation process. Rather than expecting the user to read documentation, explain the workflow interactively — contextualized to the user's experience level and current situation.
This skill is not a linear tutorial. Respond to what the user asks and where they're stuck. A user who already knows git gets a very different explanation than someone who has never used version control. Don't dump the entire process on them at once.
When the user asks "how does this work?" or similar, start with this:
Daydream Dictation is a three-phase workflow for building documents with an AI using voice input.
Phase 1 — Structured Daydreaming. Talk out loud about your idea. Don't edit, don't review, don't look at what the AI is writing — just generate. The AI captures everything and organizes it into the document as you go. You're done when new ideas dry up, your energy dips, or you genuinely want to see what you made. That's usually around 20–60 minutes. Stopping earlier (after 5–10 minutes to "check the work") almost always means you haven't actually dropped into the creative headspace yet — the real payoff comes from staying with it past that urge. When you're done, come back and the AI will walk you through Phase 2.
Phase 2 — Response and Agent Engagement. This is its own kind of thinking, not just a bridge between the other two. Phase 1 leaves gaps by design; Phase 2 is how you close them. Read through the AI's replies, answer its questions, add what's missing. Ask for a gap analysis — a structured check that surfaces holes, contradictions, and open to-dos. The AI is a sounding board and a foil here: it reflects the idea back, names what doesn't hang together, and you refine against that pushback until the work becomes cohesive. It's problem-finding and structural troubleshooting, not detail-level fact-checking (that's Phase 3). Lower focus than Phase 1; works well even when you're tired or interrupted.
Phase 3 — Diff Review. Check the pull request (or your version control diff view) and read what actually changed. This is where you catch mistakes, transcription errors, and misunderstandings. Leave inline comments on the diff with feedback, then bring them to the AI as a batch. When you're satisfied, approve and merge. This step is what makes Phase 1 safe — knowing you'll verify everything later is what lets you trust the process and stay in the creative flow.
Phases don't have to happen in a single pass. It's normal to cycle through all three more than once on the same document. After merging, start a new session — the Daydream document itself is what the next session picks up from. The Prompts document is your audit trail, kept so you can trace what dictation caused which change, not a handoff mechanism.
When teaching the workflow to a new user who's about to start their first session, stay on logistics, not the content of their project. It's tempting to ask "what's your memo about, roughly?" or "what are the main topics?" as part of setup — these feel helpful but they are Phase 1 content under a setup label, and once the user starts answering, the session boundary is gone.
Setup questions to ask:
/daydream-dictation can create the folder)Do not ask about git or version control familiarity during onboarding. Phase 1 doesn't require any git knowledge — the agent handles all of it. When the user reaches Phase 3 and actually needs to look at a diff, that's the moment to calibrate explanation depth to their comfort level. Bringing it up earlier just adds to the intimidation and delays the user getting started.
Questions to avoid before the session starts:
Those are Phase 1 material. Let them come out of the user's own dictation, captured fresh, not pulled out by the agent during onboarding. When the user is ready, hand them off to /daydream-dictation — that's the clean session boundary.
Just skip those questions silently. Don't narrate the rule ("I'm deliberately not asking about the content of your memo because..."). The user doesn't need to know about the internal guideline — it reads as rule-following theater. Ask the logistics questions and leave out the rest without comment.
Ask the setup questions exactly once. Don't list them inline and then repeat them as a trailing "unanswered questions" footer. One pass is enough; the user can read.
Teaching Daydream Dictation well means answering what the user actually asked, at the length they actually need — not delivering the whole manual every time.
If the user is mid-action — "I'm ready to talk, what's step one?", "I'm in the middle of Phase 1 and glanced" — they need a short answer that gets them moving again. A 600-word response with section headers burns their momentum. Aim for: the one or two things they need to do next, a sentence of context if truly necessary, done. Deeper theory can wait until they come back.
If the user is cold and asking "how does this work?", more depth is appropriate — but still don't dump the whole skill. Give the shape and an invitation to go deeper on what interests them.
Answer the question they asked. Don't preemptively backfill adjacent topics they didn't ask about — and in particular, don't pre-reassure them about concerns they haven't raised. "You don't need to know git" sounds helpful, but if the user hasn't mentioned git, saying this plants the worry rather than soothing it. Only address git/version control when (a) the user brings it up, or (b) you're actually at the point of Phase 3 where they need to look at a diff.
More generally:
Related context can come up when it's actually relevant to their next move. Mention it in a sentence if needed, but don't build out unsolicited sections around it, and don't volunteer reassurances about concerns the user hasn't voiced.
If the ambient project convention is to append an "unanswered questions" or "open questions" footer to plans, that convention does not apply to teach responses. Teach responses are dialogue — if you need an answer from the user, ask it once, in the natural place in the body. Don't stack a plan-style question footer at the end.
When the user asks for help with Phase 1, cover whichever of these points are relevant to their question:
A high-quality tool like Wispr Flow is essential. Built-in keyboard dictation isn't reliable enough. If the user has to constantly verify what was captured, their creative flow breaks. They need to trust the software and keep talking. A few mispoken words will be handled by the AI fine, but if whole sentences are headed in the wrong direction or voice dictation is regularly making mistakes, find a better dictation software.
Topics don't need to go in order. Useful moves:
For a brand-new user, don't deliver the whole workflow in one lecture. Teach Phase 1 well, point to the fact that Phase 2 and Phase 3 exist as the safety net, then stop. The natural handoff is the Phase 1 stopping signal itself: "when your ideas dry up or your energy dips, come back and I'll walk you through Phase 2." That's where they learn it, when it's actually useful.
The full three-phase overview is appropriate when someone is asking "how does this work?" from outside — they want the shape of the thing. When someone is mid-action ("I'm ready to start"), skip the overview and get them dictating.
Each phase has a natural physical configuration, and the research supports the mapping:
These are optimizations, not requirements. If someone has to do Phase 1 at a desk because that's what's available, it still works. But when a user asks where to do which phase, this is the answer.
Don't try to deliver a 30-minute monologue as one giant prompt. Each natural pause is a good submission point — submit every minute or two, or whenever you finish a thought. Most voice dictation tools handle this automatically when you pause.
Shorter prompts matter because:
A loose rule of thumb: if you're going to talk for more than ~3 minutes on one topic without pausing, you're probably building toward a prompt that'll be hard to review later.
The natural urge to check what the AI is writing is almost always a trust problem, not a discipline problem. Don't just tell them "don't look" — find out what they're actually checking for, then address it.
Ask them what's pulling their eyes back. It's usually one of:
If the user is new to the workflow, their trust hasn't been earned yet — it gets built by cycling through Phase 2 and Phase 3 a few times and seeing that the process genuinely catches problems. Encourage them to finish a full cycle even if Phase 1 felt rough; the trust compounds.
Where to point your attention is personal — eyes closed, looking out a window, pacing. The one thing to avoid is reading the AI's replies while you're dictating. Glancing at the screen to operate the dictation software (start it, confirm it's capturing, submit a prompt) is just using a tool — that's not what breaks Phase 1. Reading the generated text is what flips your brain out of generative mode into analytical mode, and once you're there it's hard to get back.
If absolutely necessary — rate-limited, can't focus — record prompts in a separate document and paste them in as a batch. This breaks the natural commit sequence and makes Phase 3 review harder, but it's valid for buffering thoughts.
The concept of structured daydreaming as a creative practice has prior art. Ray Mazza's article Structured Daydreaming is the direct inspiration for Phase 1.
When the user asks for help with Phase 2:
Phase 2 is its own cognitive mode — refining, troubleshooting, structural problem-solving. Phase 1 produced a lot of material with deliberate gaps; Phase 2 is where those gaps get closed and the thing becomes cohesive. The AI is a foil here: it asks questions, points out contradictions, surfaces what's missing through gap analysis, and the user refines against that pushback. It's social in a way — a dialogue, not a monologue — and the friction is the point. Don't confuse it with Phase 3: Phase 2 is about structure and holes, not fact-checking at the sentence level.
Begin at the top of the AI's replies from Phase 1 and work down. Address questions, fill gaps, add details. If something sparks a new idea, add it. Work through the whole list before asking for the gap analysis.
Once all Phase 1 replies are addressed, ask for a gap analysis. The AI examines what's been built and surfaces missing sections, unanswered questions, thin coverage, and open to-dos. Or use /dd-gap-analysis to run it.
After addressing the gap analysis, try running it again.
Phase 2 has much lower focus requirements. If tired, low on energy, or no longer in a creative setting — that's a good time for Phase 2. Getting off the couch and sitting at a desk can help shift into the more methodical mindset Phase 2 benefits from.
Once the user has addressed what they want and things are winding down, move to Phase 3. Or jump back into Phase 1 if re-energized. But don't stay in Phases 1 and 2 for hours without a Phase 3 pass.
When the user asks for help with Phase 3:
A diff view highlights exactly what changed — new text in green, removed text in red. In GitHub, this is the pull request view. Only read what changed — don't re-read the whole document.
If the user is unfamiliar with diffs or version control, walk them through it step by step.
The Prompts document is the reference for understanding what caused any change.
Phase 3 does require the user to touch the PR page for two things: reading the diff (that's where the before/after view lives) and approving/merging at the end. What's optional is the feedback mechanism in the middle — there are two ways:
Both paths land in the same PR. Mix and match freely. After the AI makes corrections, jump to the most recent commits on the PR to verify the fixes, then approve and merge.
When satisfied, approve and merge the pull request. Don't skip this — without a merge, work can appear lost. If the user feels lost with version control, guide them through it.
When the user asks about when to end or start sessions:
Good signals to start a new session:
When to stay:
The end of Phase 3, right after merging, is almost always a good time to close. The Daydream document is the authoritative state — a new session reads it and takes it from there.
The phases are not a single linear pass. It's normal to cycle multiple times. What matters is keeping each phase distinct — don't blur them. When in Phase 1, stay in Phase 1. The discipline of the phases is the point.
When the user needs help understanding version control as it relates to Phase 3:
Calibrate the depth of explanation to the user. A developer needs almost none of this. Someone who has never used git needs all of it, step by step.
npx claudepluginhub ecnassianer/daydream-dictation --plugin daydream-dictationGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.