Curso de Atlassian Rovo para Empresas — Gestión y colaboración

Comprender el modelo de Rovo Dev Free, Rovo Dev Standard, créditos mensuales, consumo por complejidad y límites configurables.

Diferenciar Rovo credits de Rovo Dev credits para evitar confusiones entre Rovo general y capacidades específicas de desarrollo.

Revisar qué funcionalidades requieren Rovo Dev Standard, como CLI, IDE, instrucciones custom avanzadas o uso completo según el contexto vigente.

Analizar la asignación de créditos por usuario y cómo impactan code reviews, tareas CLI, tareas en Jira y automatizaciones.

Definir criterios para asignar licencias a developers, tech leads, QA, platform engineers y perfiles de revisión.

Diseñar una política de uso para evitar consumo innecesario en tareas triviales o prompts mal formulados.

Configurar límites de consumo y controles de extra usage cuando la organización lo permite.

Planificar pilotos con créditos controlados, repositorios concretos y métricas de productividad y calidad.

Documentar requisitos por sitio, organización, workspace Bitbucket, organización GitHub y repositorios conectados.

Crear una checklist de readiness antes de activar Rovo Dev de forma masiva.

Activar o desactivar Rovo Dev a nivel de organización según permisos de organization admin.

Activar o desactivar features a nivel de site desde Rovo Dev settings cuando se requiere control más granular.

Separar configuración de Rovo Dev CLI, IDE, code reviews y funcionalidades beta según madurez del equipo.

Revisar early access o limited beta features antes de permitirlas en entornos productivos.

Gestionar acceso de usuarios y roles para que solo perfiles autorizados consuman créditos o activen workflows críticos.

Definir quién puede administrar Rovo Dev, quién puede usarlo y quién puede configurar repositorios o automatizaciones.

Controlar si una organización está preparada para MCP, datos externos, code reviews automáticas y generación desde Jira.

Crear normas de despliegue por site, producto, equipo, repositorio y sensibilidad de código.

Documentar decisiones administrativas: qué se activa, dónde, por qué, con qué riesgos y quién lo aprueba.

Preparar un proceso de revisión periódica de features, consumo, incidentes, adopción y feedback.

Instalar Atlassian CLI en macOS, Linux o Windows siguiendo el método aprobado por IT.

Actualizar ACLI a la versión más reciente antes de habilitar funciones de Rovo Dev CLI.

Crear el token scoped para Rovo Dev CLI y autenticar con `acli rovodev auth login`.

Validar autenticación, permisos, site asociado, usuario activo y disponibilidad de créditos.

Revisar comandos `acli rovodev --help`, `acli rovodev auth`, `acli rovodev run` y `acli rovodev config`.

Configurar terminal, shell, PATH, proxy, certificados y permisos locales para que la CLI funcione correctamente.

Preparar estaciones Windows con PowerShell y entornos Unix-like cuando el equipo lo requiera.

Diagnosticar errores de autenticación, token, site no activado, créditos agotados o permisos insuficientes.

Documentar instalación estándar para onboarding de nuevos desarrolladores.

Crear un procedimiento de revocación y rotación de tokens cuando cambia un usuario o equipo.

Iniciar Rovo Dev CLI con `acli rovodev run` y trabajar en modo terminal interactivo.

Formular instrucciones de desarrollo que incluyan objetivo, contexto, límites, archivos relevantes y criterios de aceptación.

Pedir a Rovo Dev que analice el repositorio antes de modificar archivos para reducir cambios impulsivos.

Usar Rovo Dev para generar código, revisar módulos, refactorizar, depurar errores, escribir documentación y crear tests.

Revisar cada propuesta antes de aceptar cambios sobre archivos, comandos o herramientas.

Mantener conversación técnica con el agente sin mezclar varias tareas incompatibles en una misma sesión.

Usar `/help` y ayuda contextual para consultar comandos, sesiones, prompts, memoria, herramientas y ajustes.

Diseñar prompts de trabajo para tareas pequeñas, cambios medianos y refactors complejos.

Evitar pedir “hazlo todo” cuando el repositorio necesita análisis, plan, tests y revisión incremental.

Crear una rutina de trabajo CLI: entender, planificar, cambiar, probar, revisar, documentar y cerrar.

Ejecutar instrucciones de una sola vez con `acli rovodev run [instruction]` para tareas repetibles o análisis puntuales.

Usar CLI no interactiva para generar resúmenes, preparar cambios pequeños, revisar código o crear documentación técnica.

Diseñar instrucciones deterministas para reducir resultados ambiguos en scripts o automatizaciones internas.

Ejecutar tareas con configuración específica mediante `--config-file` cuando un proyecto necesita parámetros aislados.

Combinar Rovo Dev con comandos Git, test, lint, build y validaciones previas o posteriores.

Usar salida estructurada o logs cuando el equipo necesita trazabilidad de lo ejecutado.

Evitar modo no interactivo para cambios de alto riesgo que requieren preguntas, revisión y confirmación humana.

Integrar CLI en flujos locales de desarrollo sin sustituir PRs, code owners ni CI.

Documentar patrones de uso aceptados para `run` en equipos y repositorios.

Crear ejemplos internos de instrucciones para documentación, test generation, refactor seguro y análisis de errores.

Iniciar Rovo Dev en modo web con `acli rovodev run --web` para trabajar desde interfaz web cuando encaja mejor que terminal.

Usar `acli rovodev serve [port]` para levantar server mode en escenarios de integración o trabajo controlado.

Comprender cuándo conviene terminal UI, web UI, server mode, IDE o Jira sandbox según tarea.

Proteger cualquier modo servidor evitando exposición innecesaria de puertos, proyectos y sesiones locales.

Diseñar laboratorios donde server mode se usa para probar integración, automatización o sesiones compartidas de forma segura.

Revisar logs, estado de sesión y errores cuando el servidor no responde o falla una herramienta.

Evitar abrir server mode en redes compartidas sin autenticación, control de host y aislamiento.

Documentar puertos, alcance, entorno, proceso de parada y responsables de server mode.

Comparar server mode con automatizaciones Jira y Bitbucket Pipelines para elegir la vía adecuada.

Crear criterios corporativos para permitir o bloquear server mode según riesgo y necesidad real.

Usar `acli rovodev run --worktree` para ejecutar Rovo Dev en un Git worktree aislado.

Mantener el checkout principal limpio mientras se experimenta con cambios generados por IA.

Crear nombres de worktree por feature, bug, spike o Jira key para facilitar trazabilidad.

Revisar diferencias entre ramas, worktrees y sandboxes cloud de Jira.

Usar worktree mode para prototipos, refactors, alternativas de solución y pruebas sin ensuciar el directorio principal.

Limpiar worktrees antiguos para evitar ramas olvidadas, cambios no revisados o consumo de disco.

Diseñar flujo de PR desde worktree con commits pequeños, tests y revisión humana.

Evitar usar worktree mode como excusa para aceptar cambios masivos sin comprenderlos.

Documentar comandos Git asociados: status, diff, branch, worktree list, worktree remove y cleanup.

Crear una política de uso de worktrees para equipos con repositorios grandes o monorepos.

Gestionar sesiones para mantener contexto entre interacciones sin repetir todo el histórico de la tarea.

Usar `/new` y `/sessions new` para separar tareas independientes y evitar contaminación de contexto.

Restaurar sesiones con `--restore` cuando se necesita continuar un trabajo anterior.

Renombrar sesiones con títulos útiles vinculados a issue, PR, feature, bug o spike.

Forkear sesiones para probar alternativas de solución sin perder el contexto principal.

Usar `/clear` cuando el historial deja de ser útil o contiene decisiones obsoletas.

Usar `/prune` para reducir tamaño de contexto conservando lo importante y eliminando resultados de herramientas.

Diseñar una disciplina de sesiones: una tarea principal por sesión, resumen final y cierre técnico.

Exportar o documentar aprendizajes relevantes antes de borrar o limpiar sesiones.

Evitar sesiones gigantes con cambios inconexos que dificultan revisión y aumentan coste.

Usar memoria para retener preferencias, estándares, decisiones de arquitectura, patrones y flujos habituales.

Diferenciar memoria de usuario en `~/.rovodev/AGENTS.md` y memoria de proyecto en `AGENTS.md` o `AGENTS.local.md`.

Inicializar memoria del proyecto con `/memory init` para que Rovo Dev analice setup, comandos y patrones del repositorio.

Usar `/memory reflect` para incorporar aprendizajes de una sesión a la memoria del proyecto.

Escribir memoria con ejemplos concretos, rutas, comandos y decisiones reales en lugar de consejos genéricos.

Documentar testing strategy, arquitectura, convenciones, dependencias externas, deuda técnica y gotchas del proyecto.

Separar memoria compartida de memoria local para no commitear preferencias personales o datos sensibles.

Revisar memoria después de cambios de arquitectura, framework, comandos o estructura de repositorio.

Evitar memorias enormes que consumen contexto y reducen precisión del agente.

Tratar `AGENTS.md` como documentación técnica viva y revisable por el equipo.

Editar configuración con `acli rovodev config` y entender el archivo `~/.rovodev/config.yml`.

Comprender estructura YAML, defaults razonables y opciones jerárquicas de comportamiento.

Configurar preferencias de respuesta, herramientas, modelos, permisos y experiencia de trabajo según equipo.

Compartir recomendaciones de configuración sin imponer ajustes personales que no pertenecen al repositorio.

Mantener configuraciones separadas por entorno cuando se trabaja con varios proyectos o clientes.

Usar `--config-file` para crear configuraciones alternativas aisladas.

Revisar compatibilidad entre configuración CLI e IDE, ya que ambas comparten ajustes de Rovo Dev.

Documentar parámetros críticos para onboarding, seguridad, MCP, modelos y herramientas.

Evitar cambios de configuración que activen herramientas peligrosas sin revisión.

Crear una plantilla corporativa de configuración base para equipos de desarrollo.

Usar `/models` en modo interactivo para cambiar entre modelos disponibles en Rovo Dev CLI.

Diferenciar modelos para análisis rápido, refactor complejo, generación de tests, documentación o revisión profunda.

Revisar credit multipliers y coste relativo de modelos antes de estandarizar su uso.

Diseñar criterios de selección por tarea: complejidad, coste, latencia, sensibilidad y calidad esperada.

Comparar resultados de varios modelos sobre la misma tarea de laboratorio.

Evitar usar modelos de alto coste para consultas simples o tareas que puede resolver documentación local.

Documentar modelo recomendado por tipo de actividad y stack tecnológico.

Revisar límites de disponibilidad de modelos según plan, site, beta o configuración activa.

Combinar selección de modelo con prompts claros, memoria y contexto de proyecto.

Medir si un modelo mejora calidad real de PR, test, documentación o resolución de bugs.

Crear prompts guardados para tareas frecuentes: resumen de PR, test generation, refactor review, bug analysis o docs update.

Usar `/prompts` para abrir menú, ejecutar prompts concretos y añadir información adicional.

Diseñar prompts con variables, parámetros, archivos esperados y criterios de salida.

Separar prompts personales y prompts de equipo para no mezclar preferencias individuales con estándares corporativos.

Crear plantillas por stack: React, Java, Python, .NET, Node.js, Terraform, Kubernetes o SQL.

Evitar prompts largos y ambiguos que contienen demasiadas tareas sin orden ni verificaciones.

Incorporar checklist de validación al final de cada prompt reutilizable.

Versionar prompts importantes cuando forman parte del workflow del equipo.

Revisar prompts después de cambios en arquitectura, CI, calidad o procesos de PR.

Crear una biblioteca interna de prompts aprobados por engineering enablement o platform team.

Comprender que Rovo Dev puede pedir permisos para usar herramientas, leer, modificar, ejecutar o consultar recursos.

Gestionar aprobaciones Once, Session y Always según riesgo y frecuencia de uso.

Denegar herramientas explicando motivo cuando la acción es peligrosa o no cumple políticas del proyecto.

Configurar permisos para bash, PowerShell, archivos, MCP, herramientas externas y rutas sensibles.

Revisar qué comandos puede ejecutar Rovo Dev antes de conceder permisos permanentes.

Evitar approvals Always para comandos destructivos, instalación de paquetes, migraciones, deploys o cambios de secrets.

Crear perfiles de permisos por contexto: análisis, desarrollo local, QA, seguridad, documentación y CI.

Documentar herramientas autorizadas y prohibidas por repositorio.

Revisar historial de herramientas cuando aparece un cambio inesperado.

Convertir permisos en guardrails técnicos, no en obstáculos arbitrarios al desarrollo.

Comprender cómo Rovo Dev ejecuta comandos bash o PowerShell dentro del entorno de trabajo.

Revisar cada comando antes de permitir ejecución cuando afecta a archivos, paquetes, Git, red o servicios.

Configurar reglas para comandos habituales: test, lint, typecheck, build, format, git diff y grep.

Bloquear comandos peligrosos como `rm -rf`, deploy, terraform apply, kubectl apply, migrations productivas o git push no autorizado.

Usar YOLO mode solo en laboratorios aislados, nunca en repositorios productivos o con secrets.

Diseñar allowlists y denylists de comandos por stack y nivel de madurez del equipo.

Diferenciar comandos seguros de lectura y comandos que modifican estado local o remoto.

Registrar comandos ejecutados cuando forman parte de pruebas, CI o automatizaciones.

Crear sandboxes locales o worktrees para probar comandos potencialmente destructivos.

Formar a los equipos para no aceptar comandos por confianza ciega en la IA.

Crear subagentes con capacidades especializadas, system prompts propios y configuración de herramientas ajustada.

Entender que los subagentes reciben contexto suministrado por el agente principal y reducen carga del contexto principal.

Diseñar subagentes para revisión de seguridad, QA, documentación, performance, arquitectura, migraciones o análisis de dependencias.

Invocar subagentes explícitamente cuando la tarea requiere especialización o revisión independiente.

Configurar permisos de cada subagente según su rol, evitando que todos puedan editar o ejecutar comandos amplios.

Redactar prompts de sistema específicos, con alcance, límites, ejemplos y formato de salida.

Evaluar si un subagente aporta mejora real frente a una instrucción puntual.

Evitar demasiados subagentes solapados que confunden delegación y aumentan coste.

Versionar subagentes relevantes dentro de la configuración del equipo.

Crear un catálogo de subagentes aprobados con owner, propósito, permisos y ejemplos de uso.

Crear Agent Skills como instrucciones reutilizables para enseñar a Rovo Dev tareas específicas.

Organizar skills en ubicaciones built-in, user y project según alcance de uso.

Usar `~/.rovodev/skills`, `~/.agents/skills`, `.rovodev/skills` o `.agents/skills` según necesidad.

Definir cada skill mediante carpeta, `SKILL.md`, YAML header, instrucciones y recursos de apoyo.

Añadir scripts, documentación, plantillas o ejemplos como materiales complementarios de una skill avanzada.

Diseñar skills para testing, refactor seguro, release notes, seguridad, migración, arquitectura o documentación.

Evitar skills genéricas que repiten lo que ya está en memoria o en prompts reutilizables.

Probar cuándo Rovo Dev carga una skill y si aplica instrucciones con consistencia.

Mantener skills por proyecto en Git para que todo el equipo comparta comportamiento.

Crear governance de skills: revisión, owner, versión, propósito, ejemplos y retirada de skills obsoletas.

Comprender MCP como estándar para conectar modelos con datos, herramientas y servicios externos.

Usar el Atlassian MCP server conectado automáticamente cuando la funcionalidad lo permite.

Configurar servidores MCP externos desde `~/.rovodev/mcp.json` o con `acli rovodev mcp`.

Gestionar MCP mediante `/mcp` para ver estado, servidores disponibles, herramientas y activación/desactivación.

Conectar fuentes como documentación interna, APIs, bases de datos, observabilidad, repositorios o sistemas de ticketing.

Revisar cada llamada a MCP que pueda enviar datos fuera del sitio Atlassian o del entorno corporativo.

Aplicar permisos explícitos antes de permitir que datos salgan hacia terceros.

Documentar términos, políticas y consentimientos de cada fuente externa conectada.

Crear catálogo MCP aprobado con owner, finalidad, permisos, datos accesibles, riesgos y procedimiento de baja.

Decidir entre Teamwork Graph CLI y MCP según contexto, datos necesarios, seguridad y gobierno.

Instalar la extensión Atlassian en VS Code o IDE compatible como Cursor.

Autenticar Rovo Dev en el IDE y validar que site, créditos y feature de VS Code están activos.

Usar Rovo Dev en IDE para crear, revisar y refactorizar código sin salir del entorno habitual.

Aprovechar contexto del workspace, archivos abiertos y flujo de edición del desarrollador.

Accionar work items de Jira y commit de código en Bitbucket cuando el flujo lo permite.

Aplicar la misma configuración `~/.rovodev/config.yml` que en CLI para mantener consistencia.

Revisar diferencias entre trabajar en CLI, IDE y Jira sandbox.

Configurar extensiones, terminal integrada, Git, linters y test runners para que Rovo Dev pueda validar cambios.

Evitar usar el IDE como canal de cambios masivos sin PR, tests ni revisión.

Crear recomendaciones por equipo sobre cuándo usar IDE frente a CLI o Jira.

Utilizar Rovo Dev en Jira para transformar work items en cambios de código.

Preparar historias con descripción, acceptance criteria, contexto técnico, repositorio, branch y Definition of Done.

Entender la sesión cloud segura en sandbox dedicada, separada del entorno local del desarrollador.

Configurar branch details, variables, secrets, herramientas y entorno necesario para que el sandbox funcione.

Usar contexto de Jira, Confluence, repositorio y conocimiento de equipo cuando la modalidad lo permite.

Revisar y editar código generado dentro de la sesión antes de crear pull request.

Crear draft pull request desde sandbox para que el equipo revise y complete el merge.

Evitar work items ambiguos que obligan a Rovo Dev a inventar arquitectura o criterios.

Definir plantillas de Jira optimizadas para Rovo Dev: problema, alcance, ACs, pruebas, constraints y riesgos.

Documentar flujo end-to-end desde issue hasta PR con owners, límites y controles.

Conectar Bitbucket Cloud o GitHub Cloud con Jira para habilitar flujos Rovo Dev en Jira.

Validar repositorios públicos y privados con permisos de lectura/escritura para el usuario o conexión autorizada.

Revisar límite de tamaño de repositorio y estructura antes de usar Rovo Dev en Jira.

Configurar workspaces, organizations, apps, permisos y conexiones de repositorio al site Jira.

Diseñar naming de branches con issue keys para mejorar trazabilidad entre PR y Jira.

Mantener relación entre work item, branch, commit, PR, acceptance criteria y revisión.

Evitar repositorios no conectados, forks no autorizados o permisos inconsistentes.

Revisar diferencias operativas entre Bitbucket Cloud y GitHub Cloud.

Documentar cómo conectar nuevos repositorios al flujo Rovo Dev.

Crear checklist de repositorio listo para Rovo Dev: tamaño, permisos, CI, tests, instrucciones, owners y seguridad.

Configurar sesiones Rovo Dev en Jira con branch, entorno, variables, secrets y herramientas necesarias.

Preparar sandbox con dependencias, comandos de build, test, lint, typecheck y generación.

Configurar secrets sin exponer credenciales reales innecesarias ni claves de producción.

Definir qué herramientas puede usar el agente dentro de la sesión cloud.

Establecer variables de entorno para APIs mock, bases de datos de test, tokens limitados y endpoints no productivos.

Documentar diferencias entre sandbox cloud y entorno local del desarrollador.

Validar que el agente puede instalar dependencias, ejecutar pruebas y crear PR sin permisos excesivos.

Evitar sesiones de Jira para tareas que requieren acceso a sistemas internos no disponibles o no seguros.

Crear plantillas de sesión por stack y repositorio.

Revisar outputs de la sesión antes de convertirlos en PR revisable.

Activar Rovo Dev code reviews en repositorios Bitbucket y GitHub con permisos de admin necesarios.

Entender que Rovo Dev analiza pull requests para detectar problemas de calidad, seguridad, rendimiento y mantenibilidad.

Decidir si las reviews se ejecutan al crear PR, al crear PR y en cada commit, o solo de forma manual.

Revisar comentarios generados por Rovo Dev como apoyo a reviewers humanos, no como decisión final automática.

Configurar PRs vinculadas a Jira para que Rovo Dev pueda revisar requisitos y acceptance criteria.

Crear política de cuándo un comentario de Rovo Dev debe resolverse, discutirse o descartarse.

Evitar que code review IA sustituya ownership técnico, code owners, QA o pruebas automatizadas.

Medir utilidad de reviews por defectos detectados, ruido, tiempo ahorrado y feedback del equipo.

Diagnosticar fallos de review por cuentas no vinculadas, permisos, repositorios no soportados o configuración incompleta.

Crear estándares de activación por repositorio: crítico, experimental, librería, aplicación, plataforma o sandbox.

Configurar checks de acceptance criteria para validar si un PR cumple los requisitos del work item vinculado.

Escribir criterios de aceptación claros, medibles, positivos y enfocados en una sola cosa.

Colocar acceptance criteria en summary, description o campos custom reconocibles por el equipo.

Usar nombres de campos coherentes como Acceptance Criteria, Business Requirements, Functional Requirements o Definition of Done.

Asegurar que branch name o commit messages incluyen la Jira key adecuada para que Rovo Dev encuentre el work item correcto.

Evitar PRs vinculadas a varios work items cuando se necesita una comprobación clara de aceptación.

Activar o desactivar acceptance criteria checks por repositorio según madurez y ruido esperado.

Revisar falsos positivos y falsos negativos para mejorar plantilla de historias.

Documentar formato estándar de ACs para producto, QA y desarrollo.

Usar los checks como conversación de calidad, no como sustituto de QA funcional.

Crear carpeta `.rovodev` en la raíz del repositorio para guardar instrucciones de review.

Crear `.rovodev/.review-agent.md` con normas específicas de calidad, arquitectura, QA, seguridad y estilo.

Escribir instrucciones simples, accionables y separadas por tema para facilitar seguimiento.

Incluir patrones de archivos, convenciones de naming, ejemplos correctos, ejemplos incorrectos y temas a ignorar.

Agrupar instrucciones por categorías como Code quality, Architecture, Security, Testing, Performance o Domain rules.

Evitar instrucciones excesivas que generan comentarios ruidosos o contradictorios.

Iterar instrucciones después de varias PRs para reducir ruido y mejorar precisión.

Documentar qué reglas ya cubren linters o tests para que Rovo Dev no repita comentarios innecesarios.

Revisar cambios en `.review-agent.md` como cualquier archivo crítico del repositorio.

Crear plantillas corporativas de review por stack tecnológico y tipo de aplicación.

Crear reglas de Jira Automation que usan acciones Rovo Dev para generar código en tareas repetitivas.

Entender el modelo trigger, conditions y action dentro de automatizaciones Jira.

Configurar Generate code action para conectar con repositorio y abrir draft pull request.

Diseñar reglas que actúan solo cuando etiquetas, estado, tipo de issue o campos cumplen condiciones estrictas.

Usar automatizaciones para tareas repetibles a escala, no para trabajo complejo que exige conversación iterativa.

Tener en cuenta que Rovo Dev automation actions trabajan en modo restringido y no usan Teamwork Graph context.

Evitar reglas que generan PRs sobre issues ambiguas, sin acceptance criteria o sin repositorio claro.

Añadir acciones posteriores: comentario en issue, asignación, transición, notificación o actualización de campos.

Controlar límites de Jira Automation y consumo de créditos Rovo Dev.

Documentar cada regla con propósito, owner, condiciones, repositorios afectados y rollback.

Activar Rovo Dev en Bitbucket workspace settings cuando se va a usar en Pipelines.

Entender que Rovo Dev en Bitbucket Pipelines puede resumir cambios y explicar fallos de build en lenguaje claro.

Usar información de commits, work items Jira y datos de despliegue para generar resúmenes útiles.

Analizar steps fallidos y sugerencias de corrección sin sustituir revisión técnica del pipeline.

Aplicar la funcionalidad beta con especial cuidado en repositorios productivos.

Controlar permisos del workspace y relación con otras funcionalidades Rovo Dev del mismo entorno.

Diseñar plantillas de pipeline que incorporen análisis Rovo Dev en branches, PRs o despliegues concretos.

Evitar exponer secretos de pipeline en logs, prompts, comentarios o explicaciones generadas.

Medir utilidad por reducción de tiempo de diagnóstico de CI/CD y calidad de recomendaciones.

Documentar procedimiento para activar, desactivar y soportar Rovo Dev en Pipelines.

Revisar organizaciones GitHub que usan IP allow lists antes de activar code reviews Rovo Dev.

Configurar allow lists para que Rovo Dev pueda acceder a repositorios autorizados.

Entender limitaciones con GitHub Enterprise Server o configuraciones no soportadas.

Documentar organizaciones, repositorios y excepciones de red que afectan a code reviews.

Coordinar cambios con seguridad, platform engineering y admins GitHub.

Probar code review en repositorio no crítico antes de habilitar en repositorios sensibles.

Revisar fallos de acceso causados por allow lists, apps no autorizadas o cuentas no vinculadas.

Evitar relajar políticas de red sin aprobación formal.

Crear matriz de compatibilidad por organización GitHub, repositorio, site Jira y Rovo Dev plan.

Mantener allow lists actualizadas cuando Atlassian cambie requisitos o endpoints.

Comprender que Rovo Dev respeta permisos existentes de Atlassian y puede devolver resultados distintos según acceso del usuario.

Revisar qué datos de Jira, Confluence, Bitbucket, GitHub y herramientas conectadas pueden influir en respuestas.

Evaluar impacto de Teamwork Graph en calidad de contexto y también en gobierno de permisos.

Definir qué proyectos, espacios, repositorios y documentación puede usar cada perfil.

Limitar acceso a Confluence, issues, repositorios o knowledge bases sensibles antes de activar Rovo Dev ampliamente.

Revisar flujos donde MCP o terceros pueden sacar datos fuera del sitio Atlassian con aprobación del usuario.

Crear política de datos: código propietario, secrets, datos de clientes, incidentes, documentación confidencial y prompts.

Auditar permisos Atlassian antes de culpar a Rovo Dev por resultados incompletos o excesivos.

Evitar usar Rovo Dev con cuentas compartidas, admins genéricos o permisos excesivos.

Documentar controles de acceso como parte del gobierno de IA en ingeniería.

Preparar secrets y variables para sesiones Rovo Dev en Jira sin usar credenciales productivas.

Usar tokens de alcance limitado, expiración corta y permisos mínimos en repositorios, APIs y servicios de prueba.

Separar entornos de sandbox, desarrollo, staging y producción.

Evitar que Rovo Dev ejecute cambios sobre servicios reales desde una sesión de generación de código.

Documentar qué secrets son obligatorios para build, tests, mocks, APIs internas y generación de PR.

Revisar que los secrets no aparecen en logs, comentarios, archivos generados o pull requests.

Diseñar variables de entorno por stack: Node, Java, .NET, Python, Docker, Terraform o mobile.

Crear checklist de sandbox listo para Rovo Dev in Jira.

Revocar secrets usados en laboratorio después de pruebas sensibles.

Integrar seguridad de secrets con plataforma DevOps y políticas corporativas.

Preparar work items con suficiente contexto para que Rovo Dev pueda generar cambios útiles.

Pedir a Rovo Dev que explique plan, archivos afectados, riesgos y pruebas antes de escribir código.

Revisar código generado en sandbox, CLI o IDE antes de crear PR.

Crear draft PRs para que el equipo mantenga revisión humana, CI y ownership.

Usar ramas con Jira key para trazabilidad de acceptance criteria y PR.

Añadir commits pequeños y mensajes claros cuando el flujo lo permite.

Generar documentación y tests junto con la implementación.

Rechazar soluciones generadas que cambian demasiado alcance o arquitectura sin justificación.

Usar Rovo Dev para preparar notas de PR, resumen técnico y riesgos conocidos.

Medir tiempo desde issue ready hasta PR listo para review.

Usar Rovo Dev para analizar impacto de cambios antes de refactorizar.

Dividir refactors grandes en pasos pequeños, reversibles y cubiertos por tests.

Crear subagentes de análisis para localizar dependencias, patrones repetidos y zonas de riesgo.

Usar worktree mode para experimentar con alternativas sin alterar el checkout principal.

Aplicar Rovo Dev a migraciones de frameworks, versiones, APIs, librerías o estructura de carpetas.

Revisar lockfiles, build scripts, pipelines y documentación cuando una migración cambia dependencias.

Evitar refactors “cosméticos” masivos que dificultan review y aumentan riesgo.

Pedir validaciones explícitas: tests, lint, typecheck, build y smoke tests.

Documentar decisiones de refactor en ADRs o notas de PR.

Crear prompts y skills de migración por stack para repetir patrones seguros.

Usar Rovo Dev para crear unit tests, integration tests, contract tests y casos de regresión.

Pedir explicación de fallos de test antes de aceptar cambios de código.

Usar logs, stack traces, errores de CI y pasos de reproducción como contexto de debugging.

Evitar que Rovo Dev arregle tests modificando expectativas sin validar comportamiento real.

Crear prompts para “reproduce first, fix second, verify third”.

Analizar flakiness, dependencias externas, datos de prueba, mocks y problemas de entorno.

Usar Rovo Dev en Pipelines para explicar build failures y sugerir fixes.

Integrar QA con acceptance criteria checks y PR reviews.

Documentar bugs resueltos con causa raíz y prevención.

Crear skills de testing por lenguaje y framework.

Usar Rovo Dev para generar documentación desde código, tests, issues y decisiones técnicas.

Crear contenidos Confluence o propuestas de documentación cuando el flujo lo permite.

Pedir documentación con referencias a archivos reales y comandos verificados.

Actualizar README, guías de setup, API docs, ADRs, runbooks y troubleshooting guides.

Usar memoria y prompts para mantener estilo de documentación del equipo.

Evitar documentación inventada o no validada contra el código.

Conectar documentación con Jira, Confluence, repositorio y PR.

Crear prompts para onboarding de repositorios complejos.

Revisar documentación generada con owners técnicos.

Medir reducción de preguntas repetidas y mejora en onboarding.

Definir que todo cambio generado por Rovo Dev debe pasar por PR, CI, review y estándares de equipo.

Configurar code owners, reviewers obligatorios y branch protection cuando el repositorio lo requiere.

Usar Rovo Dev code review como primera capa de feedback, no como aprobación automática.

Combinar Rovo Dev con linters, static analysis, dependency scanning, SAST y tests.

Crear reglas para que Rovo Dev no mergee cambios ni ejecute despliegues productivos.

Revisar especialmente código de seguridad, autenticación, pagos, datos personales, infra y migraciones.

Documentar cuándo un comentario de Rovo Dev se acepta, descarta o convierte en issue.

Medir ruido de revisión IA y ajustar instrucciones custom.

Crear checklist de PR generada con IA.

Formar al equipo para mantener pensamiento crítico ante respuestas convincentes pero incorrectas.

Definir qué repositorios son candidatos a Rovo Dev y cuáles requieren restricciones adicionales.

Crear categorías: open source interno, producto, infraestructura, datos, seguridad, librerías compartidas y legacy.

Activar code reviews por fases empezando por repositorios de menor riesgo.

Configurar instrucciones custom por repositorio según stack, arquitectura y criterios de calidad.

Conectar repositorios a Jira para work item linking y acceptance criteria.

Revisar restricciones de tamaño, permisos, organización y workspace.

Diseñar políticas distintas para Bitbucket Cloud y GitHub Cloud.

Evitar habilitar Rovo Dev en repositorios con secretos históricos sin auditoría previa.

Crear plantilla de `.rovodev` por tipo de repositorio.

Documentar proceso de alta y baja de repositorios en Rovo Dev.

Identificar tareas repetitivas candidatas: small fixes, docs, tests, dependency updates, issue triage y boilerplate.

Diseñar Jira automation rules que crean draft PRs sin merge automático.

Usar Bitbucket Pipelines para resumir cambios y explicar fallos de pipeline.

Preparar prompts no interactivos para análisis de repositorios y generación de documentación.

Definir límites de automatización por riesgo, repositorio, rama, etiqueta o tipo de issue.

Añadir condiciones de seguridad antes de invocar Rovo Dev: label, status, assignee, component y repository.

Revisar coste en créditos de automatizaciones repetitivas.

Crear panel de seguimiento de PRs generadas por Rovo Dev.

Evitar automatizar tareas mal definidas que generan PRs ruidosas.

Crear una metodología “automate small, review always”.

Diagnosticar problemas de CLI por autenticación, tokens, site no activado, créditos, permisos o versión de ACLI.

Revisar errores de IDE por extensión, feature desactivada, configuración compartida, site o créditos.

Diagnosticar Rovo Dev en Jira por repositorio no conectado, permisos insuficientes, sandbox mal configurado o secrets ausentes.

Resolver code reviews fallidas por cuenta GitHub no vinculada, IP allow list, permisos o repositorio no soportado.

Investigar acceptance criteria que no se detectan por campo, descripción vacía, branch sin Jira key o múltiples work items.

Revisar problemas MCP por servidor no disponible, OAuth, permisos, herramientas bloqueadas o aprobación denegada.

Usar `/help`, documentación, logs y settings para aislar causas.

Crear runbook de soporte N1/N2 para errores frecuentes.

Documentar incidencias y ajustar onboarding, permisos, settings o plantillas.

Escalar a Atlassian Support con datos mínimos, entorno, repositorio, logs, site, feature y pasos reproducibles.

Revisar uso de Rovo Dev credits por CLI, code reviews, tareas en Jira y funcionalidades activas.

Medir consumo por usuario, equipo, repositorio, feature y tipo de tarea.

Relacionar créditos consumidos con outcomes: PRs revisadas, bugs detectados, tiempo ahorrado, tests creados y documentación actualizada.

Detectar uso ineficiente por prompts vagos, tareas excesivamente grandes o automatizaciones mal definidas.

Crear dashboards de adopción con uso, satisfacción, ruido, calidad y coste.

Medir lead time de PR, review time, defect leakage, CI failures y retrabajo antes y después.

Comparar Rovo Dev en CLI, IDE, Jira y automation para saber qué modalidad aporta más valor.

Revisar uso de modelos y complejidad de tareas cuando el coste se dispara.

Establecer límites y recomendaciones de consumo por perfil.

Presentar resultados a dirección con productividad, calidad, seguridad y coste equilibrados.

Crear owner de Rovo Dev dentro de engineering enablement, plataforma o DevEx.

Definir políticas de uso: repositorios permitidos, features activas, MCP, secrets, prompts, code reviews y automatizaciones.

Crear comité ligero con ingeniería, seguridad, plataforma, QA y admins Atlassian.

Lanzar piloto con equipos, repositorios, objetivos, métricas y feedback definidos.

Crear plantillas de Jira, `.rovodev`, `.review-agent.md`, `AGENTS.md`, prompts, skills y subagentes.

Formar a usuarios en uso responsable, revisión crítica, seguridad y control de herramientas.

Revisar incidentes, costes, feedback y calidad semanalmente durante el piloto.

Escalar por oleadas según madurez, valor, riesgo y soporte disponible.

Crear documentación interna de onboarding, FAQs, ejemplos y troubleshooting.

Convertir Rovo Dev en práctica de ingeniería gobernada, no en herramienta individual sin control.

Diseñar una implantación completa de Atlassian Rovo Dev para una empresa con Jira, Bitbucket, GitHub, Confluence y varios equipos.

Activar Rovo Dev en una organización o site de laboratorio, configurando features, usuarios, créditos y permisos.

Instalar Atlassian CLI, autenticar Rovo Dev y validar `acli rovodev run`, config, help, sesiones y modelos.

Configurar VS Code o Cursor con Rovo Dev en IDE y validar generación, refactor, debugging y unit tests.

Preparar un repositorio conectado a Jira con work items, acceptance criteria, branch naming, CI y PRs.

Crear `AGENTS.md`, memoria de proyecto, memoria local, prompts reutilizables y configuración YAML base.

Crear subagentes para QA, security review, documentación, arquitectura y análisis de bugs.

Crear Agent Skills para testing, refactor seguro, PR summary, troubleshooting y actualización documental.

Configurar MCP server de laboratorio, revisar herramientas disponibles, aprobar permisos y documentar riesgos.

Ejecutar una tarea desde Rovo Dev CLI, otra desde IDE y otra desde Jira sandbox generando draft PR.

Activar code reviews en Bitbucket o GitHub, configurar trigger automático/manual y acceptance criteria checks.

Crear `.rovodev/.review-agent.md` con instrucciones custom de review por stack, arquitectura, QA y seguridad.

Crear una Jira automation rule que invoque Rovo Dev para una tarea repetitiva y abra draft PR sin merge automático.

Configurar Bitbucket Pipelines con Rovo Dev beta para resumir cambios o explicar un fallo de build controlado.

Diseñar controles de seguridad: permisos de tools, bash/PowerShell, YOLO prohibido, secrets, MCP, repositorios y share de datos.

Crear métricas de adopción, créditos, ruido de review, defectos detectados, tiempo ahorrado y satisfacción del equipo.

Preparar runbook de troubleshooting para CLI, IDE, Jira, code reviews, MCP, Pipelines, permisos y créditos.

Presentar la solución final defendiendo arquitectura, configuración, seguridad, funcionalidades habilitadas, límites, costes y roadmap.