Un sistema de prompts para Claude

Si trabajas con IA generativa en producto o diseño, seguro ya viviste esto: un prompt funciona bien hoy, mañana cambia, otra persona del equipo lo copia mal, y al cabo de una semana nadie sabe qué versión era la buena. El problema no suele ser Claude, ChatGPT o Gemini. El problema es que seguimos tratando los prompts como si fueran notas sueltas, cuando en realidad muchos equipos ya necesitan un sistema.

Eso es lo interesante del repositorio Claude Design System Prompt. Más que un prompt aislado, abre una conversación útil para equipos que quieren trabajar con IA de forma consistente: cómo guardar contexto, cómo definir roles, cómo repetir tareas sin reescribir todo desde cero y cómo evitar que cada persona invente su propia versión del flujo.

Qué propone Claude Design System Prompt

El repositorio de Trystan-SA parte de una idea simple: si usas Claude para tareas repetitivas de diseño, producto o documentación, no te conviene depender de un prompt largo pegado en una nota personal. Te conviene estructurar instrucciones que puedas reutilizar, versionar y adaptar según la tarea.

Eso cambia bastante la forma de trabajar. Ya no piensas solo en “qué le digo a la IA”, sino en “qué parte del contexto siempre debe estar presente”, “qué parte cambia por proyecto” y “qué parte pertenece al equipo”. Ese salto es el que convierte un prompt en un sistema.

En la práctica, un sistema de prompts sirve para reducir fricción en tareas como:

• redactar briefs de producto
• generar variantes de UI copy
• resumir research
• convertir notas de reuniones en acciones
• revisar consistencia entre pantallas y flujos

Si tu equipo ya usa IA para acelerar estas tareas, la pregunta no es si vale la pena estructurar prompts. La pregunta es cuánto tiempo estás perdiendo por no hacerlo.

Prompt suelto vs sistema reutilizable

Un prompt suelto resuelve una tarea puntual. Un sistema reutilizable define reglas, contexto y salida esperada para varias tareas relacionadas. La diferencia parece pequeña, pero en equipos se nota rápido.

Por ejemplo, una persona puede pedirle a Claude que “resuma esta entrevista de usuario”. Otra puede pedirle “extrae insights de esta entrevista”. Ambas están haciendo algo parecido, pero si no comparten una estructura, el resultado cambia demasiado entre una y otra.

Un sistema bien armado reduce esa variación. No elimina la creatividad ni la necesidad de revisar, pero sí baja el ruido operativo.

Qué tipo de equipos se benefician más

No necesitas un equipo enorme para que esto tenga sentido. De hecho, suele servir más en equipos pequeños donde una misma persona toca diseño, producto y contenido. También funciona bien en empresas donde varias personas producen entregables parecidos y quieren una salida más homogénea.

Piensa en un equipo de producto en Quito, Medellín o Ciudad de México que trabaja con una sola base de knowledge y varios stakeholders. Si cada persona usa prompts distintos, la IA se vuelve una lotería. Si todos parten de la misma estructura, el trabajo deja de depender tanto de quién escribió la instrucción.

El valor real aparece cuando quieres escalar criterio, no solo velocidad.

Cómo se estructura un sistema de prompts

La idea central es dividir el prompt en capas. No hace falta complicarlo con teoría innecesaria. Basta con separar qué es permanente, qué es variable y qué debe producir la IA al final.

Una forma práctica de pensarlo es esta:

Esta estructura no es exclusiva de Claude. Pero Claude suele funcionar especialmente bien cuando le das contexto ordenado y una salida clara. Si le pides demasiadas cosas mezcladas, la respuesta se dispersa. Si le das bloques definidos, la calidad sube bastante.

Para equipos de diseño y producto, la clave está en que el sistema no viva solo en la cabeza de una persona. Debe quedar escrito, revisable y fácil de copiar.

Base, contexto y tarea

La base define cómo trabaja el equipo con IA. Por ejemplo: escribir en español claro, evitar relleno, no inventar métricas, usar listas cuando ayuden, pedir aclaraciones si falta información crítica. Son reglas que no cambian en cada proyecto.

El contexto sí cambia. Ahí entra el producto, la audiencia, el objetivo de negocio, la etapa del funnel o el tipo de pantalla. Si estás trabajando en onboarding para una fintech en Ecuador, ese contexto importa mucho más que una instrucción genérica.

La tarea es lo que quieres que Claude haga. Mientras más concreta sea, mejor. “Ayúdame con marketing” es demasiado amplio. “Resume estas 12 notas de entrevista y devuelve 5 patrones de fricción” ya le da una dirección útil.

Salida y validación

La salida debe estar definida desde el inicio. Si quieres una tabla, dilo. Si quieres bullets con prioridad, dilo. Si quieres un JSON para pegar en otra herramienta, dilo. No asumas que Claude adivina el formato que te conviene.

La validación es la parte que muchos olvidan. Aquí le dices a la IA qué revisar antes de entregar. Por ejemplo: “verifica que cada recomendación tenga un ejemplo”, “no repitas ideas”, “marca cualquier dato que no esté sustentado en el input”. Eso ayuda a reducir respuestas elegantes pero poco útiles.

Si trabajas en producto, esta capa te ahorra mucho tiempo de edición manual.

Cómo aplicarlo en producto y diseño

El valor del repositorio no está solo en el texto del prompt. Está en el patrón mental que sugiere: convertir el uso de IA en una práctica repetible. Eso encaja muy bien con equipos de diseño, research, contenido y producto, donde hay tareas que se repiten con pequeñas variaciones.

Un caso muy común es el de research. Tienes entrevistas, notas, comentarios de soporte y feedback de beta testers. En vez de pedirle a Claude un resumen genérico, puedes darle una estructura fija: objetivo del análisis, formato de salida, criterios de agrupación y una lista de señales que sí importan.

Lo mismo pasa con diseño de producto. Puedes usar un sistema para revisar microcopy, detectar inconsistencias entre pantallas o proponer variantes de mensajes para errores, empty states y onboarding.

Casos de uso reales

Aquí van algunos escenarios concretos donde un sistema así sí aporta valor:

1. Resúmenes de research: conviertes 8 entrevistas en 5 patrones, 3 riesgos y 2 preguntas abiertas.
2. Revisión de UX writing: comparas el tono de varios mensajes y detectas dónde suena demasiado técnico.
3. Generación de variantes: produces 10 opciones de CTA, pero bajo reglas de marca.
4. Preparación de workshops: transformas notas dispersas en agenda, objetivos y dinámica.
5. Documentación interna: conviertes decisiones de Slack o Notion en un resumen limpio para el equipo.

En todos esos casos, el truco no es pedir “más inteligencia”. El truco es pedir una salida más útil.

Ejemplo de prompt modular

No necesitas copiar un prompt larguísimo cada vez. Puedes armar bloques reutilizables. Por ejemplo:

Base:
- Escribe en español claro y directo.
- No inventes datos.
- Si falta contexto, dilo.
- Prioriza claridad sobre ornamentación.

Contexto:
- Producto: app de pagos para pymes.
- Audiencia: personas no técnicas.
- Objetivo: reducir abandono en el primer flujo.

Tarea:
- Revisa este onboarding y detecta puntos de fricción.
- Propón mejoras concretas para cada pantalla.

Salida:
- Tabla con pantalla, problema, impacto y sugerencia.
- Luego, 3 riesgos prioritarios.

Ese formato es fácil de mantener. Además, permite que varias personas del equipo usen la misma base y solo cambien el contexto y la tarea.

Cómo convertir prompts en sistema de trabajo

Si quieres que esto funcione en serio, no te quedes en un archivo bonito. Un sistema de prompts necesita gobernanza mínima: dónde vive, quién lo actualiza, cómo se versiona y cuándo se revisa.

Esto es especialmente útil si tu equipo trabaja con varios proyectos a la vez. Sin una estructura común, cada persona termina guardando sus prompts en lugares distintos: Notion, Google Docs, mensajes fijados, snippets locales o incluso en chats viejos. Luego nadie sabe cuál es la versión vigente.

Lo práctico es definir un flujo simple. No hace falta una burocracia pesada. Hace falta orden.

Pasos para implementarlo en un equipo

1. Identifica 3 tareas repetidas que ya haces con IA, por ejemplo research, copy y síntesis.
2. Escribe una base común con tono, límites y formato.
3. Separa contexto de tarea para no mezclar reglas permanentes con información del proyecto.
4. Define una salida estándar por cada caso de uso.
5. Prueba con 2 o 3 personas y compara si la salida mejora o se vuelve más consistente.
6. Versiona el prompt con fecha o número, por ejemplo v1.2, para saber cuál está vigente.
7. Revisa cada 2 semanas si el prompt sigue sirviendo o ya quedó viejo.

Con ese esquema ya puedes trabajar mejor que con prompts dispersos. Y no necesitas una plataforma compleja para empezar.

Qué medir para saber si funciona

No basta con sentir que “ahora responde mejor”. Si quieres justificar el esfuerzo ante un equipo, mide cosas simples. Tiempo de edición, número de correcciones, consistencia entre salidas y cantidad de veces que alguien tiene que reescribir el prompt.

Por ejemplo, si antes tardabas 25 minutos en convertir notas de una entrevista en un resumen usable y ahora tardas 12, ya tienes una señal clara. Si además dos personas distintas obtienen una salida similar usando el mismo sistema, mejor todavía.

También puedes medir calidad con una revisión manual rápida. Haz una lista de 5 criterios, puntúa de 1 a 5 y compara antes y después.

Riesgos y límites de este enfoque

Un sistema de prompts ayuda, pero no reemplaza criterio humano. Si el input es malo, la salida también lo será. Si el equipo no sabe qué quiere resolver, el prompt solo va a maquillar el problema.

Otro riesgo común es sobreestructurar. A veces el equipo crea un prompt tan largo que nadie lo usa porque da pereza mantenerlo. Ahí el sistema deja de ser una ayuda y se vuelve una carga.

También hay un riesgo más sutil: confiar demasiado en la consistencia de la IA. Que Claude responda parecido no significa que siempre tenga razón. Tienes que revisar especialmente cuando haya decisiones de producto, claims de marketing o datos sensibles.

Cuándo sí y cuándo no usarlo

Sí conviene cuando la tarea es repetitiva, el formato importa y varias personas necesitan la misma calidad mínima. No conviene cuando estás explorando ideas sin dirección, cuando necesitas una conversación muy abierta o cuando el contexto cambia demasiado rápido.

En otras palabras, úsalo para estandarizar lo repetible. No lo conviertas en una camisa de fuerza para todo.

Si trabajas con equipos en Latinoamérica, además hay un punto práctico: el lenguaje. Un sistema bien hecho puede ayudarte a mantener consistencia entre español neutro, tono local y terminología de producto. Eso evita que un mismo mensaje suene demasiado formal en un país y demasiado informal en otro.

Tabla resumen

Recursos útiles para profundizar

Si quieres revisar la base oficial, vale la pena mirar la documentación de Claude en Anthropic: https://docs.anthropic.com/

También ayuda leer sobre buenas prácticas de prompting en la guía oficial de OpenAI, porque muchas ideas de estructura y validación se cruzan entre modelos: https://platform.openai.com/docs/guides/prompt-engineering

Y si tu equipo trabaja con documentación viva, conviene entender cómo versionar y mantener conocimiento interno en herramientas como Notion o Git, aunque el sistema de prompts viva fuera de ahí.

En la práctica, la lección del repositorio es bastante clara: no trates los prompts como hacks aislados. Si tu equipo ya depende de IA para producir, resumir o revisar, te conviene pensar en un sistema reutilizable con reglas, contexto y salida estándar.

Eso no solo mejora la calidad. También hace más fácil que dos personas distintas obtengan resultados parecidos sin pasar media hora reescribiendo instrucciones.

Si quieres empezar hoy, elige una tarea repetida, escribe una base común y prueba una versión mínima con tres bloques: contexto, tarea y salida. Con eso ya puedes notar si tu flujo se vuelve más ordenado o si estabas resolviendo todo a mano sin necesidad.