De la Idea a la Tienda, sin Programar

La idea lleva meses ahí adentro y cada vez que la cuentas sale distinta. Ese es el problema real: mientras viva solo en tu cabeza, no se puede recortar, no se puede planear y no se puede construir. El primer paso no es técnico. Es sacarla, entera y desordenada, y dejarla escrita en algún lado.

Hay dos maneras de sacarla que funcionan bien, y las dos sirven aunque no programes: se la dictas hablando, o le tomas una foto al boceto que ya hiciste en una hoja. Las dos terminan en lo mismo, que es texto que Claude puede leer y devolverte ordenado.

Antes de nada, una aclaración que ahorra una tarde perdida: Claude no oye. Maneja texto, imágenes y documentos. Mandarle una nota de voz no sirve de nada, porque no hay nada del otro lado escuchándola.

Qué puedes meterle y qué no

La lista de «No entra» es corta y es toda del mismo tipo: audio. Es el error más común de quien apenas empieza, porque en el teléfono todo se manda igual y uno supone que del otro lado alguien escucha.

Primera entrada: se la dictas

El dictado vive dentro de la sesión de Claude Code y convierte tu voz en texto antes de que el modelo vea nada. Es la diferencia exacta con mandar un audio: cuando sueltas la barra, lo que llega ya son letras.

es una app para la gente que renta cosas, o sea yo tengo tres
departamentos y llevo todo en una libreta y en whatsapp, entonces
quiero que el inquilino vea cuanto debe y que yo le pueda mandar
el recordatorio sin escribirlo cada mes, y tambien que suba la foto
del comprobante, y tambien que si hay una fuga me avise, ah y que
guarde los contratos, y que me diga cuanto llevo cobrado en el año

Sale sin comas, con «y también» tres veces y con dos ideas metidas a la fuerza. Está bien que salga así. Lo desordenado es materia prima; lo que no sirve es lo que se queda sin escribir.

Acabo de dictarte mi idea de app tal como me salió, sin ordenar y sin pensarla. No la resumas, no la mejores y no le agregues funciones. Haz exactamente esto, en este orden:

1. Reescríbela en diez renglones o menos, en español simple, sin palabras técnicas y sin meter nada que yo no haya dicho.

2. Sepárala en tres listas cortas:
   - Lo que dije con claridad.
   - Lo que dije a medias y se puede entender de dos maneras.
   - Lo que nunca mencioné y hace falta.

3. Contesta estas seis preguntas con una sola línea cada una, usando únicamente lo que dije. Si no lo dije, escribe tal cual "no lo dijo":
   - ¿Quién la usa? Una persona concreta, con su situación, no "todo el mundo".
   - ¿Qué problema le quita de encima hoy?
   - ¿Cómo resuelve eso hoy, sin la app?
   - ¿Qué tiene que pasar adentro para que valga la pena abrirla otra vez mañana?
   - ¿Qué información se guarda y quién más la puede ver?
   - ¿Cómo sabría yo, en un mes, que sirvió de algo?

4. Hazme las preguntas que te faltan para poder describir la app completa. Máximo ocho, numeradas, una por renglón, en lenguaje de todos los días. Ordénalas de la que más cambia la app a la que menos. No me des opciones todavía: solo las preguntas.

5. Cierra con una sola frase que empiece con "Es una app que le sirve a ... para ...". Esa frase es la que voy a usar de aquí en adelante.

No propongas pantallas, no propongas herramientas y no escribas nada de código. Guarda todo en un archivo llamado idea.md en esta carpeta y dime en qué quedó.

Segunda entrada: la foto del boceto

Si ya dibujaste las pantallas en una hoja, ese papel vale más que tres párrafos de explicación. Una imagen sí entra, y hay tres maneras de pasarla. Las tres llegan al mismo lugar; usa la que te quede más cómoda.

Te estoy pasando la foto de un boceto que hice a mano. Está chueco, tiene tachones y algunas cosas están a medias. Léelo así como está y no lo embellezcas.

Primero, antes de interpretar nada, descríbeme qué ves en la hoja: cuántos recuadros hay, qué texto alcanzas a leer y qué flechas hay entre ellos. Si algo no se entiende, dilo en vez de adivinar.

Después arma esto:

1. La lista de pantallas que están dibujadas. Una por renglón, con el nombre que yo les puse. Si no les puse nombre, ponles uno corto y avísame que fue tuyo.

2. Por cada pantalla: qué se ve, qué botones tiene y qué pasa al tocar cada botón. Si el dibujo no dice a dónde lleva un botón, escribe "sin destino en el dibujo" y no lo inventes.

3. El recorrido completo: desde que la persona abre la app hasta que logra lo que venía a hacer. Numerado, pantalla por pantalla.

4. Lo que falta y casi siempre se olvida en un boceto:
   - Qué se ve la primera vez, cuando todavía no hay nada guardado.
   - Qué se ve mientras algo está cargando.
   - Qué se ve cuando algo sale mal.
   - Cómo se sale, se cancela o se regresa.

5. Las contradicciones entre lo que está dibujado y lo que te conté antes de la idea. Si no hay ninguna, dilo.

No hagas diseño, no propongas colores y no escribas código. Guarda el resultado en idea.md, en la misma carpeta, debajo de lo que ya esté escrito ahí. Si ese archivo todavía no existe, créalo. No crees archivos nuevos: todo lo de este paso vive en idea.md.

Lo que ya debe estar escrito antes de seguir

Si alguno de estos cinco todavía vive nada más en tu cabeza, no sigas. El paso que viene recorta, y no se puede recortar lo que no está escrito. Los cinco viven en el mismo archivo, idea.md, que es el único que deja este paso.

• La frase de una línea: es una app que le sirve a alguien concreto para algo concreto.
• Quién la usa, dicho como una persona y no como un mercado.
• Qué hace esa persona hoy para resolverlo sin la app.
• La lista de pantallas que ya se ven en el boceto, con sus botones.
• La lista de lo que todavía no decidiste, marcada como pendiente y no como si ya estuviera resuelto.

Con eso ya tienes la idea afuera, escrita y con sus huecos señalados. Es más de lo que llega a tener la mayoría de las ideas que se quedan en el camino. También es más grande de lo que puedes construir primero, y eso se arregla en el paso que sigue.

La idea completa no se termina nunca. Siempre hay una función más que la haría mejor, y cada una parece pequeña vista de a una. Juntas son la razón por la que la app nunca sale.

Recortar no es rendirse ni hacer una versión pobre. Es escoger la parte más chica que ya le resuelve algo real a una persona real. Si esa parte no le sirve a nadie, no está recortada: está incompleta, que es otra cosa.

Y hay una razón práctica además de la anímica. Lo que construyes primero es lo que vas a tener que corregir, mantener y explicar. Mientras menos sea, más rápido descubres si la idea aguanta.

Ojo con el momento, porque hay dos recortes distintos y se hacen en momentos distintos. Cuando ya tienes un plan escrito y lo que sobra es alcance, el prompt que sirve es «Corta el alcance», y vive en Planea antes del automático. Aquí todavía no hay plan de nada: hay un párrafo desordenado recién salido de tu cabeza. Por eso el prompt de esta sección parte de la idea cruda y devuelve versiones enteras, no funciones tachadas de una lista.

La regla para decidir

Una sola regla, y se aplica contra la frase de una línea que quedó escrita en el paso anterior. Cada función se lee al lado de esa frase y se pregunta si la persona logra lo que iba a lograr sin ella. Si lo logra, la función se va.

Las tres versiones de la misma idea

El prompt no decide por ti. Te pone las tres versiones lado a lado para que la decisión sea tuya y con los ojos abiertos. La tercera es la importante: es la lista exacta de lo que estás dejando fuera, escrita para que no se te olvide que existe.

Esta es mi idea de app, tal como quedó escrita. Todavía no hay ningún plan y no quiero que lo hagas. Quiero decidir qué construyo primero.

Dame tres versiones de la MISMA idea, en este orden y sin mezclarlas:

VERSIÓN A — la mínima que ya le sirve a alguien.
- Un solo recorrido, de principio a fin: qué abre la persona, qué hace y con qué se va.
- La lista de pantallas de ese recorrido. Ni una más.
- Lo mínimo que hay que guardar para que el recorrido tenga sentido la segunda vez que la abra.
- Una línea que diga a quién le sirve esto ya, hoy, tal como está.
- Si esta versión no le sirve a nadie todavía, dímelo de frente y explícame qué le falta para servir.

VERSIÓN B — la que pedí.
- Todo lo que aparece en mi idea, incluyendo lo que se me coló sin darme cuenta.
- Márcame cuáles de esas funciones son en realidad una segunda app metida adentro de la primera.

VERSIÓN C — la diferencia entre A y B.
- La lista de todo lo que queda fuera de la versión mínima.
- Junto a cada punto, en una sola línea: por qué se puede esperar.
- Junto a cada punto, también: qué pierde la persona mientras no exista.
- Ordénalos por lo que más se va a extrañar.

Reglas para las tres:
- Español simple, sin palabras técnicas y sin nombres de herramientas.
- No propongas tecnología, no escribas código y no hables de tiempos.
- No me digas cuál escoger hasta el final.

Al final, y solo al final, dime cuál me recomiendas y por qué en tres renglones. Luego hazme la única pregunta que más te falta contestar para que la versión A quede bien definida.

Guarda las tres versiones en recorte.md, en esta carpeta.

VERSIÓN A — la mínima
  Recorrido: abrir · elegir departamento · registrar el pago · ver el saldo
  Pantallas: lista de departamentos · detalle · registrar pago
  Se guarda: departamento, inquilino, pagos con fecha y monto
  Le sirve a: tú, el primer día, para dejar la libreta

VERSIÓN C — la diferencia
  Recordatorio automático  ·  se puede esperar: hoy lo mandas tú por mensaje
  Foto del comprobante     ·  se puede esperar: el monto ya queda registrado
  Aviso de fugas           ·  esto es otra app, no una función de esta
  Total cobrado del año    ·  se puede esperar: se saca sumando a mano

Ese es el aspecto que tiene una respuesta útil: la mínima se lee en cuatro renglones y la diferencia dice qué se pospone y qué ni siquiera pertenece a esta app.

Señales de que todavía no está recortado

Si reconoces dos o más de estas en tu versión mínima, todavía estás mirando la idea completa con otro nombre. Vuelve a pasar el prompt, diciéndole que la versión A que te dio sigue siendo demasiado grande.

• La versión mínima tiene más de cinco pantallas.
• Para explicarla necesitas la palabra «además» o la palabra «también».
• Hay dos tipos de persona usándola: quien la administra y quien la consume.
• Ninguna función se puede quitar sin que, según tú, la app pierda el sentido.
• La lista de lo que se va está vacía o tiene un solo punto.
• Cuando la cuentas en voz alta, tardas más de un minuto en llegar al final.

Al terminar este paso tienes una sola cosa decidida, y es la que más pesa en todo lo que viene: qué se construye primero y qué espera su turno por escrito. Con esa decisión tomada, la idea ya se puede volver plano.

La idea ya salió de tu cabeza y ya está recortada. Lo que sigue no es construir: es escribirla de manera que otra sesión pueda construirla sin volver a preguntarte nada. A ese documento le decimos el plano.

Sin plano, cada vez que abres Claude Code le vuelves a contar tu app con otras palabras, y cada vez entiende algo un poco distinto. La versión del martes no es la del jueves. Con plano, tu app deja de vivir en la conversación y pasa a vivir en un archivo que se lee igual hoy que en dos semanas.

El plano lo escribe The Architect, un plugin que te entrevista antes de escribir nada. Tú contestas con palabras normales; él traduce a decisiones. Aquí va lo justo para que lo instales, elijas entrevista y salgas con tu plano en la mano.

Los dos comandos que lo dejan puesto

Los dos se escriben dentro de Claude Code, con la sesión ya abierta, y en ese orden. El primero le dice a Claude Code de dónde bajar el plugin; el segundo lo instala. Cuando termine el segundo, cierra la sesión y vuelve a abrirla para que aparezcan los comandos nuevos.

Esto se hace una vez en tu computadora, no una vez por app. La segunda idea que se te ocurra ya arranca con el plugin puesto.

Cuál de las dos entrevistas te toca

Hay dos maneras de llegar al plano y las dos terminan en el mismo tipo de documento. Cambia cuánto te pregunta antes de escribirlo. Los dos se escriben dentro de Claude Code, parado en la carpeta donde quieres que viva el proyecto: la misma donde ya guardaste idea.md y recorte.md.

Si dudas, corre la corta primero. Ver el plano terminado te enseña qué tipo de preguntas vienen, y la entrevista larga después se contesta mucho mejor.

La entrevista empieza preguntándote qué quieres construir. En vez de contestar esa primera pregunta con una frase, pega esto: manda a leer idea.md y recorte.md, los dos archivos que ya dejaste hechos en los pasos anteriores, y te ahorras la mitad de las preguntas que vienen después. Los renglones de abajo quedan de respaldo, por si alguno de los dos archivos no está a la mano. Arrastra la foto de tu boceto a la misma ventana antes de mandarlo.

Voy a diseñar una app y llego con tres cosas listas: idea.md y recorte.md, que están en esta misma carpeta, y la foto de mi boceto en papel que te acabo de adjuntar.

Antes de seguir con la entrevista, lee idea.md y recorte.md. En el primero está la idea completa como se la dicté; en el segundo, las tres versiones que recorté y cuál elegí. Toma todo eso como respuestas ya dadas y no me lo vuelvas a preguntar.

Si alguno de los dos archivos no está en la carpeta, dímelo y contesto a mano lo que falte de esta lista:

- Para quién es: [descríbelo como si hablaras de una persona real que conoces]
- El problema que resuelve, en una frase: [...]
- La única cosa que la app tiene que hacer bien: [...]
- Lo que decidí dejar fuera de la primera versión: [...]
- Cómo voy a saber que sirve: [qué tiene que pasar para que digas que funcionó]
- Dónde la voy a usar: [teléfono, computadora, las dos]

Sobre el boceto adjunto: léelo como el orden en que se ven las pantallas y qué hay en cada una. Donde mi dibujo esté ambiguo, no lo adivines: pregúntame por esa pantalla en concreto.

Reglas para el resto de la entrevista:

1. Yo no programo. Cada pregunta explícamela con palabras normales, y cuando tengas que darme a elegir entre dos opciones técnicas, dime en una línea qué cambia para el usuario final con cada una.
2. Hazme una pregunta a la vez y espera mi respuesta. No me mandes bloques de cinco.
3. Si una respuesta mía te deja con dudas, márcala y pregúntame de nuevo con otras palabras en vez de rellenar el hueco por tu cuenta.
4. No amplíes el alcance. Si se te ocurre una función que yo no pedí, anótala aparte como idea para después, no la metas al plano.
5. Al final, dime en tres renglones qué entendiste que voy a construir, y no escribas el plano hasta que yo te confirme que eso es.

Dónde queda cuando termina

Al cerrar la entrevista aparece una carpeta nueva dentro del proyecto. Ahí vive el plano, y ahí lo va a buscar la sesión que construya.

tu-proyecto/
└── blueprints/
    ├── el plano completo, con sus 20 secciones
    └── tasks.json  ← la lista de tareas, en orden y con sus dependencias

Esa carpeta es tuya y se queda en el proyecto: no vive en la conversación, así que no se pierde cuando cierras la sesión. Ábrela y léela. Es un archivo de texto normal, escrito para que lo entiendas.

La entrevista corre en cuatro fases —Descubrimiento, Profundización, Arquitectura y Generar— y se detiene en dos puntos de control antes de escribir nada: The Architect es la guía que recorre las fases y los puntos de control uno por uno, junto con sus otros comandos. Aquí no se explican: aquí se usa el plugin para salir con el plano.

Ya tienes el documento del que se construye. Lo que el plano no trae es cómo se ve tu app, y ese hueco no se llena inventando pantallas desde cero: se llena copiando el patrón de apps que ya están publicadas y funcionando. Eso es lo que sigue.

Una app hecha con ayuda de un modelo se delata en lo visual antes que en cualquier otra cosa. No falla porque se vea fea: falla porque las pantallas están acomodadas de una forma que nadie usa. El registro pide seis datos de golpe, la pantalla principal aparece vacía el primer día y no dice qué hacer, y el botón que importa está donde el pulgar no llega.

El arreglo no es pedir «hazlo bonito». Eso devuelve otra pantalla inventada. El arreglo es copiar el patrón: la secuencia con la que las apps que ya están publicadas resuelven ese mismo momento, después de años de gente usándolas.

Mobbin es la biblioteca donde viven esas pantallas, y se conecta a Claude Code como servidor MCP. A partir de ahí, Claude deja de imaginar interfaces y empieza a mirar las que ya existen antes de proponerte una.

Qué es Mobbin, en corto

Antes de conectarlo conviene saber exactamente qué estás conectando y qué te va a costar. Las dos últimas filas son las que la gente descubre tarde.

El plan se contrata en mobbin.com con la misma cuenta que vas a usar para autorizar la conexión más abajo. Si prefieres no pagarlo, sáltate esta sección: el resto de la guía funciona sin ella, con una condición. El paso que sigue —el de las piezas— lee por nombre los tres archivos que deja esta sección —patron-registro.md, patron-primer-dia.md y pantallas.md—, y el de construir los vuelve a abrir cuando toca una pantalla, así que el patrón lo vas a tener que escribir tú a mano en esos mismos tres archivos, mirando dos o tres apps que ya uses. No hace falta que sean bonitos; hace falta que existan y que digan el orden de los pasos.

Conectarlo, una sola vez

Son dos momentos: un comando en la terminal que da de alta el servidor, y una autorización que se firma desde adentro de Claude Code. El comando se corre con Claude Code cerrado o en otra ventana; da igual en qué carpeta estés, porque queda dado de alta para tu usuario y no para un proyecto.

Y ahora la autorización

Lo que te tienes que llevar de aquí

No te lleves capturas ni una lista de apps bonitas. Llévate un archivo de texto con el patrón escrito en pasos, porque eso es lo que se le pega a Claude cuando llegue el momento de construir. Este es el aspecto que tiene ese archivo cuando quedó bien hecho:

# Patrón de registro y primer ingreso
Revisadas: 6 apps del mismo rubro.

## La secuencia que se repite
1. Pantalla de bienvenida. Una frase, una imagen, un botón.
2. Entrar con el teléfono o con una cuenta que ya tengas.
3. Código de seis dígitos.
4. Nombre. Nada más. La foto y el resto quedan para después.
5. Pantalla principal, ya adentro.

## Lo que NADIE pide antes de dejarte entrar
- Contraseña con reglas de mayúsculas y símbolos.
- Fecha de nacimiento.
- Permiso de notificaciones.

## Dónde no se ponen de acuerdo
- 4 de 6 dejan mirar la app antes de pedir cuenta; 2 no.
- 3 de 6 piden el permiso de notificaciones hasta la tercera sesión.

Tres prompts que ya vienen armados

Los tres se pegan dentro de Claude Code, con Mobbin ya autorizado. Van en orden y cada uno usa el archivo que dejó el anterior. Cambia el rubro y el nombre de tu app; lo demás se queda tal cual, porque la parte que hace el trabajo es la que le prohíbe a Claude contestar de memoria.

Usa Mobbin para esto. No inventes pantallas y no contestes con lo que recuerdes:
todo lo que me digas tiene que salir de pantallas reales que hayas encontrado ahí.

Busca cómo resuelven el registro y el primer ingreso las apps de [TU RUBRO — por
ejemplo: administrar la renta de departamentos]. Quiero al
menos seis apps distintas y, de cada una, la secuencia completa desde que se
abre la app hasta que la persona ya está adentro.

Después arma un solo patrón con lo que se repite. Dame:

1. La lista de pasos en orden, con el nombre de cada pantalla.
2. Qué dato se pide en cada paso y qué se deja para más adelante.
3. En qué paso aparece el permiso de notificaciones, si es que aparece.
4. Cuáles piden correo y contraseña, cuáles piden solo el teléfono, y cuáles
   dejan mirar la app antes de pedir cuenta.
5. Las tres decisiones donde esas apps NO coinciden, con la postura de cada lado.

Cierra con dos listas: lo que hacen casi todas, y lo que hace solo una o dos.
No me des recomendaciones todavía y no escribas nada de código.

Guarda todo en patron-registro.md, en pasos numerados, sin adjetivos.
Al final del archivo escribe de qué apps salió cada cosa.

Sigue usando Mobbin. Misma regla: nada de memoria, todo de pantallas reales.

El día que alguien instala mi app no hay nada adentro. Ni un movimiento, ni un
registro, ni una lista. Esa pantalla vacía es la que decide si la persona vuelve
al día siguiente, y es la que casi nunca se diseña.

Busca cómo se ve la pantalla principal de seis apps del mismo rubro cuando la
cuenta está recién creada y todavía no hay datos. Quiero específicamente:

1. Qué se ve en el centro de la pantalla: dibujo, texto, o el listado vacío.
2. Qué dice exactamente el texto. Cópialo literal, no lo parafrasees.
3. Cuál es la única acción que ofrece esa pantalla, y qué tan grande es.
4. Si hay algún dato de ejemplo precargado para que la app no se vea muerta.
5. Cómo cambia esa pantalla en cuanto la persona hace la primera acción.

Después dime qué hacen distinto las dos apps que mejor resuelven ese momento y
por qué, mirando las capturas y no lo que se supone que es una buena práctica.

Guarda el resultado en patron-primer-dia.md.

Lee patron-registro.md y patron-primer-dia.md antes de contestar. Si algo no
está en esos dos archivos, búscalo en Mobbin; si tampoco está ahí, dímelo en vez
de rellenarlo.

Mi app hace esto: [describe en dos frases qué resuelve y para quién].
La versión recortada, la primera que voy a construir, tiene solo esto:
[pega aquí las funciones que quedaron después del recorte].

Arma la lista completa de pantallas de esa versión recortada. Para cada pantalla:

1. Nombre corto de la pantalla.
2. Para qué existe, en una frase.
3. Qué se ve de arriba a abajo, en orden.
4. Cuál es la acción principal y en qué parte de la pantalla queda.
5. Qué pasa cuando está vacía y qué pasa cuando algo falla.
6. De qué app real salió el patrón de esa pantalla.

Ordénalas en el recorrido que hace la persona, de la primera vez que abre la app
hasta que ya está usándola. Si detectas una pantalla que estoy pidiendo y que
ninguna app del rubro tiene, dímelo y explícame por qué crees que nadie la tiene.

Guarda todo en pantallas.md, que es el archivo que los pasos siguientes leen
por ese nombre. Nada de código todavía.

Al terminar esta sección tienes un patrón escrito y una lista de pantallas, y sigues sin una sola línea de interfaz. Eso es correcto: el patrón dice cómo se acomodan las cosas, no con qué se arman. Con qué se arman es lo que sigue, en las piezas.

Una advertencia que ahorra discusiones: copiar el patrón no es copiar la app. Lo que estás tomando es el orden de los pasos y el momento en que se pide cada cosa, que es conocimiento que ya se volvió costumbre en el rubro. El nombre, los colores, los textos y la idea siguen siendo tuyos, y si terminas con una app que se ve idéntica a otra, el problema no fue Mobbin.

Con el patrón escrito ya sabes cómo se acomodan las pantallas. Falta con qué se arman. Y aquí hay una tentación cara: pedirle a Claude que escriba desde cero cada campo, cada lista y cada botón. Funciona, tarda, y el resultado tiene ese aire de interfaz recién inventada que se nota a los dos segundos.

El atajo honesto es tomar piezas que ya existen. Un formulario de registro, una lista que se ve bien cuando está vacía, una hoja que sube desde abajo: alguien ya las construyó, ya las probó en pantallas chicas y ya las dejó listas para usarse. 21st.dev es el catálogo de esas piezas.

Se conecta a Claude Code como plugin. A partir de ahí le pides una pieza en español, te muestra opciones del catálogo y deja la que elijas dentro de tu proyecto, sin que tú toques el código.

Si lo que quieres es una página web o una landing, esta no es la sección: eso vive completo en El Diseñador Web Definitivo, que además instala 21st por otra ruta. Aquí la instalación va por plugin y todo lo que se pide son pantallas de app: registro, listas, estados vacíos y avisos. Es la misma herramienta usada para otra cosa, así que si ya la tienes puesta por la otra guía, sáltate los dos comandos de abajo.

Dos comandos y una llave

Son dos comandos y se escriben en lugares distintos, que es donde se atora casi todo el mundo. El primero va en la terminal, con Claude Code cerrado o en otra ventana. El segundo se escribe adentro de Claude Code, en la misma caja donde le escribes cualquier cosa. Dar de alta un marketplace admite las dos puertas: desde la terminal se escribe claude plugin al principio, y desde adentro se escribe /plugin. Es la misma operación, y por eso en el paso del plano entraste por la de adentro y aquí entras por la de la terminal.

Qué es 21st.dev, en corto

El código está abierto y se puede revisar antes de instalar nada: vive en 21st-dev/magic-mcp. No hace falta entenderlo para usar la herramienta, pero que exista y se pueda mirar es la diferencia entre una herramienta y una caja negra.

Qué te resuelve y qué te sigue tocando a ti

Una pieza es una pieza. Te ahorra el trabajo de construirla y te deja intacto el trabajo de decidir. Esta división evita la decepción de la primera tarde.

Cómo se pide una pieza

Adentro de Claude Code, /ui abre la búsqueda en el catálogo. Entre más específico seas, menos vueltas das. Este es el tamaño mínimo de detalle que vale la pena escribir:

Te va a mostrar opciones. Elige mirando cuál se parece más al patrón que sacaste antes, no cuál se ve más bonita en la vista previa. La que se parece al patrón es la que no vas a tener que rehacer en dos semanas.

Dos prompts que amarran el patrón con la pieza

Estos dos son los que hacen el trabajo de verdad, porque le entregan a 21st el patrón que ya sacaste en lugar de dejarlo elegir a ciegas. Se pegan dentro de Claude Code, en la carpeta de tu proyecto, con los archivos del paso anterior a la mano. Si te saltaste Mobbin porque no ibas a pagarlo, esto sigue funcionando: escribe tú los tres archivos —patron-registro.md, patron-primer-dia.md y pantallas.md— con el orden de los pasos tal como lo resuelven dos o tres apps que ya uses, aunque sean diez renglones cada uno. Los prompts los leen por nombre y les da igual quién los escribió.

Antes de buscar nada, lee patron-registro.md y pantallas.md. Lo que está ahí
manda sobre cualquier ejemplo que encuentres.

Necesito la pantalla de registro de mi app móvil, tal como quedó descrita en esos
archivos. Resumen de lo que dice el patrón: se entra con el teléfono, llega un
código de seis dígitos, y el nombre se pide después. Nada de contraseña.

Usa 21st para buscar piezas que sirvan para eso. Antes de instalar nada:

1. Muéstrame tres opciones de campo de teléfono con selector de país.
2. Muéstrame dos opciones de campo para el código de seis dígitos.
3. De cada una dime qué trae de fábrica: aviso de error, estado de carga,
   bloqueo del botón mientras se envía, y si se ve bien en pantalla chica.
4. Dime cuál se parece más al patrón del archivo y por qué, en dos frases.

Espera a que yo elija antes de instalar. Recuerda que la capa gratuita solo
permite dos instalaciones al día, así que no instales para probar.

Cuando yo te diga cuál, instálala, déjala en la pantalla de registro y cambia
todos los textos de ejemplo por los míos: [pega aquí el nombre de tu app y los
textos que quieres que vea la persona]. No agregues campos que el patrón no pide.

Lee patron-primer-dia.md y pantallas.md antes de empezar. El estado vacío tiene
que quedar como está descrito ahí, no como se te ocurra.

Quiero la pantalla principal de mi app: una lista de [di qué se lista: gastos,
pedidos, citas, lo que sea]. Cada elemento muestra [di qué se ve en cada renglón].

Busca en 21st una pieza de lista que traiga los tres estados resueltos, porque
son los tres que se olvidan y los tres que se ven feos si se improvisan:

1. Vacía, el primer día, cuando no hay nada. Con el texto y la única acción que
   dice el archivo del patrón.
2. Cargando, mientras llegan los datos. Sin que la pantalla salte cuando lleguen.
3. Con error, cuando no se pudieron traer. Con una forma clara de reintentar.

Muéstrame las opciones que encuentres y dime cuáles traen los tres estados y
cuáles solo el primero. No instales todavía: dime cuál recomiendas y espera.

Una vez instalada, quiero ver la pantalla en los tres estados, uno por uno,
para revisarla antes de seguir. Si la pieza no trae alguno de los tres, dímelo
de frente en vez de dejarlo a medias.

Antes de gastar una instalación

• Ya leíste el patrón y sabes qué debe traer la pieza.
• Comparaste al menos tres opciones del catálogo.
• Confirmaste que la pieza trae el estado vacío y el de error.
• Los textos de ejemplo ya los tienes reemplazados por los tuyos, en tu cabeza o en un archivo.

Con las piezas dentro del proyecto ya hay algo que se puede abrir y mirar, y ahí empieza la parte que de verdad decide si esto llega a la tienda: construir una función a la vez sin romper la anterior, en construir.

Si al final una pieza no te convence, quítala y pide otra. Lo que no se hace es quedarse con una pantalla que no te gusta porque ya está puesta: eso es exactamente lo que después se ve como una app hecha de prisa, y es lo único de esta sección que no tiene arreglo más adelante.

Aquí es donde casi todo el mundo se cae. Con el plano listo y las piezas escogidas, la tentación es escribir «constrúyeme la app» y ver qué sale. Sale algo, y ese algo se ve bien la primera media hora. Después aparece la pantalla que no lleva a ningún lado, el botón que no guarda nada y la lista que se llena con datos de mentira, y ya no sabes cuál de las veinte cosas que se hicieron a la vez fue la que rompió a las otras.

La regla es una sola y no tiene excepciones: una función a la vez, terminada y comprobada, antes de empezar la siguiente. No es una cuestión de paciencia, es de poder señalar el error. Cuando cambias una cosa y algo se rompe, sabes exactamente qué lo rompió. Cuando cambias doce, no.

El plano ya trae el trabajo partido en tareas, en orden, y cada tarea llega con sus criterios de aceptación y su comando de verificación. Lo que falta es la disciplina de recorrerlas de una en una, y eso es lo que arma esta sección.

La mecánica ya existe y se llama /architect-next

No hay que inventar un sistema de tareas: el plugin que escribió el plano trae el comando que lo recorre. Lee la lista de tareas que quedó junto al plano, encuentra la primera que está pendiente y cuyas dependencias ya están terminadas, y la imprime con sus criterios de aceptación y sus comandos de verificación. Eso es lo que hace que una construcción larga sobreviva a que cierres la computadora. Cómo funciona por dentro se explica en The Architect; aquí solo se usa.

Se escribe dentro de Claude Code, parado en la carpeta del proyecto. Si tu plano vive en otro lado, la ruta va como primer argumento, antes de la bandera. El comando pelado y sus cuatro banderas; con eso tienes de sobra para construir la app completa.

El identificador de la tarea sale de la lista: cámbialo por el que te haya impreso el comando anterior antes de mandarlo.

Este es el primer mensaje de cada sesión de construcción. Pégalo tal cual: no le pide que construya nada todavía, le pide que se ubique y te demuestre que entendió antes de tocar un archivo.

Vas a construir, no a diseñar. El diseño ya está cerrado y vive en el plano que está en la carpeta blueprints de este proyecto. Tú no estuviste en esa conversación y no la necesitas: lo que hay que saber está escrito ahí y en los archivos de patrón que están junto al proyecto.

Antes de escribir una sola línea de código, hazme estas cuatro cosas y párate:

1. Lee el plano completo, sus 20 secciones, y la lista de tareas que está junto a él. Si en la carpeta existen pantallas.md, patron-registro.md o patron-primer-dia.md, léelos también: ahí está cómo se ve cada pantalla y en qué orden van sus pasos.
2. Dime en tres renglones, con tus palabras, qué construye este proyecto y para quién.
3. Dime cuál es la primera tarea pendiente cuyas dependencias ya están terminadas, y léeme sus criterios de aceptación y su comando de verificación.
4. Dime si encontraste algo en el plano que no alcances a entender o que se contradiga con otra sección.

Cómo vamos a trabajar de aquí en adelante, y esto no cambia:

- Una tarea a la vez. Terminas, comprobamos, y hasta entonces pasamos a la siguiente.
- No adelantes trabajo de tareas que vienen después, aunque te quede a la mano. Si mientras trabajas ves algo que hay que arreglar en otra parte, anótalo y sigue.
- No inventes lo que no esté en el plano ni en los archivos de patrón. Si ninguno dice algo que necesitas para avanzar, pregúntame en vez de decidirlo tú.
- Nada de datos de mentira ni de pantallas de adorno. Si una parte todavía no se puede conectar, dímelo con esas palabras en vez de simularla.
- Cuando termines la tarea, corre su comando de verificación y pégame la salida tal cual, sin resumirla.
- Yo abro la app y la uso antes de darte el visto bueno. Tu palabra de que quedó no cierra la tarea.

No empieces a construir todavía. Contéstame los cuatro puntos y espera a que yo te diga que sí.

Qué revisas antes de pasar a la siguiente

Una tarea no está terminada porque Claude Code diga que está terminada. Está terminada cuando estas cinco cosas se cumplen, y las cinco se comprueban en menos de diez minutos. Si una falla, la tarea sigue abierta.

• El comando de verificación de la tarea corrió y su salida está a la vista, sin resumir.
• Los criterios de aceptación de la tarea se leyeron uno por uno y todos se cumplen.
• Tú abriste la app y usaste la función con la mano, como la usaría alguien que no la construyó.
• Lo que ya funcionaba sigue funcionando: probaste la función anterior y no se rompió.
• No quedó nada simulado: ni datos de relleno, ni botones que no hacen nada, ni pantallas de adorno.

El cuarto punto es el que casi nadie hace y el que más caro sale. Cada tarea nueva toca cosas que ya estaban, y la única manera de enterarte de que rompió algo es volver a usar lo de antes.

Y este es el mensaje con el que se cierra cada tarea. Hace la revisión de arriba en orden, te dice qué probar con la mano, y solo después marca la tarea y te entrega la que sigue.

Dices que la tarea quedó. Antes de marcarla y de pasar a la siguiente, hazme el corte completo, en este orden y sin saltarte nada:

1. Corre el comando de verificación de esta tarea y pégame la salida tal cual, completa. Si falla, no sigas con los demás puntos: dime qué falló.
2. Repasa uno por uno los criterios de aceptación de la tarea. Escribe cada criterio y al lado si se cumple o no, con la razón en una línea. No los resumas en un «todo listo».
3. Enlístame los archivos que tocaste y qué cambió en cada uno, en una línea por archivo.
4. Dime si dejaste algo simulado: datos de relleno, un botón que todavía no hace nada, una pantalla puesta como adorno, o cualquier parte que se vea terminada sin estarlo. Si no dejaste nada, dilo así.
5. Dime qué de lo que ya funcionaba pudo verse afectado por este cambio, y qué tendría que volver a probar yo por eso.

Después del corte, y solo si los cinco puntos salieron limpios, dame la lista de pasos exactos que tengo que hacer yo con la app abierta para comprobar esta función: qué abro, qué toco, qué escribo y qué debería ver en la pantalla. Numerada y en orden, sin explicaciones de código.

Ahí te detienes. Yo la pruebo y te digo.

Cuando yo te confirme que sí, marca la tarea como terminada con la bandera que corresponde y luego dame la siguiente tarea desbloqueada, con sus criterios de aceptación y su comando de verificación. Preséntamela y espera: no la empieces hasta que yo te lo diga.

Qué haces cuando una tarea se atora

Va a pasar. Una tarea que se resiste, un arreglo que rompe otra cosa, un comando de verificación que no pasa por tercera vez. Lo que no se hace es repetir el mismo mensaje con más énfasis: pedir lo mismo otra vez da lo mismo otra vez. Estos cinco pasos, en orden, y en el quinto se sale.

Una regla que ahorra tardes enteras: si llevas más de tres intentos en la misma tarea, deja de pedir arreglos y empieza por el paso uno. Nunca es el cuarto intento el que la saca.

Cada tarea que cierras la comprobaste con la mano, y en cada tarea la comprobaste igual: abres la app, haces los mismos pasos, revisas lo mismo. Esa prueba que estás repitiendo tarea tras tarea es la que conviene dejar de hacer a mano. En la sección que sigue se convierte en una habilidad que se corre sola.

Cada vez que le agregas algo a la app haces lo mismo con las manos: la abres, te registras con un teléfono nuevo, lo intentas otra vez con el mismo número a ver si sale el error, tecleas un código equivocado, revisas que el mensaje aparezca donde debe. Y en la siguiente función lo vuelves a hacer, igual, desde el primer paso.

Lo que vale ahí no es la prueba: es la repetición. Los pasos son siempre los mismos y el resultado que esperas también, así que se pueden escribir una vez y dejarlos guardados. De ahí en adelante los corre Claude, y tú te quedas con la parte que sí necesita ojos.

El cambio se hace una sola vez por prueba, y se hace justo después de probar a mano, cuando todavía tienes fresco el orden exacto de lo que tocaste.

Lo primero del archivo son dos datos: el nombre de la habilidad y su descripción. La descripción es la que decide cuándo se usa, así que ahí se escribe el momento con todas sus letras —después de cada función nueva, antes de cualquier envío— y no una frase bonita.

Cuándo una prueba ya se ganó ser habilidad

No toda prueba merece archivo. La que lo merece se reconoce por cuatro cosas, y las cuatro se cumplen al mismo tiempo o todavía no es momento.

• Ya la hiciste completa con las manos y salió bien. Guardar una prueba que nunca pasó solo guarda tu confusión, con más pasos.
• Los pasos son siempre los mismos y no dependen de lo que se te ocurra ese día. Si cada vez la haces distinto, todavía estás explorando, no probando.
• Sabes decir, sin pensarlo, qué tiene que salir en cada paso. Una prueba sin resultado esperado no falla nunca, y por eso no sirve.
• La vas a volver a correr. Si es de una sola vez, hazla con las manos y sigue adelante; escribirla cuesta más de lo que ahorra.

La señal más clara llega sola: el momento en que te descubres haciendo los mismos toques por segunda vez y ya te aburre. Ese aburrimiento es el aviso.

Cómo se hace, en tres pasos

Acabo de probar a mano una parte de la app y quiero dejar esa prueba guardada como habilidad, para no volver a repetirla con las manos cada vez.

Estos son los pasos que hice, en orden (reemplaza esta lista por la tuya):
1. Abrí la app.
2. Entré a la pantalla de registro.
3. Me registré con un teléfono que no estaba dado de alta y tecleé el código de seis dígitos que llegó.
4. Cerré sesión y me registré otra vez con el MISMO teléfono.
5. Volví al registro y tecleé un código de seis dígitos equivocado.

Y esto es lo que tiene que salir en cada caso:
- Con el teléfono nuevo: la cuenta se crea y se abre la pantalla principal.
- Con el teléfono repetido: sale un mensaje que dice que ese número ya está registrado, y no se crea una segunda cuenta.
- Con el código equivocado: sale un mensaje debajo del campo y el botón no continúa.

Quiero que hagas esto:
1. Crea una habilidad dentro de .claude/skills, con un nombre corto en minúsculas y con guiones que describa la prueba.
2. En su descripción escribe cuándo debe usarse, con estas palabras: después de cada función nueva y antes de cualquier envío.
3. Escribe los pasos en orden, uno por línea, tal como los haría una persona con la app enfrente.
4. Escribe al lado qué tiene que pasar en cada paso, para que se pueda comparar contra lo que pasa de verdad.
5. Agrega al final qué hacer si algo no coincide: qué anotar y qué no tocar.
6. No metas ningún paso que no esté en mi lista. Si crees que falta uno, pregúntamelo antes de escribirlo.
7. Escríbelo en español, en frases cortas, sin tecnicismos.

Cuando termines dime tres cosas: el nombre de la habilidad, la ruta exacta del archivo, y qué le tengo que escribir después para que la corras.

Cómo se ve el archivo que queda

Esto es una habilidad completa. No hay nada más: dos datos de identidad arriba, los pasos, lo que tiene que pasar, y qué hacer si algo no coincide. Se mira, no se copia, porque lo escribe Claude por ti.

---
name: prueba-de-registro
description: Corre la prueba manual del registro — teléfono nuevo, número
  repetido y código equivocado. Úsala después de cada función nueva y
  antes de cualquier envío.
---

# Prueba de registro

## Pasos
1. Abre la app, entra al registro y date de alta con un teléfono nuevo.
2. Cierra sesión y regístrate otra vez con el mismo teléfono.
3. Vuelve al registro y teclea un código de seis dígitos equivocado.

## Qué tiene que pasar
1. La cuenta se crea y se abre la pantalla principal.
2. Sale el mensaje de número ya registrado y no se crea otra cuenta.
3. Sale un mensaje debajo del campo y el botón no continúa.

## Si algo no coincide
Anota el paso, lo que se esperaba y lo que salió. No corrijas nada
sin avisar primero.

Una habilidad por prueba, y cada una con su nombre. Cuando sean varias, el reporte del segundo prompt te llega ya separado por nombre, y sabes de una lectura qué se rompió con la función de hoy.

Acabas de terminar la función NOMBRE DE LA FUNCIÓN. Antes de que sigamos con la siguiente, corre las pruebas que ya están guardadas.

Hazlo en este orden:
1. Revisa qué habilidades de prueba hay en .claude/skills y dime cuáles vas a correr.
2. Corre cada una siguiendo sus pasos al pie de la letra, sin saltarte ninguno.
3. Para cada paso, anota qué tenía que pasar y qué pasó de verdad.
4. Si algo no coincide, detente ahí. No lo arregles todavía.

Después dame un reporte corto, con esta forma:
- Pruebas que pasaron: solo los nombres.
- Pruebas que fallaron: el nombre, el paso exacto donde falló, qué esperaba y qué salió.
- Tu sospecha de por qué falló, en una frase.
- Qué cambiarías para arreglarlo, todavía sin cambiarlo.

Tres reglas que no se rompen:
- No edites ninguna habilidad por tu cuenta. Si la función nueva cambió el flujo de una prueba vieja, dímelo y espera.
- Si una prueba ya no aplica, propón borrarla y espera a que yo diga que sí.
- No cuentes una prueba como aprobada si tuviste que cambiar algo a la mitad para que pasara.

Si todas pasaron, dilo en una línea y quédate ahí: la siguiente función te la pido yo.

Con las pruebas guardadas, la app deja de romperse por la espalda cada vez que crece. Lo que falta es el repaso de afuera: por qué te rechazan revisa la app contra las guías con las que la tienda la mira, cada punto con su número.

El rechazo casi nunca llega por algo raro. Llega por lo mismo de siempre, y lo mismo de siempre tiene número: Apple publica sus guías de revisión numeradas, y el correo que te avisa cita el número de la que no cumpliste.

Por eso el repaso previo se hace guía por guía y no de corrido. Tres son las que se llevan casi todo, y las tres se pueden revisar en una tarde con la app abierta enfrente.

Esto se hace antes de enviar, no después. Un rechazo no te tumba la app, pero te devuelve al final de la fila, y la fila la caminas otra vez completa.

Las tres guías que se llevan casi todo

Una ficha por guía: qué pide, con qué te rechaza y qué revisas tú antes de enviar; la de completitud trae además cuánto pesa. El número va al frente porque es el que vas a leer en el correo si algo sale mal.

Dentro de la guía 5.1.1 vive también el requisito de que se pueda borrar la cuenta desde la propia app, y ese tema tiene guía propia: Borrar Cuenta en la App Store lo explica completo, y es la que se lee si tu app crea cuentas.

La guía 4.2 es la que le pone piso al recorte: el recorte deja lo mínimo que ya le sirve a alguien, no lo mínimo que se puede construir. Ese «ya le sirve a alguien» es exactamente lo que se revisa aquí.

El repaso, punto por punto

Se pasa entero, con la app corriendo y usándola como la usaría alguien de fuera, no como la usas tú mientras construyes. Cada punto lleva su número de guía al frente para que sepas dónde buscar si el correo lo cita.

• Guía 2.1 — La app abre desde cero, sin nada guardado de tus pruebas, y no truena al abrirla ni al salir.
• Guía 2.1 — No queda ningún texto de relleno, ninguna imagen de ejemplo ni ninguna pantalla que diga que falta algo.
• Guía 2.1 — Tocaste todos los enlaces de la app y ninguno queda roto ni lleva a una pantalla vacía.
• Guía 2.1 — Hay un enlace a soporte con un contacto que de verdad revisas y que responde.
• Guía 2.1 — Hay un enlace a la política de privacidad y abre desde la app.
• Guía 2.1 — Nada de lo que entregas queda a medias: no hay información incompleta en ninguna parte.
• Guía 4.2 — La app hace algo completo por sí sola, de principio a fin, sin que tú expliques nada.
• Guía 4.2 — Puedes decir para quién es y para qué sirve en una frase, y esa persona no eres solo tú.
• Guía 5.1.1 — La política dice qué datos recoges, cómo y para qué, y coincide con lo que la app hace de verdad.
• Guía 5.1.1 — Si compartes datos con alguien más, la política lo dice y confirma que ese tercero da la misma protección.
• Guía 5.1.1 — Si la app crea cuentas, se puede borrar la cuenta desde la propia app.

Los que fallan casi siempre son los de en medio: el enlace de soporte con un correo que nadie abre, y la política que se escribió antes de la última función y ya no dice la verdad.

Voy a enviar esta app a la App Store y quiero un repaso previo contra las guías de revisión de Apple. No eres abogado y no quiero una opinión legal: quiero una lista de lo que falta.

Revisa el proyecto y contéstame guía por guía, en este orden.

Guía 2.1, que la app esté terminada:
- Busca en todo el proyecto los textos de relleno y de ejemplo que se quedaron: nombres inventados, párrafos de prueba, imágenes de muestra, pantallas que no llevan a ningún lado.
- Junta todos los enlaces que aparecen en la app y dime a dónde va cada uno.
- Dime si existe un enlace a soporte con un contacto, y si existe uno a la política de privacidad.

Guía 4.2, que sirva para algo:
- Escribe en una frase qué hace la app completa, de principio a fin, sin usar la palabra «todavía».
- Dime qué partes están anunciadas pero no funcionan.

Guía 5.1.1, privacidad:
- Haz la lista de todos los datos personales que la app pide o guarda, y de a dónde van.
- Dime qué servicios de terceros reciben algo, aunque sea el correo.
- Compara esa lista contra el texto de la política de privacidad y señala cada diferencia.

Reglas del reporte:
- Una sola lista al final, ordenada por lo que más probablemente cause un rechazo.
- Cada punto con la guía que le toca, el archivo o la pantalla donde está, y qué hay que hacer.
- Si algo no lo puedes comprobar desde el proyecto, dilo en vez de suponerlo.
- No arregles nada todavía. Primero quiero ver la lista completa.

El texto completo, con todas las guías y sus números, está publicado: las App Review Guidelines de Apple es la referencia que manda, y la que conviene abrir el día que llegue un correo citando un número que no esté en esta página.

Lo que sigue, cuando la app ya está publicada

Aquí termina el camino: la idea salió de tu cabeza, se recortó, se volvió plano, tomó forma de pantallas, se construyó por partes y pasó el repaso. Lo que viene después ya no es lanzar, y tiene sus propias guías.

La idea que llevabas meses cargando ya no vive en tu cabeza. Está escrita, recortada, construida por partes y revisada contra las guías con las que la van a mirar. El siguiente paso es de la tienda, y ese ya no lo controlas: lo que sí controlaba este camino, quedó hecho.