Prompting method

Finding Your Unknowns

With today's models, output quality is no longer limited by the model — it is limited by your ability to clarify your unknowns.

This guide maps the "finding your unknowns" method onto ClaudeKit commands: an iterative loop of discovering what you do not know before, during, and after implementation.

The map is not the territory

Your prompts, skills, and context are the map. The codebase and its real constraints are the territory. They never fully match.

Unknowns are the gap

Wherever the map is blank, the agent guesses what you want. More work done means more guesses made.

Finding them early is cheap

Every brainstorm, interview, prototype, and quiz is a cheap way to find out what you did not know — before it gets expensive to fix.

Four kinds of unknowns

Break every task down before prompting.

Known knowns

In your prompt

Known unknowns

Open decisions

Unknown knowns

Know it when you see it

Unknown unknowns

Blind spots

Method credit: "A Field Guide to Fable: Finding Your Unknowns" — Thariq (@trq212)

Which kind of stuck are you?

Instead of browsing commands by category, start from the kind of unknown you are facing. Each quadrant has commands built to resolve it.

Known knowns

What you already state in your prompt: the requirements, constraints, and context you write down.

"Add a rate limiter to the API client, max 10 req/s."

/ck:cook/ck:fix/ck:plan

No dedicated command — known knowns are just the task you hand to whatever you run next.

Known unknowns

What you know you have not decided yet: open questions you are aware of.

"Should retries use exponential backoff or a fixed delay? I have not picked."

/ck:brainstorm/ck:plan/ck:plan validate

All three interview you with targeted questions before locking in a design or its assumptions.

Unknown knowns

Criteria so obvious you would never write them down — but you would recognize them on sight. Visual design lives here.

"I cannot describe the dashboard I want, but show me 4 directions and I will point."

/ck:brainstorm --html/ck:preview

Prototype first, react second. Low-cost HTML mocks surface these before implementation locks them in.

Unknown unknowns

What you have not considered at all: questions you do not know to ask, potholes you cannot see, quality bars you cannot picture.

"I am adding an auth provider but know nothing about the auth modules here."

/blindspot/ck:scenario/ck:predict/ck:scout/ck:plan red-team

The main target of this method. Ask the agent to find them for you — it reads the territory faster than you.

Techniques by phase

You will not use every technique every time. Treat this as a toolbox: pick what fits the unknowns you suspect.

Before implementation

Most unknowns are cheapest to find here.

  • Blind spot pass /blindspot custom

    Ask the agent to find your unknown unknowns in an unfamiliar area and teach you to prompt better.

  • Brainstorm & prototype /ck:brainstorm --html

    Surface "know it when I see it" criteria with lightweight HTML mocks and competing approaches.

  • Interview built-in

    Let the agent question you about ambiguities — built into brainstorm and plan validation.

  • References over descriptions /ck:xia

    The best reference is source code. Point the agent at a repo that already does it right.

  • Decisions-first plan /ck:plan --html

    Lead the plan with what you are most likely to tweak: data models, interfaces, UX flows.

During implementation

Unknown unknowns always lurk in the work itself.

  • Implementation notes /impl-notes custom

    When an edge case forces a deviation from plan: pick the conservative option, log it, keep going.

After implementation

Close the loop: understanding and buy-in.

  • Pitch & explainer /ck:preview

    Package spec, prototype, and notes into one artifact reviewers can absorb fast.

  • Comprehension quiz /quiz-gate custom

    Get quizzed on the change and merge only after a perfect score.

  • Reflection /ck:journal

    Journal what the session taught you — feed for the next map.

The end-to-end workflow

Six phases from "I have no idea" to "shipped and understood." Each phase pairs a technique with the ClaudeKit command that runs it. Not every task needs all six — scale the gates to how novel and risky the work is.

  1. 0

    Locate your unknowns

    Find your unknown unknowns before starting.

    /blindspot custom
    Example prompt
    /blindspot "I'm adding a new auth provider but know nothing about the auth modules here. Do a blindspot pass."
  2. 1

    Explore & design

    Explore approaches, prototype, surface unknown knowns.

    /ck:brainstorm --html

    For high-risk changes, add /ck:predict or /ck:scenario.

    Example prompt
    /ck:brainstorm --html "I want a dashboard for this data but I have no visual taste and do not know what is possible. Make me an HTML page with 4 wildly different design directions so I can react to them."
  3. 2

    Plan

    Turn the agreed approach into phased implementation steps.

    /ck:plan
    or /ck:plan --tdd
    Example prompt
    /ck:plan "Turn the dashboard direction we picked into a phased plan. Lead with the parts I am most likely to change my mind about."

    When the change touches critical logic with solid existing tests

    Example prompt
    /ck:plan "This touches the payment retry logic and it already has good test coverage." --tdd

    Optional, for high-risk changes (public API, security, high blast radius) — skip if using --hard/--deep/--parallel/--two, they already run this

    Example prompt
    /ck:plan red-team <path-to-your-plan>

    Run after red-team, right before cook — a critical-questions interview that locks assumptions with you

    Example prompt
    /ck:plan validate <path-to-your-plan>

    Advanced, optional, needs a separate OpenAI subscription (Codex CLI) — a different model catches blind spots Claude shares with itself. Runs last, after red-team + validate have already hardened the plan.

    one-time setup
    /plugin marketplace add openai/codex-plugin-cc
    /plugin install codex@openai-codex
    /codex:setup
    Example prompt
    /codex:adversarial-review --wait this plan already passed red-team + validate — challenge the approach, hidden assumptions, tradeoffs
  4. 3

    Execute

    Implement; log deviations the moment they happen, conservative option first.

    /impl-notes init custom
    /ck:cook
    /impl-notes review custom

    How to run it

    sequence
    /impl-notes init
    /ck:cook <path-to-your-plan>
    # if an edge case forces a deviation mid-session:
    /impl-notes log "plan said X, found Y, chose Z because..."
    /impl-notes review
  5. 4

    Understanding gate

    Two independent gates: does the code work, and do YOU understand what shipped.

    /ck:code-review
    /quiz-gate custom

    Closes the loop: the plan-side gates (red-team, validate) killed the plan's unknowns; this gate kills yours.

    How to run it

    sequence
    # both default to reviewing your pending changes, no argument needed
    /ck:code-review
    # optional, advanced — needs a separate OpenAI subscription (Codex CLI):
    # /codex:adversarial-review --wait focus on the riskiest part of this diff
    /quiz-gate
  6. 5

    Ship

    Buy-in artifact, ship, reflect.

    /ck:preview
    /ck:git
    /ck:ship
    /ck:journal

    How to run it

    sequence
    /ck:preview --html --explain "why we built it this way, demo GIF up top"
    /ck:git cp
    # or, for a full PR pipeline instead of a direct push:
    # /ck:ship
    /ck:journal "what this session taught us"

3 custom skills

Custom

Not part of ClaudeKit core — 3 small skills built to close the exact gaps this method needs.

blindspot
Custom

Turns ‘I don't know what I don't know’ into a sharp, ready-to-paste prompt.

new area unfamiliar domain before coding
Early access
impl-notes
Custom

Catches every plan deviation the moment it happens — before it becomes a mystery.

during coding edge cases handoff notes
Early access
quiz-gate
Custom

No perfect quiz score, no merge. Simple as that.

before merge comprehension PR review
Early access

Shared early with Subscribers first

These 3 skills are being refined inside a private Facebook group before going public. Once stable, they ship to a public repo and this section links straight to it.

Join the Facebook group

Example prompts

Ten everyday, ready-to-run prompts grouped by the kind of unknown they resolve. Copy, adapt, and drop your own context in.

Known unknowns

Known unknowns #1
/ck:brainstorm "Before we start, ask me one question at a time about anything unclear — prioritize the ones that would change how you build this."
Known unknowns #2
/ck:brainstorm "I want to add a 'forgot password' feature but haven't decided how to send the reset email. List the options from cheapest to best, with trade-offs."

Unknown knowns

Unknown knowns #1
/ck:brainstorm --html "I want a dashboard for this data but I have no design taste and don't know what's possible. Make an HTML page with 4 completely different design directions so I can react to them."
Unknown knowns #2
/ck:brainstorm --html "Before touching real code, mock the new homepage in a single HTML file with fake data. I want to react to the layout first."

Unknown unknowns

Unknown unknowns #1 · custom
/blindspot "I need to add 'Login with Google' but I've never touched the auth code in this project. Help me find the unknown unknowns before I start."
Unknown unknowns #2 · custom
/blindspot "I don't know what color grading is but I need to color-grade this video. Teach me my unknown unknowns about it so I can ask for the right thing." --domain

References

References #1
/ck:xia ~/projects/old-website "hiệu ứng loading" --port
References #2
/ck:xia shadcn-ui/ui "date picker component" --compare

Post-implementation

Post-implementation #1
/ck:preview --html --explain "why we built it this way, demo GIF up top"

No argument needed — it inspects your pending changes. Or just say it: "I want to make sure I understand everything that changed — quiz me on it."

Post-implementation #2 · custom
/quiz-gate

References

Method credit & further reading