Docs Recetas
Recetas
Secuencias de comandos para copiar y pegar en los escenarios más comunes de ASDT. Cada receta muestra los comandos exactos para ejecutar en Claude Code u OpenCode. Filtrá por lo que estás tratando de hacer, o navegá las 14 de abajo — cualquier cosa que toque autenticación, pagos, PII (información personal identificable) o integraciones externas debería incluir una revisión de seguridad.
Mostrando 14 recetas para "Todas".Mostrando 5 recetas para "Empezar de cero".Mostrando 2 recetas para "Añadir a código existente".Mostrando 5 recetas para "Revisar y endurecer".Mostrando 2 recetas para "Entender y documentar".
Lanzar una feature nueva de cara al usuario
Empezá acá cuando el pedido de una feature está en lenguaje vago y necesita la secuencia completa PM → Architect → Developer.
Revisá la secuencia de especialistas sugerida y después corré cada uno en orden.
/asdt "Add a contact form with email notification"
/asdt-pm "Add a contact form with email notification"
/asdt-architect
/asdt-developerConstruir un nuevo endpoint REST
Para cambios solo de backend donde el contrato de la API es la decisión de diseño principal.
/asdt "Add a POST /api/v1/subscriptions endpoint"
/asdt-pm "Add a POST /api/v1/subscriptions endpoint"
/asdt-architect
/asdt-developerPantalla nueva con diseño UX primero
Para features de cara al usuario donde el diseño de UI debería preceder a la implementación.
/asdt "Add an onboarding wizard for new users"
/asdt-pm "Add an onboarding wizard for new users"
/asdt-ux-ui
/asdt-architect
/asdt-developer
/asdt-qaFeature con revisión de seguridad antes de publicar
Para cualquier cosa que toque auth, pagos, PII (información de identificación personal) o integraciones externas.
/asdt "Add OAuth login with GitHub"
/asdt-pm "Add OAuth login with GitHub"
/asdt-architect
/asdt-security
/asdt-developer
/asdt-qaExplorar antes de planificar (problema difuso)
Cuando el problema no está claro y necesitás descubrimiento antes de definir requisitos.
Researcher produce un discovery brief con una dirección recomendada — pasáselo al PM después.
/asdt-researcher "We're losing users at the signup step — what could we do?"
/asdt-pm "Based on the discovery brief: add progressive disclosure to the signup flow"Fijar el alcance y escribir historias de usuario
Cuando tenés una idea de feature clara y solo necesitás requisitos estructurados.
/asdt-pm "Add dark mode toggle to user settings"Documentar una decisión de arquitectura
Cuando el enfoque técnico necesita un ADR formal y un diseño de sistema.
/asdt-architect "Document the decision to use PostgreSQL row-level security for multi-tenancy"Escribir código de producción a partir de una spec ya definida
Cuando el alcance y la arquitectura ya están definidos en la base de conocimiento.
/asdt-developer "Implement the multi-tenancy RLS policy from the Architect's ADR"Auditoría de seguridad sobre una feature existente
Corré en cualquier momento — no requiere que haya corrido un especialista antes.
/asdt-security "Review the session management in the auth module"Diseñar un nuevo componente de UI
Cuando necesitás una spec de componente antes de que el developer empiece a codear.
/asdt-ux-ui "Design a data table component with sorting, filtering, and pagination"Validar la cobertura de tests antes de publicar
Corré después de Developer — QA lee la implementación automáticamente.
/asdt-qaRetomar en Developer después de un ADR existente
Cuando PM y Architect corrieron en una sesión anterior. Developer carga los artefactos previos automáticamente.
No hace falta volver a correr PM o Architect — los artefactos están en la base de conocimiento.
/asdt-developerAgregar una revisión de seguridad a un pipeline en curso
Corré Security en cualquier momento sin reiniciar el pipeline.
Security lee system-design-final y dev-implementation de la base de conocimiento.
/asdt-securityHacer QA de una feature terminada sin pipeline completo
Cuando se construyó una feature sin ASDT — corré QA contra el código existente.
/asdt-pm "Add acceptance criteria for the existing checkout flow"
/asdt-qa