Template
Agent skills that teach coding agents to operate a Batocera arcade cabinet: ops, ROMs, display, tuning, maintenance. Claude Code plugin.
npx -y skills add t3chnaztea/batocera-skills --skill templateAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 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 when [the specific situations, symptoms, and phrases that should trigger this skill]. Pack the words someone would actually type or think when they hit this problem. Describe ONLY when to use it, never summarize the workflow inside. Keep the whole frontmatter under 1024 characters. End by naming what this skill is NOT for, pointing at the sibling skill that covers it.
SKILL.md
2.5 KB, as published. Nobody here has run it
Batocera Yourskill
One or two sentences: what this skill covers and that it assumes the connection
pattern, filesystem model, and safety doctrine from batocera-ops. Cross-
reference sibling skills by name (batocera-roms, batocera-display,
batocera-tuning, batocera-maintenance) rather than repeating their content.
Guidelines for a good Batocera skill
Delete this section in your real skill; it's guidance for authoring.
- Name:
batocera-<area>, lowercase and hyphens only. The directory name MUST equal the frontmattername. - Description: starts with "Use when…", lists concrete triggers and keywords, ends with a "not for X, use Y" pointer. No workflow summary (an agent will follow the description instead of reading the body).
- Original prose only. Do not paste text from the Batocera wiki or other docs — write the lesson in your own words and link the wiki as the canonical manual. Ship institutional knowledge the wiki doesn't have.
- Parameterize everything host-specific. Use
$BATOCERA_HOST, never a real IP; read passwords from env; never commit tokens, credentials, MQTT secrets, or personal ROM/library specifics. - Non-destructive doctrine. Prefer hide/move/append over delete/overwrite; back up configs and gamelists before editing; never inject synthetic input.
- Verify against ground truth. Show the reader how to confirm the change (read the generated config, launch + screenshot), not just make it.
- Keep
SKILL.mdunder ~500 lines. Push heavy detail intoreferences/*.mdand reusable code intoscripts/. Scripts should be--dry-run-first where they mutate, idempotent, and self-documenting in a header.
Overview
What this is and the core principle in 1–2 sentences.
When to use
Symptoms and situations (bullets). When NOT to use.
[Your sections]
Quick-reference tables, worked examples, the specific traps you learned. One excellent example beats five generic ones.
References
- references/topic.md — heavy detail loaded on demand.