PTENES
MÓDULO 2.2

🗂️ Estructura del repositorio

Cada carpeta tiene un propósito claro. Entender la estructura de mp-skill/ y lo que permite encontrar una skill en segundos, decidir dónde crear la siguiente y saber qué es público y qué es privado.

9
Secciones
40
Minutos
Inter
Nivel
Práctico
Tipo
1

🌳 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`.
Raíz
4 docs + LICENSE
Servicio
docs, scripts, plugin
Buckets
6 carpetas en skills/
Promoción
README + plugin.json
2

⚙️ 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/

diagnose Investiga un bug o un comportamiento extraño de forma sistemática antes de proponer una corrección.
grill-with-docs Somete un plan a prueba frente a la documentación existente del proyecto y actualiza los ADR en línea.
triage Clasifica issues y tareas en categorías de prioridad rápida.
improve-architecture Audita la arquitectura del codebase y propone simplificaciones concretas.
setup-mp-skills Instala y configura todo el paquete de skills de Matt Pocock en un proyecto nuevo.
tdd Guía el desarrollo orientado a pruebas con red-green-refactor explícito.
to-issues Divide una idea o un plan en issues accionables en GitHub.
to-prd Convierte una conversación exploratoria en un PRD estructurado.
zoom-out Obliga a dar un paso atrás para revisar las premisas y la dirección del trabajo.
prototype Levanta un prototipo funcional descartable para validar una idea.

💡 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.

Frecuencia
Diaria
Enfoque
Código
Visibilidad
Publica
Tamaño
10 skills
3

🧰 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.

4

📦 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.

1

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.

2

export-conversation

Empaqueta una conversación en markdown para archivarla o compartirla. Solo aparece cuando realmente quieres guardarlo todo.

3

video-transcript

Transcribe y resume un video. Se usa ocasionalmente cuando alguien comparte una conferencia de 1 h.

4

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.

5

🔒 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.md raíz
  • ✓ Registradas en .claude-plugin/plugin.json
  • ✓ Listadas en el README.md del 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.md raíz que enlaza el SKILL.md.
  • 3. Agregar entrada en .claude-plugin/plugin.json.
  • 4. Actualizar el README.md del 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.

6

📄 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 principios

Quié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 agente

Convenciones 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.

7

📡 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/ o in-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.

8

🧬 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
Obligatorio
SKILL.md
Frontmatter
name + description
Trigger
"Usar cuando..."
Cuerpo
Markdown conciso

📌 Resumen del módulo

✓
Raíz compacta — 4 documentos, LICENSE, 3 carpetas de servicio, 1 carpeta `skills/`.
✓
6 buckets, 6 intenciones — engineering, productivity, misc, personal, in-progress, deprecated.
✓
Público vs. privado — decidido por bucket, no por una flag interna.
✓
Promoción en 4 pasos — mover carpeta + README en la raíz + plugin.json + README del bucket.
✓
CLAUDE/CONTEXT/README — tres públicos distintos: agente, principios, persona que llega.
✓
plugin.json y el manifest — sin una entrada ahí, la skill es invisible para el agente.
✓
SKILL.md = frontmatter + cuerpo — description con "Use when..." y lo que activa la skill.

Siguiente módulo:

2.3 — Convenciones de nomenclatura y granularidad de skills