🌳 Visión general de la estructura
El repositorio mp-skill/ y está organizado en una raíz corta con tres tipos de elementos: archivos de documentación en la raíz, carpetas de servicio (docs, scripts, manifest) y la carpeta skills/ dividida en buckets. Mira el árbol completo en un solo lugar:
mp-skill/ ├── README.md # indice publico de skills ├── CONTEXT.md # quem e o autor, principios ├── CLAUDE.md # regras do repo para o agente ├── LICENSE # licenca de uso ├── .claude-plugin/ │ └── plugin.json # manifest do plugin Claude Code ├── docs/ # documentos longos, ADRs ├── scripts/ # automacoes auxiliares └── skills/ ├── engineering/ # codigo diario (publico) ├── productivity/ # workflow nao-codigo (publico) ├── misc/ # uso raro (publico) ├── personal/ # meu setup (privado) ├── in-progress/ # rascunhos (privado) └── deprecated/ # aposentadas (privado)
🔎 Lectura rápida del diseño
- • Raíz compacta: solo 4 archivos `.md` + 1 LICENSE + 3 carpetas de servicio.
- • Todo lo que se convierte en skill vive en
skills/: nada fuera de este directorio. - • Seis buckets, seis intenciones: ningún bucket compite con otro.
- • Visibilidad pública frente a privada y se decide según el bucket, no mediante una flag dentro del `.md`.
⚙️ skills/engineering/ — código diario
El bucket engineering/ guarda las skills que realmente usas cuando estás escribiendo, leyendo o revisando código. Son 10 skills, cada una con un propósito acotado y un verbo claro. Si una skill de aquí no se usa por semanas, pasa a misc/ — engineering no acumula experiencia.
Las 10 skills de engineering/
💡 Consejo práctico
Antes de crear una nueva skill en engineering/, lee los nombres de las 10 existentes. Si la nueva idea es variación de una de ellas; es mejor extender la existente que duplicarla. El bucket solo crece cuando aparece una intención realmente nueva.
🧰 skills/productivity/ — flujo de trabajo sin código
El bucket productivity/ existe para skills que orquestan el trabajo: conducir entrevistas, cerrar sesiones, escribir, decidir. Aquí no hay nada de compilar código. Son 4 skills, todas se usan semanalmente.
Las 4 skills de productivity/
-
1
grill-me — sesión adversarial: el agente cuestiona tu plan antes de que gastes tiempo ejecutándolo.
-
2
handoff — empaqueta el estado de una sesión para que el próximo agente continúe sin perder contexto.
-
3
brainstorm — explora la intención y los requisitos antes de escribir una sola línea de código.
-
4
doc-coauthoring — guía un flujo estructurado de coautoría de documentos largos.
📊 Por qué separar de engineering/
Las skills de productividad se activan en fases diferentes del trabajo: antes (brainstorm, grill-me), durante (handoff) o en paralelo (doc-coauthoring). Mezclarlo con engineering contamina los triggers del agente: intenta incorporar handoff en medio de un TDD, o tdd durante una conversación sobre PRD.
📦 skills/misc/ — uso poco frecuente
misc/ y el purgatorio. Skills que ya fueron útiles, todavía sirven en casos específicos, pero no merecen espacio mental a diario. Se quedan aquí precisamente para no llenar engineering ni productivity.
benchmark-models
Ejecuta un conjunto de prompts en varios modelos y compara las salidas. Es útil cuando evalúas una actualización de modelo; rara vez se necesita en un día normal.
export-conversation
Empaqueta una conversación en markdown para archivarla o compartirla. Solo aparece cuando realmente quieres guardarlo todo.
video-transcript
Transcribe y resume un video. Se usa ocasionalmente cuando alguien comparte una conferencia de 1 h.
scrape-doc
Captura una página HTML y la convierte en Markdown limpio. Resuelve un problema muy específico.
⬆️ Cuándo mover de misc/ a engineering/
Si notas que estás invocando una skill de misc/ más de 2x por semana, ya no es «rara». Promuévela a engineering/ o productivity/, añádelo al README y al plugin.json. También vale el camino inverso: una skill de engineering que lleve más de 1 mes parada baja a misc.
🔒 personal/, in-progress/, deprecated/
Los tres buckets privados. Todo esto está en el repo, pero no aparece en el README.md ni en el plugin.json. Saber la diferencia entre ellos evita llenar el catálogo público de borradores o de herramientas tan específicas que solo funcionan en tu máquina.
✓ Aparece públicamente
-
✓
Skills en
engineering/ -
✓
Skills en
productivity/ -
✓
Skills en
misc/ -
✓
Listadas en el
README.mdraíz -
✓
Registradas en
.claude-plugin/plugin.json -
✓
Listadas en el
README.mddel bucket
✗ Queda privado
-
✗
personal/— vinculada a mi setup -
✗
in-progress/— borrador sin terminar -
✗
deprecated/— retirada, conservada como referencia histórica - ✗ NUNCA aparece en el README raíz
-
✗
NUNCA entra en
plugin.json - ✗ NUNCA se menciona en el README del bucket
🛂 Regla de promoción
Para una skill salir de personal/in-progress/deprecated y entrar en engineering/productivity/misc, necesitas, en el mismo PR:
- 1. Mover la carpeta al bucket público correcto.
- 2. Agregar una línea en el
README.mdraíz que enlaza elSKILL.md. - 3. Agregar entrada en
.claude-plugin/plugin.json. - 4. Actualizar el
README.mddel bucket con la descripción de una línea.
Sin estos 4 pasos, la promoción está incompleta — y el agente podrá encontrar la skill, pero el catálogo humano no.
📄 CLAUDE.md, CONTEXT.md, README.md
Los tres `.md` de la raíz tienen públicos distintos. Cambiar uno por otro confunde tanto a las personas como al agente. Memoriza: README es para quien llega, CONTEXT para entender la intención y CLAUDE para que el agente opere.
README.md
público humanoÍndice navegable de las skills públicas. Cada skill enlazada a su SKILL.md. Quien llega a GitHub lee primero este archivo.
CONTEXT.md
intención y principiosQuién es el autor, por qué existe el repo, principios de diseño que orientan las decisiones (ej.: "las skills son pequeñas y enfocadas"). Estable, rara vez cambia.
CLAUDE.md
reglas del agenteConvenciones operativas: dónde crear skills, qué debe aparecer en README/plugin.json, restricciones de bucket. Claude Code lo lee automáticamente.
# Trecho real do CLAUDE.md deste repo Skills are organized into bucket folders under `skills/`: - engineering/ # daily code work - productivity/ # daily non-code workflow tools - misc/ # kept around but rarely used - personal/ # tied to my own setup, not promoted - in-progress/ # drafts not yet ready to ship - deprecated/ # no longer used Every skill in engineering/, productivity/, or misc/ must have a reference in the top-level README.md and an entry in .claude-plugin/plugin.json. Skills in personal/, in-progress/, and deprecated/ must not appear in either.
🧭 Consejo práctico
Cuando tengas dudas sobre dónde escribir una regla nueva, pregunta: ¿quién necesita leer esto? Si es una persona explorando el proyecto, va en CONTEXT o README. Si es el agente operando, va en CLAUDE. Mezclarlo todo en README es el error más común y lo que hace que el repo sea difícil de mantener.
📡 plugin.json y cómo Claude Code descubre skills
Claude Code no descubre tus skills por magia del filesystem. Lee un manifest en .claude-plugin/plugin.json que enumera explícitamente cada skill pública. Sin una entrada en el manifest, la skill existe en el disco, pero el agente no la ve.
// .claude-plugin/plugin.json { "name": "mp-skill", "version": "1.0.0", "description": "Skills do Matt Pocock para Claude Code", "skills": [ { "name": "diagnose", "path": "skills/engineering/diagnose" }, { "name": "tdd", "path": "skills/engineering/tdd" }, { "name": "handoff", "path": "skills/productivity/handoff" } // ... uma entrada por skill publica ] }
✓ Buen uso del manifest
- ✓Una entrada por skill publicada
- ✓Path relativo a la raíz del repo
- ✓El nombre coincide con el
name:del frontmatter - ✓Actualizado en la misma PR que agrega la skill
✗ Errores típicos
- ✗Listar skills de
personal/oin-progress/ - ✗El nombre no coincide con el frontmatter
- ✗Path que apunta a un archivo, no a una carpeta
- ✗Olvidar la entrada — skill "invisible" para el agente
🔁 Flujo de descubrimiento
Claude Code carga el plugin.json al iniciar, lee cada path de la lista, abre el SKILL.md de cada uno y indexa el frontmatter (especialmente el description) en la memoria de triggers. Y es la description la que decide si la skill se activa en una conversación, no el nombre del archivo.
🧬 Anatomía de una SKILL.md
Toda skill y un único archivo: SKILL.md, dentro de una carpeta con el nombre de la skill. Frontmatter YAML al principio y cuerpo en Markdown debajo. Ya no hay más archivos obligatorios; si necesitas referencias, colócalas en references/ dentro de la carpeta.
--- <-- frontmatter YAML name: minha-skill description: Use when ... (descricao de trigger) --- <-- fim do frontmatter # Skill body Instrucoes em markdown para o agente seguir quando esta skill ativa. Pode ter exemplos, regras, checklists, snippets de codigo. Mantenha conciso: o agente vai ler isso TODA vez que a skill ativar. Cada linha gasta contexto.
🎯 Reglas del description
- • Empieza con "Usar cuando ..." o "Use this when ..." — el agente busca ese patrón.
- • Enumera activadores concretos: "when the user wants to debug a failing test", no "for debugging".
- • Incluye palabras clave que probablemente dirá el usuario ("rebind", "permission", "bucket").
- • Si hay casos en los que NO usar, menciona: "Skip if ...".
- • 1-3 frases. Los triggers consumen contexto en cada conversación.
📁 Estructura de carpetas de una skill
skills/engineering/diagnose/ ├── SKILL.md # obrigatorio ├── references/ # opcional, refs longas │ └── checklist.md └── examples/ # opcional, exemplos └── caso-1.md
📌 Resumen del módulo
Siguiente módulo:
2.3 — Convenciones de nomenclatura y granularidad de skills