to-issues

Descripción general de la skill to-issues

Qué hace to-issues

to-issues convierte un plan, una especificación o un PRD en tickets para el issue tracker que se puedan trabajar uno a uno. La skill to-issues está pensada para slices verticales tipo tracer bullet, así que cada issue debería representar un recorrido fino de extremo a extremo, no un bloque horizontal grande de una sola capa.

Quién debería usarla

Usa to-issues si necesitas tickets de implementación que realmente estén listos para ejecutar, especialmente para trabajo de producto, refactors, migraciones o entrega de funcionalidades. Encaja muy bien cuando quieres que el issue tracker refleje secuencias reales, dependencias y responsabilidades, en lugar de un backlog difuso.

Qué la hace diferente

El valor principal de la skill to-issues es su disciplina de slicing: prioriza issues que se puedan tomar de forma independiente y que atraviesen esquema, API, UI y tests cuando corresponda. También distingue entre slices AFK y slices HITL, lo que ayuda a separar el trabajo que se puede fusionar sin intervención humana de los elementos que requieren revisión o una decisión.

Cómo usar la skill to-issues

Instalación y configuración

Instala la skill to-issues con npx skills add mattpocock/skills --skill to-issues. Antes de usarla, asegúrate de que tu issue tracker, las etiquetas y el vocabulario de triage ya estén disponibles para el agente; la skill parte de esa configuración y señala explícitamente que quizá necesites /setup-matt-pocock-skills si no existe.

Dale la entrada correcta

Para obtener el mejor to-issues usage, proporciona el material de origen que quieres desglosar: un plan corto, una especificación, un PRD o un issue enlazado con comentarios. Si estás haciendo referencia a un ticket existente, incluye el número del issue, la URL o la ruta para que el agente pueda recuperar el cuerpo completo y los comentarios en lugar de adivinar a partir del título.

Flujo de trabajo recomendado

Parte del contexto actual de la conversación y luego deja que la skill reúna cualquier contexto que falte, inspeccione el codebase si hace falta y redacte slices tracer-bullet. Un buen enfoque de to-issues guide es pedir issues que sean:

• acotados, pero completos de extremo a extremo
• nombrados con la propia glosario del proyecto
• ordenados según dependencias reales, no según la estructura de archivos
• marcados como AFK cuando puedan fusionarse sin input humano

Archivos y señales que leer primero

Al evaluar o ampliar to-issues, empieza por SKILL.md, ya que el repositorio no tiene actualmente README.md, AGENTS.md ni archivos auxiliares de reglas. La señal práctica está en el texto del proceso y en las reglas de vertical slices, así que céntrate en la sección de proceso en lugar de buscar scripts ocultos o configuración extra.

Preguntas frecuentes sobre la skill to-issues

¿to-issues es solo para el seguimiento de issues?

En general, sí. to-issues está orientada específicamente al seguimiento de issues y a la descomposición del trabajo, no a la lluvia de ideas general ni a redactar roadmaps. Si necesitas notas de versión, documentación de arquitectura o listas de tareas que no estén pensadas para un issue tracker, quizá te convenga más un prompt genérico.

¿Qué debo aportar antes de usarla?

Las mejores entradas son un plan claro, contexto del codebase en su estado actual y cualquier convención del tracker que importe, como etiquetas o reglas de triage. Sin eso, to-issues todavía puede redactar issues, pero obtendrás títulos más débiles, una secuenciación menos precisa y más riesgo de desajuste de alcance.

¿Es apta para principiantes?

Sí, si puedes describir el trabajo con claridad. La skill se encarga de la parte difícil de convertir un objetivo grande en slices listos para ejecutar, pero los principiantes también se benefician de dar un único objetivo concreto y pedir issues en la terminología propia del proyecto.

¿Cuándo no debería usarla?

No uses to-issues cuando solo necesites una lista rápida de pendientes, cuando el trabajo sea demasiado ambiguo para dividirlo o cuando no exista un issue tracker. También es mala opción si quieres un único ticket grande en lugar de varios issues que se puedan entregar de forma independiente.

Cómo mejorar la skill to-issues

Aporta material de origen más sólido

La mejor forma de mejorar los resultados de to-issues es darle a la skill una fuente de verdad precisa: una sección del PRD, una nota de diseño o el issue exacto que quieres descomponer. Incluye restricciones que afecten a la implementación, como requisitos de rollout, áreas afectadas de la app o cualquier ADR que el trabajo deba respetar.

Pide calidad de slices, no solo cantidad

Un fallo habitual es obtener tickets demasiado amplios, demasiado por capas o demasiado dependientes entre sí. Pide una salida de to-issues que priorice slices de extremo a extremo, mantenga cada ticket demostrable y separe el trabajo AFK de las decisiones HITL para que la cola siga siendo accionable.

Itera sobre títulos, alcance y orden

Después de la primera pasada, ajusta los títulos de los issues para que encajen con el vocabulario del equipo y aprieta cualquier ticket que siga sintiéndose horizontal. Si la descomposición está cerca pero no del todo bien, pide una revisión que ajuste el orden de dependencias, divida slices arriesgados o haga más concretos los criterios de aceptación para el tracker que usas.