agentleFS
Sign inStart free
oneafrikanoneafrikan/the-grid/skills/skill-scout/SKILL.md

skill-scout

Skill4 starsChanged 8 days agoMITView on GitHub

Scout public agent-skill directories (ranked by installs) and propose new skills for the-grid, deduped against what is wired. Use when the user says "skill-scout", "find new skills" or "what skills should I add".

23 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use context-budget.

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.
  • get-proofpilotSkill

    context-budget

    Audits Claude Code context window consumption across agents, skills, MCP servers, and rules. Identifies bloat, redundant components, and produces prioritized token-savings recommendations.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 22 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read each skill's name: from its frontmatter.

    line 26
  2. Distinctive:

    Keep the proposal short and skimmable.

    line 65
  3. Distinctive:

    Read a section only when its condition applies.

    line 68

“Common” is measured: kept by at least 6 in 10 of the 22 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

skill-scout

Find popular Claude skills the-grid doesn't have yet, and propose them — ranked by install count. Propose only. Never add submodules or run wire.sh; the user adds skills via the-grid's normal flow (git submodule add … && bash scripts/wire.sh).

How to run

  1. Gather candidates.
    • Ranked web directories: WebFetch each listing page and pull the ranked rows — skill name, popularity number (installs), and source owner/repo. Normalise install counts ("1.8M" → 1_800_000) so they sort.
    • Local library submodules: read them straight off disk — categories/*.md for awesome-list indexes, or grep SKILL.md frontmatter for real collections. These have no install count — keep them in a separate, unranked pile.
  2. Load what the-grid already has. From the repo root (GRID_DIR, default the repo this skill lives in):
    • Root-level skills: top-level directories containing a SKILL.md.
    • Submodule skills: repos/*/**/SKILL.md (one or more skill dirs per submodule).
    • Read each skill's name: from its frontmatter. Also note the source repo of each submodule (git config -f .gitmodules or the repos/<name> path) so a match on either skill name or source repo counts as "already have it".
  3. Dedupe. Drop any candidate whose skill name OR source repo the-grid already carries. Matching is case-insensitive; compare on the bare skill name (ignore owner/ prefixes) and on the owner/repo source.

  4. Rank and propose. Sort the ranked-directory survivors by install count, descending. Present the top ~15 as a table:

    SkillInstallsSource (owner/repo)Why it fits the-grid

    For "Why it fits", write one honest line covering fit for a developer workflow (dev workflow, debugging, git, planning, testing, infra/ops). If a candidate is a poor fit, say so plainly rather than inventing a reason — or omit it.

    Then, separately, surface a handful of relevant picks from the local index (repos/voltagent) grouped by category — no install column, since it isn't ranked. Flag that these are OpenClaw-ecosystem skills worth a manual look, not ranked recommendations.

  5. Hand off, don't act. End with the exact commands the user would run to add any they pick, but do not run them:

    git submodule add <repo-url> repos/<name>
git submodule update --init
bash scripts/wire.sh

Notes

  • "Based on installs" means the directory's own popularity ranking — we don't recompute it. If a source has no popularity signal, it doesn't belong here.
  • Skills already in the-grid via a submodule (e.g. repos/anthropic/skills/*, repos/gstack/*) must be deduped by source repo too — a popular skill from vercel-labs/skills is "new" only if that repo isn't already a submodule.
  • Keep the proposal short and skimmable. The user decides; this skill only scouts.

Sections

Read a section only when its condition applies; do not preload them.

  • sections/sources.md: read when gathering candidates (step 1)

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.

Check your setup, free