Sota scout
Anti-slop Claude Code skills: ground Claude in measured reality — live GitHub SOTA ranking + real design-token extraction — instead of training-data priors.
npx -y skills add Dweeb1578/claude-grounding-skills --skill sota-scoutAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use BEFORE implementing any non-trivial feature, algorithm, data structure, integration, or architectural decision, and when choosing a library or approach. Finds and ranks state-of-the-art GitHub repositories for the problem at hand (a multi-signal score, not just stars) and distills each repo's key technique, so the implementation builds on proven SOTA instead of generic defaults. Also use when the user says "find the best/SOTA repo", "how do the top projects do this", or "what's the state of the art for X".
SKILL.md
3.5 KB, 763 tokens by cl100k_base, as published. Nobody here has run it
sota-scout
Overview
Ground implementation work in real, current, high-signal references instead of generating from priors. Given a description of what you're about to build, this skill searches GitHub, ranks candidates on recency/momentum/velocity/contributors/ releases/issue-health/security/buzz, and hands back the top repos plus condensed README/architecture material so you can lift their techniques into the task.
When to use
- Proactively, at the start of any non-trivial implementation, before writing code.
- Choosing between libraries, algorithms, or architectural patterns.
- The user asks for "the best way", "SOTA", "how the top projects do this".
When not to: trivial edits, pure refactors with no new approach, or when the user has already specified the exact library/approach to use.
How to run
Dependencies are installed by install.py (just httpx). Run the bundled script
by its full path — it works from any working directory:
python "$HOME/.claude/skills/sota-scout/scripts/scout.py" \
--query "<concise description of what we're building>" \
--lang <github-language-if-relevant> \
--top 8 \
--json repos.json
(scripts/scout.py is relative to this SKILL.md; use this skill's own directory.)
- Derive
--queryyourself from the task — use concise, canonical keywords (2-4 terms), not a sentence. GitHub repo-search ANDs terms and does not stem, so prefer the common noun form ("fastapi rate limit", not "rate limiting for my FastAPI app"). If results look thin or off-target, re-run with a variant of the key term ("rate limiter" vs "throttle", "vector db" vs "embeddings store"). - Set
--langto the project's language when it matters. - A GitHub token (
GITHUB_AUTH_TOKENin the repo.env) raises limits and enables more signals. Without it the script still runs, with a smaller pool — that's fine. - Flags:
--top N,--min-stars N(auto-relaxes if thin),--deep(extra enrichers),--no-technique(skip README fetch),--json PATH,--out PATH.
What you get
- stdout /
--out: a markdown brief — ranked repos with score, tier, the "why" (top contributing signals), README outline, and README/architecture excerpts. --json: structured results (scores, per-signal breakdown, technique excerpts).
What to do with it (don't stop at the list)
- Read the brief. For the top 3-5 repos, write a short technique card each:
- What's novel here (the core idea/algorithm/architecture).
- How it differs from the obvious/default approach.
- How to adopt it in our task — concretely, and whether it's adoptable in isolation or implies a larger change.
- Synthesise a recommendation: which technique(s) to use here and why.
- Then implement, building on those references. Cite the repos you drew from.
Treat the score as a way to order the shortlist, not a verdict — see
references/scoring.md for what each signal means and which are proxies.