A Claude Code and Codex plugin that helps you discover what you don't know — before it gets expensive to fix.
Ten shared skills packaging the techniques from A Field Guide to Fable: Finding Your Unknowns by Thariq (@trq212) of the Claude Code team.
The map is not the territory. The map is your prompts and context; the territory is the codebase and its real constraints. The gap between them is your unknowns — and with today's models, the quality of the work is bottlenecked by your ability to clarify them.
🇰🇷 한국어 README
Both clients expose the same skill set; plugin-management and local-checkout syntax differ by client.
/plugin marketplace add junjunjunbong/into-the-unknown
/plugin install into-the-unknown@into-the-unknown
Try a local checkout in Claude Code:
claude --plugin-dir /path/to/into-the-unknown
codex plugin marketplace add junjunjunbong/into-the-unknown
codex plugin add into-the-unknown@into-the-unknown
Try a local checkout in Codex:
codex plugin marketplace add /path/to/into-the-unknown
codex plugin add into-the-unknown@into-the-unknown
Skill names are shown as slash commands because they are the shared product surface. Use the client-specific invocation style your environment provides.
Two commands cover 80% of usage:
/discovery add CSV export to the reports page
→ maps what you know / don't know about the task as correctable hypotheses, asks the single highest-leverage question first, and routes you to whichever technique (if any) is worth running before you build. Has special modes for coding, research, and product unknowns.
/diagnose the dashboard came back nothing like I imagined
→ when a result misses the mark: traces which unknown caused it, banks the lesson, and sets up the retry so it doesn't happen again.
Match the sentence in your head to a command:
| You're thinking… | Run | Example |
|---|---|---|
| "I don't know where to start" / "what am I missing?" | /discovery |
/discovery migrate our cron jobs to queues |
| "I've never touched this part of the codebase / domain" | /blindspot |
/blindspot the billing module — never worked in it |
| "I'll know what I want when I see it" | /brainstorm |
/brainstorm 4 wildly different directions for the settings page |
| "There are decisions I haven't made yet" | /interview |
/interview me about the notifications spec |
| "Make it work like that thing over there" | /reference |
/reference vendor/rate-limiter — same backoff semantics in our TS client |
| "I'm ready to build — plan it" | /impl-plan |
/impl-plan bulk CSV import per the decisions so far |
| "Implement it" (in a fresh session, with the plan) | /impl-notes |
implement .unknowns/plan-csv-import.md with /impl-notes active |
| "I need buy-in / approval on this" | /pitch |
/pitch this change for the team channel |
| "Did I actually understand what just got built?" | /quiz |
/quiz me on this branch before I merge |
| "That's… not what I wanted" | /diagnose |
/diagnose the export format is wrong |
For a real feature, the flow looks like this:
- Scope —
/discovery(or jump straight to a technique if you already know your gap). - Close the gaps that matter — usually one or two of
/blindspot,/brainstorm,/interview,/reference. Never all of them by default. - Plan —
/impl-planconsolidates everything into a decisions-first plan you review in 5 minutes (Tier 1 only — the mechanical stuff is buried at the bottom on purpose). - Implement in a fresh session — pass the plan file in, with
/impl-noteslogging any deviation from it. - Verify & ship —
/quizbefore merge (perfect pass required),/pitchif you need approvals. - When it misses —
/diagnose, bank the lesson, retry with it inherited.
Small tasks skip straight from step 1 to "just implement". That's correct usage, not cheating.
Canonical order when several apply: blindspot → brainstorm → interview → impl-plan (/reference slots in whenever you have something to point at). Each step makes the next better: you can't brainstorm well in a domain you don't understand, and reactions to prototypes generate better interview questions than a blank page.
| Situation | Sequence |
|---|---|
| Trivial fix, familiar code | none — just implement |
| Medium feature, familiar area | quick /brainstorm → /impl-plan |
| Clear spec, open details | /interview → /impl-plan |
| Unfamiliar part of the codebase | /blindspot → /interview → /impl-plan |
| Taste-heavy (UI, design, tone) | /brainstorm → /interview → /impl-plan |
| New domain AND taste-heavy | all four |
| "Make it like X" | /reference → /impl-plan |
Skills share an artifact directory, .unknowns/ at your repo root (gitignored by default), so each picks up where the last left off — and so you can implement in a fresh session without losing anything:
.unknowns/
ledger.md ← ALL skills quiet human index, open → closed
state.jsonl ← ALL skills machine recovery events
map.md ← /discovery the knowns/unknowns 2×2
blindspot-<topic>.md ← /blindspot what you didn't know to ask
brainstorm-<topic>.html ← /brainstorm throwaway prototypes to react to
decisions.md ← /interview append-only decision record + taste criteria
plan-<topic>.md ← /impl-plan decisions-first plan (honors decisions.md)
pitch-<topic>.html ← /pitch buy-in doc built from notes + plan
quiz-<topic>.html ← /quiz interactive report + self-grading quiz
implementation-notes.md ← /impl-notes deviations log (repo root, per the article)
Skills ship with templates (design-directions page, interactive quiz with grading, implementation-notes format, decisions-first plan, pitch doc) so the assistant fills in a proven format instead of improvising one each time.
.unknowns/ledger.md keeps open unknowns from getting lost across sessions — but it's agent-owned bookkeeping, not your homework. The split: file updates are mandatory (every skill reads it silently at start and writes the delta at end, so continuity never depends on anyone's memory), chat is quiet (you never maintain it or get it recited at you). What you see is at most one plain sentence when something moves: "Settled: dense tables. Still open: conflict policy — defaulting to last-write-wins."
The field-level contract lives in docs/unknowns-state-contract.md: ledger.md stays the quiet index, while state.jsonl records phase, resume_cursor, owner_action, why_stopped, and closure_evidence for resumable machine state.
The settling rule is strict on purpose: an unknown counts as settled only on your articulation — a decision you made, a criterion you voiced, a teach-back you passed (/blindspot quizzes you on its own report before moving on). The assistant writing the answer into a document does not count; that only moves the unknown from your head into a file.
Relatedly, /discovery opens with hypotheses, not a diagnosis: a small draft map (5–8 items, guesses tagged as guesses, questions about you phrased as questions) that you correct before anything is written or routed. Every "no, actually…" you reply with is the mechanism working.
Commitments from the original article that the skills are built around:
- Field guide, not pipeline. Techniques to reach for when a specific gap appears — skipping most of them on most tasks is correct.
- Artifacts compose your reply. Reacting is easier than imagining — so every artifact carries reaction controls (copy buttons per finding, "this resonates" checkboxes, steal/skip chips, paste-back override lines) that build your next message for you. Modeled directly on the example artifacts accompanying the article.
- Thought partner. Every skill starts by calibrating to your starting point: where you are in your thinking, what you know about the problem and codebase.
- Iterative. Unknowns surface before, during, and after implementation. Going backward (re-framing after a deviation pileup) is the process working.
- You're supposed to get better. Reducing unknowns is the skill of agentic coding. Every verbalized reaction and diagnosed misfire compounds it — the plugin treats your improvement as a deliverable alongside the code.
- A wrong result is a signal. It usually means unknowns were under-defined, or the plan left no room to improvise.
/diagnoseoperationalizes exactly that.
All credit for the ideas goes to Thariq's original article — this plugin is those patterns, packaged. MIT licensed.