Finding skills that fit this project

The alternative to this is a hardcoded list of recommended skills, which is stale within a month of being written and wrong for most projects even while it is fresh. Searching at the moment of need scales; curating does not.

The value here is almost entirely in the filtering. Searching is easy, and a list of twelve plausible results is worse than no list — the user has to evaluate all twelve, which is the work they wanted delegated.

1. Know the project first

Do not search before you know:

• the stack, as concrete strings — "Next.js", "Postgres", "dbt", "Stripe"
• the domain or differentiator — what this project is actually for

During a bootstrap these come from interview blocks A and B. Standalone, read bootstrap.yaml and CLAUDE.md; if the stack is not recorded anywhere, ask rather than inferring it from file extensions.

2. One query per item

npx skills find nextjs
npx skills find postgres
npx skills find stripe
npx skills find checkout ux

Never one combined query. npx skills find nextjs postgres stripe returns shallow results for every term in it — the specific match for each technology is exactly what gets diluted.

Search the domain as well as the stack. A payments project wants payment conventions, not only framework conventions, and the domain query is the one that finds things the user did not think to ask for.

3. Filter hard

Applied before anything reaches the user:

The fit test is the one that gets skipped. A well-made skill for a framework this project uses for one peripheral thing is not a recommendation, it is noise.

If nothing clears the bar for a stack item, say nothing about that item. Do not pad the list. A weak recommendation costs more credibility than a missing one, and a user who learns to ignore this list gets no value from it at all.

4. Present, do not install

For each surviving result:

• name and what it actually does, in your own words
• install count and source
• why it fits this project, specifically
• the install command: npx skills add <owner/repo@skill> -g -y

Then stop. The user picks. Install only what they name, one at a time, and report what actually happened — an install that partially failed and went unmentioned is worse than one that failed loudly.

Mark anything from an unfamiliar source as such. The user is installing software from a stranger; that belongs in the recommendation, not in a footnote.

5. Feed the result back into the team

This is the step that makes discovery worth running during a bootstrap rather than after it.

A skill that covers a responsibility well means the corresponding role gets leaner, or does not get created at all. A project that installs a testing- conventions skill and also creates a bespoke agent restating the same conventions has two sources of truth that will disagree, and an orchestrator that has to choose between them.

State that trade-off explicitly when you present the findings: "installing this means the X role can be dropped" is far more useful than the install count.

When the CLI is unavailable

npx skills needs Node. If npx is not on the PATH, say so once, note it in kb/roadmap.md as a deferred item, and continue — the relevant knowledge is usually already in the model, and a missing optional tool is not a reason to stop a bootstrap.

Do not substitute a web search and present the results in the same format. Install counts and source reputation are the whole filter, and guessing at them produces a list that looks vetted and is not.