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.
Installs into .claude/skills of the current project.
Are you the author of Template?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/t3chnaztea-template-batocera-skills)
---
name: batocera-yourskill
description: >-
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.
compatibility: Requires SSH access to a Batocera host (tested on v41-v43).
---
# 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 frontmatter `name`.
- **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.md` under ~500 lines. Push heavy detail into `references/*.md` and
reusable code into `scripts/`. 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](references/topic.md) — heavy detail loaded on demand.
