hbardet/batch-features

Funcionalidades por lotes

Parte de entrada del flujo de trabajo. La otra parte es work-issue.

No estás archivando un volcado de backlog. Estás convirtiendo ideas aproximadas en issues a partir de los cuales un agente pueda planificar sin tener que rehacer tu descubrimiento. Eso significa un debate por elemento, luego una aprobación, y luego archivar.

Anuncia al inicio: «Estoy usando la skill batch-features para convertir esta lista en issues.»

Configuración

shared/ es el directorio junto a esta skill — ~/.agents/skills/shared/ cuando está instalada, o ../shared/ en un clon. Si una ruta shared/... no se resuelve, usa la otra.

1. Lee el repositorio: AGENTS.md (o CLAUDE.md) en la raíz. Es vinculante para las convenciones.
2. Lee .agent-skills/config.json si existe; si no, lee shared/config.md, haz las preguntas de primera ejecución y escribe el archivo.
3. Lee shared/tracker-adapter.md, shared/labels.md y shared/issue-template.md.
4. Detecta el gestor de incidencias. Examina las etiquetas e issues existentes para que los nuevos encajen.
5. Plantillas. Comprueba si el proyecto ya tiene una plantilla de issue (.gitlab/issue_templates/*.md, .github/ISSUE_TEMPLATE/*.md). Si la tiene, úsala y guarda su ruta en la configuración como issueTemplate. Si no, anota que al final ofrecerás una vez confirmar shared/issue-template.md en el proyecto.

El debate

Trabaja la lista elemento por elemento. Para cada uno:

1. Reformúlalo con tus propias palabras: qué es, a quién sirve, por qué ahora. Mantén la redacción original como cita textual bajo Intención en el cuerpo del issue — incluso cuando el resto esté en inglés.
2. Propón una interpretación concreta. No «¿qué quieres aquí?» sino «Entiendo esto como X, porque Y. Di la palabra si querías decir Z.»
3. Haz como máximo dos preguntas. Cada una debe ser específica, y cada una debe llevar un valor por defecto que el usuario pueda aceptar con una palabra. Pregunta aquello cuya respuesta más cambiaría lo que se construye. Si el usuario pidió una revisión exhaustiva, pregunta más; si no, dos.
4. Fija dos cosas: criterios de aceptación (cada uno observable y verificable) y tipo (feature / fix / refactor / chore). Nada más — ni tamaño, ni área, ni dependencias.

Si un elemento no puede fijarse tras el debate, márcalo como status::blocked con una nota de «necesita especificación» en lugar de adivinar. Archivar un issue vago es peor que no archivarlo.

No pases a archivar hasta que cada elemento haya sido debatido.

La tabla de revisión

Después del último elemento, presenta una única tabla para todo el lote:

| # | Título | Tipo |
|---|--------|------|
| 1 | ...    | feature |

Luego pide aprobación. El usuario puede editar títulos, eliminar elementos o cambiar tipos. No se archiva nada antes de esta aprobación.

Archivar los issues

Para cada elemento aprobado, en el orden que prefiera el usuario (por defecto orden de creación):

1. Crea el issue con la CLI del gestor de incidencias, el cuerpo según la plantilla del proyecto si la tiene, si no según shared/issue-template.md. Títulos y cuerpos en el language de la configuración (por defecto en).
2. Aplica etiquetas: status::ready y kind::<kind>. Registra el número del issue.
3. Informa las URLs de los issues.

Si la lista del usuario implicaba un orden («X puis Y»), anótalo en el cuerpo del issue bajo Notas — no crees una relación de dependencia ni una etiqueta.

Si el proyecto no tiene plantilla de issue y el usuario aceptó tu oferta, confirma shared/issue-template.md en la ruta esperada del gestor una vez, luego archiva. No lo crees en silencio.

Informe

Al final, imprime:

• Las URLs de los issues, una línea cada una.
• El resumen del lote: N archivados, M bloqueados.
• Una línea: «Para empezar a trabajar, di work-issue <n>.»

Barreras estrictas

• No se crea ningún issue sin la aprobación de la tabla de revisión.
• No se crea ningún issue con una sección Criterios de aceptación o Verificación vacía.
• No se crea ningún issue con un alcance adivinado: si es vago tras el debate, es status::blocked.
• Nunca reclames un issue ni comiences la implementación desde esta skill; eso es work-issue.