Docs Especialistas
Especialistas
Usá esta página para elegir el especialista correcto en menos de 60 segundos. Desplegá cualquier fila de abajo para ver cuándo invocar a ese especialista, qué produce, cuándo NO usarlo y un comando de ejemplo. AC (acceptance criteria, o “criterios de aceptación” — la lista que define cuándo algo está “terminado”) y CWE (un catálogo público de tipos comunes de vulnerabilidades) aparecen en algunas filas más abajo.
PM /asdt-pm Fija el alcance y convierte pedidos vagos en historias de usuario estructuradas.
- Invocar cuando…
- El pedido es vago o de cara al usuario, el alcance no está definido, o todavía no existen historias de usuario
- Produce
- pm/handoff — el cambio en una frase, historias en orden de entrega, alcance dentro/fuera, criterios de aceptación, riesgos
- No usar cuando…
- Ya tenés un backlog entry claro — volver a correr PM regenera las historias desde cero
- Comando de ejemplo
-
/asdt-pm "Add dark mode toggle to user settings"
Architect /asdt-architect Decide cómo encajan las piezas antes de escribir código.
- Invocar cuando…
- La solución toca límites de servicios, modelos de datos o contratos de API, o tiene dos enfoques técnicos viables que vale la pena documentar
- Produce
- architectural-decision (ADR) + system-design-final — modelo de datos, superficie de API, límites de servicios
- No usar cuando…
- Necesitás código de implementación, planes de pruebas o specs de UX — Architect produce decisiones, no código
- Comando de ejemplo
-
/asdt-architect "Document the decision to use PostgreSQL row-level security for multi-tenancy"
Developer /asdt-developer Convierte un diseño ya definido en un plan de implementación ordenado o código real.
- Invocar cuando…
- La forma de la solución está definida y necesitás un plan de implementación ordenado o código de producción escrito en el repo
- Produce
- developer/dev-implementation — manifiesto de archivos ordenado y plan de código
- No usar cuando…
- Todavía no fijaste el alcance ni la arquitectura — Developer va a implementar contra requisitos ambiguos
- Comando de ejemplo
-
/asdt-developer "Implement the multi-tenancy RLS policy from the Architect's ADR"
QA /asdt-qa Convierte los criterios de aceptación en un plan de pruebas sistemático con un veredicto de go/no-go.
- Invocar cuando…
- El código está listo para revisión, existen AC pero no fueron validados, o necesitás cobertura sistemática de edge cases y límites
- Produce
- test-plan — % de cobertura de AC, gaps sin cubrir, lista completa de test cases Given/When/Then, veredicto de calidad
- No usar cuando…
- Querés código de test ejecutable — QA produce especificaciones de test, no código que corra
- Comando de ejemplo
-
/asdt-qa "Review the checkout flow for edge cases"
Security /asdt-security Busca riesgos de auth, datos e integraciones antes de que se publiquen.
- Invocar cuando…
- La feature toca auth, sesiones, PII, integraciones externas, webhooks, o nuevos endpoints públicos de API
- Produce
- security-findings (con severidad y CWE) + hardening-checklist — qué arreglar sí o sí vs qué se puede postergar
- No usar cuando…
- Querés código de implementación o decisiones arquitectónicas — Security solo produce findings y checklists
- Comando de ejemplo
-
/asdt-security "Review the session management in the auth module"
UX/UI /asdt-ux-ui Mapea flujos y componentes antes de que arranque la implementación.
- Invocar cuando…
- Una pantalla nueva o una UI a nivel de feature necesita diseño antes de implementar, o hay que mapear flujos de usuario
- Produce
- ux-brief (flujos, IA, criterios de éxito) + component-spec — inventario de componentes reusados/extendidos/nuevos
- No usar cuando…
- La pantalla ya está construida — una spec de UX entregada después de implementar llega demasiado tarde para darle forma
- Comando de ejemplo
-
/asdt-ux-ui "Design a data table component with sorting, filtering, and pagination"
Researcher /asdt-researcher Explora un problema difuso antes de comprometerse con una dirección.
- Invocar cuando…
- El problema es difuso o abierto — necesitás descubrimiento y enmarcado antes de poder escribir requisitos
- Produce
- researcher/handoff — encuadre del problema, una dirección recomendada, cada descartada con su razón, evidencia de factibilidad
- No usar cuando…
- Ya tenés un problema bien definido — Researcher explora; no produce historias de usuario ni ADRs
- Comando de ejemplo
-
/asdt-researcher "Explore ways to reduce onboarding drop-off"
Cuando el trabajo abarca múltiples perspectivas, salteá las filas de arriba y ejecutá /asdt <descripción del feature> — el orquestador clasifica el cambio y lo enruta por los especialistas correctos en el orden correcto.
Cambiar de especialista
No existe un especialista “equivocado” del que haya que recuperarse — los especialistas trabajan de forma independiente, así que cambiar no cuesta nada. Podés correr cualquier especialista directamente en cualquier momento; cada uno lee automáticamente los artefactos previos desde la base de conocimiento compartida. Si un pedido no encaja con el especialista que elegiste, /asdt te va a recomendar uno más adecuado.
Ejemplo: si corriste /asdt-developer antes de crear un ADR, corré /asdt-architect para producir el registro de decisión, y después volvé a invocar /asdt-developer. El Developer va a leer el ADR automáticamente en su próxima corrida.
Mirá Solución de problemas para procedimientos de recuperación paso a paso.