System prompts filtrados: el atajo a un CLAUDE.md mejor

Hay un repositorio en GitHub con 134.000 estrellas que recopila las instrucciones internas de casi todos los agentes de código que usas a diario, Claude Code incluido. No es una filtración morbosa: es la mejor escuela gratuita de prompt engineering que existe ahora mismo.

TL;DR

Qué es: los system prompts filtrados son las instrucciones internas que herramientas como Claude Code, Cursor o Devin envían al modelo en cada turno. Repos públicos las recopilan y versionan.
Por qué importa: ver cómo los pros estructuran reglas, límites y formato de salida te da plantillas probadas para tu propio CLAUDE.md sin pasar por meses de prueba y error.
Qué aprenderás: dónde leer estos prompts, qué cinco patrones copiar, qué dejar fuera y cómo evitar que tu CLAUDE.md se convierta en ruido que el agente ignora.

El problema: escribes reglas y el agente las ignora

En mi experiencia migrando flujos de Java a Python con agentes de código, el patrón se repite: añades una regla a tu CLAUDE.md ("usa siempre type hints", "no toques los tests"), y el agente la respeta dos turnos y luego la olvida. La reacción típica es escribir la regla más fuerte, en mayúsculas, con tres signos de exclamación. Casi nunca funciona.

El motivo es que la mayoría escribimos instrucciones a ciegas. No sabemos cómo redactan sus prompts los equipos que llevan meses optimizando este problema con millones de sesiones reales. Y resulta que esa información está pública. Aprender de los system prompts filtrados es la diferencia entre adivinar y copiar lo que ya funciona a escala.

¿Qué es un system prompt filtrado?

Un system prompt es el bloque de instrucciones que una herramienta inyecta antes de tu mensaje para definir el comportamiento del modelo: tono, herramientas disponibles, límites de seguridad y formato de salida. Un system prompt filtrado es ese bloque hecho público, normalmente extraído mediante técnicas de prompt extraction o reconstruido a partir del tráfico de la herramienta.

Tu CLAUDE.md no es exactamente lo mismo, pero juega en la misma liga: es texto que el agente lee al arrancar y trata como contexto de máxima prioridad. Las técnicas que los equipos de Anthropic o Cursor usan en su system prompt se trasladan casi directas a cómo deberías escribir el tuyo.

Las dos fuentes que merecen tu tiempo

No todos los repos son iguales. Estos dos son los que uso como referencia:

Repositorio	Qué contiene	Cuándo usarlo
x1xhlol/system-prompts-and-models-of-ai-tools	Prompts de 28+ herramientas (Cursor, Windsurf, Devin, Claude Code, v0, Replit). Más de 30.000 líneas.	Comparar enfoques entre herramientas y robar patrones transversales.
Piebald-AI/claude-code-system-prompts	Los system prompts de Claude Code con conteo de tokens, actualizado a v2.1.172 (10/06/2026) y un CHANGELOG de 205 versiones.	Entender cómo cambia Claude Code release a release y cuánto pesa cada sección.

Un detalle que descoloca a casi todos: Claude Code no tiene un system prompt, tiene muchos. Hay prompts distintos para la herramienta Edit, para Grep, para el modo de aprendizaje, para extraer insights de tu sesión. Cada uno está optimizado por separado. Esa modularidad es la primera lección.

Cómo extraer patrones útiles paso a paso

Leer 30.000 líneas no sirve de nada sin método. Este es el flujo que me funciona:

Abre dos herramientas en paralelo. Pon el prompt de Cursor Agent y el de Claude Code lado a lado. Donde resuelven el mismo problema de forma distinta, hay una decisión de diseño que entender.
Marca las reglas imperativas. Busca verbos en imperativo y mayúsculas selectivas ("NEVER", "ALWAYS", "IMPORTANT"). Fíjate en qué reservan para ese énfasis: casi nunca es trivial.
Copia la estructura, no el contenido. El orden de las secciones, el uso de listas frente a prosa, dónde ponen los ejemplos. Eso es portable. Los detalles específicos de cada herramienta, no.
Mide el coste. Con el repo de Piebald sabes cuántos tokens pesa cada bloque. Si una sección de 700 tokens te aporta poco, fuera.

Cinco patrones que puedes copiar hoy

Estos son los patrones que más se repiten en los prompts de producción y que mejor se trasladan a un CLAUDE.md:

Énfasis escaso. Las herramientas serias usan "IMPORTANT" en contadas líneas. Si todo es importante, nada lo es. Reserva las mayúsculas para la regla que de verdad no se puede romper.
Reglas accionables, no deseos. "Escribe código limpio" es ruido. "Usa funciones de menos de 30 líneas y nombres descriptivos" es ejecutable.
Negativos explícitos. Los buenos prompts dicen qué NO hacer con tanto detalle como qué hacer. "Nunca uses cat/grep, usa bat/rg" es más eficaz que un genérico "usa herramientas modernas".
Formato de salida cerrado. Cuando esperan una estructura concreta, la describen con un ejemplo literal. No la insinúan.
Jerarquía de prioridades. Definen qué gana cuando dos reglas chocan (correctness sobre velocidad, por ejemplo). El agente necesita ese orden para resolver conflictos sin inventárselo.

Aquí tienes el antes y el después de una regla real, reescrita con estos principios:

# Antes (vago, el agente lo ignora)
- Escribe buen código y maneja bien los errores.

# Despues (accionable, con limite y prioridad)
## Rules
- NEVER swallow exceptions: log con contexto o propaga.
- Funciones < 30 lineas. Si crece, extrae.
- Prioridad si hay conflicto: correctness > legibilidad > performance.

Esta lógica de redactar instrucciones claras y jerarquizadas es la misma que aplicas al diseñar software bien acoplado. Si te interesa profundizar, el principio de separación de responsabilidades en arquitectura de software se traslada casi tal cual a cómo organizas un CLAUDE.md por bloques con un único propósito.

Caso real: depurar un CLAUDE.md que contradecía al modelo

Un patrón que me funciona en producción es auditar el CLAUDE.md cuando el agente empieza a comportarse raro tras una actualización. En un proyecto de pipelines con FastAPI, el agente había dejado de respetar el formato de commits. Al comparar mi CLAUDE.md con el system prompt de Claude Code de esa versión, vi que mi regla chocaba con una instrucción interna nueva sobre cómo redactar mensajes.

La solución no fue gritar más fuerte, fue reformular mi regla para que encajara con la jerarquía del prompt base en lugar de pelearse con ella. Si actualizas seguido, este ejercicio conecta con la idea de auditar tu CLAUDE.md antes de seguir trabajando cada vez que cambia el modelo o la versión de la CLI.

En Producción

Trasladar estos patrones a un equipo cambia algunas cosas respecto al tutorial individual:

Coste en tokens. Tu CLAUDE.md se carga en cada sesión. Un archivo de 4.000 tokens lleno de buenas intenciones se paga en cada turno. El repo de Piebald te enseña a pensar en tokens por sección; aplícalo a tu archivo. Cuando el contexto se hincha, el problema se nota: lo cubro en cómo cruzar 200k tokens vacía tu presupuesto.
Reglas duras van en hooks, no en el prompt. La propia documentación de Claude Code es clara: los hooks son obligatorios, el CLAUDE.md es orientativo. Si una regla no se puede romper jamás (bloquear escritura en archivos sensibles, por ejemplo), va en un hook con exit code 2, no en una frase en mayúsculas.
Versiona el CLAUDE.md como código. En equipo, un CLAUDE.md con reglas contradictorias degrada al agente para todos. Revísalo en pull request igual que cualquier otro artefacto.
No copies sin probar. Un patrón de Cursor puede no encajar con cómo Claude Code interpreta el contexto. Mide en tu repo antes de adoptarlo.

Si tu necesidad va más allá de reglas y entra en comportamientos reutilizables, conviene saber dónde acaba el CLAUDE.md y empieza una skill. Lo desarrollo en cómo crear una Claude Skill con tu plantilla y en por qué tu Claude Code puede necesitar un agent harness cuando las reglas sueltas se quedan cortas.

Errores comunes y depuración

Error: el agente ignora una regla crítica. Causa: está enterrada entre veinte reglas con el mismo énfasis. Solución: sube las dos o tres innegociables al principio y deja el resto como orientación.
Error: tras actualizar la CLI, el comportamiento cambia sin tocar tu config. Causa: el system prompt base cambió en esa release. Solución: revisa el CHANGELOG de Piebald de esa versión y ajusta tu CLAUDE.md a la nueva jerarquía.
Error: copias un prompt entero de otra herramienta y el agente se confunde. Causa: traes detalles específicos de tooling que no existe en Claude Code. Solución: copia solo la estructura y las reglas portables, no las referencias a herramientas ajenas.

Preguntas frecuentes

¿Es legal y ético usar system prompts filtrados?

Leerlos con fines de aprendizaje es práctica común y los repos son públicos con cientos de miles de estrellas. Otra cosa es copiar literalmente el prompt comercial de una empresa para un producto competidor. Para inspirarte y mejorar tu CLAUDE.md, estás en terreno seguro.

¿Cómo de a menudo cambian estos prompts?

Mucho. El repo de Piebald registra más de 205 versiones de Claude Code y se actualiza minutos después de cada release. Por eso conviene no tatuarte un patrón: revisa el CHANGELOG cuando actualices y trata tu CLAUDE.md como algo vivo.

¿Reemplaza esto a leer la documentación oficial?

No, la complementa. La documentación te dice qué deberías hacer; los system prompts filtrados te enseñan cómo lo hace el equipo que diseñó la herramienta. Usa ambos: la doc para los principios, los prompts reales para la ejecución.

Lo que te llevas

Hemos visto que los system prompts filtrados son una biblioteca de patrones probados, no una curiosidad. La clave está en copiar la estructura y no el contenido, reservar el énfasis para lo innegociable y mover las reglas duras a hooks en lugar de confiarlas a un párrafo en mayúsculas. Tu CLAUDE.md mejora más leyendo cómo escribe Anthropic su prompt que añadiendo otra regla a ciegas.

¿Has reescrito tu CLAUDE.md a partir de algún prompt filtrado? Cuéntame qué patrón te funcionó en los comentarios o en Twitter @sergiomarquezp_. En el próximo artículo entro en cómo testear un CLAUDE.md como si fuera código, con evals ligeras que detectan reglas contradictorias antes de que degraden al agente.