Menu
Use when creating new skills or editing existing skills for the project or personal skill library
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Use when executing implementation plans with independent tasks in the current session
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when you have a spec or requirements for a multi-step task, before touching code
Use after implementation is verified and before merge — consolidates multiple spec iterations into a single final-state report, marks related specs, and records key lessons
Use when you want to evolve your own capabilities — create new tools to avoid repeating patterns, add hooks to improve your own behavior, build skills to accumulate domain knowledge, or override built-in tools to adapt to project needs. This is your self-iteration interface.
| name | compose:new-skill |
| hidden | true |
| description | Use when creating new skills or editing existing skills for the project or personal skill library |
A skill is a reusable reference guide — techniques, patterns, or tools — that helps agents find and apply effective approaches.
Skills are: Reusable techniques, patterns, tools, reference guides
Skills are NOT: Narratives about how you solved a problem once
Create when:
Don't create for:
| Type | Purpose | Examples |
|---|---|---|
| Technique | Concrete method with steps | condition-based-waiting, root-cause-tracing |
| Pattern | Way of thinking about problems | flatten-with-flags, test-invariants |
| Reference | API docs, syntax guides | tool documentation, library guides |
---
name: skill-name
description: Use when [specific triggering conditions]
---
# Skill Name
## Overview
Core principle in 1-2 sentences.
## When to Use
Bullet list with symptoms and use cases.
When NOT to use.
## Core Pattern
Before/after code comparison or step-by-step process.
## Quick Reference
Table or bullets for scanning common operations.
## Common Mistakes
What goes wrong + fixes.
name: letters, numbers, hyphens only (max 64 chars)description: third-person, starts with "Use when...", max 1024 charsTesting revealed that when a description summarizes the skill's workflow, agents may follow the description instead of reading the full skill content. A description saying "code review between tasks" caused the agent to do ONE review, even though the skill's flowchart clearly showed TWO reviews.
The trap: Descriptions that summarize workflow create a shortcut the agent will take. The skill body becomes documentation it skips.
# BAD: summarizes workflow — agent may follow this instead of reading skill
description: Use when executing plans - dispatches subagent per task with code review
# BAD: too much process detail
description: Use for TDD - write test first, watch it fail, write minimal code, refactor
# GOOD: just triggering conditions
description: Use when executing implementation plans with independent tasks
# GOOD: symptoms-focused
description: Use when tests have race conditions, timing dependencies, or pass/fail inconsistently
# BAD: first person
description: I can help you with async tests when they're flaky
# BAD: too abstract, doesn't include when to use
description: For async testing
# GOOD: third person, starts with "Use when"
description: Use when implementing any feature or bugfix, before writing implementation code
Agents read descriptions to decide which skills to load. Make it answer: "Should I read this skill right now?"
Use words agents would search for:
Use active voice, verb-first:
condition-based-waiting not async-test-helperscreating-skills not skill-creationroot-cause-tracing not debugging-techniquesskills/
skill-name/
SKILL.md # Main reference (required)
supporting-file.* # Only if needed
Keep inline: Principles, concepts, code patterns (short examples).
Separate files for:
Personal skills: .mimocode/skills/<name>/SKILL.md
Skills load into context — every token counts.
Target word counts:
Techniques:
# BAD: Document all flags inline
search-conversations supports --text, --both, --after DATE, --before DATE
# GOOD: Reference --help
search-conversations supports multiple modes and filters. Run --help for details.
# BAD: Repeat instructions from another skill
When searching, dispatch subagent with template...
[20 lines of repeated instructions]
# GOOD: Cross-reference
Always use subagents (50-100x context savings). REQUIRED: Use [other-skill-name] for workflow.
Cross-referencing: Use skill name only with explicit markers:
**REQUIRED BACKGROUND:** You MUST understand compose:tdd**REQUIRED SUB-SKILL:** Use eslint-setup@ links (force-loads files, burns context)One excellent example beats many mediocre ones. Choose the most relevant language:
Don't implement in 5+ languages. Don't create fill-in-the-blank templates.
Before deploying, verify the skill works:
For discipline-enforcing skills (TDD, verification requirements), watch for rationalization:
| Excuse | Reality |
|---|---|
| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
| "I'll test after" | Tests passing immediately prove nothing. |
| "The skill is obviously clear" | Clear to you ≠ clear to other agents. |
REQUIRED BACKGROUND: Use compose:tdd principles for testing discipline-enforcing skills.