agentleFS
unclejobs-aiunclejobs-ai/second-claude-code/skills/discover/SKILL.md

discover

Skill41 starsChanged 7 days agoMITView on GitHub

Use when the current skills cannot handle a task and new skills are needed

57 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use daily-arxiv, exp-eval and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • LambenthanSkill

    daily-arxiv

    每日从 arXiv 拉取新论文,过滤相关性,auto-ingest 高优先级论文,检测 SOTA 更新

    Also in 5 projects that use this

  • LambenthanSkill

    exp-eval

    实验判决门:Review LLM 独立评判实验结果 → 4 种判决路径 → 自动更新 claims confidence、ideas status、graph edges

    Also in 5 projects that use this

  • skyllwtSkill

    exp-pilot-eval

    Pilot result evaluation — read pilot results, apply success criteria, update idea page (pilot_result, failure_reason if failed), generate PILOT_VERDICT_REPORT. Called by /ideate Phase 5 after /exp-pilot-run.

    Also in 4 projects that use this

  • skyllwtSkill

    exp-pilot-run

    Pilot experiment execution — read Pilot Spec YAML, write pilot code, run experiment(Confirm with the user before operation and require the applicant to conduct manual inspection), return results. Called by /ideate Phase 5. Does NOT modify wiki pages or judge pass/fail.

    Also in 4 projects that use this

  • phanghonghaoSkill

    poster

    HTML/CSS A4 海报生成。从沙龙/活动 Markdown 文件生成科技风 A4 海报 PDF/PNG。Use when user mentions: poster, 海报, 海报生成, make poster, generate poster, 活动海报, 沙龙海报.

    Also in 4 projects that use this

  • +6 more from Lambenthan
  • +1 more from skyllwt

The file

We split this skill into the rules it gives an agent

12 rules. 0 are common, 9 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 50 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Check built-in capabilities: Before searching, check if the requested capability is already available through built-in tools (Read for …

    line 35
  2. Very specific:

    If no strong match, search external sources in priority order (see Source Prioritization).

    line 37
  3. Very specific:

    Never auto-install. Pin exact versions (see references/discover-scoring.md).

    line 77
  4. Very specific:

    Postinstall check: Before recommending any npm package, inspect its package.json for preinstall, install, or postinstall scripts.

    line 78
  5. Distinctive:

    Never invent package names.

    line 98
  6. Distinctive:

    Never recommend a package without checking recency and source.

    line 99
  7. Distinctive:

    Never skip the approval step.

    line 100
  8. Distinctive:

    Never recommend a bare repo URL without a pinned version or commit hash.

    line 101
  9. Distinctive:

    Never rely solely on metadata -- always attempt Candidate Inspection.

    line 102
  10. Distinctive:

    If marketplace CLI does not exist, skip silently and note the gap.

    line 103
  11. Distinctive:

    Never search externally when built-in tools already handle the capability.

    line 104
  12. Distinctive:

    Always persist discover results to JSON for future reference.

    line 105

“Common” is measured: kept by at least 6 in 10 of the 50 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Resolve runtime paths before file or script operations.

Iron Law

Check existing tools before installing new ones.

Red Flags

  • "This package looks useful, let me install it" → STOP, because installation requires explicit user approval after scoring — never auto-install.
  • "It has 5000 stars so it must be safe" → STOP, because popularity alone is not safety — check for lifecycle scripts, license, recency, and dependency weight before recommending.
  • "I need an external tool for this" → STOP, because built-in capabilities (Read, WebFetch, Bash) must be checked first — install only when built-ins genuinely cannot handle the task.
  • "The README looks fine, skip the inspection" → STOP, because candidate inspection of the actual SKILL.md/README is mandatory for the top 3 — metadata alone is insufficient.
  • "It scored 2.5 but it's the only option" → STOP, because packages below 3.0 must not be recommended — suggest building a custom pipeline instead.

Discover

Find existing skills first, then search external marketplaces only when needed and safe. Discovery is registry-first: prefer the official/local/verified registry path before broader community search.

When to Use

  • The current skills do not cover the task
  • A pipeline references a missing capability
  • The user wants to browse or install additional skills

Workflow

  1. Check built-in capabilities: Before searching, check if the requested capability is already available through built-in tools (Read for PDFs, WebFetch for URLs, Bash for shell tasks, etc.). If built-in tools suffice, report that and skip external search.
  2. Scan local skills by name and description.
  3. If no strong match, search external sources in priority order (see Source Prioritization). Treat official/local/verified registry sources as the default adoption path.
  4. Candidate Inspection: Fetch and read README/SKILL.md for the top 3 candidates. If inspection is blocked (private repo, rate limit): (a) search package name + "review"/"tutorial", (b) check npm page for README, (c) note "inspection blocked" and apply a -1 score penalty. See references/discover-scoring.md for the full workflow.
  5. Score candidates on relevance, popularity, recency, dependency weight, and source trust. Show the full weighted breakdown (see references/discover-scoring.md).
  6. Apply the Build vs Install threshold. If no candidate scores above 3.0, recommend a custom pipeline instead.
  7. Present ranked options with pinned versions and wait for explicit approval.
  8. Install only with approval and only when the environment supports it.

Source Prioritization

PrioritySourceConditionTrust Tier
1Local skills/ directoryAlwaysTier 1 (highest)
2GitHub repos with SKILL.mdWhen gh is availableTier 2
3npm packages with claude-code keywordWhen npm is availableTier 3
4General web searchAlways availableTier 4 (lowest)

Trust tier scores: Tier 1 = 5, Tier 2 = 4, Tier 3 = 3, Tier 4 = 2. Bumps apply for verified orgs or scoped packages.

Evaluation Weights

Each criterion is scored 1-5. The weighted sum produces a final score (1.0-5.0).

CriterionWeightScoring Guide
Relevance30%5 = exact match, 3 = partial overlap, 1 = tangential
Popularity20%5 = 1000+ stars, 3 = 100-999, 1 = <50
Recency20%5 = updated within 30 days, 3 = within 6 months, 1 = >1 year stale
Dependencies15%5 = zero or minimal, 3 = moderate (5-15), 1 = heavy or native
Source trust15%See trust tier mapping above

Thresholds

Score RangeAction
4.0+Strong recommendation -- install with confidence
3.0-3.9Viable with caveats -- list limitations
<3.0Do NOT recommend. Suggest building a custom pipeline instead.

Safety

  • Never auto-install. Pin exact versions (see references/discover-scoring.md).
  • Postinstall check: Before recommending any npm package, inspect its package.json for preinstall, install, or postinstall scripts. Flag packages with lifecycle scripts and apply a -1 score penalty. Packages with obfuscated or network-calling lifecycle scripts must be rejected entirely.
  • Flag heavy or stale packages.
  • Degrade gracefully to local-scan-only mode if marketplace tooling is missing.
  • Flag repos with no LICENSE file or suspicious content.

Output Format

Return a ranked list AND save results to <plugin-data>/discovers/{query-slug}.json:

{
  "query": "...",
  "searched_at": "ISO-8601",
  "built_in_check": { "capable": false, "reason": "Read tool handles PDFs up to 20 pages but cannot extract tables" },
  "candidates": [{ "rank": 1, "name": "...", "source": "...", "score": 3.8, "install_cmd": "...", "inspection_notes": "..." }],
  "recommendation": "install|build-custom|use-builtin"
}

Gotchas

  • Never invent package names.
  • Never recommend a package without checking recency and source.
  • Never skip the approval step.
  • Never recommend a bare repo URL without a pinned version or commit hash.
  • Never rely solely on metadata -- always attempt Candidate Inspection.
  • If marketplace CLI does not exist, skip silently and note the gap.
  • Never search externally when built-in tools already handle the capability.
  • Always persist discover results to JSON for future reference.

Subagents

skill-searcher: { model: haiku, tools: [Bash, WebSearch], constraint: "return only real results; query sources in priority order" }
skill-inspector: { model: sonnet, tools: [Bash, Read], constraint: "fetch and read README/SKILL.md for top 3; verify claims" }
skill-evaluator: { model: sonnet, tools: [Read], constraint: "score consistently; show full breakdown with rationale" }

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.