charliesbot/android-design-explore

Exploración de diseño visual

Sigue el skill android-design para cada decisión de diseño: su sección 0 de respuestas, componentes, tematización, diseño y las preguntas de la verificación de pantalla. Este skill es dueño del flujo de trabajo. Cada ejecución es de un solo disparo: resumen breve, se escribe una propuesta, se verifica, se muestra y luego se detiene. Las pantallas de teléfono, plegable, tableta, escritorio y Wear OS están dentro del alcance; los tiles de Wear, las esferas de reloj y los widgets no lo están. Cuando Wear difiere, la sección Wear OS a continuación explica cómo.

Una propuesta es un archivo de datos que la aplicación de vista previa, una ventana nativa de macOS, dibuja con componentes reales de Compose Material 3 y redibuja en cada guardado. La verificas a través del árbol de diseño de la aplicación; el usuario juzga el gusto visual en la ventana.

Requisitos

macOS, con la aplicación de vista previa instalada y registrada como un servidor MCP llamado android_design_preview. Llama primero a su herramienta status. Cuando sus herramientas no estén disponibles, detente y dile al usuario los dos pasos, luego espera:

1. Construye e instala la aplicación desde una copia del repositorio android-design: cd app && ./gradlew :app:installApp, que instala ~/Applications/AndroidDesignPreview.app.
2. Regístrala para su entorno, luego reinicia la sesión (<binary> es ~/Applications/AndroidDesignPreview.app/Contents/MacOS/AndroidDesignPreview, escrito como una ruta absoluta donde el entorno no expande ~):
   • Claude Code: claude mcp add --scope user android_design_preview -- <binary>
   • Codex: una tabla [mcp_servers.android_design_preview] en ~/.codex/config.toml con command = "<binary>" y default_tools_approval_mode = "approve"
   • Antigravity: agy mcp add android_design_preview <binary>

Resumen breve

Cuando hay una aplicación, primero lee sus pantallas relevantes, tema, recursos y cualquier DESIGN.md y propuestas design/ existentes. Responde la sección 0 de android-design en la respuesta.

• Elige una semilla: el color de la marca o un color de contenido del tema (un plato, un álbum, un viaje), nunca el color predeterminado de la aplicación #6750A4.
• Cuando la pantalla es un momento héroe (pregunta 3 de la sección 0), superpone tres o más tácticas (sección 3) y nómbralas.
• Mantén el código de la aplicación y las dependencias sin cambios.
• Usa datos y recursos representativos y no sensibles. Usa generación de imágenes solo para recursos dentro de una propuesta, nunca como sustituto de una.

Haz varias propuestas solo cuando el usuario lo solicite. Cada una es su propio archivo, una composición distinta (no un recolorido) con su propia semilla en su theme, y al menos una es un héroe.

Archivos

Trabaja en la raíz del repositorio de la aplicación, o en la carpeta que el usuario nombre. Nunca escribas dentro del repositorio de este propio skill.

• DESIGN.md en la raíz contiene el sistema de diseño compartido. Créalo cuando falte, con la semilla elegida, las fuentes y los estilos nombrados. Cámbialo solo cuando la dirección cambia lo que todas las propuestas comparten; el aspecto de una dirección propia va en el theme de su propuesta.
• design/<slug>.proposal.json contiene una propuesta.

Ambos son archivos normales rastreados; confirmarlos sigue el flujo de trabajo del propio proyecto. Dile al usuario la ruta absoluta de la propuesta.

Escribir

1. Llama a get_catalog (su descripción de herramienta dice lo que devuelve). Es el único vocabulario de componentes: un componente que le falta está fuera de alcance, así que construye la idea a partir de Box, Row, Column, Text y Shape, o déjalo fuera.
2. Lee references/proposal-format.md, luego escribe DESIGN.md y la propuesta, de forma compacta como dice su sección "Escritura compacta".

La propuesta lleva estas reglas de diseño; proposal-format.md da la sintaxis para cada una, y su sección Reglas de componentes contiene las reglas para pestañas, carruseles, superposiciones, opciones, barras de herramientas, menús, barras de aplicaciones y distintivos:

• La pantalla tiene una acción principal, marcada como primaria, y lidera a sus pares como describe la sección 2 de android-design.
• Se adapta a 600 y 840 dp: una barra de navegación en compacto se convierte en un rail desde mediano hacia arriba, y la pantalla de detalle de una lista se abre junto a la lista en anchos expandidos.
• El texto se trunca intencionadamente, con puntos suspensivos. Las etiquetas de botones, chips y navegación caben en una línea.

Verificar

Para una propuesta, este paso reemplaza el renderizado en la verificación de pantalla de android-design. Responde sus preguntas a partir de los resúmenes de diseño y errores de check_proposal (y get_tree cuando no sean suficientes), nunca a partir de un renderizado o píxeles. Las capturas de pantalla quedan fuera de este bucle: nunca tomes una ni pidas una.

1. Llama a open_proposal con la ruta absoluta de la propuesta. Carga el archivo, lo vigila, muestra la ventana y devuelve errores de validación. Corrígelos y llama a status hasta que no informe ninguno.
2. Llama a check_proposal. Una llamada verifica cada pantalla en cada vista y devuelve los errores de cada vista y el resumen de layout; su descripción de herramienta da el formato.
3. Corrige cada error una vez, luego llama a check_proposal de nuevo. Un error overflow nombra un nodo dispuesto más ancho que su padre o la vista (una fila que necesita más ancho que su celda); hazlo más estrecho, envuélvelo o déjalo desplazarse. Informa cualquier cosa que aún falle en lugar de repetir.
4. Confirma la adaptación a partir de los resúmenes de layout: cada vista más grande revela lo que tu respuesta de adaptación de la sección 0 prometió, como un segundo panel, un rail o más regiones. Google: "El espacio adicional no solo significa hacer lo mismo más grande". Una vista más grande con solo las regiones del teléfono extendidas más anchas falla.
5. Llama a get_tree solo cuando un resumen o un error no sea suficiente; su descripción de herramienta dice lo que devuelve.

El paso termina cuando check_proposal pasa o cada error restante está en la lista que informas, y la adaptación está confirmada.

Mostrar

Llama a show_preview. Di en una línea qué es la propuesta, nombra las tácticas que un héroe superpone, enumera cualquier hallazgo no resuelto e informa "calidad visual juzgada solo desde el árbol de diseño". Luego detente y espera la respuesta del usuario.

Revisar

Edita la misma propuesta con los comentarios del usuario; la ventana se redibuja al guardar. Repite la verificación en las pantallas que cambiaste. La revisión reemplaza la versión anterior; no conserves copias.

Aprobar y portar

La aprobación es que el usuario lo diga en el chat. Informa la ruta de la propuesta aprobada y que references/compose-mapping.md es la tabla de portabilidad. Una solicitud solo de exploración termina ahí: no implementes. Una solicitud de construcción (el skill android-design envía aquí primero las construcciones centradas en diseño de nuevas aplicaciones, pantallas y rediseños) continúa al portado. La aprobación nunca autoriza cambios de versión de bibliotecas.

El portado sigue las reglas de planificación, rama, verificación y revisión del proyecto solicitante:

1. Llama a export_kotlin para las pantallas a portar. Su Kotlin es el primer borrador, no código terminado.
2. Ajústalo a las convenciones de la aplicación y versiones de bibliotecas con references/compose-mapping.md.
3. Renderiza el resultado con el skill compose-preview y compáralo con los árboles de la propuesta en las mismas vistas.

Informa los componentes que el mapeo marca como no verificados, y cualquier cosa que falte, en lugar de inventar un equivalente de Compose. Si el diseño no se puede preservar con las dependencias de la aplicación, pregunta.

Wear OS

Una propuesta de Wear sigue el mismo flujo de trabajo. android-design references/wear-os.md es dueño de las reglas de diseño, y proposal-format.md es dueño del formato de archivo (id del catálogo, vistas, Screen, primary, large).

• Su propio archivo. Una superficie por propuesta: escribe design/<slug>-wear.proposal.json junto al del teléfono.
• Verificación de adaptación: la anulación de tamaño de Wear se aplica desde 225dp, por lo que la verificación es "cabe y se lee en ambos tamaños de reloj, y el grande muestra más valor, nunca menos".
• DESIGN.md compartido: su semilla y roles de color se aplican a Wear; su tipografía se reemplaza por Roboto Flex.
• Hallazgos: corrige round-edge-clipped (control o texto cortado por el borde redondo en una pantalla fija) con márgenes de estilo porcentual o un diseño más pequeño.
• Portado: los mismos tres pasos. export_kotlin escribe Compose de Wear: un WearAppTheme con los colores exactos del visor, AppScaffold y ScreenScaffold, y Navigation 3 con deslizar para descartar. Renderiza el portado en ambos tamaños redondos (204 y 227dp).

Eliminar

Cuando el usuario lo solicite, elimina design/<slug>.proposal.json. Conserva DESIGN.md a menos que el usuario solicite eliminarlo también.