Comment utiliser last30days pour accomplir des besoins de recherche basés sur les réseaux sociaux

27 juin 2026

Comment utiliser last30days pour accomplir des besoins de recherche AI basés sur les réseaux sociaux

Sur les réseaux sociaux, les gens s’expriment chaque jour : publier des posts, voter, débattre, se désabonner, migrer. Ces voix dispersées sur Reddit, X, YouTube comments, TikTok, Hacker News, Polymarket ne sont que du bruit si on les regarde séparément, mais ensemble elles constituent une tranche d’opinion publique assez authentique. Le problème c’est que personne ne veut parcourir trente jours de posts sur huit plateformes juste pour une conclusion de recherche.

Le skill Last30days est fait pour ça. Il va rassembler pour vous le contenu des trente derniers jours de tous ces canaux, les synthétiser par thème. Et le couche preset task transforme “appeler last30days” d’une commande nécessitant de se souvenir des paramètres en un formulaire prêt à être exécuté.

Cet article ne veut pas parler de l’efficacité de last30days lui-même, mais de la façon dont HagiCode utilise le mécanisme d’orchestration preset task pour concrétiser “un skill orchestré en quatre postures de recherche”. Après tout, skill est la capacité, preset est la colle qui transforme la capacité en produit.

Contexte : ce que preset veut économiser, c’est cette phrase répétée

Le système preset task liait initialement un skill au niveau preset. C’est-à-dire qu’un preset correspondait à un skill, le mode d’appel était relativement unique. Mais dans la réalité, la même capacité doit souvent être utilisée avec différentes postures — pour last30days aussi, parfois vous voulez faire une recherche générale, parfois vous voulez faire une comparaison de concurrents, parfois vous voulez seulement faire une analyse de style de prompt pour un certain produit.

Forcer ces différents modes d’utilisation dans un même flux d’interface rend l’interface de plus en plus confuse ; les diviser en quatre skills indépendants, c’est recréer la roue. Alors le design a fait un pas vers le milieu : permettre de lier un skill au niveau command. Un preset accroche plusieurs commands, chaque command s’auto-décrit sur quel skill il veut appeler, avec quels paramètres ; tandis que preset requirements sert comme liste d’autorité, déclarant quels skills ce preset dépend au total.

Ainsi, l’interface reste l’interface, l’exécution reste l’exécution. Qui veut mélanger le style d’interface et la logique d’exécution en une bouillie.

Un skill, quatre modes

Le preset Last30days est le modèle de ce paradigme : un skill, quatre commands. Les quatre commands correspondent à quatre postures de recherche :

• general（recherche générale） : donnez un query, laissez last30days aller pêcher les discussions pertinentes des trente derniers jours sur différentes plateformes, puis synthétiser la conclusion.
• comparison（comparaison） : donnez explicitement les objets à comparer, laissez le skill organiser le matériel autour de “qui est meilleur/qui est pire/quels sont les points de douleur respectifs”.
• competitors（concurrents） : se concentre sur l’écosystème de concurrents d’un certain produit, appelle le flag --competitors intégré de last30days.
• prompting（style de prompt） : s’intéresse à la façon dont les gens utilisent réellement, comment ils posent des questions, orienté vers l’utilisation et les modèles mentaux.

Dans commands.json, tous les commands déclarent "skill": "last30days", mais leurs preludes (paramètres et prompts) sont différents. Dans le tiroir frontal, l’utilisateur choisit le mode, écrit le query, coche les dépôts cibles ; quant à la commande assemblée derrière, c’est le preset lui-même qui décide. L’utilisateur n’a pas besoin de se souvenir des paramètres, ni de savoir l’existence du flag --competitors.

Deux couches de données : commands.json et task-preset.json

Dans le preset, deux fichiers partagent les responsabilités, divisées assez proprement :

• commands.json : décrit “quels commands existent, à quoi chaque command ressemble”. Chaque command a un champ skill, expliquant quel skill il doit appeler ; porte aussi son propre modèle de prelude, expliquant comment assembler ce command en une ligne de commande. C’est l’auto-description au niveau command.

• task-preset.json : décrit “ce que ce preset nécessite globalement”. Il contient requirements (déclarant la liste des skills dépendants), la définition des inputs, inputBindings, ainsi que des méta-informations comme selectionMode. C’est la liste d’autorité au niveau preset.

La frontière entre les deux couches est très claire : command est responsable de dire “j’ai besoin de ce skill”, preset est responsable de dire “quels skills ce preset permet d’utiliser”. Si un command déclare un skill qui n’est pas dans preset requirements, la validation rapportera une erreur — diagnostic command-skill-not-in-requirements. Cet échec explicite est bien meilleur qu’une dégradation silencieuse.

Injection en une ligne : /{skill} {prelude}

Ce qui relie vraiment skill au flux d’exécution, c’est un petit mécanisme peu visible : l’injection en une ligne. Dans PresetTaskCatalogProvider, il y a une méthode appelée CombineCommandSkillPrelude. La logique est simple : si un command déclare skill, et la ligne prelude qu’il rend ne commence pas par /{skill}, alors on ajoute /{skill} devant. Ce qui est finalement passé à l’exécuteur est une commande indépendante de la forme :

/last30days {commandPrelude}

Vient ensuite le corps rendu par user.hbs : mode de modelage, query, frontière du dépôt cible, ainsi que la contrainte “non interactif, enregistrer les hypothèses”.

Pourquoi faire ça ? Parce que le skill last30days lui-même se charge et exécute selon “recevoir la commande /{skill}”. Le preset ne peut pas supposer que le skill sera automatiquement déclenché, il doit explicitement passer cette commande. Une seule ligne, mais c’est la clé pour que toute la chaîne fonctionne.

Chaîne technique en cinq segments

En connectant tout ça, du clic de l’utilisateur à la conclusion revenant au dépôt, c’est cinq segments :

1. Sélection frontal : l’utilisateur dans CreatePresetTaskDrawer choisit le mode, écrit le query, coche les dépôts cibles. resolveCommandPreview reflète la logique d’assemblage du backend, affiche en temps réel la commande de prévision à l’utilisateur ; buildTargetScopeMarkdown groupe read/write, calcule la frontière du dépôt en un paragraphe markdown.

2. Validation backend : la requête arrive à SessionsController.PresetTasks.TryResolvePresetTaskRequestAsync. Il vérifie d’abord si les clés inputs/targets/derived sont dans la liste blanche, si le command est dans le catalog, si selectionMode est single, puis exécute PresetTaskRequirementCheckService.CheckAsync : pour chaque requirements skill, consulte l’inventory de skill local via LocalSkillCommandAdapter, déduplique par CacheKey.

3. Rendu du prompt : selon la locale, rend le user.hbs correspondant, injecte last30daysMode, last30daysQuery, targetScopeMarkdown, targetRepositories. user.hbs interdit explicitement AskUserQuestion, exige que l’exécuteur enregistre les hypothèses au lieu de demander face à l’ambiguïté — c’est la frontière dure de l’exécution non interactive.

4. Chargement et exécution du skill : l’exécuteur reçoit le prompt assemblé. /last30days comme commande indépendante au début, déclenche le chargement du skill. À l’intérieur du skill, il exécute selon ses LAWs : Step0.45 keyword-trap pré-vérification (empêcher query d’être mal pris comme handle/subreddit), Step0.5/0.55 analyser les canaux dirigés, Step0.75 laisser le modèle de raisonnement générer --plan lui-même, puis exécuter le moteur Python pour aller chercher des données sur Reddit/X/YouTube/TikTok/Instagram/HN/Polymarket/Web, Step 2 WebSearch supplémentaire, Step2.5 ajouter au fichier raw, enfin synthétiser la conclusion selon les LAWs.

5. Retour de la conclusion : la conclusion synthétisée est ramenée dans le contexte du preset. La frontière read/write du dépôt cible est une contrainte douce par l’injection du prompt targetScopeMarkdown — le preset dit au skill “tu ne peux lire que ceux-ci, écrire ceux-là”, le skill respecte cette frontière dans son exécution.

Quelques points de pratique

• La frontière non interactive doit être écrite dans le modèle. Dans user.hbs, désactiver AskUserQuestion n’est pas une suggestion, c’est une contrainte dure. Quand preset s’exécute, personne n’est assis devant l’écran pour répondre aux questions, donc l’ambiguïté doit être digérée par “enregistrer les hypothèses”.

• Préconfigurer les flags qu’on peut. Le mode concurrent met directement --competitors dans le prelude, l’utilisateur n’a pas besoin de savoir l’existence de ce flag. Le sens de preset est de cacher les paramètres professionnels entre les bonnes mains.

• La déduplication du skill se fait par CacheKey. Ce n’est pas grave si le même skill apparaît plusieurs fois dans requirements, PresetTaskRequirementCheckService déduplique par CacheKey, ne vérifie pas et ne charge pas en double.

• La frontière du dépôt est une contrainte douce. La frontière read/write dépend de l’injection du prompt, pas du sandbox. Cela signifie que si le skill obéit, cela dépend en partie de son degré de respect du prompt. C’est un compromis réaliste.

• L’échec doit être explicite, pas silencieux. Si le skill manque, rapportez l’échec de la vérification requirement, retournez 400, et donnez une entrée “installation en un clic” au frontend (openSkillGalleryForSkill). Laisser l’utilisateur savoir où ça casse, comment réparer, c’est beaucoup plus responsable que de se dégrader silencieusement en “peut exécuter sans skill”.

• La migration doit être sans destruction. L’évolution de preset skill par skill par command est rétro-compatible. La déclaration au niveau preset de l’ancien reste valide, la nouvelle déclaration au niveau command est une capacité superposée, pas un remplacement. Faire un pas trop grand, c’est facile de se tirer, pourquoi le faire.

---

Preset task transforme un skill en quatre formes de produits, non pas grâce à un algorithme élaboré, mais à plusieurs contrats avec des frontières proprement délimitées : auto-description du command, liste d’autorité du preset, injection en une ligne, contrainte dure non interactive, échec explicite. En connectant tout ça, “utiliser last30days pour faire la recherche sur les réseaux sociaux” passe d’une commande nécessitant de se souvenir des paramètres à une fonction qui s’exécute juste en remplissant un formulaire.

Quant à ce que ces voix rassemblées peuvent vraiment indiquer, c’est le travail de last30days lui-même…

Tags:

• last30days
• hagicode
• skill

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

Un routage précis pour chaque commande : Implémentation de la prise en charge de plusieurs compétences dans HagiCode Preset Task