--- version: 2.0.0 updated: 2026-03-11 tags: [issues, documentation, workflow, automation] --- # Command: auto-create-issue Crea un issue nuevo en `dev/issues/` y lo integra automáticamente a master **sin pedir confirmación**. ## Para el usuario ### Cuándo usar este comando Usar cuando estés completamente seguro del contenido del issue y quieras saltear la confirmación manual. El comando ejecuta todo el flujo automáticamente sin pausar. **⚠️ Advertencia:** Este comando no pide confirmación. Si no estás seguro, usa `/issues:create-issue` en su lugar. ### Sintaxis ```bash /issues:auto-create ``` El comando preguntará interactivamente por los datos necesarios, pero NO pausará para confirmar. ### Ejemplos **Ejemplo 1: Issue simple automatizado** ```bash /issues:auto-create # Título: Actualizar dependencias # Descripción: Upgrade de módulos Go ``` Crea, commitea, mergea y pushea automáticamente sin confirmación. **Ejemplo 2: Issue multi-parte automatizado** ```bash /issues:auto-create # Título: Sistema de notificaciones # Descripción: Email, SMS, y push notifications ``` Crea sub-issues y feature flag, integra todo automáticamente. ## Para Claude ### Precondiciones Verificar antes de ejecutar: - [ ] Directorio `dev/issues/` existe - [ ] Archivo `dev/issues/README.md` existe - [ ] Template `.claude/templates/issue.md` existe - [ ] Working tree limpio (para poder crear rama) ### Inputs Se necesitan los datos del issue. Si no se proporcionan, preguntar: - `titulo`: título corto y descriptivo - `descripcion`: objetivo/descripción de lo que se quiere lograr - `dependencias` (opcional): issues de los que depende ### Flujo obligatorio #### 1-7. Crear el issue (igual que `/issues:create-issue`) {{include: issue-numbering}} **Seguir los pasos 1-7 de `/issues:create-issue`:** 1. Determinar número del issue 2. Generar slug 3. Evaluar tamaño (simple vs multi-issue) 4. Crear issue desde template 5. Agregar sección de desglose si es multi-issue 6. Registrar feature flag si aplica 7. Actualizar índice en `dev/issues/README.md` **⚠️ DIFERENCIA CLAVE:** NO mostrar contenido ni pedir confirmación. Continuar directamente al paso 8. #### 8. Integración automática a master **SIN pedir confirmación**, ejecutar el flujo completo de git: ##### 8.1. Crear rama quick {{include: git-update-master}} ```bash git checkout master git pull --rebase git checkout -b quick/issues:create-issue- ``` ##### 8.2. Crear commits atómicos **Si es issue simple:** ```bash git add dev/issues/-.md dev/issues/README.md git commit -m "docs: crear issue -" -m "Crea issue : Objetivo: Tipo: issue simple Archivos: dev/issues/-.md, dev/issues/README.md Este issue define ." ``` **Si es multi-issue:** Commit 1 (archivos de issues - SOLO sub-issues, NO archivo principal): ```bash git add dev/issues/*.md dev/issues/README.md git commit -m "docs: crear sub-issues para -" -m "Crea sub-issues a-d: Objetivo: Sub-issues creados (sin archivo principal): - a-: - b-: - c-: Cada sub-issue es autocontenido con toda la información necesaria. Feature flag: (activado en último sub-issue)." ``` Commit 2 (feature flag): ```bash git add dev/feature_flags.json git commit -m "feat: agregar feature flag " -m "Agrega feature flag para issue multi-issue - Flag: Estado inicial: disabled Issue: Descripción: Se activará cuando todos los sub-issues estén integrados y validados." ``` ##### 8.3. Ejecutar tests (si aplican) {{include: run-tests}} ```bash go test -tags goolm ./... ``` - Si fallan → **STOP** y reportar error al usuario - Si pasan o no aplican → continuar ##### 8.4. Merge a master {{include: git-merge-to-master}} ```bash git checkout master git pull --rebase git merge --no-ff quick/issues:create-issue- -m "merge: quick/issues:create-issue- — crear issue -" -m "Integra issue : Tipo: [issue simple / issue multi-issue con N sub-issues] Archivos: dev/issues/*.md, dev/issues/README.md[, dev/feature_flags.json] Listo para implementación con /issues:fix-issue [a/b/...]" ``` ##### 8.5. Push a remoto ```bash git push ``` ##### 8.6. Limpiar rama local ```bash git branch -d quick/issues:create-issue- ``` ### Verificación final Informar al usuario: **Issue simple:** ``` ✓ Issue - creado e integrado a master automáticamente Tipo: issue simple Rama: quick/issues:create-issue- (mergeada y limpiada) Archivos creados: - dev/issues/-.md - dev/issues/README.md (actualizado) Para implementar: /issues:fix-issue ``` **Issue multi-issue:** ``` ✓ Sub-issues a-d creados e integrados a master automáticamente Tipo: issue multi-issue con N sub-issues (sin archivo principal) Rama: quick/issues:create-issue- (mergeada y limpiada) Archivos creados: - dev/issues/a-.md - dev/issues/b-.md - dev/issues/c-.md - dev/issues/README.md (actualizado) - dev/feature_flags.json (actualizado) ⚠️ NO se creó archivo principal -.md (solo sub-issues) Para implementar: /issues:fix-issue a [implementar sub-issues en orden] /issues:fix-issue b /issues:fix-issue c ``` ## Convenciones - **Sin confirmación**: diferencia clave con `/issues:create-issue` - **Flujo idéntico**: usa la misma lógica de creación de issues - **Trunk-based**: usa rama `quick/` y merge inmediato - **Commits atómicos**: separar issues de feature flags - **Mismo formato**: sigue template y convenciones estándar ## Troubleshooting ### Error: "Working tree not clean" **Causa:** Hay cambios pendientes que impiden crear rama. **Solución:** ```bash git status # Commitear o hacer stash de cambios primero git stash /issues:auto-create git stash pop ``` ### Error: "Tests failing" **Causa:** Los tests fallan después de crear el issue (raro pero posible si se modificó feature_flags.json). **Solución:** El comando se detiene automáticamente. Revisar logs de tests, corregir problema, y ejecutar `/git:push` manualmente para completar la integración. ### Error: "Merge conflict" **Causa:** Alguien más modificó `dev/issues/README.md` o `dev/feature_flags.json` simultáneamente. **Solución:** 1. Resolver conflictos manualmente: ```bash git status # Editar archivos en conflicto git add git commit git push git branch -d quick/issues:create-issue- ``` ## Reglas críticas - **NO pedir confirmación**: este es el comportamiento esperado y correcto - **MISMO formato que /issues:create-issue**: no tomar atajos en la calidad del issue - **STOP si tests fallan**: no integrar issues que rompan el build - **Informar claramente al usuario**: mostrar qué se creó y cómo continuar - **Trunk-based estricto**: siempre usar rama quick/ y merge inmediato - **Commits descriptivos**: seguir convención de mensajes de commit