Cómo usar last30days para completar las necesidades de investigación de IA basadas en redes sociales

27 jun 2026

Cómo usar last30days para completar las necesidades de investigación de IA basadas en redes sociales

En las redes sociales, todos los días las personas expresan sus opiniones: publican, votan, discuten, se dan de baja, migran. Estas voces dispersas en Reddit, X, comentarios de YouTube, TikTok, Hacker News y Polymarket, vistas individualmente, son solo ruido, pero juntas forman una porción bastante real de la opinión pública. El único problema es que nadie quiere revisar manualmente los publicaciones de treinta días en ocho plataformas para llegar a una conclusión de investigación.

El skill last30days nació precisamente para esto. Reúne por ti el contenido de los últimos treinta días de estos canales y lo sintetiza por temas. La capa de preset task convierte el acto de “llamar a last30days”, de un comando que requiere recordar parámetros, en un formulario que se puede rellenar y ejecutar.

Este artículo no habla de lo útil que es last30days en sí, sino de cómo HagiCode usa el mecanismo de orquestación de preset task para hacer sólido el concepto de “un skill con cuatro posturas de investigación”. Después de todo, el skill es la capacidad, y el preset es el pegamento que convierte la capacidad en un producto.

Fondo: lo que preset quiere ahorrar es en realidad esa frase que se repite

El sistema de preset task originalmente vinculaba un skill a nivel de preset. Es decir, un preset correspondía a un skill, y la forma de invocación era relativamente única. Pero en la realidad, la misma capacidad a menudo se usa de diferentes maneras: con el mismo last30days, a veces quieres hacer una investigación general, a veces quieres hacer una comparación de productos, a veces solo quieres analizar el estilo de los prompts para un producto específico.

Forzar estas diferentes formas de uso en un solo flujo de interacción haría que la interfaz se volviera cada vez más caótica; dividirlas en cuatro skills independientes sería reinventar la rueda. Así que el diseño dio un paso en el medio: permitir vincular skills a nivel de command. Un preset puede tener múltiples commands, cada command se describe a sí mismo sobre qué skill llama y con qué parámetros; mientras que los requirements del preset sirven como lista autorizada, declarando qué skills depende este preset en total.

De esta manera, la interfaz es la interfaz, la ejecución es la ejecución. ¿Quién querría mezclar el estilo de la interfaz con la lógica de ejecución?

Un skill, cuatro modos

El preset last30days es el modelo de este paradigma: un skill, cuatro commands. Los cuatro commands corresponden a cuatro posturas de investigación:

• general（investigación general）: Proporciona una query y deja que last30days recopile las discusiones relevantes de los últimos treinta días en varias plataformas, luego sintetiza una conclusión.
• comparison（comparación）: Especifica claramente los objetos a comparar y deja que el skill organice el material alrededor de “quién es mejor/quién es peor/dolores de cada uno”.
• competitors（competidores）: Se enfoca en el ecosistema de competidores de un producto específico, invocando el flag --competitors incorporado de last30days.
• prompting（estilo de prompt）: Se centra en cómo las personas realmente lo usan y cómo preguntan, orientado al uso y modelos mentales.

Los cuatro commands en commands.json declaran todos "skill": "last30days", pero sus preludios (parámetros y prompts) son diferentes. En el cajón frontal, el usuario selecciona el modo, escribe la query y marca los repositorios de destino; en cuanto a qué comando se arma detrás, el preset lo decide por sí solo. El usuario no necesita recordar parámetros ni conocer la existencia de flags como --competitors.

Dos capas de datos: commands.json y task-preset.json

El preset tiene dos archivos que comparten responsabilidades, divididas de manera bastante limpia:

• commands.json: Describe “qué commands hay y cómo se ve cada command”. Cada command viene con un campo skill que indica qué skill va a invocar; también viene con su propia plantilla de prelude que explica cómo convertir este command en una línea de comando. Esta es la autodescripción a nivel de command.
• task-preset.json: Describe “qué necesita este preset en general”. Contiene requirements (lista autorizada de skills dependientes), definiciones de inputs, inputBindings, y metainformación como selectionMode. Esta es la lista autorizada a nivel de preset.

Los límites de las dos capas son bastante claros: el command es responsable de decir “necesito este skill”, y el preset es responsable de decir “qué skills permite este preset”. Si un command declara un skill pero no está en los requirements del preset, la validación arrojará un error: el diagnóstico es command-skill-not-in-requirements. Este fallo explícito es mucho mejor que una degradación silenciosa.

Inyección de una línea: /{skill} {prelude}

Lo que realmente conecta el skill al flujo de ejecución es un mecanismo pequeño pero notable: la inyección de una línea.

En PresetTaskCatalogProvider hay un método llamado CombineCommandSkillPrelude. La lógica es simple: si un command declara un skill, y la línea de prelude que renderiza no comienza con /{skill}, entonces se añade el prefijo /{skill} al principio. Lo que finalmente se entrega al ejecutor es un comando independiente de la forma:

/last30days {commandPrelude}

Le sigue el cuerpo renderizado por user.hbs: modelado de modo, query, límites de repositorios de destino, y la restricción de “no interactivo, registrar suposiciones”.

¿Por qué hacer esto? Porque skills como last30days se cargan y ejecutan recibiendo el comando /{skill}. El preset no puede asumir que el skill se activará automáticamente, debe alimentar explícitamente este comando. Solo una línea, pero es la clave para que toda la cadena funcione.

Cadena técnica de cinco segmentos

Uniendo todo lo anterior, desde que el usuario hace clic en enviar hasta que la conclusión se conecta de nuevo al repositorio, son cinco segmentos:

1. Selección frontal: El usuario selecciona el modo, escribe la query y marca los repositorios de destino en CreatePresetTaskDrawer. resolveCommandPreview refleja la lógica de ensamblaje del backend y muestra el comando de vista previa al usuario en tiempo real; buildTargetScopeMarkdown agrupa por read/write y calcula los límites del repositorio en un fragmento de markdown.
2. Validación backend: La solicitud llega a SessionsController.PresetTasks.TryResolvePresetTaskRequestAsync. Primero valida que las claves de inputs/targets/derived estén en la lista blanca, que el id del command esté en el catálogo, que el selectionMode sea single, luego ejecuta PresetTaskRequirementCheckService.CheckAsync: para cada skill en requirements, consulta el inventario local de skills a través de LocalSkillCommandAdapter y elimina duplicados por CacheKey.
3. Renderizado del prompt: Renderiza el user.hbs correspondiente según el locale, inyectando last30daysMode, last30daysQuery, targetScopeMarkdown, targetRepositories. user.hbs prohíbe explícitamente AskUserQuestion, requiriendo que el ejecutor registre suposiciones en lugar de hacer preguntas cuando encuentre ambigüedad: esta es la frontera dura de la ejecución no interactiva.
4. Carga y ejecución del skill: El ejecutor recibe el prompt ensamblado. /last30days como comando independiente está al principio, activando la carga del skill. Dentro del skill, corre según sus propias LAWs: Step 0.45 hace una preverificación de keyword-trap (para evitar que la query se confunda con handle/subreddit), Step 0.5/0.55 analiza canales dirigidos, Step 0.75 deja que el modelo de razonamiento genere --plan, luego ejecuta el motor de Python para extraer datos de Reddit/X/YouTube/TikTok/Instagram/HN/Polymarket/Web, Step 2 suplementa con WebSearch, Step 2.5 añade al archivo raw, y finalmente sintetiza la conclusión según las LAWs.
5. Conexión de la conclusión: La conclusión sintetizada se devuelve al contexto del preset. Los límites de read/write de los repositorios de destino son restricciones blandas a través de targetScopeMarkdown en el prompt: el preset le dice al skill “solo puedes leer estos, puedes escribir esos”, y el skill respeta este límite en su ejecución.

Puntos prácticos importantes

• El límite no interactivo debe escribirse en la plantilla. En user.hbs, deshabilitar AskUserQuestion no es una sugerencia, es una restricción dura. Una vez que el preset se ejecuta, no hay nadie sentado frente a la pantalla para responder preguntas, así que las ambigüedades deben digerirse mediante “registrar suposiciones”.
• Los flags que pueden preestablecerse deben preestablecerse. El modo de competidores escribe directamente --competitors en el prelude, el usuario no necesita conocer la existencia de este flag. El significado del preset es ocultar los parámetros profesionales en las manos adecuadas.
• La deduplicación de skills se basa en CacheKey. No importa si el mismo skill aparece varias veces en requirements, PresetTaskRequirementCheckService elimina duplicados por CacheKey, sin repetir verificaciones o cargas.
• Los límites del repositorio son restricciones blandas. Los límites de read/write se inyectan a través del prompt, no a través de un sandbox. Esto significa que si el skill obedece o no depende parcialmente de qué tan bien siga el prompt. Este es un compromiso realista.
• El fracaso debe ser explícito, no silencioso. Si falta el skill, informa un fallo de requirement check, devuelve 400, y proporciona una entrada de “instalar con un clic” en el frontend (openSkillGalleryForSkill). Dejar que el usuario sepa qué está roto y cómo arreglarlo es mucho más responsable que degradar silenciosamente a “también puede ejecutarse sin skill”.
• La migración debe no ser destructiva. La evolución de skill a nivel de preset a skill por command es compatible hacia atrás. Las declaraciones antiguas a nivel de preset siguen siendo válidas, las nuevas declaraciones a nivel de command son capacidades adicionales, no reemplazos. Si el paso es demasiado grande, es fácil romperse, ¿por qué hacerlo?

---

El preset task convierte un skill en cuatro formas de producto, no gracias a algoritmos sofisticados, sino a varios contratos con límites limpios: autodescripción del command, lista autorizada del preset, inyección de una línea, restricción dura no interactiva, fallo explícito. Uniendo todo esto, “usar last30days para investigación de redes sociales” se convierte de un comando que requiere recordar parámetros a una función que se puede ejecutar rellenando un formulario.

En cuanto a lo que realmente pueden explicar estas voces reunidas, eso ya es trabajo de last30days…

Tags:

• last30days
• hagicode
• skill

让所有 Agent 都会 /goal：HagiCode 持续工作预设的兼容扩展设计

Haga que cada comando se enrute con precisión: Soporte de múltiples habilidades en HagiCode Preset Task en la práctica