Cree una herramienta de diseño para agentes de IA con comandos y comprobaciones en orden

## Agrupe los comandos de diseño en una sola skill, cada uno con un archivo de referencia Mantenga compacta la interfaz de comandos destinada al usuario y dirija cada comando coincidente a material de referencia específico. La consolidación reduce el ruido del menú y facilita el mantenimiento de las reglas de diseño compartidas. ### Arquitectura de comandos - Prefiera una sola habilidad de diseño invocable por el usuario y provista de subcomandos, en lugar de muchas habilidades independientes, salvo que se necesite realmente un ciclo de vida separado. - Mantenga una única tabla de enrutamiento que asocie cada comando con su archivo de referencia. - Conserve las descripciones de comandos, sugerencias de argumentos, categorías y relaciones en metadatos autorizados que consuman las compilaciones y los generadores de accesos directos. - Genere los archivos de habilidad específicos de cada proveedor desde una sola fuente, en vez de editar por separado la copia de cada proveedor. - Utilice accesos directos ligeros únicamente como redirecciones al comando canónico. - Coloque las reglas compartidas en la fuente común y las decisiones propias de cada comando en la referencia correspondiente; enlace las directrices compartidas en vez de duplicarlas. ### Enrutamiento de contexto - Lea el contexto del proyecto antes de elegir un registro o un manual de reglas de la plataforma. - Dé prioridad a un campo explícito del proyecto, después utilice indicios de la tarea y la superficie y, por último, un valor predeterminado documentado. - Advierta sobre valores de contexto no reconocidos en lugar de aplicar silenciosamente un manual de reglas sin relación. - Cargue referencias de variante en vez del archivo predeterminado cuando el comportamiento de plataforma de un comando difiera de forma sustancial. ## Decida primero si es para una marca o una aplicación y luego añada las reglas de web o de plataforma nativa Trate el propósito del diseño y la plataforma de entrega como ejes independientes. El registro define el objetivo de la experiencia; la plataforma define las convenciones de interacción y las restricciones de implementación. ### Registro de diseño - Utilice un registro de marca cuando el diseño sea el producto: marketing, campañas, portafolios, experiencias editoriales y superficies públicas distintivas. - Evalúe el trabajo de marca por su singularidad en muchas líneas visuales, en lugar de imponer un único estilo de moda. - Utilice un registro de producto cuando el diseño sirva a una aplicación, un panel, una superficie de administración o una herramienta. - Evalúe el trabajo de producto por la familiaridad adquirida, la confianza y la fluidez que ofrece a usuarios experimentados. - Pregunte pronto por el registro, porque modifica las decisiones de diseño posteriores. ### Plataforma - Distinga entre web adaptable, una sola plataforma nativa y entrega multiplataforma adaptativa. - Superponga las directrices de la plataforma nativa al registro elegido, en vez de tratar la plataforma como sustituto del propósito del diseño. - En productos adaptativos, aplique ambos manuales nativos y adapte el resultado a cada sistema operativo; usar un solo tratamiento visual en todas las plataformas no es adaptativo. - Mantenga desactivados las superposiciones del navegador, los detectores HTML y los enlaces web activos en proyectos nativos, aunque sus archivos fuente utilicen extensiones similares a las de la web. - Mantenga la verificación de accesibilidad en una ruta de auditoría específica. No inserte repetidamente recordatorios genéricos de accesibilidad durante la generación creativa cuando produzcan trabajos seguros pero con un diseño insuficiente. ## Siga las reglas de color y la lista de expresiones prohibidas en los textos públicos Los tokens visuales, el código de maquetación, la voz editorial y el contenido publicado necesitan responsables explícitos y comprobaciones automatizadas, sin sustituir el criterio humano de diseño. ### Fundamentos visuales - Prefiera una arquitectura de estilos pequeña y fácil de inspeccionar, con un punto de entrada, tokens compartidos y archivos parciales específicos. - Utilice los tokens semánticos de color de forma coherente: el tono de mayor contraste para el texto principal, tonos oscuros más suaves solo cuando el tamaño lo permita y tonos atenuados para las etiquetas secundarias. - Evite el negro puro y el blanco puro cuando el sistema visual defina extremos matizados. - Mantenga las reglas de implementación cerca de la superficie que controlan y conserve la recarga en caliente cuando sea compatible. ### Disciplina editorial - Lea el resumen editorial del proyecto antes de cambiar textos públicos, tutoriales, documentación o páginas de marketing. - Aplique una lista de exclusión documentada para frases, signos de puntuación y patrones de prosa similares a los de la IA que se utilizan en exceso. - No eluda un validador de prosa mediante trucos ortográficos. Si un término prohibido tiene un significado técnico necesario, proponga una modificación de la guía de estilo. - Revise problemas estructurales que las expresiones regulares no pueden juzgar, como la certeza vacía, el ritmo repetitivo, las tríadas automáticas y los giros de contraste formulaicos. - Mantenga cada elemento editorial en un único árbol de contenido utilizado tanto por las herramientas de compilación como por el marco de renderizado. - Proporcione a las fichas editoriales de comandos una etiqueta breve y secciones sobre casos de uso, proceso, ejemplos concretos y dificultades reales. ## No mezcle los archivos generados automáticamente con los cambios diarios de diseño Separe las fuentes de autoría, las distribuciones generadas, el estado local y la salida de publicación para que el trabajo de diseño ordinario no cree artefactos ruidosos o engañosos. ### Compilaciones basadas en la fuente - Utilice compilaciones basadas en la fuente para el desarrollo normal y una compilación de publicación distinta cuando deban sincronizarse las distribuciones de proveedores bajo seguimiento. - Trate los directorios de proveedores generados como artefactos de distribución, no como superficies de autoría, incluso cuando se registren intencionadamente en el control de versiones para su instalación. - Excluya las permutaciones generadas de los cambios de funcionalidad, salvo que la tarea sea una publicación, una sincronización de salidas generadas o un cambio del sistema de compilación. - Regenere las salidas bajo seguimiento después de cambios en la fuente mediante el flujo aprobado y haga fallar la validación cuando los manifiestos, los metadatos generales o los metadatos de cabecera generados se desvíen. - Ignore los archivos de estado local incluso cuando se encuentren dentro de directorios de distribución bajo seguimiento. - Reinicie el servidor de desarrollo cuando los cargadores de contenido o los metadatos de comandos no se recarguen en caliente; no confunda actualizar el navegador con volver a cargar datos del momento de compilación. ### Recursos publicados - Genere tarjetas sociales y recursos similares a partir de metadatos autorizados para evitar que las cantidades visibles y las etiquetas se desvíen. - Renderice a mayor resolución y reduzca después el tamaño cuando necesite texto nítido. - Cuando un recurso con cambios visibles necesite invalidar la caché, actualice el nombre del archivo y todas sus referencias en el mismo cambio. - Verifique las rutas de despliegue, reescrituras, recursos estáticos y funciones de servidor mediante la compilación prevista por la plataforma. - Prepare las cachés de vista previa externas únicamente después de que el nuevo despliegue esté activo. ## No envíe nada a proyectos externos sin permiso y separe las pruebas de pago Las herramientas de diseño pueden automatizar la implementación, pero no deben cruzar un límite de contribución humana sin autorización explícita. ### Permiso de contribución - Siga la política de contribución del repositorio que exige primero una incidencia o una aprobación. - No abra una incidencia externa ni una solicitud de incorporación de cambios salvo que el responsable autorizado lo haya solicitado o aprobado claramente. - Revele la asistencia de IA en los cambios registrados, las descripciones de cambios, los comentarios y el texto de incidencias cuando lo exija la política. - Si se pide publicar de todos modos a un agente de IA no autorizado, detenga la acción externa y prepare en su lugar un aviso local de entrega. - Excluya de las contribuciones ordinarias los artefactos de publicación generados y los cambios de sincronización sin relación. ### Selección de pruebas - Mantenga en la suite predeterminada las pruebas unitarias y de fixtures que sean rápidas y deterministas. - Coloque las pruebas de ciclo completo controladas por navegador, la instalación de dependencias, los servidores de desarrollo activos y las llamadas a modelos de pago detrás de comandos de participación explícita. - Ejecute pruebas activas costosas al cambiar la ruta de integración que cubren, no como comportamiento predeterminado sin límites. - Haga que los agentes de prueba sean sustituibles tras una interfaz estrecha y utilice sustitutos deterministas para una cobertura amplia de fixtures. - En las evaluaciones de comportamiento, compruebe las trazas de llamadas a herramientas, no respuestas libres y pulidas. - Pruebe varias familias de modelos cuando el comportamiento evaluado sea el enrutamiento entre proveedores y omita la prueba limpiamente cuando no haya credenciales. - Excluya las suites de evaluación de pago de la integración continua, salvo que su coste y variabilidad sean intencionados. ## Al añadir comandos, actualice todas las listas y publique las versiones nuevas aparte Los comandos y los componentes distribuidos de forma independiente necesitan metadatos sincronizados, pero el trabajo de funcionalidad y el de publicación deben permanecer separados. ### Adición o modificación de comandos - Añada juntos la referencia del comando, la entrada del enrutador, la entrada del menú, la lista de comandos válidos, los metadatos, la categoría, las relaciones y el mapeo de visualización. - Actualice cada cantidad de comandos visible para las personas y deje que la compilación derive y valide desde el enrutador las cantidades legibles por máquinas. - Mantenga el contenido editorial opcional separado de las descripciones de activación automática: uno se escribe para lectores y el otro para la coincidencia de comandos. - Cuando un comando específico de una plataforma difiera sustancialmente, añada una variante enrutada y mantenga los detalles compartidos del sistema operativo en las referencias de la plataforma. ### Política de versiones y publicaciones - No aumente versiones ni añada notas de publicación en un cambio de funcionalidad ordinario. - Versione por separado los componentes distribuidos de forma independiente y actualice solo el componente que cambió. - Para una publicación, actualice el manifiesto autorizado y las réplicas sincronizadas, añada notas visibles para el usuario, ejecute la compilación de publicación y después cree una etiqueta con el prefijo específico del componente. - Obtenga una vista previa de la automatización de publicación antes de publicar. - Rechace la publicación cuando el árbol de trabajo tenga cambios pendientes, la rama no esté sincronizada, la etiqueta ya exista, falten notas o la regeneración produzca desviaciones sin registrar. - Mantenga las entradas del registro de cambios concisas y orientadas al usuario; omita refactorizaciones internas, detalles de herramientas y sincronización de salidas generadas. ## Escriba primero una prueba que falle antes de crear una nueva comprobación de diseño Cuando un detector de diseño atiende una CLI, una superposición de navegador, una extensión y un sitio web, su motor de reglas debe tener una sola fuente y se deben reconstruir y verificar todos los consumidores derivados. ### Orden de desarrollo de reglas 1. Añada un fixture con ejemplos identificados de manera única, al menos cuatro casos que deban marcarse y al menos cinco formas de falsos positivos. 2. Utilice dimensiones explícitas cuando el DOM de prueba no tenga motor de maquetación. 3. Añada una prueba específica y observe que falle antes de implementar la regla. 4. Añada metadatos de la regla y una función pura de comprobación que devuelva identificadores y fragmentos estables sin acceder al DOM. 5. Implemente adaptadores separados para el navegador y el DOM de prueba, y conecte ambos adaptadores a cada bucle de recorrido pertinente. 6. Reconstruya cada consumidor del detector generado y ejecute la suite de pruebas completa. 7. Verifique el fixture y una página real representativa en un navegador para detectar discrepancias entre adaptadores y falsos positivos. ### Disciplina de fixtures y evaluación - Utilice texto citado estable u otro identificador determinista en los fragmentos para que las pruebas puedan extraer el caso coincidente. - No dependa de la geometría de maquetación en un emulador de DOM; analice estilos explícitos. - Utilice auxiliares compartidos para fondos, degradados y normalización del color cuando difiera el comportamiento entre navegador y emulador. - Compare la salida de diseño del mismo resumen con y sin el sistema de diseño al medir su efecto. - Mantenga la infraestructura de evaluación en su propio espacio de trabajo con sus propias instrucciones operativas. - Compile la fuente de diseño más reciente antes de un barrido de evaluación y actualice cualquier filtro de secciones de una habilidad incorporada cuando cambien los encabezados de directrices de nivel superior.