know-your-unknowns

name

know-your-unknowns

description

Systematic discovery of unknowns for software, product, design, research, and writing tasks. Use when the user asks in natural language to find what they missed, what they do not know, hidden risks, blindspots, assumptions, edge cases, ambiguity, better questions, implementation-plan risks, prompt improvements, reviewer objections, merge readiness checks, or when a request is underspecified and would benefit from clarification before or during execution. Trigger on phrases like "帮我找出未知", "我漏了什么", "哪里可能出问题", "what am I missing", "find the risks", "spot assumptions", and "tell me what I have not considered".

Know Your Unknowns

Use this skill to turn vague work into safer work by exposing the gap between the user's map and the real territory. Prefer concrete artifacts over abstract warnings: lists of decisions, assumptions, experiments, prompts, prototypes, review objections, and verification checks.

Natural Invocation

Do not require the user to say skill jargon such as "shallow", "deep", "blindspot pass", or "evidence before confidence". Treat those as internal operating modes.

When the user simply asks "help me find the unknowns", "what am I missing", "where could this go wrong", or similar, run the default shallow pass and mention the result in ordinary language. Escalate to deep mode silently when the stakes are high, the request is broad, or the first pass finds conflicting assumptions. Explain the escalation as "I am going a level deeper because..." rather than naming methodology unless the user asks.

Core Loop

1. Name the territory: restate the task, intended user/outcome, constraints, and current plan.
2. Sort unknowns into four buckets:
   • Known knowns: facts already established.
   • Known unknowns: questions the user already knows to ask.
   • Unknown knowns: context likely hidden in code, docs, screenshots, prior decisions, or conventions.
   • Unknown unknowns: plausible failure modes the user has not asked about.
3. Choose the cheapest next artifact that reveals risk before expensive work.
4. Ask only blocking questions. For non-blocking uncertainty, state assumptions and continue with visible checkpoints.
5. Convert findings into action: revised prompt, implementation plan, prototype, test list, review memo, or quiz.

Depth Modes

Default to shallow unless the user asks for deep analysis, the task is high-impact, or early evidence suggests the obvious answer may be wrong.

• Shallow mode: produce a fast pass using five probes: pre-mortem, assumption audit, adjacent-domain analogy, second-order effects, and contradiction scan. Use this for routine planning, quick reviews, and early conversation.
• Deep mode: add a dedicated Unknown Unknowns pass. Rotate through orthogonal lenses such as social/technical/economic/political context, customer/actor/worldview constraints, past/present/future timelines, and adversarial misuse or failure. Add a 9-windows scan: subsystem/system/supersystem across past/present/future.

Keep deep mode bounded: state the timebox or artifact count, then stop with the highest-leverage risks and probes.

Phase Picker

Use pre-implementation patterns before coding, writing, designing, or committing to a plan:

• Blindspot pass: scan unfamiliar territory and produce risk cards.
• Teach me my unknowns: explain the domain vocabulary and controls needed to ask better.
• Design directions: produce multiple contrasting approaches when taste or framing is unknown.
• Mock before you wire: build a cheap prototype or sketch before permanent implementation.
• Brainstorm the intervention: generate several grounded interventions with effort/risk tradeoffs.
• Interview: ask one question at a time, ordered by blast radius.
• Reference port: compare against a reference implementation or exemplar before translating.
• Tweakable plan: separate high-variance decisions from mechanical work.

Use during implementation patterns while work is underway:

• Keep implementation notes: log deviations from the plan, surprises, constraints discovered in code, conservative choices, and follow-up checks.

Use post-implementation patterns before handoff, review, or merge:

• Buy-in doc: answer likely objections and explain tradeoffs.
• Merge quiz: test whether the implementer understands what changed, why, and how it can fail.

Output Shapes

Pick the smallest useful shape:

• Risk cards: title, why it matters, current evidence, evidence to look for, likely fix, confidence basis.
• Decision table: decision, options, default, when to change it, owner, validation.
• Question queue: one blocking question first, then optional questions sorted by blast radius.
• Implementation plan: high-variance decisions first, mechanical steps second, verification last.
• Deviation log: planned approach, discovered reality, adjustment, residual risk.
• Review memo: summary, objections answered, tests run, remaining risks.
• Quiz: scenario-based questions with expected answers and red flags.

When the user wants reusable prompts or more detailed examples, read references/prompt-patterns.md.

Working Rules

• Do not treat unknown discovery as a reason to stall. If the unknown is not blocking, proceed with a named assumption and a validation hook.
• Evidence before confidence: inspect local artifacts before rating confidence. For every important risk, mark the basis as observed, inferred, assumption, or unverified.
• Do not claim "verified", "confirmed", or "safe" unless you can name the actual artifact, command, test, source, or user answer that supports it.
• Make risks specific to the user's domain. Avoid generic warnings like "add tests" unless tied to a concrete failure mode.
• Include at least one "cheap probe" whenever confidence is low: quick grep, minimal prototype, single fixture, small benchmark, screenshot check, or reviewer-facing question.
• End with an actionable next step, not just a taxonomy.