Menu
Use when creating new skills, editing existing skills, or verifying skills work before deployment
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Use when doing any creative work — creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when you have a written implementation plan to execute with review checkpoints
Use when implementation is complete and all tests pass — guides completion by presenting structured options for merge, PR, or cleanup
Use when receiving code review feedback, before implementing suggestions — requires technical rigor and verification, not performative agreement
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Basé sur la classification professionnelle SOC
| name | nobody-writes-skills |
| description | Use when creating new skills, editing existing skills, or verifying skills work before deployment |
Writing skills IS Test-Driven Development applied to process documentation. Write test scenarios, watch agents fail without the skill, write the skill, watch them succeed.
skill-name/
├── SKILL.md # Required: frontmatter + instructions
├── scripts/ # Helper scripts (optional)
└── references/ # Detailed docs (optional)
---
name: skill-name
description: Use when [specific triggering conditions]
---
# Skill Name
## Overview
Core principle in 1–2 sentences.
## When to Use
Symptoms and use cases.
## Process
Steps to follow.
## Common Mistakes
What goes wrong + fixes.
name: lowercase, hyphens, 1–64 chars, must match directory namedescription: start with "Use when...", max 1024 chars, describe triggers NOT workflowCritical: Description = WHEN to use, NOT what the skill does. Testing shows agents follow descriptions as shortcuts and skip the full skill body.
Run a pressure scenario with a subagent WITHOUT the skill. Document:
Write skill addressing the specific failures observed. Run same scenario WITH skill — agent should now comply.
Agent found a new rationalization? Add explicit counter. Re-test.
Do create for: Reusable techniques, non-obvious patterns, cross-project workflows Don't create for: One-off solutions, project-specific config, mechanically enforceable rules