lab10-org

Automatiza acciones en el navegador con agent-browser (CLI) para pruebas E2E, flujos de login y verificación de UI. Usar cuando se necesite abrir URLs, hacer snapshot del DOM, interactuar por refs (@e1, @e2) o capturar pantallas.

Define el flujo para crear y aplicar cambios de base de datos con Supabase en este proyecto. Usar cuando se requiera modificar el schema de la base datos, crear migraciones SQL, ejecutar migraciones, o recuperar una base local con migraciones corruptas.

Inspecciona la base de datos usando MCP de Supabase en modo solo lectura para debugging, exploracion de esquema y consultas informativas. Usar cuando se requiera entender tablas, migraciones, extensiones, logs o ejecutar SQL de lectura. Nunca modificar la base; los cambios se hacen via migraciones CLI.

Define and enforce a practical TDD workflow for this codebase. Use when implementing features, fixing bugs, or refactoring where use cases must be explicit, tests must be written before implementation, and verification must confirm behavior.

Orchestrates the `planner` subagent to fully converge a feature spec's tasks.md (Phase 3 of the spec workflow): bootstraps the task list when none exists, then iterates EVERY task one by one until each reaches CRITERIA MET — the goal is 100% of tasks.md validated against the approved requirements.md and design.md and the real state of the codebase. Use this WHENEVER the user wants to create, re-plan, iterate, converge, or audit the task list of a spec — phrases like "plan the tasks", "iterate tasks.md", "planear las tareas", "itera el tasks.md", "audita las tareas", "replan after the spec change", or right after design.md is approved and before TDD execution starts. Trigger even if the user doesn't mention tasks.md by name, as long as they want the implementation plan of a spec produced or validated.

Spec out a new feature using the Requirements-First approach before writing any code: produce a requirements.md (EARS-format acceptance criteria), then a design.md (technical architecture), then a tasks.md (ordered TDD task list that doubles as the execution/decision log) — each after user approval. Use this WHENEVER the user wants to define, spec, plan, or scope a new feature or capability — phrases like "spec this out", "write requirements", "let's define the feature", "before we build", "escribir el spec", "definir la feature", or when starting the "spec" step of a brainstorm → spec → build workflow. Trigger even if the user doesn't say the word "spec", as long as they're describing a feature they want to formalize before implementation.

Use this before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design through dialogue, and stops once the design is approved.

Usar cuando se esta iniciando con la intencion de implementar un producto o feature nuevo, tambien cuando se tiene poca claridad o los requerimientos son ambiguos.

Facilita la definición de requisitos antes de implementar. Hace preguntas para eliminar ambigüedades, enfocándose en el qué y el cómo (no en detalles técnicos), y presenta 2-3 enfoques para resolver el problema. Usar al iniciar features nuevas, cambios de diseño, o cuando la petición del usuario sea vaga o ambigua.

Redacta design specs de producto a partir del output de brainstorming. Documenta el qué y el cómo con criterios de aceptación verificables, sin detalles técnicos. Genera un archivo markdown en docs/specs/. Usar después de brainstorming, cuando el enfoque esté acordado y antes del plan técnico o la implementación.