finding-unknowns-skills: 13 installable skills that hunt down your unknowns before they get expensive
13 installable skills for Claude Code, OpenAI Codex, and Hermes, for finding your unknowns before they get expensive: blindspot pass, brainstorms, interviews, references, plans, notes, pitches, a merge quiz, plus a context audit, agent interface design, and progressive disclosure.
At a glance
- What is it?
- A community skill pack for Claude Code, Codex, Hermes and other SKILL.md readers, distilled from Thariq Shihipar's essays on unknowns and context engineering. It is a prompting discipline packaged as commands, not a library you import.
- Who is it for?
- Adopt it if you already run Claude Code, Codex or another SKILL.md-reading agent and your failures come from underspecified prompts rather than model capability; the blindspot-pass, interview-me and change-quiz trio is the cheapest part to try. Skip it if you need a library, a service or anything with a runtime API, because this repository ships instruction files and a validation workflow, nothing executable.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this repository is trying to close
The README states the premise plainly: the prompt is a map, the codebase and the real world are the territory, and the difference between them is your unknowns. The project's one-table framing splits that difference into four quadrants. Known-knowns are what sits in your prompt. Known-unknowns are what you know you have not figured out. Unknown-knowns are so obvious you would never write them down but would recognize them on sight. Unknown-unknowns are what you have not considered at all. Every skill in the pack is described as a cheap way to move something out of that bottom row before implementation makes it expensive.
That is a real problem for anyone driving an agent through an unfamiliar subsystem. The failure is rarely that the model cannot write the code; it is that the model writes exactly what you asked for, and what you asked for encoded an assumption you never examined. The target user is therefore someone already comfortable with an agent CLI, not someone looking for an autocomplete plugin. Eleven of the skills are attributed to public essays by Thariq Shihipar, who the README places on the Claude Code team at Anthropic; two are maintainer-designed extensions. The repository is explicit that it is a community project and not an official Anthropic repository.
How the 13 skills split across task phases and context layers
The pack is organized in two dimensions. Eight task-level skills follow a single piece of work through phases: before implementation you get blindspot-pass, brainstorm-prototypes, interview-me, reference-hunt and implementation-plan; during implementation you get implementation-notes; after it you get pitch-packager and change-quiz. The README's one-liners are concrete about the mechanism. interview-me asks one question at a time and puts architecture-changing questions first. reference-hunt treats working source code as the spec, even across languages. implementation-plan leads with the decisions you are most likely to change. change-quiz is a comprehension quiz you must pass before you merge.
Three more work one layer up, on the instructions the agent carries into every task rather than into one prompt. context-audit finds contradictions, duplicates and dead rules in your CLAUDE.md and skills. agent-interface-design is about designing tools an agent cannot misuse so you do not have to document them. progressive-disclosure splits an oversized skill or spec into an entry file plus files loaded only when needed. The README cites Anthropic deleting 80% of Claude Code's system prompt with no measurable loss as the motivating example for that layer. Two further extensions, assumption-test and test-blindspots, push the workflow from identifying unknowns toward testing them: turning a consequential assumption into a bounded falsifiable experiment, and investigating what passing tests do not establish.
The packaging is where the design work actually lives. Each skill is a directory containing a SKILL.md file, and the README describes the contribution as reusable instruction design: focused triggers, concrete deliverables, scope boundaries, portable packaging and documented checks. There is no Python package to import despite Python being the primary language, which almost certainly reflects the validation scripts and tests rather than a runtime.
Installing finding-unknowns-skills and running a first pass
The README gives one command as the recommended path. Vercel's skills CLI auto-detects your coding agent and installs into the right place for each, covering Claude Code, Cursor, Codex, Copilot, Gemini and others. Add --list to preview the 13 skills before committing, or --skill to install just one.
npx skills add Neeeophytee/finding-unknowns-skillsTo preview first, the README documents a listing flag and a single-skill flag:
npx skills add Neeeophytee/finding-unknowns-skills --list
npx skills add Neeeophytee/finding-unknowns-skills --skill blindspot-passIf you are in Claude Code and want all 13, the plugin route is two commands:
/plugin marketplace add Neeeophytee/finding-unknowns-skills
/plugin install finding-unknowns@finding-unknowns-skillsThere is also a manual path: copy any skills/<name>/ folder into your project's .claude/skills/ directory, or into ~/.claude/skills/ to make it available across projects. The README does not document an uninstall command for any of these routes, so removal means deleting the copied folder or using your agent's plugin management.
Once installed, the intended first use is blindspot-pass against an area you do not know well. The README describes it as surfacing your unknown unknowns in an unfamiliar area and then helping you prompt better, which means the deliverable is a revised prompt rather than code. If you would rather not run commands at all, the repository ships guidance/finding-unknowns.md. Copy it into your project root as CLAUDE.md for Claude Code, or as AGENTS.md for Codex and other AGENTS.md-reading agents, or append it to an existing one. The README notes this file moved in v1.2.0: it used to be the repository's own CLAUDE.md, and the root files now hold maintenance gotchas for the repository itself.
Where progressive-disclosure and the Codex path diverge
The most interesting detail in the README is a compatibility failure that the maintainers document rather than hide. progressive-disclosure ships with disable-model-invocation: true. In Claude Code that makes the skill user-invoked only: it stays out of the model's reach and costs nothing in your context window until you type its name. Codex ignores the flag, and the README states this was verified on v0.143, with the skill and its description still loading into the model-visible prompt. The practical consequence is that the same skill directory behaves differently depending on which agent reads it, and on Codex you should treat progressive-disclosure as an ordinary model-invoked skill.
That is worth internalizing before you install the whole pack. A skill whose entire purpose is reducing context cost can, on one supported agent, add context cost instead. The repository also separates installation instructions per agent, with INSTALL-CODEX.md and INSTALL-HERMES.md at the top level alongside COMPATIBILITY.md, which suggests the maintainers expect the answer to differ by host. If you run more than one agent, read COMPATIBILITY.md before assuming a skill behaves identically in both.
The limits of an instruction-only pack
Nothing here is executable. The repository ships Markdown skill files, a guidance document, evaluation fixtures under evals/ and a validation workflow, and the README frames the contribution as instruction design rather than tooling. If you want a library that parses your codebase, indexes it or enforces anything at commit time, this is the wrong project. There is no runtime, no API and no daemon.
The second limitation is that these skills depend on the host agent honoring them. The Codex behavior above is the proof: a flag that one agent respects is ignored by another. Instruction files are suggestions to a model, and their effect is not something the repository can guarantee across versions of Claude Code, Codex or Hermes. The third is scope. Several skills assume a team workflow. change-quiz exists so a reviewer can confirm comprehension before a merge, and pitch-packager bundles a spec, prototype and notes into a buy-in document for reviewers. On a solo prototype with no reviewer, both are overhead. The evidence extensions carry their own caveat: the README describes assumption-test and test-blindspots as maintainer-designed additions informed by established testing practices, distinct from the eleven skills distilled from published essays. That does not make them weaker, but it does mean the track record behind them is shorter, and the README points to the evaluation protocol and fixtures under evals/ rather than to external validation.
How this differs from writing your own CLAUDE.md rules
The obvious alternative is not a competing product but the thing most teams already do: keep a hand-written CLAUDE.md or AGENTS.md with a list of rules you have accumulated. The difference is structural. A flat rules file is always loaded and always applies, which is exactly the pattern the README says context-audit is designed to find and cut. The skill pack instead splits guidance into named, separately triggered units, each with its own described deliverable and scope boundary, and the user decides which phase to invoke. That gives you a way to retire a skill you never use, which a rules file does not give you.
The trade-off runs the other way too. A hand-written rules file is one file you can read end to end in a minute. Thirteen skill directories plus a guidance document plus evaluation fixtures is a body of text you will not hold in your head, and the pack's own context-audit skill exists because accumulated instructions rot. If your unknowns problem is small and stable, a short rules file is the lower-maintenance choice. The pack earns its size only when you are repeatedly hitting the same class of failure across unfamiliar areas, which is the case the blindspot-pass and interview-me skills are built for.
Licence, maintenance and what an upgrade actually costs
The repository is MIT licensed, with a NOTICE.md at the top level alongside LICENSE. MIT is permissive and permits commercial use and modification, but the README is careful about provenance: eleven skills are distilled with attribution from public essays, and the repository states it is a community project and not an official Anthropic repository. If you redistribute the skill files inside a product, read NOTICE.md and the attribution statements in the README first. This is a description of what the repository says, not legal advice.
Maintenance looks current rather than abandoned. The last push was on 2026-09-09, and the release history shows v1.2.0 on 2026-07-27 expanding the pack from 8 to 11 skills with the context-engineering additions, v1.3.0 on 2026-07-28 adding the Codex plugin and Hermes install, and v1.4.0 on 2026-09-09 adding the evidence skills and repository validation. The README notes the original eleven skill files are unchanged in v1.4.0. That is the upgrade cost in practice: a release can add skills without touching the ones you already installed, but it can also move files, as v1.2.0 did when the guidance document was relocated out of the repository's own CLAUDE.md. If you copied files manually rather than installing through the CLI, a relocation like that leaves you with a stale copy and no upgrade path, which is an argument for the plugin or CLI route if you plan to track releases.
Editorial conclusion
Adopt it if you already run Claude Code, Codex or another SKILL.md-reading agent and your failures come from underspecified prompts rather than model capability; the blindspot-pass, interview-me and change-quiz trio is the cheapest part to try. Skip it if you need a library, a service or anything with a runtime API, because this repository ships instruction files and a validation workflow, nothing executable. Before installing all 13, run npx skills add Neeeophytee/finding-unknowns-skills --list and decide which phases you actually have, since a merge quiz is dead weight on a solo prototype and a plan-deviation log is dead weight on a one-file script. Then check COMPATIBILITY.md for your agent, because progressive-disclosure is user-invoked only in Claude Code while Codex loads it into the model-visible prompt.
Frequently asked questions
What does the term "unknown unknowns" mean?
In this project's framing, unknown unknowns are the things you have not considered at all, as opposed to known unknowns, which you know you have not figured out. The README's four-quadrant table places them in the bottom row and describes every skill in the pack as a cheap way to move something out of that row before implementation makes it expensive.
What are the 7 types of skills?
The repository ships 13 skills, not 7, and groups them in three blocks rather than by type: eight task-level skills covering before, during and after implementation, three context-engineering skills, and two evidence extensions. The README's own table is the authoritative list, with each skill's phase and one-line description.
Can you give me an example of an unknown unknown?
The README's table defines them as what you have not considered at all, and the blindspot-pass skill is the pack's tool for surfacing them in an unfamiliar area. The README does not give a worked example in the excerpt available, so the concrete illustration lives in the linked EXAMPLES.md rather than in the README.
What is the skill that helps you know what you know and what you don't know?
interview-me is the closest match: it asks one question at a time and puts architecture-changing questions first. blindspot-pass targets the other direction, surfacing unknown unknowns in an area you do not know well and then helping you prompt better.
Community notes