Saltar al contenido

Herramientas de Análisis y Estimación (Stream C)

Las herramientas del Stream C te ayudan a entender tu codebase, estimar esfuerzo, detectar problemas de calidad y mantener las specs alineadas con la realidad.

Referencia Rápida

HerramientaDescripciónDisponibilidad
estimateCalcula tiempo, esfuerzo y costo para construir una funcionalidadIncluida
estimate_ai_costEstima los costos de tokens de IA para implementar una specIncluida
validateVerifica cuánto de un plan ha sido realmente construidoIncluida
detect_driftDetecta dónde la implementación diverge de una spec aprobadaIncluida
validate_workflowValida que el workflow de desarrollo coincide con el proceso previstoIncluida
auditAuditoría completa de configuración, arquitectura y cumplimiento del proyectoIncluida
audit_stackAnaliza el tech stack en busca de problemas de compatibilidad, seguridad y performanceIncluida
audit_trailConsulta el log de auditoría inmutableIncluida
generate_attestationGenera un documento de atestación de cumplimiento para una specIncluida
reverse_engineerGenera una spec a partir de código existente mediante ingeniería inversaIncluida
scan_projectEscanea el proyecto completo y analiza módulos en paraleloIncluida
learn_patternCaptura un patrón aprendido o buena práctica de tu codebaseIncluida
capture_learningCaptura un patrón a partir de experiencia de implementaciónIncluida
paradigm_reportReporte sobre paradigmas y patrones arquitectónicos en el proyectoIncluida
reality_checkValida un plan contra restricciones y suposiciones del mundo realIncluida
security_checkEjecuta un análisis de seguridad completo en el codebase y las specsIncluida
security_reportGenera un reporte de seguridad a partir del log de auditoríaIncluida
living_spec_watchObserva una spec para cambios y sincroniza automáticamente con el códigoIncluida
living_spec_statusObtiene el estado de la sincronización de specs vivientesIncluida
living_spec_coverageMuestra análisis de cobertura de tests para una spec vivienteIncluida
sync_spec_to_codeSincroniza criterios de aceptación de la spec a comentarios y tests del códigoIncluida
sync_code_to_specSincroniza cambios del código de vuelta a la spec como documentación vivienteIncluida
resolve_sync_conflictResuelve conflictos entre spec y código durante la sincronizaciónIncluida
snapshot_spec_hashesCrea una instantánea de hashes de contenido de specs para seguimiento de cambiosIncluida
auto_reconcileReconcilia automáticamente specs con cambios de código usando coincidencia de patronesIncluida
validate_annotationsValida las anotaciones de una spec por corrección y completitudIncluida
generate_annotationsGenera anotaciones para una spec basadas en buenas prácticasIncluida

Estimación

estimate

Calcula tiempo, esfuerzo y costo para construir una funcionalidad basándose en su plan.

Qué produce:

  • Rango de story points (optimista / realista / pesimista)
  • Rango de costo en dólares (basado en SDD_HOURLY_RATE)
  • Estimación de uso de tokens para implementación asistida por IA
  • Factores de riesgo que afectan la estimación
  • Desglose por fase de implementación

Cuándo usarlo: Antes de comprometer una spec a un sprint, o al comunicar el alcance a stakeholders.

Prompt: "Estimate spec SPEC-003 for project proj_abc123"
Prompt: "How much effort is spec SPEC-007 in project proj_abc123?"

estimate_ai_cost

Estima los costos de tokens de IA para implementar una spec — desglosado por modelo, fase y complejidad.

Qué produce:

  • Estimación de conteo de tokens por fase de implementación
  • Desglose de costos por modelo (GPT-4, Claude, etc.)
  • Multiplicadores de complejidad y factores de riesgo
  • Comparación entre diferentes modelos de IA

Cuándo usarlo: Al presupuestar desarrollo asistido por IA, o al elegir qué modelo usar para la implementación.

Prompt: "Estimate AI cost for spec SPEC-003 in project proj_abc123"

Validación

validate

Verifica cuánto de un plan ha sido realmente construido. Compara los criterios de aceptación de la spec con el código real.

Qué verifica:

  • Qué criterios de aceptación cumple el código
  • Cuáles faltan o están solo parcialmente implementados
  • Porcentaje de cobertura global
  • Sugerencias para cerrar las brechas

Cuándo usarlo: Después de completar la implementación, antes de marcar una spec como done.

Prompt: "Validate spec SPEC-001 against the code at /workspace/my-app/src for project proj_abc123"

detect_drift

Analiza cambios del código contra una spec aprobada y destaca dónde la implementación diverge.

Qué reporta:

  • Criterios que ya no coinciden con el código
  • Nuevos patrones de código no cubiertos por ninguna spec
  • Violaciones de la Constitución introducidas desde el último chequeo
  • Specs downstream afectadas por el drift (impacto en cascada)

Cuándo usarlo: Periódicamente a medida que el codebase evoluciona, o antes de cualquier lanzamiento importante.

Prompt: "Detect drift in spec SPEC-003 for project proj_abc123"
Prompt: "Check if my implementation matches the SPEC-001 spec"

validate_workflow

Valida que el workflow de desarrollo coincide con el proceso previsto — verifica que las transiciones de estado de specs, compuertas de revisión y prácticas del equipo sigan el workflow configurado.

Cuándo usarlo: Al incorporar un nuevo equipo a Planu, o después de un cambio de proceso para verificar la adopción.

Prompt: "Validate the development workflow for project proj_abc123"

Auditoría

audit

Auditoría completa de configuración, arquitectura y cumplimiento del proyecto. Genera una puntuación de calidad de 0 a 100.

Desglose del score:

  • Cumplimiento de principios SOLID
  • Métricas de clean code (naming, tamaño de funciones, acoplamiento)
  • Cumplimiento de capas de arquitectura
  • Adherencia a la Constitución
  • Señales de cobertura de tests

Cuándo usarlo: Durante code review, antes de mergear, o como chequeo periódico de salud del codebase.

Prompt: "Audit the code at /workspace/my-app/src for project proj_abc123"

audit_stack

Analiza el tech stack actual en busca de problemas de compatibilidad, seguridad y performance.

Qué verifica:

  • Compatibilidad de versiones de dependencias
  • CVEs conocidos y avisos de seguridad
  • Anti-patrones de performance en el stack elegido
  • Sugerencias de actualizaciones o reemplazos

Cuándo usarlo: Durante revisiones trimestrales o antes de un lanzamiento importante para detectar riesgos ocultos en el árbol de dependencias.

Prompt: "Audit the tech stack for project proj_abc123"

audit_trail

Consulta el log de auditoría inmutable. Filtra por specId, userId, eventType y rango de fechas.

Qué retorna:

  • Log cronológico de todos los cambios de specs y transiciones de estado
  • Quién activó cada evento y cuándo
  • Llamadas a herramientas que produjeron los cambios
  • Exportable para propósitos de cumplimiento

Cuándo usarlo: Durante auditorías de seguridad, revisiones de cumplimiento o al investigar una regresión en una spec.

Prompt: "Show the audit trail for spec SPEC-005 in project proj_abc123"
Prompt: "List all events by user alice in project proj_abc123 this month"

generate_attestation

Genera un documento de atestación de cumplimiento para una spec específica — confirma que todos los criterios de aceptación fueron cumplidos, revisados y validados.

Qué produce:

  • Atestación firmada con ID de spec y resumen de criterios
  • Timestamp de la ejecución de validación
  • Porcentaje de cobertura y excepciones abiertas
  • Listo para incluir en paquetes de cumplimiento

Cuándo usarlo: Cuando una spec debe pasar una revisión formal de cumplimiento antes del lanzamiento (SOC 2, HIPAA, ISO 27001, etc.).

Prompt: "Generate an attestation for spec SPEC-010 in project proj_abc123"

Ingeniería Inversa y Escaneo

reverse_engineer

Genera una spec a partir de código existente mediante ingeniería inversa.

Cuándo usarlo: Cuando tienes código funcionando pero sin spec — común al incorporar sistemas legacy, o cuando una funcionalidad fue construida ad-hoc y ahora necesita documentación formal.

Qué produce: Un spec.md completo generado por ingeniería inversa del código — criterios de aceptación inferidos del comportamiento de la implementación, esquema inferido de los modelos de datos, y brechas identificadas donde el comportamiento es ambiguo.

Prompt: "Reverse engineer my codebase at /workspace/my-app/src/auth and generate specs for project proj_abc123"

scan_project

Escanea el proyecto completo, descubre módulos, analiza cada uno en paralelo y detecta dependencias y anti-patrones entre módulos.

Qué produce:

  • Mapa de módulos con grafo de dependencias
  • Problemas de preocupaciones transversales y acoplamiento
  • Detección de anti-patrones (objetos God, deps circulares, abstracciones con fugas)
  • Brechas de cobertura de specs por módulo

Cuándo usarlo: Al incorporarse a un codebase grande y desconocido, o antes de un refactor importante.

TIP

scan_project es la forma más rápida de entender un codebase existente. Ejecútalo antes de crear cualquier spec en un proyecto legacy.

Prompt: "Scan the project at /workspace/my-app for proj_abc123"

Aprendizaje

learn_pattern

Captura un patrón aprendido o buena práctica de tu codebase para reutilización en specs futuras.

Tipos de patrones: architecture, convention, estimation, stack, quality

Cuándo usarlo: Cuando tu equipo ha establecido un patrón que Planu debería aplicar al generar specs, planes o estimaciones.

Prompt: "Teach planu that we always use repository pattern for database access in project proj_abc123"
Prompt: "Add an estimation pattern: API integrations always take 2x longer than expected for project proj_abc123"

capture_learning

Captura un patrón aprendido u oportunidad de mejora a partir de experiencia de implementación — con deduplicación semántica.

Cuándo usarlo: Después de un post-mortem de bug, un error doloroso de estimación, o cualquier descubrimiento de workflow que quieras aplicar a specs futuras.

Planu deduplica contra patrones existentes para que no acumules reglas redundantes.

Prompt: "Capture learning: when integrating third-party OAuth, always verify token expiry handling with an explicit test"

paradigm_report

Genera un reporte sobre paradigmas y patrones arquitectónicos en el proyecto — funcional, OOP, reactivo, event-driven, declarativo, etc.

Cuándo usarlo: Al incorporarse a un codebase desconocido, o al establecer estándares de código que deben aplicarse en las specs.

Prompt: "Generate a paradigm report for project proj_abc123"

reality_check

Valida un plan contra restricciones y suposiciones del mundo real.

Qué evalúa:

  • Factibilidad técnica dado el stack actual
  • Restricciones de dependencias
  • Realismo del cronograma basado en estimaciones históricas
  • Riesgos que podrían bloquear la entrega

Cuándo usarlo: Antes de comprometerse con una fecha límite, o cuando un stakeholder solicita algo que parece poco realista.

Prompt: "Reality check: can we build a real-time collaborative editor in 2 weeks for project proj_abc123?"

Seguridad

security_check

Ejecuta un análisis de seguridad completo en el codebase y las specs — OWASP Top 10, patrones inseguros y un score de seguridad (A–F) con detección de drift.

Qué verifica:

  • Vulnerabilidades de inyección (SQL, comandos, LDAP)
  • Autenticación y gestión de sesiones
  • Exposición de datos sensibles
  • Problemas de control de acceso
  • Mala configuración de seguridad

Cuándo usarlo: Antes de cualquier spec que involucre autenticación, autorización, pagos o datos de usuario.

Prompt: "Run a security check on spec SPEC-005 for project proj_abc123"
Prompt: "Security audit the code at /workspace/my-app/src/api for project proj_abc123"

security_report

Genera un reporte de seguridad a partir del log de auditoría — muestra amenazas, llamadas bloqueadas y recomendaciones.

Qué produce:

  • Resumen de eventos de seguridad del log de auditoría
  • Amenazas detectadas y bloqueadas
  • Vulnerabilidades abiertas ordenadas por severidad
  • Recomendaciones de remediación

Cuándo usarlo: Para revisiones periódicas de seguridad, paquetes de cumplimiento o después de un incidente de seguridad.

Prompt: "Generate a security report for project proj_abc123"

Specs Vivientes

Las specs vivientes se sincronizan con tu código automáticamente. Las herramientas a continuación gestionan esa sincronización bidireccional.

living_spec_watch

Observa una spec para cambios y sincroniza automáticamente con el código a medida que evoluciona la implementación.

Cuándo usarlo: Durante la implementación activa de una spec para mantener el documento de spec actualizado sin reconciliación manual.

Prompt: "Start watching spec SPEC-007 in project proj_abc123"

living_spec_status

Obtiene el estado de la sincronización de specs vivientes — muestra qué specs se están observando y su timestamp de última sincronización.

Prompt: "Show living spec status for project proj_abc123"

living_spec_coverage

Muestra análisis de cobertura de tests para una spec viviente — mapea archivos de test a criterios de aceptación.

Cuándo usarlo: Para verificar que todos los criterios de una spec viviente tienen tests correspondientes antes de marcarla como done.

Prompt: "Show living spec coverage for SPEC-007 in project proj_abc123"

sync_spec_to_code

Sincroniza los criterios de aceptación de la spec a comentarios y tests del código — inyecta referencias a criterios como comentarios estructurados en los archivos de implementación.

Cuándo usarlo: Al inicio de la implementación para dar al agente de IA (o desarrollador) un vínculo claro entre el código y los criterios.

Prompt: "Sync spec SPEC-007 criteria to the code in project proj_abc123"

sync_code_to_spec

Sincroniza cambios del código de vuelta a la spec como documentación viviente — actualiza la spec para reflejar lo que el código realmente hace.

Cuándo usarlo: Después de que la implementación diverge de la spec original de formas que deben capturarse como la nueva verdad.

Prompt: "Sync code changes back to spec SPEC-007 in project proj_abc123"

resolve_sync_conflict

Resuelve conflictos entre spec y código durante la sincronización — presenta cada conflicto para decisión humana.

Cuándo usarlo: Cuando sync_spec_to_code o sync_code_to_spec detecta contradicciones que requieren juicio humano.

Prompt: "Resolve sync conflicts for spec SPEC-007 in project proj_abc123"

snapshot_spec_hashes

Crea una instantánea de hashes de contenido de specs para seguimiento de cambios — permite hacer diff del contenido de specs a lo largo del tiempo.

Cuándo usarlo: Antes de un refactor importante o lanzamiento para establecer una línea base de detección de drift.

Prompt: "Snapshot spec hashes for project proj_abc123"

auto_reconcile

Reconcilia automáticamente specs con cambios de código usando coincidencia de patrones — aplica reglas de reconciliación aprendidas sin intervención humana.

Cuándo usarlo: Como paso de CI para mantener las specs alineadas después de cada merge.

Prompt: "Auto-reconcile all specs in project proj_abc123"

validate_annotations

Valida las anotaciones de una spec por corrección y completitud — verifica que las referencias a criterios, links a archivos y metadatos sean válidos.

Prompt: "Validate annotations for spec SPEC-007 in project proj_abc123"

generate_annotations

Genera anotaciones para una spec basadas en buenas prácticas — agrega metadatos estructurados, referencias a criterios y links de trazabilidad.

Prompt: "Generate annotations for spec SPEC-007 in project proj_abc123"

Ver También

Únete a la comunidadHaz preguntas, comparte feedback y conecta con otros desarrolladores usando Planu.
Unirse a Discord