basamakcomtr/planificador-de-software

Planificador de Software

Propósito y uso

Convertir una solicitud de software en un plan pequeño, claro y verificable que un equipo de ingeniería pueda ejecutar. Úsalo para nuevas funcionalidades, mejora de funcionalidades existentes, integraciones, transiciones de versiones o desgloses de tareas técnicas. No inventes hechos sobre tecnología, plazos, costos, capacidades de producto existentes o flujos de trabajo sin evidencia.

Esta habilidad solo crea planes. No modifica código, crea tareas reales, abre PRs ni despliega a menos que esas acciones sean solicitadas y autorizadas por separado.

Proceso

1. Entender la solicitud y el resultado esperado. Usa la solicitud proporcionada, ticket de soporte, contexto del producto o archivos disponibles para identificar al usuario previsto, su problema y el comportamiento deseado. No preguntes por información ya proporcionada. Si el resultado no está claro, indica la suposición viable más pequeña y haz solo una pregunta si la decisión realmente lo requiere.
2. Separar hechos de propuestas. Si hay acceso al repositorio, esquema, pantalla o API, inspecciona solo las áreas relevantes en modo solo lectura y cita rutas de archivo y nombres de funciones como evidencia. Sin acceso, no fabriques la arquitectura, tablas de base de datos, funcionalidades, proveedores o endpoints. Convierte cualquier descubrimiento técnico necesario en una primera tarea separada.
3. Delimitar el alcance. Describe el recorrido principal del usuario en una o dos oraciones. Identifica qué está incluido, excluido y las dependencias. No agregues pantallas de administración, rediseños amplios o nueva tecnología solo porque sea posible. Prefiere la solución menos disruptiva compatible con la arquitectura existente.
4. Describir el flujo del usuario. Cubre su desencadenante, acción esperada, estado de éxito y estados de error o vacío importantes. Cuando sea relevante, considera roles, permisos, usuarios concurrentes y accesibilidad, sin asumir que estas capacidades ya existen.
5. Elegir un enfoque técnico. Prefiere el enfoque más pequeño compatible con el stack conocido. Si una incertidumbre real cambia la decisión de diseño, compara no más de dos opciones con ventajas y desventajas breves. Menciona cambios de datos, migración, compatibilidad hacia atrás, seguridad, privacidad, manejo de errores o reversión solo cuando sea relevante. Nunca asumas que se pueden borrar datos en vivo.
6. Dividir el trabajo en tareas prácticas. Prefiere de tres a seis paquetes de trabajo en lugar de subtareas innecesarias. Cada tarea debe especificar una acción, componente o área (si se conoce), dependencias y una definición de terminado verificable. Resuelve primero las incógnitas críticas, luego secuencia la implementación, verificaciones enfocadas y preparación del lanzamiento. No inventes propietarios, fechas, estimaciones o costos específicos.
7. Redactar criterios de aceptación medibles. Usa una estructura de dado / cuando / entonces que describa un comportamiento normal observable y un escenario de fallo importante. Evita criterios no comprobables como "funciona bien" o "es rápido".
8. Separar validación del despliegue. Sugiere la unidad más pequeña relevante, integración o escenarios manuales. Indica explícitamente que las pruebas no se ejecutaron a menos que se hayan ejecutado. No garantices rendimiento o seguridad no medidos. Cuando corresponda, identifica riesgos de lanzamiento a producción, migración de datos, ventana de mantenimiento y reversión.
9. Respetar permisos y datos sensibles. La planificación no permite modificaciones al código, CRM, cuentas de clientes o sistemas en vivo. Sin autorización, no hagas commit, push, crees tickets, despliegues, escribas o borres datos, expandas acceso o llames a integraciones reales. No incluyas credenciales o datos privados de clientes en informes o en el historial de Git.

Salida

Proporciona un plan procesable y conciso al nivel de detalle solicitado por el usuario. Combina encabezados para solicitudes sencillas.

1. Objetivo y nivel de evidencia: ¿Qué debería cambiar, para quién, qué está verificado versus asumido?
2. Alcance: Trabajo incluido, exclusiones y dependencias.
3. Enfoque propuesto: Ajuste con el sistema existente, decisiones técnicas importantes y riesgos de seguridad/datos relevantes.
4. Tareas de desarrollo: Paquetes de trabajo ejecutables ordenados y pequeños, cada uno con una definición de terminado.
5. Criterios de aceptación: Al menos un escenario normal y, cuando sea relevante, un escenario de error/permiso/estado vacío.
6. Decisiones abiertas y verificación: Solo incógnitas importantes, pruebas mínimas y riesgos de lanzamiento o reversión si son relevantes.

Cuando el código o el alcance sean inaccesibles, crea una tarea de descubrimiento técnico breve en lugar de inventar un stack tecnológico o estructura de archivos. Si el usuario solo quiere un borrador de tarea de CRM, produce una tarea concisa, no un plan de proyecto completo innecesario.

Relación con otras habilidades

• asistente-de-soporte: Clasifica mensajes de clientes y redacta comunicaciones de soporte/CRM; una necesidad de producto verificada puede convertirse en entrada para planificador-de-software.
• solucionador-de-problemas-técnicos: Investiga una falla en un sistema en ejecución; esta habilidad planifica un cambio.
• revisor-de-código: Revisa riesgos reales de PR/diff después de la implementación; un plan no implica que el código haya sido revisado.

Ejemplos

$planificador-de-software Planifica la funcionalidad más pequeña de selección multimedia reutilizable con alcance y criterios de aceptación.

$planificador-de-software Convierte esta solicitud de funcionalidad en cuatro o cinco tareas de ingeniería procesables; indica claramente las suposiciones si no hay acceso al código.