From hope
Turns vague requests like 'add a button' or 'fix the thing' into clear work briefs with scope, acceptance criteria, and stop conditions before planning or building.
npx claudepluginhub saadshahd/moo.md --plugin hopeThis skill uses the workspace's default tool permissions.
Clarify WHAT before building anything. Every criterion must be testable by a stranger. Clarity over completeness — a partial spec with boolean criteria beats a thorough spec with vague ones.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Clarify WHAT before building anything. Every criterion must be testable by a stranger. Clarity over completeness — a partial spec with boolean criteria beats a thorough spec with vague ones.
A brief with invented details is worse than a shorter brief grounded in what the user said — assumptions compound silently downstream.
State what you heard in 1-2 sentences. If the task arrives with structured input (proposal, design, specs, task list), extract and validate — don't re-clarify.
Loop using AskUserQuestion — up to 3 questions per round, max 8 rounds. At least one question across all rounds should be "what should this NOT do?"
After each round, list remaining unknowns — things you'd have to invent if you wrote the brief right now. If the list is non-empty, ask another round targeting those unknowns. If empty, move to step 3.
Compress to one sentence (≤35 words): deliverable + top constraint.
Use AskUserQuestion to confirm:
Before generating the brief, list every detail you would need to invent — things the user never stated (numbers, thresholds, scope boundaries, tech choices).
Present each assumption via AskUserQuestion with "Accept" and 2-3 concrete alternatives. Batch unrelated assumptions together, separate dependent ones.
If there are zero assumptions, skip to step 5.
If the task is straightforward with clear precedent, skip to step 6.
Present best practices, thresholds, and standards the agent would add beyond what the user stated. Each with a one-line rationale explaining why it matters.
Use AskUserQuestion (multiSelect) so the user can cherry-pick which to promote into acceptance criteria. Selected items become acceptance criteria in the brief. Unselected items stay in a "Recommended Practices" section as suggestions.
Only after steps 4 and 5 are complete. The core brief contains only what came from the user or was approved in steps 4-5. Scale sections to task stakes — a small fix doesn't need 5 non-goals.
Structure:
User owns intent. If they say "I know what I want," proceed without clarification. When interpretations diverge, present options — never pick for them.