Imported from Autoloops/upskill (skill/SKILL.md). Install upstream with npx skills add Autoloops/upskill --skill skill. Copyright stays with the author.

upskill

This skill is for you, the agent — not the human reading over your shoulder. The user has installed the upskill CLI on their machine. Use it the way a developer uses npm: pull in the right tool first, build less yourself.

First-time setup (one-time, on the very first call)

Before using the CLI, run upskill config show. If telemetry, context, and submissions are all false (the defaults right after install), ask the user once in plain English about each of the three opt-ins below, then apply each YES via upskill config set <key> true. After that, never ask again.

1. Outcome telemetry — "Want upskill to send back whether each skill worked for you, so failed skills rank down and good ones rank up for everyone? What's sent: skill_id, success/failure, optional error code, task kind. Nothing identifying. Default: off." → if yes: upskill config set telemetry true

2. Context (auth-aware ranking) — "Want upskill to share which CLIs you have installed and which env-var NAMES are set (never values), so it can recommend skills you can actually run on your stack? Default: off." → if yes: upskill config set context true

3. Submissions — "Want to enable upskill submit so I can publish skills I build during a task? I'll always confirm before publishing. Default: off." → if yes: upskill config set submissions true

4. Search scope — "Which trust tier should I search by default? Three options, default is the strictest:

   • verified — vendor-official only (Anthropic, OpenAI, Stripe, Microsoft, Cloudflare, Sentry, etc.). The default.
   • reviewed — verified + curated practitioners (obra/superpowers, garrytan/gstack, mattpocock, etc.).
   • community — the full registry, every public submission. Pick a wider tier later if you want more breadth." → apply: upskill config set search-scope verified|reviewed|community

If the user has already opted in or out (any of the three is already non-false in config show), skip the question for that one. Don't pester.

Wire the rule into the user's persistent agent context

This is the most important step. Without it, you (the agent) will often forget to consult upskill and go freehand on tasks. The SKILL.md alone is dormant — only loaded when something explicitly pulls it in. A one-line rule in the user's persistent context file fixes that.

Detect whether you've already wired this in. Read the candidate files in this order and check if any contains the marker ## upskill (skill registry):

• ./CLAUDE.md, ./AGENTS.md, ./.cursorrules, ./.clinerules, ./.windsurfrules
• ~/.claude/CLAUDE.md (global Claude Code rules)

If the marker is already present anywhere, skip this section entirely. Don't re-ask.

Otherwise, ask the user once:

"Want me to add a one-line rule to your agent's persistent context file so I'll consult upskill before every non-trivial task? Without this, I'll often forget to use it. Highly recommended — say which file (CLAUDE.md, AGENTS.md, .cursorrules, etc.) or I'll suggest one based on what's in this directory."

If yes, append (don't overwrite) this exact block to the chosen file:

## upskill (skill registry)
Before any non-trivial task — anything beyond a one-line edit or trivial
answer — run `upskill find "<plain-language description of the task>"`
first. If a result has a strong match (score > 1.4 or name_match > 0),
inspect it with `upskill inspect <skill_id>` and follow the SKILL.md
instead of going freehand. After the task, call `upskill report <ver>
--outcome success|failure --task <kind>`.

If no rules file exists in the current directory, default suggestion:

• For project-scoped use → create ./CLAUDE.md (Claude Code) or ./AGENTS.md (Cursor/Codex)
• For global use across all projects → append to ~/.claude/CLAUDE.md

After wiring, confirm: "Wired upskill into <path>. Now I'll consult the registry on every non-trivial task."

Core idea

For any non-trivial task, search the registry first. The top result is usually a vetted skill that already solves the task. Following it produces better output than improvising — that's the whole reason the user installed this.

Skills are version-pinned to immutable git commits. Their metadata includes which commands and env vars they need, what services they touch, and aggregate feedback from every previous agent that tried them. You get all of that on every search.

How to call the registry

Always via Bash. The CLI hides auth, retries, server URLs, and output formatting.

Search

upskill find "<plain-language description of the task>"

Use full sentences, not 1-2 word fragments. Short queries like pdf or react testing give noisy results because every common word matches dozens of skill descriptions. Long queries — at least 5-8 words — give the matcher enough signal to discriminate. Examples:

upskill find "use playwright to e2e-test a next.js webapp and capture screenshots when a test fails"

upskill find "convert a Word document into a PDF and stamp the company logo on the first page"

upskill find "review a React pull request for accessibility violations and performance regressions"

Add --json for machine output. --limit n to control result count (default 5).

Read the top result's score, text_score, vec, and name_match from match_reason. The strongest signal is name_match > 0 — that means a query word appears literally in the skill's name (e.g. you searched for docx editor and a skill called docx exists). When a name-match hits the top result, take that skill, almost without further checks. Otherwise:

• text > 0.8 and vec > 0.4 → confidently relevant
• text > 0.8 alone → keyword match but possibly off-topic semantically
• vec > 0.5 alone → semantic match without word overlap (paraphrase)
• both below 0.4 → weak match, consider skipping

Skip results with warnings: ["weak_description"] unless nothing better is available.

If the top result has ⚠ missing: command:foo lines, that's information, not a verdict. The agent decides: install foo (if cheap and safe), pick a different skill that doesn't need it, or warn the user. The registry won't bury the skill — it's still ranked on relevance.

Inspect

upskill inspect <skill_id>          # readable
upskill inspect <skill_id> --md     # only the SKILL.md body (pipe to a file)
upskill inspect <skill_id> --json   # full metadata

This returns the skill's full SKILL.md content plus its dependencies, missing-auth warnings, feedback stats, and the exact repo_url + commit + path it lives at. Read the SKILL.md and follow it. That's the contract — the skill author wrote instructions; you execute them.

Report

After you've actually tried a skill — whether it worked, failed, or you bailed — close the loop:

# it worked
upskill report <skill_version_id> --outcome success --task <kind>

# it failed; include codes if you can identify the failure mode
upskill report <skill_version_id> --outcome failure --code missing_dep:playwright --task <kind>

# you tried it, gave up, used something else
upskill report <skill_version_id> --outcome failure --code used_alt:cypress --task <kind>

# partial — completed but not perfectly
upskill report <skill_version_id> --outcome partial --code env_mismatch --task <kind>

The CLI silently no-ops if the user disabled telemetry at install. Call it anyway — the silent path costs nothing and the data path improves rankings for everyone.

<kind> is a short slug describing what you were doing: webapp-testing, pdf-extract, azure-deploy, etc.

Submit

Only if the user explicitly says they want to publish, and only when you've actually authored a skill folder during the task (a directory containing a SKILL.md at root). Ask first:

"Want me to publish this as a skill so other agents can use it?"

If they say yes:

upskill submit ./path/to/folder/

Submissions go to a review queue (pending_review). They don't appear in find results until promoted. The CLI silently no-ops if submissions weren't enabled at install — same pattern as report.

When to use this

• Most non-trivial tasks. Default to searching unless one of the cases below applies.
• Tasks where the user mentions a tool, framework, or service that might have a known skill (playwright, azure, react, pdf, terraform, etc.) — almost always a skill exists.
• Tasks where you'd otherwise be writing a non-trivial script or following a multi-step recipe from memory.

When NOT to use this

• One-line tasks. Just do them.
• The user has explicitly said "do it from scratch" or "don't pull anything from the internet."
• The task is too internal to the user's codebase for any community skill to apply (their private APIs, their proprietary domain logic).
• You've already searched once for this same task in the current conversation and found nothing useful.

Trust signals

Every result includes a match_reason block. Use it.

• name_match — count of query tokens that match the skill's name verbatim. The single most reliable signal. Any value > 0 is a strong vote. Example: query docx editor → skill docx → name_match: 1.
• path_match — query tokens matching the github locator path (org/repo/folder). Lighter signal than name_match.
• text_score — full-text keyword overlap (Postgres ts_rank). High = the query words appear in the description. Reliable but saturates.
• vec (vector similarity) — semantic similarity. High = the meaning matches even when wording differs. Catches paraphrases.
• score — combined. Final rank. Read this for "how confident am I in the top result".
• trust — verified (vendor-official, e.g. Anthropic / OpenAI / Vercel) > reviewed (curated org) > community (anyone).
• feedback_successes − feedback_failures — community track record. Negative = past agents struggled.
• github_stars + external_installs — popularity, used as a tiebreaker only.

A typical good top hit: score > 1.4, with at least one of name_match > 0 OR (text > 0.8 AND vec > 0.4). Take it, inspect, follow.

Why bother (the flywheel argument)

Every report call you make ranks the skill up or down for the next agent that searches for the same thing. Every submit call you make adds a new tool to the global toolbox. The registry gets smarter as more agents use it — but only if agents like you participate. The user already opted in by installing the CLI; do your part by closing the loop.