OpenMinis / MinisSkills

# MinisSkills
A community collection of skills for Minis — reusable instruction sets that extend Claude's capabilities with specialized workflows, domain knowledge, and bundled resources.
---
## What is a Skill?
A skill is a directory containing a `SKILL.md` file (plus optional bundled resources) that Claude loads when it detects a relevant user request. Skills use a three-level loading system:
1. **Metadata** (`name` + `description` in frontmatter) — always in context, used for triggering (~100 words)
2. **SKILL.md body** — loaded into context whenever the skill triggers (keep under 500 lines)
3. **Bundled resources** — scripts, references, and assets loaded only as needed (unlimited size)
---
## Directory Structure
### Repository Layout
 [code] 
### Skill Directory Naming
- Use **lowercase kebab-case**: `my-skill-name`
- Be descriptive but concise (2–4 words is ideal)
- Use the domain or action as a prefix when it helps group related skills
- ✅ Good: `health-sleep-analysis`, `nano-banana`, `remote-dev-minis-app`
- ❌ Avoid: `MySkill`, `skill_for_doing_things`, `s1`
---
## SKILL.md Format
Every skill **must** have a `SKILL.md` with a YAML frontmatter block followed by Markdown instructions.
### Frontmatter (Required)
 [code] 
> **Why the description matters:** The `description` field is the primary trigger mechanism. Claude reads the skill name + description to decide whether to load the skill. A vague description leads to undertriggering. A good description covers both *what the skill does* and *when to use it*, with concrete phrases a real user might say.
### Optional Frontmatter Fields
 [code] 
### Full Anatomy
 [code] 
---
## Writing a Good Skill
### Instructions Style
- Write in the **imperative form**: "Fetch the file", "Parse the JSON", "Return a table"
- **Explain the *why*** behind requirements — don't just say `MUST do X`, explain why X matters. Claude understands reasoning and applies it more flexibly than rigid rules
- Use `ALWAYS` / `NEVER` sparingly; prefer reasoning over mandates
- Aim for **under 500 lines** in SKILL.md; if longer, split content into `references/` files with clear pointers
### Defining Output Formats
Use an explicit template block when the output structure is fixed:
 [code] 
### Including Examples
 [code] 
### Multi-Domain Skills
When a skill covers multiple frameworks or platforms, keep `SKILL.md` lean and delegate to reference files:
 [code] 
### Progressive Disclosure Pattern
For large skills, add a hierarchy:
1. `SKILL.md` — overview, decision logic, pointers to sub-references
2. `references/ .md` — deep detail, loaded only when relevant
3. `scripts/ .py` — executed directly without loading into context
---
## Evals (Optional but Recommended)
Skills with objectively verifiable outputs benefit from test cases saved in `evals/evals.json`:
 [code] 
**Tips for good eval prompts:**
- Write them the way a real user would — casual, with typos, abbreviations, specific file names
- Cover edge cases, not just the happy