MaybeMonad Blindspot
Use this skill to expose the unknowns that may make the user's prompt or plan misrepresent the real territory. The goal is to help the user prompt better and choose a safer next step before implementation gets expensive.
Workflow
- Establish the starting point:
- What the user explicitly wants.
- What they know, do not know, and can judge by taste.
- The codebase, domain, runtime, data, references, or real-world system that forms the territory.
- Inspect before asking:
- Search local files, docs, examples, screenshots, logs, or current external sources when those can answer factual unknowns.
- State what was inspected and what is still uninspected.
- Classify important unknowns using
references/unknowns-taxonomy.md. - Prioritize only unknowns that can change architecture, scope, UX, correctness, safety, cost, or validation.
- For each major blindspot, give the cheapest probe: code search, reference read, prototype, user question, runtime check, test, or source lookup.
- End with a better prompt, plan constraint, or next artifact for the user to use.
Output Shape
Use this structure unless the user asks for another format:
- Starting point
- Territory inspected
- Top blindspots
- Cheap probes
- Better prompt
- Blocking questions
Rules
- Lead with the unknowns that could most change the work.
- Separate unknowns from risks. A risk is a known possible failure; an unknown is missing information that may reveal a different path.
- Do not ask a broad questionnaire. Ask only questions whose answers change the next step.
- Teach just enough vocabulary for the user to recognize better options.
- If the right next step is not implementation, say so and name the artifact: brainstorm, prototype, interview, reference analysis, or plan review.
Resources
references/unknowns-taxonomy.md: read when producing the blindspot pass or when the task needs a structured unknown-card format.