Method
Methodology
Playbooks are text we write for Grok Bot. Skill listings are a reading aid for public SKILL.md files, not a sandbox.
This directory has two kinds of pages. Grok Bot playbooks are
instructions we write for one job. Paste them into Grok Bot. Skill listings come from a
scheduled job that reads a fixed list of public GitHub repositories and looks for
SKILL.md files with YAML name and description. Task
pages and the homepage skill collection are editorial: we choose which interface jobs to
compare, and which skills belong on those short lists. The full index is everything the job kept.
Playbooks
A playbook covers one job, such as a phone line, an invoice reminder, or a post on X. It is not fetched from GitHub, and it is not an xAI product. The Pass / Review / Risk line on a skill listing is a text search of that file. It does not apply to a playbook. Read the risks on the playbook page itself.
Source
A skill enters the catalog when a public repo on that list contains a
SKILL.md we can fetch without signing in. If a repo has several copies of the
same skill (tests, examples, nested plugin folders), we keep the path that looks like the
real skill directory — usually under skills/ — not a test copy.
Short lists on a task page prefer an official org or a path that still receives commits. A popular monorepo is not enough; the date that matters is the last commit that touched this file.
Safety labels
Each listing has a static label: Pass, Review, or Risk. It is a regex pass over the skill body. We look for:
- Secret-file paths (
.env,id_rsa,credentials.json, SSH dirs). - A remote URL piped into a shell (
curl | sh). - Hosts used to siphon data (webhook.site, ngrok, pastebin).
- “Ignore previous instructions” phrasing.
Zero hits is Pass. One hit is Review. Two or more is Risk. We print the matching flags on the listing. We do not run the scripts, and we do not sandbox the agent.
Pass does not mean safe. A skill can be polite markdown and still tell the agent to rewrite production CSS or fetch a URL we have never seen. How to read a listing before you install is in the evaluation guide.
Dates, stars, scripts
The date on a listing is the last commit that touched this file when GitHub gives it to us — not the last push to an unrelated file in the same repo. If we cannot ask GitHub for that commit (no token when we refresh, or the API refuses), the date stays empty rather than faking one.
Stars are repository stars, labelled as such. We do not show install growth we cannot
audit. If the skill folder contains .py, .sh, .js,
or similar, the listing says so. Those files are never executed at build time; an agent
that follows the skill might run them on your machine.
Duplicates and licenses
Two skills with the same file text are treated as one. The later copy is dropped — usually a fork. Skills with no license can appear in the index. They stay off task comparison pages and off the homepage collection unless they come from Anthropic, Vercel Labs, or CloudAI-X and GitHub still has not published a license file. Those listings still say Unspecified.
License is taken from GitHub’s license field, then a LICENSE file next
to the skill or at the repo root, then package.json. A skill in an unlicensed
monorepo inherits that gap even if the markdown itself looks fine.
Refresh
Snapshots refresh from GitHub on a regular schedule. Unchanged files are not rewritten. Oversized files are skipped. A failed build leaves the previous site in place. The date on a listing stays the last change to that file. Submissions go to a private inbox; we read the file before it lands on a task page.
Result previews
A few listings include a demo screenshot from one run of the skill, with the prompt we used.
We keep that screenshot and prompt in this project; the GitHub refresh does not overwrite
them. Each demo is its own HTML page — a shared template would make the screenshots look the
same. After the pages exist, npm run capture-previews takes the screenshots
together. We only add a demo when the skill’s job is to produce a visible interface. Review-only
files, someone else’s company brand, and extra Three.js lesson files stay without one until
there is a distinct page to show.
What we will not claim
We do not rank skills by quality. We do not certify them. We do not promise the snapshot matches HEAD this minute. If a listing looks wrong, see corrections or email [email protected] with the URL and the GitHub path.