El skill sintetizador de investigación: un informe que puedes defender, no una corazonada disfrazada de certeza

Pides una investigación y te devuelven un informe fluido y seguro de sí mismo que se lee como pura verdad. El problema es que no hay forma de saber cuáles frases salieron de una fuente y cuáles las escribió el modelo solo porque sonaban convincentes; y en una decisión donde equivocarse sale caro, eso no vale nada. Un skill sintetizador de investigación fija una sola disciplina en algo que invocas por su nombre: reúne fuentes, contrasta cada afirmación con ellas y escribe un informe donde cada frase que sostiene la decisión tiene una cita en la que puedes hacer clic. Aquí repaso qué hace el skill, cuándo exactamente conviene que se active, cómo funciona por dentro, una invocación real con su resultado, las opciones de configuración y los detalles a cuidar; sobre todo, el modo de falla que vuelve todo peligroso si no lo previenes desde el diseño.

Lo primero que vale la pena interiorizar: este skill no hace al modelo más inteligente, lo hace honesto. El razonamiento corre sobre el mismo modelo con el que hablarías de todos modos. Lo que el skill impone es una actitud, cita o admite que no puedes, y esa actitud marca toda la diferencia entre un informe que puedes defender en una reunión y uno que esconde tres invenciones que vas a descubrir cuando ya hayas actuado sobre ellas.

01 · Qué hace el skill en realidad

Un skill de investigación responde una pregunta reuniendo fuentes, contrastando las afirmaciones con ellas y escribiendo un informe que indica de dónde salió cada dato. Si le quitas el empaque, hace cuatro cosas, en este orden:

1. Descomponer la pregunta. Convierte una pregunta difusa ("¿adoptamos X?") en sub-preguntas bien afiladas ("¿cuánto cuesta X a nuestra escala?", "¿cuál es la ruta para migrar y salir de Y?", "¿cuáles son los modos de falla conocidos?"). Si entra algo vago, sale algo vago: la descomposición es donde un simple repaso se convierte en un informe.
2. Buscar cada sub-pregunta y guardar las URLs. Lanza búsquedas en paralelo entre varias fuentes, reúne candidatos y se queda con las URLs exactas, no con un recuerdo vago de "leí en algún lado que…".
3. Pegarle una fuente a cada afirmación. Cada frase del informe que sostiene la decisión lleva su cita y, esto es lo que importa, la línea citada relevante de esa fuente queda junto a la afirmación, para que verifiques que la cita de verdad la respalda.
4. Marcar lo que no pudo verificar. Todo lo que no logró anclar a una fuente queda marcado como NO VERIFICADO, en vez de omitirlo en silencio o, peor todavía, darlo por hecho. Un vacío reconocido es información; una suposición segura de sí misma es una bomba de tiempo.

La disciplina detrás de los cuatro pasos cabe en una frase: separa lo que dicen las fuentes de lo que al modelo le gustaría que fuera cierto. Suena obvio, pero también es lo más difícil de lograr con un modelo de lenguaje fluido, porque fluidez y precisión no son la misma habilidad, y el modelo es buenísimo en la primera.

02 · Cuándo conviene que se active

Actívalo en un solo tipo de situación: una decisión donde equivocarse sale caro y necesitas poder defender los insumos. No para curiosear sin más; para eso, simplemente pregunta. El costo del skill (descomponer, buscar, citar, marcar vacíos) solo se justifica cuando una respuesta segura pero equivocada te puede salir cara de verdad.

En concreto, recurre a él cuando:

• Estás tomando una decisión técnica, elegir una base de datos, un framework, un proveedor de auth, y necesitas comparar lo que se dice sobre costo, límites y rutas de migración con lo que de verdad reportan los proveedores y los usuarios.
• Estás evaluando un aviso de seguridad o un CVE y necesitas saber qué está realmente afectado, cuál es la solución de verdad y si el titular alarmista coincide con los detalles.
• Estás respondiendo una pregunta de mercado o de competencia donde lo que está en juego justifica verificar en lugar de irte por intuición.

No lo actives para:

• Una pregunta que puedes responder desde tu propio codebase: eso es búsqueda en código, no investigación web.
• Algo donde una respuesta rápida y aproximada basta. El skill es más lento y más caro que una respuesta normal, y eso es a propósito; no pagues ese peaje cuando lo que está en juego es poco.
• Una pregunta tan vaga que no se puede descomponer. "Háblame de la IA" produce un repaso vago por muy disciplinado que sea el skill. Primero afina la pregunta.

El encuadre honesto: esto es apoyo para decidir, no un oráculo. Vuelve confiables los insumos de tu decisión, pero no decide por ti, y un informe con tres afirmaciones sólidas y citadas más un sincero "lo demás no lo pude verificar" sirve mucho más que diez frases seguras que no puedes rastrear.

03 · Cómo funciona por dentro

Un skill de Claude Code es un directorio con un archivo markdown: un frontmatter (un nombre y una descripción) más el cuerpo que le indica al modelo qué hacer. La descripción es lo que dispara su uso: es lo que Claude lee para decidir si el skill viene al caso, así que tiene que dejar claro cuándo usarlo, no solo qué es.

Aquí tienes una definición completa y lista para usar:

---
name: research-synth
description: >
  Responde una pregunta de alto impacto con un informe citado. Lanza
  búsquedas en paralelo, le pega una fuente citada a cada afirmación
  y marca como NO VERIFICADO lo que no se pueda confirmar. Úsalo para
  decisiones técnicas, avisos de seguridad o preguntas de mercado
  donde equivocarse sale caro y la respuesta debe poder defenderse.
---

Estás redactando un informe de investigación que se pueda defender. Sigue estos pasos.

1. DESCOMPÓN la pregunta en 3-6 sub-preguntas bien afiladas. Muéstralas.

2. Por cada sub-pregunta, BUSCA y reúne fuentes. Guarda la URL
   exacta de cada fuente en la que te apoyes.

3. Escribe el informe. Por CADA afirmación que sostenga la decisión, adjunta:
   - la URL de la fuente, y
   - la línea exacta citada de esa fuente que la respalda.
   Si no puedes citar una línea que la respalde, NO la afirmes
   como un hecho. Márcala NO VERIFICADO o déjala fuera.

4. Cierra con una sección de CONFIANZA: qué está bien respaldado, qué
   está flojo y qué no pudiste verificar en absoluto. No rellenes.

Nunca inventes una afirmación que ninguna fuente respalde. La meta es
un informe corto y honesto, no uno largo y vistoso.

Por dentro, el flujo es mecánico: cuando tu pedido coincide con la descripción, Claude carga el cuerpo del skill en el contexto, descompone la pregunta, lanza búsquedas por cada sub-pregunta, lee los resultados y arma un informe con la forma de los pasos numerados. El cuerpo fija el orden y la restricción rígida, cita o no lo afirmes, así que dos corridas sobre la misma pregunta terminan, más o menos, en el mismo lugar disciplinado. El modelo sigue encargándose de la búsqueda y la redacción; el skill se asegura de que muestre cómo llegó ahí y de que reconozca sus vacíos.

04 · Una invocación concreta y su resultado

Le pides: "¿Movemos nuestros jobs en background de una cola gestionada a un worker autogestionado sobre Redis? Hazme un informe." La descripción coincide, el skill se ejecuta y recibes algo con esta forma:

SUB-PREGUNTAS
1. ¿Cuál es la diferencia de costo a nuestro volumen de jobs?
2. ¿Cuánta carga operativa implica autogestionar Redis?
3. ¿Qué modos de falla conocidos y riesgos de pérdida de datos hay?

INFORME
- Autogestionarlo puede salir más barato a alto volumen, pero por
  debajo de cierto umbral el ahorro se lo come el tiempo de ops.
  > "Por debajo de unos 10M de jobs/mes la opción gestionada suele
  >  salir más barata si cuentas las horas de ingeniería."
  Fuente: https://example.com/queue-cost-analysis
- Las colas sobre Redis pueden PERDER jobs en un apagón sucio, a menos
  que la persistencia y los acks estén bien configurados.
  > "Por defecto, un crash entre el pop y el ack tira el job."
  Fuente: https://redis.example.org/reliability

NO VERIFICADO
- Tu volumen mensual concreto frente al punto de equilibrio: no
  tengo tus números. Esos los pones tú.

CONFIANZA
Bien respaldado: el tradeoff de durabilidad. Flojo: el dato de
costo (una sola fuente y tu volumen sin conocer). No pude verificar:
nada específico de tu infraestructura.

Ese es el resultado que quieres. Dos afirmaciones que llevan cada una su URL y la línea que la respalda, un bloque NO VERIFICADO explícito que nombra lo que la investigación de verdad no pudo resolver, y una sección de confianza que te dice cuánto peso aguanta cada afirmación. Puedes llevar esto a una decisión y defender cada frase, o saber exactamente cuál frase no puedes.

Compáralo con el modo de falla: un informe fluido de tres párrafos que afirma con todo el aplomo un número de equilibrio sin fuente, asegura que Redis "es confiable por defecto" (no lo es, con la config equivocada) y se lee precioso hasta que actúas sobre un número que nadie midió. El mismo modelo, pero sin barandas; que es justo lo que las restricciones del skill existen para evitar.

05 · Configuración y los ajustes que importan

Casi toda la configuración vive en el cuerpo del skill, no en flags. Los ajustes que vale la pena tocar:

• Allowlist / blocklist de fuentes. Oriéntalo hacia fuentes primarias (docs oficiales, el aviso original, la página de precios del propio proveedor) y lejos de las granjas de contenido SEO y los listicles generados por IA que se reparafrasean entre sí. Fuentes basura producen basura con cara de certeza.
• Ventana de recencia. Para cualquier cosa que cambia rápido, precios de modelos, versiones de librerías, estado de un CVE, exige una fecha en cada fuente y dile que prefiera las recientes. Un dato correcto de hace dos años es un dato equivocado hoy.
• Ancho del fan-out. Pon un tope a la cantidad de sub-preguntas y fuentes para que el informe no se infle en un crawl que quema tokens. De tres a seis sub-preguntas suele ser el punto justo entre quedarse corto y pasarse.
• Exigencia de cita textual. Esta es la innegociable: exige una línea citada exacta junto a cada afirmación. Es lo que distingue una cita cualquiera de una cita que respalda, y es lo que hace que el informe se pueda auditar.
• Forma del resultado. Fija las secciones, SUB-PREGUNTAS, INFORME, NO VERIFICADO, CONFIANZA, para que cada informe se escanee de la misma manera y los vacíos sean imposibles de pasar por alto.

El no-objetivo deliberado: no dejes que actúe sobre lo que encuentra. Un skill de investigación alimenta una decisión; no ejecuta el trade, no despliega la migración, no aplica el parche del CVE. Mantenlo en modo leer y reportar. En el momento en que una herramienta de investigación empieza a ejecutar lo que "encontró", una sola afirmación inventada se convierte en una acción en lugar de una frase que puedes descartar.

06 · Detalles a cuidar

La línea que lo decide todo es si no puede citar la línea que la respalda, la afirmación no está respaldada. Sin ella, el modo de falla es la síntesis con exceso de confianza: el modelo escribe una afirmación fluida, le pega una URL real que da la casualidad de ser del tema, y la cita apunta a una página que nunca dijo eso. El informe se ve riguroso y, en silencio, es pura ficción. Pon la exigencia de cita textual en el cuerpo tal cual y cambia el carácter de todo el resultado.

Otros que pegan duro:

• La frase convincente pero sin fuente. El instinto del modelo es rellenar los vacíos con frases que suenan bien. Dile sin rodeos que "esto no lo pude verificar" es una respuesta válida y valiosa: un bloque NO VERIFICADO honesto es una virtud, no un fallo de la corrida.
• Confiar en una sola fuente. Un solo post de blog no es un hecho verificado. Haz que avise cuándo una afirmación se apoya en una única fuente, y trata muy distinto una afirmación corroborada por dos fuentes serias e independientes que una repetida en tres sitios que copiaron el mismo comunicado de prensa.
• Fuentes desactualizadas. Una cita puede ser real y estar vieja al mismo tiempo. Para precios, versiones y estado de seguridad, una fuente vieja suele ser una fuente equivocada: exige fechas y dale más peso a lo reciente.
• Que la descomposición se desvíe. Una descomposición floja produce un informe que responde preguntas que no hiciste. Haz que el skill muestre las sub-preguntas primero y te deje corregirlas antes de gastar tokens buscando. Es la misma disciplina detrás del trabajo de deliberación en ThinkTank AI: acierta el encuadre antes de comprometer cómputo, porque una respuesta segura a la pregunta equivocada es peor que ninguna respuesta.

Un buen skill sintetizador de investigación no va a tomar la decisión por ti, pero sí se asegura de que cada insumo de esa decisión sea algo que puedas señalar y defender, y te dice, en voz alta, cuáles insumos no logró sostener. Constrúyelo una vez, mantén firme la línea de citar o admitir, y lee el bloque NO VERIFICADO con el mismo cuidado que el informe. El día que te entregue tres afirmaciones sólidas y citadas más un sincero "lo demás no lo pude verificar" en vez de diez frases seguras que no puedes rastrear, vas a saber que las restricciones están cumpliendo su trabajo.