Communitygithub.com

autor de pantallas AINDF

Crea o modifica pantallas de un sistema de diseño AINDF exclusivamente a través de su DS-MCP. Úsalo cuando te pidan construir, cambiar o arreglar una página/pantalla de un producto cuyo sistema de diseño expone un MCP AINDF (herramientas get-ds, get-component, validate-screen).

¿Qué es autor de pantallas AINDF?

Este skill te permite componer pantallas a partir de un sistema de diseño AINDF que no puedes modificar. Es útil cuando trabajas con un producto que expone un MCP AINDF y necesitas construir, modificar o corregir una página/pantalla siguiendo estrictamente las reglas del sistema de diseño. El skill está diseñado para agentes que interactúan con herramientas como `get-ds`, `get-component` y `validate-screen`, y garantiza que cada pantalla cumpla con las reglas de diseño sin inventar componentes, props o valores. El flujo comienza con `get-ds` para obtener el pin del sistema de diseño, luego se validan los contratos con `get-component` y otras herramientas, se construye un `ScreenSpec JSON`, se valida con `validate-screen` hasta obtener `ok: true`, y finalmente se envía con `submit-screen` o se entrega al usuario según las capacidades del endpoint.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/0design/ai-native-design-framework/tree/main/plugin/skills/aindf-screen-author

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

¿Qué hace autor de pantallas AINDF?

Compones pantallas a partir de un sistema de diseño que no puedes modificar. Tu único artefacto es el ScreenSpec JSON.

Reglas

  1. Comienza con get-ds. Copia su pin textualmente en cada pantalla (ds). Nunca inventes componentes, props, slots o valores.
  2. Lee los contratos con get-component, list-by-facet, slot-accepts, get-preset antes de usar cualquier cosa.
  3. Nunca escribas HTML, CSS, JSX, nombres de clase, estilos, scripts, manejadores ni URLs propios. El texto y los valores declarados (enum, booleano, número) son los únicos datos libres. Los enlaces solo dentro de props richText que lo permitan.
  4. validate-screen hasta que ok: true. Repara a partir del code + path devueltos; no intentes evadir una regla.
  5. Si la pantalla necesita algo que el DS no ofrece, detén esa parte y pídelo: llama a request-extension solo si el endpoint lo dispone; si el endpoint es de solo lectura (sin dicha herramienta), informa la necesidad al usuario. No lo aproximes con otros componentes en contra de su intención.
  6. Entrega la pantalla validada: llama a submit-screen solo si el endpoint lo dispone (almacena un borrador no aceptado); en un endpoint de solo lectura entrega el ScreenSpec validado al usuario. No puedes construir, verificar, aceptar ni publicar; nunca afirmes que el cambio está en vivo o aceptado. Reporta qué cambió, qué solicitaste y, si se envió, el id del envío.

Forma del ScreenSpec

{ "kind": "aindf.screen", "aindfVersion": "0.2", "id": "usar", "ds": "<get-ds.pin>", "route": "/usar",
  "template": { "component": "<un template>", "props": {} },
  "sections": [ { "component": "<un componente de capa de secciones>", "props": {}, "slots": { "<slot>": [ { "component": "…" } ] } } ] }

meta (título/descripción) y params (para rutas [param], una vinculación de params del DS) son opcionales y se validan de la misma manera.

Skills relacionados