aman-sharma-nine/agent-skills

Habilidad: De Tema Vago a Esquema de Artículo

Convierte un tema amplio o medio formado en un esquema de artículo distintivo e investigable sin redactar el artículo completo para el usuario. Parte del trabajo y la base de conocimiento existentes del usuario, identifica preguntas recurrentes en comunidades relevantes, selecciona una pregunta enfocada del lector y crea un andamio de investigación sección por sección.

Cuándo usarla

Úsala cuando el usuario:

• da un tema vago y quiere ayuda para convertirlo en un artículo;
• pide preguntas de investigación, un esquema o un punto de vista;
• quiere escribir manualmente y que el agente refine el trabajo después;
• pide conectar un tema nuevo con páginas wiki, proyectos o trabajo de implementación existentes.

No la uses para:

• escribir el artículo terminado inmediatamente;
• lluvia de ideas genérica sin investigación o trabajo con fuentes;
• editar un borrador existente donde la tesis y la estructura ya están claras.

Modelo Mental Principal

Usa esta secuencia:

Tema vago
  ↓
Trabajo y conocimiento existentes
  ↓
Preguntas externas recurrentes
  ↓
Problema enfocado del lector
  ↓
Tesis distintiva
  ↓
Mecanismo concreto u objeto de diseño
  ↓
Afirmaciones de sección y preguntas de investigación
  ↓
Contrargumentos y vacíos de evidencia
  ↓
Esquema reutilizable en el espacio de trabajo solicitado

El objetivo no es predecir el futuro ni resumir un campo. El objetivo es encontrar la intersección más fuerte entre:

1. lo que el usuario ha construido, observado o pensado realmente;
2. lo que un lector técnico específico necesita entender o decidir;
3. lo que los profesionales actuales están debatiendo activamente;
4. lo que puede respaldarse con fuentes primarias y ejemplos concretos.

Usa la secuencia de esquematización de [[outlining-an-article|Esquematizar un Artículo]]:

tema → volcado de ideas → agrupar → dar forma → una frase por sección → borrador

Para un artículo técnico de Substack, añade la capa de investigación antes de redactar:

tema → trabajo existente → preguntas recurrentes → ángulo enfocado
→ volcado de ideas → agrupar → forma narrativa → afirmaciones de sección → investigación → borrador

Procedimiento

1. Definir la restricción de escritura

Antes de investigar, establece:

• lector objetivo;
• tipo de artículo: ensayo técnico, guía de campo, nota de arquitectura, argumento contracorriente o estudio de caso;
• si el usuario quiere un esquema o texto terminado;
• dónde debe guardarse el esquema;
• el contexto existente del proyecto, implementación o wiki del usuario.

Por defecto: audiencia técnica, investigación y redacción manuales, solo esquema, luego refinamiento posterior.

Verificación de completitud: escribe una frase que describa al lector y el trabajo del artículo.

2. Inspeccionar primero el trabajo existente del usuario

Lee los archivos referenciados completamente para identificar:

• tesis explícitas;
• recorridos o ejemplos concretos;
• límites de arquitectura;
• casos de fallo;
• criterios de evaluación;
• compensaciones;
• preguntas no resueltas;
• lenguaje que el usuario ya usa.

Si el usuario referencia una wiki o carpeta, búscala en busca de conceptos superpuestos antes de inventar un nuevo marco. Lee la página de concepto, fuente, tema, nota y proyecto más relevantes.

Prefiere ideas fundamentadas en el trabajo propio del usuario. Una implementación concreta, una evaluación fallida, una decisión de diseño o una compensación no resuelta suele ser más valiosa que una afirmación genérica de tendencia.

Verificación de completitud: lista de 3 a 8 principios reutilizables del material del usuario.

3. Investigar preguntas recurrentes de los profesionales

Usa búsqueda web para discusiones actuales en comunidades de ingeniería y fuentes técnicas primarias. Busca en varias superficies cuando sea apropiado:

• repositorios de protocolo y issues/discusiones de GitHub;
• ejemplos de implementación oficial;
• blogs de ingeniería y documentación;
• Reddit u otras comunidades de profesionales;
• foros técnicos o material de conferencias.

Busca preguntas, no solo nombres de temas. Ejemplos:

• [tema] GitHub issue autoridad
• [tema] problema de implementación
• [tema] discusión de ingeniería fallo
• [tema] limitaciones del protocolo
• [tema] lecciones de producción

Registra las preguntas recurrentes bajo categorías como:

• identidad y autoridad;
• estado y transacciones;
• interoperabilidad;
• datos y límites de contexto;
• seguridad y abuso;
• evaluación y observabilidad;
• producto y modelo operativo.

No afirmes popularidad estadística a menos que un conjunto de datos sistemático lo respalde. Usa redacción como "preguntas recurrentes en las discusiones muestreadas" cuando la investigación sea cualitativa.

Verificación de completitud: produce de 10 a 25 preguntas recurrentes agrupadas por tema, con fuentes representativas.

4. Seleccionar la mejor pregunta del artículo

Evalúa las preguntas candidatas según:

Prueba	Pregunta
Valor para el lector	¿Ayuda a un lector específico a tomar una decisión de diseño o producto?
Autoridad del usuario	¿Tiene el usuario trabajo de primera mano o una opinión desarrollada aquí?
Evidencia	¿Puede la afirmación respaldarse con fuentes primarias y ejemplos?
Especificidad	¿Es más estrecha que el tema general?
Originalidad	¿Crea un punto de vista en lugar de un resumen?
Durabilidad	¿Seguirá siendo útil después de que pase el hype actual?
Potencial de serie	¿Puede dar lugar a artículos de seguimiento?

Selecciona una pregunta principal y, como máximo, dos alternativas. Explica por qué la ganadora es más fuerte.

Forma correcta de pregunta:

¿Cómo debería [constructor específico] diseñar [sistema específico] cuando [nueva condición]?

Evita:

¿Cómo cambiará [gran tecnología] [industria entera]?

Verificación de completitud: indica la pregunta del lector seleccionada y por qué gana.

5. Derivar la tesis del trabajo del usuario

Usa esta plantilla:

La visión común es:
El trabajo del usuario sugiere:
Esa visión es incompleta porque:
El modelo más útil es:
La consecuencia práctica para los constructores es:
La objeción más fuerte es:

La tesis debe ser una afirmación discutible, no una etiqueta de tema.

Ejemplos de transformaciones útiles:

• "Comercio electrónico agéntico" → "El agente comercial es un sistema de resolución de resultados acotado, no un chatbot."
• "Agentes empresariales" → "La unidad gobernada es el sistema de acciones, no el modelo."
• "Memoria de agente" → "La memoria es una superficie de control a nivel de aplicación, no solo una característica del modelo."

Verificación de completitud: escribe una tesis de una frase y una explicación de 30 segundos.

6. Nombrar o definir un mecanismo concreto

Dale al artículo un objeto de diseño que haga útil la tesis. Ejemplos:

• contrato de recorrido;
• límite de autoridad;
• arnés de evaluación;
• presupuesto de contexto;
• superficie de capacidad;
• rastro de decisiones;
• libro mayor de resultados;
• bucle de intervención.

No inventes jerga solo para sonar original. Busca si el término ya existe, identifica terminología adyacente y etiquétalo como término de trabajo si es necesario.

Verificación de completitud: define el mecanismo en 1 a 3 frases y muestra un pequeño ejemplo.

7. Dar forma al artículo como una historia

No crees un catálogo de temas. Dale al lector una razón para continuar de una sección a la siguiente.

Usa este flujo narrativo predeterminado:

1. Problema o escenario de apertura — muestra una situación concreta antes de explicar el tema.
2. Tensión — revela por qué la solución obvia falla o es incompleta.
3. Tesis — indica la afirmación principal con claridad.
4. Mecanismo — presenta el modelo, arquitectura u objeto de diseño que explica el problema.
5. Aplicación — recorre cómo el mecanismo cambia la práctica.
6. Barreras de seguridad o compensaciones — muestra qué puede salir mal y dónde están los límites.
7. Evidencia y evaluación — explica cómo un constructor sabría que el enfoque funciona.
8. Implicación — muestra qué cambia para el trabajo o la industria del lector.
9. Final abierto — cierra con una pregunta o tensión no resuelta, no con un resumen.

Para cada sección, escribe una frase antes de escribir párrafos:

Sección:
Afirmación que hace esta sección:
Ejemplo o evidencia:
Pregunta que tiene ahora el lector:
Cómo la responde la siguiente sección:

La siguiente sección debería responder normalmente a una pregunta creada por la sección anterior. Elimina las secciones que no hacen avanzar la historia.

Verificación de completitud: el esquema puede leerse de arriba abajo como una cadena de preguntas y respuestas, no solo una lista de temas.

8. Volcado de ideas, agrupar y reducir

Antes de finalizar el esquema:

1. Volcado de ideas con cada idea, ejemplo, fuente, objeción y observación personal relevante.
2. Busca material existente en la wiki, notas, destacados y archivos de proyecto.
3. Agrupa ideas relacionadas y elimina material que no respalde el ángulo seleccionado.
4. Elige una forma del flujo narrativo anterior u otra estructura apropiada.
5. Escribe una frase por sección y verifica las transiciones.
6. Mantén las ideas no resueltas en una lista aparte en lugar de forzarlas en el artículo.

No pases directamente del tema a la prosa. El esquema es el puente entre el pensamiento en bruto y el borrador.

Verificación de completitud: cada idea retenida pertenece a una sección, y cada sección tiene una afirmación principal.

9. Añadir preguntas de investigación y vacíos de evidencia

Para cada sección retenida, proporciona:

• preguntas de investigación que el usuario debe responder;
• evidencia que encontrar;
• probable contrarargumento;
• qué cambiaría la tesis;
• un ejemplo concreto, diagrama o caso.

No escribas preguntas que sean meramente interesantes. Cada pregunta debe ayudar a establecer, desafiar o calificar la afirmación de la sección.

Verificación de completitud: cada sección tiene de 2 a 5 preguntas de investigación respondibles y al menos un objetivo de evidencia.

10. Añadir contrarargumentos y vacíos de evidencia

No produzcas una narrativa de tendencia unilateral. Añade de 4 a 8 objeciones serias. Para cada una, crea:

Afirmación:
Evidencia a favor:
Evidencia en contra:
Qué cambiaría mi opinión:
Implicación para la tesis:

Marca las afirmaciones como hecho, pronóstico, interpretación u opinión. Identifica qué afirmaciones necesitan evidencia primaria antes de la publicación.

Verificación de completitud: lista la afirmación no respaldada más débil del artículo y la fuente necesaria para probarla.

11. Crear el artefacto del esquema

Si el usuario pide un archivo, créalo en la ubicación solicitada. Para borradores de Substack, usa:

substack/drafts/<titulo-descriptivo>.md

Usa frontmatter:

---
type: substack-draft
created: YYYY-MM-DD
updated: YYYY-MM-DD
status: esquema
working_title: "..."
---

El archivo debe contener la tesis de trabajo, el lector, la pregunta seleccionada, la disciplina de investigación, el esquema de secciones, preguntas, contrarargumentos y lista de fuentes. No escribas prosa de artículo terminado a menos que se solicite explícitamente.

No actualices wiki/index.md ni wiki/log.md para un borrador de Substack a menos que el usuario lo pida explícitamente. No modifiques raw/.

Verificación de completitud: el archivo existe, contiene el esquema completo y le indica claramente al usuario qué investigar a continuación.

12. Informar el resultado

Da un informe breve que contenga:

• el marco seleccionado;
• por qué se seleccionó;
• la superposición más fuerte con el trabajo existente del usuario;
• dónde se guardó el esquema;
• qué debería investigar y escribir el usuario a continuación;
• cualquier limitación en la investigación, especialmente si "más común" se infirió a partir de una muestra cualitativa.

Disciplina de Investigación y Fuentes

• Usa documentación técnica primaria para afirmaciones de protocolo e implementación.
• Usa discusiones comunitarias para descubrir preguntas y modos de fallo, no como evidencia incuestionable de comportamiento general del mercado.
• Separa capacidad del protocolo, comportamiento de implementación, confianza del usuario y adopción del mercado.
• Prefiere ejemplos concretos, trazas, casos de evaluación e informes de fallo sobre pronósticos genéricos.
• Cita afirmaciones factuales derivadas de internet en la respuesta final cuando se haya utilizado búsqueda web.
• No presentes resultados de búsqueda cualitativa como estadísticamente representativos.

Modos de Fallo Comunes

• Empezar con el tema de la industria en lugar de la evidencia más fuerte del usuario.
• Producir un resumen de protocolo sin un argumento.
• Tratar a un agente como la unidad de análisis cuando la unidad real es un recorrido, flujo de trabajo o sistema de acciones.
• Escribir el artículo antes de definir la pregunta del lector.
• Confundir una capacidad del modelo con una garantía de producción.
• Tratar una API o protocolo como prueba de interoperabilidad segura.
• Hacer preguntas de investigación que no pueden cambiar la conclusión del artículo.
• Ocultar la incertidumbre detrás de frases como "el mercado se está moviendo hacia".
• Crear terminología impresionante sin verificar la literatura adyacente.
• Redactar prosa pulida cuando el usuario pidió investigar y escribir manualmente.

Lista de Verificación

Antes de terminar:

• Se inspeccionaron los archivos de usuario existentes y las páginas wiki relevantes.
• El lector y el trabajo del artículo son explícitos.
• Se investigaron y agruparon preguntas recurrentes de la comunidad.
• Las afirmaciones de "más común" están calificadas a menos que se midan sistemáticamente.
• Se seleccionó una pregunta principal del lector.
• La tesis es discutible y está fundamentada en el trabajo del usuario.
• Un mecanismo concreto u objeto de diseño hace útil la tesis.
• Cada sección del esquema tiene preguntas de investigación.
• Se incluyen contrarargumentos y vacíos de evidencia.
• El esquema se guardó en la ubicación solicitada.
• No se escribió ningún artículo terminado a menos que se solicite explícitamente.