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
- anombyte93/prd-taskmastertheir own version, first seen Nov 8, 2026
- charles-adedotun/sre-plugintheir own version, first seen Nov 8, 2026
- rajanrx/skillstheir own version, first seen Nov 8, 2026
- joeldevz/skynex-pitheir own version, first seen Nov 8, 2026
- AsiaOstrich/EngramGraphtheir own version, first seen Nov 8, 2026
- islandhopper81/claude-skillstheir own version, first seen Nov 1, 2026
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.
LambenthanSkilldaily-arxiv
每日从 arXiv 拉取新论文,过滤相关性,auto-ingest 高优先级论文,检测 SOTA 更新
Also in 5 projects that use this
LambenthanSkillexp-eval
实验判决门:Review LLM 独立评判实验结果 → 4 种判决路径 → 自动更新 claims confidence、ideas status、graph edges
Also in 5 projects that use this
skyllwtSkillexp-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
skyllwtSkillexp-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
phanghonghaoSkillposter
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
Other versions57 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 57
- skyllwt/OmegaWiki★ 1.7ksame name
- DAIR-AutoResearch/AutoSci★ 1.7ksame name
- PKU-DAIR/AutoSci★ 1.7ksame name
- skyllwt/AutoSci★ 1.7ksame name
- suboss87/FDEOps★ 940same name
- anombyte93/prd-taskmaster★ 608same name
- zaxbysauce/opencode-swarm★ 519same name
- ZaxbyHub/opencode-swarm★ 518same name
- hsantanna88/clo-author★ 262same name
- hugosantanna/clo-author★ 262same name
47 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
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
- Distinctive: line 35
Check built-in capabilities: Before searching, check if the requested capability is already available through built-in tools (Read for …
- Very specific: line 37
If no strong match, search external sources in priority order (see Source Prioritization).
- Very specific: line 77
Never auto-install. Pin exact versions (see references/discover-scoring.md).
- Very specific: line 78
Postinstall check: Before recommending any npm package, inspect its package.json for preinstall, install, or postinstall scripts.
- Distinctive: line 98
Never invent package names.
- Distinctive: line 99
Never recommend a package without checking recency and source.
- Distinctive: line 100
Never skip the approval step.
- Distinctive: line 101
Never recommend a bare repo URL without a pinned version or commit hash.
- Distinctive: line 102
Never rely solely on metadata -- always attempt Candidate Inspection.
- Distinctive: line 103
If marketplace CLI does not exist, skip silently and note the gap.
- Distinctive: line 104
Never search externally when built-in tools already handle the capability.
- Distinctive: line 105
Always persist discover results to JSON for future reference.
“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.
Files
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
- 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.
- Scan local skills by name and description.
- If no strong match, search external sources in priority order (see Source Prioritization). Treat official/local/verified registry sources as the default adoption path.
- 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.mdfor the full workflow. - Score candidates on relevance, popularity, recency, dependency weight, and source trust. Show the full weighted breakdown (see
references/discover-scoring.md). - Apply the Build vs Install threshold. If no candidate scores above 3.0, recommend a custom pipeline instead.
- Present ranked options with pinned versions and wait for explicit approval.
- Install only with approval and only when the environment supports it.
Source Prioritization
| Priority | Source | Condition | Trust Tier |
| 1 | Local skills/ directory | Always | Tier 1 (highest) |
| 2 | GitHub repos with SKILL.md | When gh is available | Tier 2 |
| 3 | npm packages with claude-code keyword | When npm is available | Tier 3 |
| 4 | General web search | Always available | Tier 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).
| Criterion | Weight | Scoring Guide |
| Relevance | 30% | 5 = exact match, 3 = partial overlap, 1 = tangential |
| Popularity | 20% | 5 = 1000+ stars, 3 = 100-999, 1 = <50 |
| Recency | 20% | 5 = updated within 30 days, 3 = within 6 months, 1 = >1 year stale |
| Dependencies | 15% | 5 = zero or minimal, 3 = moderate (5-15), 1 = heavy or native |
| Source trust | 15% | See trust tier mapping above |
Thresholds
| Score Range | Action |
4.0+ | Strong recommendation -- install with confidence |
3.0-3.9 | Viable with caveats -- list limitations |
<3.0 | Do 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.jsonforpreinstall,install, orpostinstallscripts. 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" }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
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.

