Auditoría de org a tareas
La versión hecha a mano de esto tomaba medio día: leer una auditoría larga, decidir qué va junto, escribir cada tarea con prioridad y definición de terminado, y luego tipearla en el sistema de seguimiento. Este skill se encarga de la lectura y el tipeado. La decisión sigue siendo de la persona.
Paso 1: preguntar antes de actuar
Pregunta en un solo mensaje y espera:
- ¿Qué org (alias CLI)? Confirma que no sea una org de producción de un cliente a menos que el compromiso permita escaneos de solo lectura allí.
- ¿Dónde van las tareas? ClickUp (qué lista) o GitHub (qué repositorio). Verifica que el servidor MCP correspondiente esté conectado; si no, detente y di cómo conectarlo.
- ¿Quién es el responsable de las tareas? Nombres de asignados, o déjalas sin asignar.
- ¿Hay algo que omitir? Algunos hallazgos son conocidos y aceptados. Decirlo ahora evita ruido después.
Paso 2: auditar
node audit.js --org <alias> --out ./out
Escribe out/findings.md y out/findings.json. Solo lectura: cada llamada es una consulta o un listado.
Paso 3: dar forma a las tareas
node to-tasks.js out/findings.json
Escribe out/tasks.json: una tarea por tipo de hallazgo y severidad, cada componente afectado como un elemento de lista de verificación, grupos largos divididos en lotes de 25, con prioridad, esfuerzo, etiquetas y criterios de aceptación.
Paso 4: revisar con la persona
Muestra la lista de tareas como una tabla: clave, título, prioridad, esfuerzo, cantidad de elementos de lista de verificación. Luego aplica el juicio que el script no puede:
- Fusionar o dividir donde la agrupación no coincida con cómo trabaja el equipo.
- Eliminar los hallazgos que la persona dijo que omitiera en el Paso 1.
- Destacar lo que parece pequeño pero no lo es (un usuario de integración con Modificar Todos los Datos es un hallazgo de seguridad y un hallazgo de control de cambios).
- Reescribir los criterios de aceptación cuando el equipo tenga su propia definición de terminado.
No crees nada hasta que la persona diga que la lista está correcta.
Paso 5: crear
Crea cada tarea aprobada a través del servidor MCP conectado, o para GitHub con node create-issues.js --repo propietario/nombre (previsualiza primero con --dry-run), con el título, descripción, prioridad, etiquetas, lista de verificación (lista de verificación de ClickUp o una lista de tareas de GitHub en el cuerpo) y criterios de aceptación. Registra la URL de cada tarea creada nuevamente en out/tasks.json bajo url.
Luego informa: cuántas tareas se crearon, dónde, y el tiempo desde el Paso 2 hasta la última tarea creada.
Reglas
- La auditoría nunca escribe en la org.
- No se crea ninguna tarea sin la aprobación de la lista.
- No hay nombres de clientes en nada que salga de la carpeta del compromiso.
- Si una llamada al sistema de tareas falla, detente, informa qué se creó y qué no, y no reintentes ciegamente.