La habilidad /setup-matt-pocock-skills

Fuente: The /setup-matt-pocock-skills Skill — traducción comunitaria no oficial al español.

Qué hace

setup-matt-pocock-skills responde tres preguntas sobre un repositorio: dónde viven las incidencias, cómo se llaman las etiquetas de triaje y dónde están los documentos del dominio. Registra las respuestas como archivos markdown bajo docs/agents/.

Esos archivos son lo único que varía entre repositorios. Las habilidades son idénticas en todas partes; leen docs/agents/issue-tracker.md en tiempo de ejecución y hacen lo que dice. Por eso el conjunto no está atado a GitHub, y por eso ningún archivo de habilidad necesita editarse para apuntar a otro lado. Invocarla con «conecta las habilidades a un gestor de incidencias propio» funciona con cualquier cosa que puedas conectar programáticamente, con cero cambios en las habilidades.

Es una habilidad guiada por prompts, no un script determinista. Lee tu git remote, tu CLAUDE.md existente, tu CONTEXT.md existente, propone lo que encontró y espera tu confirmación antes de escribir nada.

Cuándo recurrir a ella

La invocas escribiendo /setup-matt-pocock-skills; el agente no la usará por su cuenta. Está marcada deliberadamente como no invocable, así que ninguna otra habilidad puede dispararla por ti.

Recurre a ella una vez por repositorio, antes del primer uso de cualquier otra habilidad de ingeniería. Si triage, to-spec, to-tickets o wayfinder empiezan a adivinar dónde van tus incidencias, o aplican etiquetas que tu gestor no tiene, es que aún no se ha configurado aquí. Un repositorio ya a mitad de proyecto es un buen lugar para ejecutarla; la habilidad lee lo que ya hay y ningún trabajo anterior se desperdicia.

Requisitos previos

Escribe dentro del repositorio donde la ejecutas:

Escribe	Dónde
`issue-tracker.md`	`docs/agents/`
`domain.md`	`docs/agents/`
`triage-labels.md`	`docs/agents/`, solo cuando la habilidad `triage` está instalada
Un bloque `## Agent skills`	el que ya exista de `CLAUDE.md` / `AGENTS.md`

Todo es markdown publicado en commit. No hay modo de usuario ni modo global: la configuración vive en el repositorio, así que cada repositorio tiene su propia copia.

Las tres decisiones

Encabeza cada sección con la respuesta recomendada, y se salta cualquier exploración ya resuelta. La mayoría de las ejecuciones son dos confirmaciones y listo.

Decisión	Qué propone	Cuándo pregunta realmente
Gestor de incidencias	el que coincide con tu `git remote`	siempre: esta es la única elección real
Etiquetas de triaje	mantener los cinco nombres canónicos (`needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`)	solo si la habilidad `triage` está instalada
Documentos del dominio	contexto único: un `CONTEXT.md` más `docs/adr/` en la raíz	solo si detecta señales de monorepositorio, y entonces ofrece un `CONTEXT-MAP.md` multicontexto

Las opciones del gestor:

Opción	Dónde viven las incidencias	Necesita
GitHub	las GitHub Issues del repositorio	la CLI `gh`
GitLab	las GitLab Issues del repositorio	la CLI `glab`
Markdown local	archivos bajo `.scratch/<feature>/` en este repositorio	nada: ningún remoto
Otro	donde tú digas	un párrafo tuyo describiendo el flujo

Las tres primeras vienen como plantillas en la habilidad y funcionan sin más. El markdown local es una opción de primera clase, no un apaño: un proyecto en solitario sin remoto está totalmente soportado. Vale la pena repetir una advertencia: no uses markdown local si usas GitHub. Son alternativas, no capas.

«Otro» tampoco es un esbozo. Es la razón por la que Jira, Linear, Azure DevOps y Beads funcionan: describes el flujo, la habilidad registra tu prosa en docs/agents/issue-tracker.md, y las habilidades siguientes siguen la prosa. La comunidad ya lo hizo: una variante de Jira sobre MCP, una CLI de Gitea con forma de gh, un panel local hecho a mano.

Preguntas comunes

¿Tengo que usar GitHub?

No. GitHub, GitLab y markdown local bajo .scratch/ vienen como plantillas listas, y cualquier otra cosa funciona por la vía «otro». Esta es la pregunta más repetida del registro, más o menos en estas palabras: «atado a github», «¿puedo usar GitLab / Jira», «qué pasa con Azure DevOps». La respuesta cada vez es que el gestor es una respuesta de configuración, no una propiedad de la habilidad.

¿Tengo que reejecutarla tras actualizar las habilidades?

Preguntado directamente tras v1.1, Matt dijo que sí. El mensaje de cierre de la propia habilidad es más suave: dice que reejecutar solo hace falta para cambiar de gestor o empezar de cero. Ambas son defendibles y la razón del hueco es real: las plantillas semilla cambian entre versiones, así que un docs/agents/issue-tracker.md escrito por una versión anterior puede quedar rancio frente a las habilidades que ahora lo leen. Si una habilidad siguiente empieza a hacer algo distinto de lo que describen los documentos, reejecutar es el arreglo barato.

Escribió en CLAUDE.md, pero estoy en Codex.

Hueco conocido, aún abierto. La regla de selección de archivo es «edita CLAUDE.md si existe, si no AGENTS.md»: comprueba qué archivo existe, no qué entorno corre. Un repositorio con un CLAUDE.md sobrante de Claude Code recibirá su bloque ## Agent skills en un lugar que Codex nunca lee. Circulan dos soluciones: mover el bloque a AGENTS.md a mano, o mantener AGENTS.md canónico y hacer que CLAUDE.md sea un puntero de una línea hacia él. Si no existe ningún archivo, la habilidad pregunta cuál crear en vez de decidir, lo que confundió a gente que esperaba que simplemente decidiera.

No creó mis etiquetas de triaje.

No las crea. docs/agents/triage-labels.md es un mapeo: dice a /triage qué cadenas de tu gestor corresponden a los cinco roles canónicos. No ejecuta gh label create. En un repositorio GitHub nuevo las etiquetas genuinamente aún no existen, y esto se ha archivado como error más de una vez. Dos añadidos:

Si tu gestor ya usa los nombres canónicos, el mapeo es una tabla identidad y no hay nada que configurar. Ese es el caso común previsto, no un paso faltante.
Las etiquetas wayfinder:map y wayfinder:<type> de wayfinder tampoco se crean aquí, y gh issue create --label <faltante> falla en seco en vez de crear la etiqueta. Créalas a mano antes de la primera ejecución de wayfinder en un repositorio GitHub.

¿Puedo configurar aquí el comportamiento de las demás habilidades (cadencia del interrogatorio, formato de preguntas, tono)?

No. Configura tres cosas: gestor, etiquetas, diseño de documentos. Hubo peticiones directas de hacerla el hogar de preferencias por usuario, y la respuesta vigente es que las habilidades siguen siendo opinadas: «Config is death». Las preferencias van en tu CLAUDE.md como instrucciones llanas, que cada habilidad ya lee.

¿Puedo guardar la configuración en ~/.claude en vez de publicarla en cada repositorio?

Hoy no. Hay una petición abierta exactamente para esto de alguien que corre las habilidades en muchos repositorios, y no existe modo a nivel de usuario. Cada repositorio lleva su propio docs/agents/.

¿No es raro tener una habilidad que configura a las demás habilidades?

Una queja de larga data dice que sí, en estas palabras: «tener una habilidad para configurar la otra habilidad no me cuadra: significa que el LLM está configurando sus propias habilidades». El trueque es real y reconocido: la alternativa a un paso de configuración es duplicar instrucciones del gestor en cada habilidad que toca incidencias. La salida es markdown inspeccionable y editable, que es la mitigación: puedes leer cada archivo que escribió y cambiarlo a mano, y los ajustes del día a día son exactamente eso, no otra ejecución.

Funciona si

Existen docs/agents/issue-tracker.md y docs/agents/domain.md, más triage-labels.md si triage está instalado.
Aparece una sección ## Agent skills en el archivo de instrucciones que tu entorno realmente lee, con un resumen de una línea apuntando a cada uno de esos archivos.
El gestor que propuso coincide con el remoto que realmente usas, y las cadenas de etiquetas coinciden con etiquetas que realmente existen en tu gestor.
Después, /to-tickets publica sin preguntarte dónde viven las incidencias, y /triage aplica etiquetas en vez de inventarlas.
Nada en los archivos de habilidad cambió. Si la configuración editó un SKILL.md, algo salió mal.

Dónde encaja

setup-matt-pocock-skills es la configuración única para el flujo de ingeniería, la precondición que todo lo demás asume más que un paso de la cadena. Sus vecinas son sus lectoras: triage, que aplica el vocabulario de etiquetas escrito aquí; to-spec y to-tickets, que publican en el gestor nombrado aquí; y wayfinder, que lee la sección «Wayfinding operations» del mismo archivo del gestor para saber cómo se guardan los mapas y los tickets hijos. El diseño de documentos del dominio que registra es el que domain-modeling rellena después: crea CONTEXT.md y ADR de forma perezosa, cuando un término o decisión realmente se resuelve, así que un repositorio vacío tras la configuración es el estado esperado. Para saber a qué habilidad recurrir después, ask-matt enruta todo el conjunto.