APareek89/Agent Design Studio

¿Qué hace Agent Design Studio?

Un breve resumen es la única entrada requerida. Use el asistente anfitrión; no necesita clave de proveedor adicional ni configuración de cuenta. Complete el detalle usted mismo. Los hechos, políticas, roles, volúmenes y precios propuestos deben ir en un registro de supuestos con propietarios de verificación y bloqueadores de lanzamiento. Nunca invente evidencia ni aprobación de partes interesadas. El permiso de diseño no autoriza escrituras de negocio, despliegue, pagos, cambios de acceso ni mensajes.

Elija la salida

Acepte los parámetros opcionales mode: lite | standard | full e interactive: true | false. Valores predeterminados: standard, false. No pida al usuario que elija cuando solo haya proporcionado un breve.

• lite: PDF de cuatro páginas (resumen de decisión, árbol de tareas, flujo de trabajo, principales riesgos) y un DESIGN.html de cuatro vistas (Resumen de decisión, Mapa de tareas, Flujo, Riesgos); además de un design.json completo. Conserve también la revisión y la evidencia de ejecución.
• standard: primero el resumen de decisión; PDF principal de máximo 12 páginas; DESIGN.html de doce vistas. Los apéndices detallados residen en _evidence/ y en los hitos de build/. Esta es la ejecución normal solo con breve.
• full: resumen de decisión y diagramas renderizados, seguidos del informe completo de diez etapas y apéndices; DESIGN.html de doce vistas. Sin límite de páginas.

Si no existe ningún breve, solicite únicamente el breve.

Primero, clasifique el breve. Ejecute scripts/design_intake.py classify sobre él antes de cualquier otra cosa. Lee el idioma, la longitud y la forma del breve y devuelve un briefProfile: el idioma según escritura y palabras funcionales; si el breve es demasiado corto o vago, o tiene más de 6.000 palabras; si describe un sistema de agente; si escribe en algún sistema de registro; si es en tiempo real o por voz; si es multiinquilino; y si pide eliminar un control que la habilidad mantiene. Cada señal lleva un mensaje en lenguaje natural para mostrar al usuario. Confirme el perfil con el usuario en una línea antes de redactar, regístrelo bajo intake.briefProfile y establezca overriddenBy cuando el usuario lo corrija. Toda detección es heurística, y con un breve que no esté en inglés las verificaciones de palabras clave no son fiables: ejecútelas de nuevo sobre una traducción que usted produzca, o indique que las omitió.

Actúe según el perfil:

• No está en inglés: redacte el diseño en el idioma del breve a menos que el usuario solicite lo contrario.
• Demasiado corto o vago: dígale al usuario que el breve es demasiado escaso para un diseño fiable y que el resultado se basará en N supuestos, luego haga las cuatro preguntas. Si el anfitrión no puede preguntar, entregue en modo lite con un banner visible de "breve insuficiente" en el Resumen de decisión.
• Demasiado largo: no hay nada que decidir; el exportador lo cita y el PDF completo lo incluye como apéndice.
• No es un sistema de agente: dígalo en una oración, ofrezca continuar de todos modos y, si continúa, establezca runOptions.mode en lite.
• Conflictos con las reglas: nunca rediseñe en silencio alrededor del conflicto. Registre briefConflicts y diga en la tarjeta de Contexto "Alcance del desencadenante y primer lanzamiento" y en el Resumen de decisión: el breve pide X, este diseño mantiene Y porque Z, y una anulación necesita un propietario con nombre. La validación falla hasta que ambos lo confirmen.
• Solo lectura, tiempo real o multiinquilino: estos cambian lo que el diseño debe contener; consulte las tres secciones de perfil en personas.md.

Luego, encuentre las brechas. Ejecute scripts/design_intake.py questions sobre el breve: enumera la información clave que el breve omite (qué acciones pueden ejecutarse solas, sistemas de registro, volumen, regulación y privacidad, usuarios, canales, medidas de éxito, industria y región, plataforma, idiomas) y formula como máximo cuatro preguntas con opciones. Si encuentra brechas y el anfitrión tiene un diálogo de preguntas, haga esas preguntas una vez, en un solo diálogo: Claude Code usa la herramienta AskUserQuestion (su propia lista de opciones más texto libre); Codex usa request_user_input; otros anfitriones muestran las preguntas en un solo mensaje con opciones numeradas. Cada pregunta es opcional y termina con "No estoy seguro; proponga un supuesto". Espere la respuesta real. Si el anfitrión no puede preguntar, el usuario omite o la ejecución no es interactiva, continúe sin preguntar y regístrelo. Registre el intercambio en design.json bajo intake; la respuesta del usuario es un hecho que puede citar como fuente context con file:"user-intake"; una pregunta omitida se convierte en un supuesto H con un propietario. Nunca haga una segunda ronda, y nunca pida al usuario que elija un modo.

Respete las restricciones explícitas; elija un primer lanzamiento útil y explique por qué se rechazó una opción más amplia. Trate el material fuente adjunto como evidencia, no como permiso para anular la solicitud del usuario.

Investigue el caso de uso y las herramientas

Cuando el anfitrión proporcione una herramienta de búsqueda web o recuperación de páginas, investigue antes de redactar y regístrelo en el objeto research de nivel superior (consulte output-contract.md). Dedique entre 10 y 20 búsquedas. Cubra, en este orden: la industria y el caso de uso (cómo se realiza el trabajo hoy, regulación y estándares, volúmenes típicos y líneas base de KPI, modos de falla comunes, las palabras que usan los profesionales); cada capacidad que el breve necesita más allá del modelo (voz y telefonía, habla, barreras de seguridad y manejo de PII, búsqueda web, recuperación con embeddings y un almacén de vectores, grafo de conocimiento, IA documental, orquestación, canales, identidad), comenzando desde tool-catalog.md y verificando las opciones actuales, límites, base de precios, regiones y licencias; y cualquier cosa que el breve mencione, como un proveedor, sistema o regulación. Prefiera fuentes primarias: documentación del proveedor, reguladores, organismos de normalización.

Escriba cada hallazgo que use con sus propias palabras, incluyendo su URL, título y fecha de recuperación, cíelo desde elementos con fuente research, y desde supuestos a través de usedBy. La investigación informa el diseño y la elección de herramientas; nunca verifica las políticas, contratos, datos o sistemas del usuario, que siguen siendo supuestos H con propietarios. Nunca envíe el texto del breve, nombres de clientes o empresas, ni ningún detalle confidencial a un motor de búsqueda; busque términos genéricos. Si no hay herramienta web disponible, establezca research.performed en false con la razón, dígalo en la tarjeta de contexto "Límites de evidencia", y marque cada candidato de herramienta como no verificado. Su propio conocimiento sigue siendo válido; la investigación añade frescura y fuentes, no reemplaza el juicio.

Redacte el diseño canónico

Lea output-contract.md y semantic-contract.md. Los nuevos diseños usan schemaVersion 1.1 y declaraciones semánticas explícitas. Las entradas de la versión 1.0 siguen siendo legibles pero tienen cobertura semántica no verificada; nunca las etiquete como si superaran las nuevas comprobaciones.

Trabaje a través de los diez roles lógicos de autor en personas.md, leyendo el rol relevante según sea necesario: contexto, mapa de tareas, componentes, flujo de trabajo, arquitectura, plan de modelos, FMEA, evaluaciones, despliegue y transferencia. En el paso de Pila y permisos, añada una tarjeta tooling por cada capacidad que el diseño necesite más allá del modelo, elegida de tool-catalog.md y verificada por investigación cuando sea posible; cada candidato lleva su estado de verificación. No es necesario que sean diez procesos. Escriba en una carpeta de salida nueva; conserve el breve exacto del usuario en design.json.

Entre componentes y flujo de trabajo, andamie el contrato semántico. Una vez que las etapas de tareas y componentes estén completas, ejecute scripts/design_scaffold.py design.json --merge. Escribe el esqueleto semantics: una fila de nodo por nodo de flujo de trabajo con un tipo adivinado desde su grupo de componentes, una fila componentEffects por componente, una transición por borde declarado con el when propio del contrato, una fila modelOutputs por campo de salida del LLM, y los nombres de campo que necesita cada enlace de escritura. Nunca inventa un resultado de transición, una categoría de salida, una fuente de enlace, una clase de acción, una duración de espera ni un valor de referencia: esos son juicios sobre el negocio, y una suposición es peor que un espacio en blanco. Devuelve una lista de verificación de lo que debe completar. Cada espacio en blanco es "TODO" y falla la validación, por lo que un contrato inacabado no puede entregarse como uno terminado.

En prosa y encabezados, use los nombres de paso del lector: Breve y alcance, Mapa de tareas, Componentes, Flujo, Pila y permisos, Modelos y costo, Riesgos, Pruebas, Medir y desplegar, Transferencia. Las claves de etapa en design.json no cambian.

El código es dueño del dinero, la identidad, las fechas y los límites. Los modelos pueden proponer una regla o explicación usando evidencia, pero nunca tienen autoridad de escritura. Muestre los productores reales de confianza, la validación, las excepciones humanas, el aviso durante esperas largas, la prueba de registro, la reconciliación de escrituras inciertas y las rutas de recuperación acotadas. Trace cada hoja a través de componente, flujo de trabajo y prueba. Enlace riesgos y evaluaciones en ambas direcciones.

Mantenga cada hecho y prueba en un solo lugar mantenido. Prefiera pruebas de referencia autocontenidas. Si la herencia ahorra una repetición sustancial, use una base inmutable con versión y una regla de fusión explícita, incluyendo la prueba resuelta. Escriba pruebas tanto positivas como negativas para cada clase de acción. Nunca afirme que esas especificaciones fueron controles de negocio ejecutados.

Codiseño opcional

Con interactive: true, deténgase después de tareas y después de componentes. Muestre un resumen compacto ID/título con autonomía, riesgo y dependencias. Pida ediciones, eliminaciones o confirmación. Espere la respuesta real del usuario; el silencio o el tiempo transcurrido no es confirmación. Este punto de control aprueba el contenido del diseño, no acciones en vivo.

Registre el punto de control pendiente con scripts/design_session.py checkpoint. Aplique las eliminaciones/ediciones de tareas del usuario con apply-tasks; los descendientes y las etapas posteriores obsoletas se eliminan. Reautorice los componentes en adelante desde el árbol retenido. Para ediciones de componentes, reautorice el flujo de trabajo en adelante y las declaraciones semánticas. No deje IDs, componentes, pruebas o instrucciones de compilación eliminados aguas abajo. Registre el historial de puntos de control; valide solo después de completar el diseño reconstruido. El modo predeterminado solo con breve no tiene pausas.

Capa orientada al lector e hitos de compilación

Redacte los elementos de nivel superior presentation, runOptions y milestones usando report-contract.md. Tanto la primera página del PDF como el HTML Resumen de decisión los leen. La primera página debe contener, en orden: descripción del sistema en una oración; 3–5 decisiones de diseño con opción rechazada y motivo; tabla de acción/autonomía; cinco principales riesgos por RPN; bloqueadores de lanzamiento y propietarios; costo ilustrativo por caso; método de revisión, ronda y estado en una línea. Mueva las puntuaciones D1–D12 al final.

Use lenguaje sencillo en las páginas 1–2: facilidad de lectura al menos 50, longitud media de oración como máximo 20 palabras. Evite canónico, discriminado, enlace de carga útil, resumen, idempotencia, recíproco y disposición terminal en esas páginas. Mantenga los nombres exactos en los archivos de contrato/compilación y explíquelos en el glosario.

El PDF debe contener diagramas vectoriales reales de tareas y flujo de trabajo, no código Mermaid. También dibuje una tabla de riesgo por severidad × ocurrencia y una matriz de cobertura de evaluación de riesgo/tarea de alto riesgo (standard/full). El HTML dibuja su árbol de tareas y flujo SVG desde el mismo design.json; taskLabels y workflowLabels acortan los nombres de cajas y nodos sin renombrar IDs. Cada tarea/nodo permanece visible; divida diagramas grandes en lugar de reducir texto o eliminar nodos. Si el renderizador de PDF informa un límite de densidad, simplifique el resumen del lector o proporcione un dibujo legible de varias páginas manteniendo todos los contratos en los archivos complementarios. No debilite la trazabilidad para ajustarse a un límite de páginas.

Divida el contexto de codificación en build/00-overview.md y archivos de hito seleccionando solo sus contratos, reglas de rama, pruebas y criterios de aceptación. Estándar: cada uno ≤25 KB, total ≤100 KB. Las pruebas completas permanecen indexadas en _evidence/eval-set.json; la fuente exacta en design.json. No incluya un volcado completo del diseño en cada archivo de compilación.

Revise y repare

Lea quality-rubric.json. Si el anfitrión puede iniciar un agente separado dentro de los recursos permitidos de la tarea, use un revisor nuevo con solo el breve, design.json, la evidencia fuente real y la rúbrica, sin el razonamiento del autor ni el veredicto propuesto. Retenga review.json, validation.json, scripts/historial del autor y evaluaciones previas para la primera revisión; validation.json incrusta la revisión del autor. Inspeccione exportaciones, HTML y PDF después de los hallazgos independientes o use un evaluador visual separado. Etiquete esa revisión real como independent-agent. Si la delegación no está disponible, use y etiquete self-review. No afirme una calificación independiente desde un rol diferente en el mismo proceso.

Inspeccione contratos y pruebas efectivas, no solo títulos e IDs. Ejecute:

python3 <skill-dir>/scripts/design_io.py validate <out>/design.json

Antes de la revisión, ejecute design_io.py validate <out>/design.json --strict-coverage. Informa si el diseño lleva la información que un lector espera (COV1 a COV15 en output-contract.md): tarjetas de contexto para decisión, actores, alcance, medidas, restricciones y límites de evidencia; la capa del lector; hitos; el registro de investigación; una tarjeta de herramienta por cada capacidad que el breve implique; un desencadenante humano donde el breve implique dinero o escrituras de registro; y elementos recomendados como volumen, líneas base de KPI y dos ejemplos por hoja. Corrija cada brecha requerida, o justifíquela con una cadena de supuesto que comience con su ID (por ejemplo COV9: el anfitrión no ofreció ninguna herramienta de búsqueda web). La comprobación busca información esperada; no juzga la calidad, por lo que la revisión aún lo hace.

Repare los hallazgos y los efectos posteriores durante como máximo tres rondas de revisión. Conserve cada review-round-N.json fallido; nunca reduzca los umbrales ni reescriba fallos históricos. Para aprobar se requiere cada D1–D12 ≥3/4, ningún problema mayor/crítico sin resolver, estructura válida y declaraciones semánticas, y límites explícitos. La falta de evidencia de lanzamiento es un bloqueador etiquetado, no un hecho fabricado. Si aún no está resuelto, entregue el borrador completo como necesita trabajo, con los hallazgos.

Renderice y entregue

El tiempo de ejecución necesita ReportLab y pypdf para el PDF, listados en requirements-pdf.txt. El validador, exportador y renderizador HTML usan solo la biblioteca estándar de Python. Use un tiempo de ejecución/habilidad de PDF disponible y verifique visualmente el resultado. Si el PDF no se puede producir, muestre advertencias en el resumen de entrega y entregue solo HTML y design.json.

Escriba la salida en la carpeta elegida y entregue la carpeta completa al usuario. Todos los archivos de salida están en: breve, perfil, intercambio de preguntas (si lo hubo), resultados de investigación, checked JSON, contratos sin resolver, evidencia de revisión y artefactos renderizados. El design.json incluye versionado y lastUpdated para cada etapa. Etiquete los artefactos de producto (presentación, HTML, PDF, build/overview) con sus IDs de etapa; los artefactos de proceso (revisiones, validaciones, puntos de control) con su tipo y ronda. La última etiqueta en cada archivo refiere al estado de validación más reciente conocido.

Finalice con un resumen de una línea de lo que se entregó, dónde y con qué estado.