Wie man last30days für soziale Netzwerk-basierte AI-Rechercheanforderungen nutzt

27.06.2026

Wie man last30days für soziale Netzwerk-basierte AI-Rechercheanforderungen nutzt

In sozialen Netzwerken äußern sich täglich Menschen: durch Posts, Abstimmungen, Streitigkeiten, Abmeldungen und Migrationen. Diese Stimmen, die über Reddit, X, YouTube-Kommentare, TikTok, Hacker News und Polymarket verstreut sind, erscheinen einzeln betrachtet nur als Rauschen, aber zusammen bilden sie eine ziemlich authentische Momentaufnahme der öffentlichen Meinung. Das Problem ist nur – niemand möchte für eine Forschungsergebnis manuell Beiträge von acht Plattformen über dreißig Tage durchsuchen.

Der last30days Skill wurde genau dafür entwickelt. Er sammelt automatisch Inhalte der letzten dreißig Tage von all diesen Kanälen, fasst sie thematisch zusammen. Die Preset Task-Ebene macht den Aufruf von last30days von einem Befehl, für den man sich Parameter merken muss, zu einem Formular, das man einfach ausfüllen kann.

Dieser Artikel geht nicht darum, wie nützlich last30days selbst ist, sondern wie HagiCode das Preset Task-Orchestrierungsmechanismus nutzt, um “einen Skill in vier Forschungsmodi zu orchestrieren”. Schließlich sind Skills Fähigkeiten und Presets der Klebstoff, der Fähigkeiten in Produkte verwandelt.

Hintergrund: Was Preset eigentlich spart, ist der Satz, der immer wiederholt wird

Das Preset Task-System war ursprünglich auf Preset-Ebene an einen Skill gebunden. Das bedeutete, ein Preset entsprach einem Skill, die Aufrufmethode war relativ einfach. In der Praxis wird dieselbe Fähigkeit oft in unterschiedlichen Modi verwendet – egal ob last30days, manchmal möchten Sie eine allgemeine Recherche machen, manchmal einen Wettbewerbsvergleich, manchmal eine Analyse des Prompting-Stils für ein bestimmtes Produkt.

All diese verschiedenen Nutzungsmöglichkeiten in einen Interaktionsablauf zu zwängen, würde die Benutzeroberfläche zunehmend unübersichtlich machen; in vier unabhängige Skills aufzuteilen, würde das Rad neu erfinden. Also machte das Design einen Schritt in die Mitte: Erlaube die Bindung von Skills auf Command-Ebene. Ein Preset hat mehrere Commands, jeder Command beschreibt selbst, welchen Skill er aufrufen und mit welchen Parametern; während die Preset-Ebene requirements als authoritative Liste deklariert, welche Skills dieses Preset insgesamt benötigt.

So bleiben Benutzeroberfläche und Ausführung getrennt. Wer möchte schon Benutzeroberfläche-Stile und Ausführungslogik in einem Knäuel vermischen.

Ein Skill, vier Modi

Das last30days Preset ist das Musterbeispiel für dieses Paradigma: ein Skill, vier Commands. Die vier Commands entsprechen vier Forschungsmodi:

• general (allgemeine Recherche): Geben Sie eine Query an, lassen last30days selbst relevante Diskussionen der letzten dreißig Tage von verschiedenen Plattformen sammeln und dann Schlussfolgerungen ziehen.
• comparison (Vergleich): Geben Sie explizit die zu vergleichenden Objekte an, lassen den Skill Material um “wer besser/wer schlechter/jede Schmerzpunkte” organisieren.
• competitors (Wettbewerber): Fokus auf das Wettbewerber-Ökosystem eines Produkts, ruft den --competitors Flag von last30days auf.
• prompting (Prompting-Stil): Beachtet, wie Leute tatsächlich verwenden, wie fragen, neigt zu Nutzung und mentalen Modellen.

Alle vier Commands deklarieren in commands.json "skill": "last30days", aber ihre jeweilige prelude (Parameter und Hinweise) sind unterschiedlich. Im Frontend-Drawer wählt der Benutzer den mode, schreibt die query, wählt Ziel-Repositories; welcher Befehl im Hintergrund zusammengestellt wird, entscheidet das Preset selbst. Benutzer müssen sich keine Parameter merken und müssen nicht wissen, dass Flags wie --competitors existieren.

Zwei Datenebenen: commands.json und task-preset.json

Das Preset-Paket teilt sich die Verantwortung auf zwei Dateien auf, recht sauber:

• commands.json: Beschreibt “welche Commands es gibt, wie jeder Command aussieht”. Jeder Command hat ein skill-Feld, das erklärt, welchen Skill er aufruft; sowie seine eigene prelude-Vorlage, die erklärt, wie dieser Command zu einer Zeile Befehl zusammengestellt wird. Dies ist die selbstbeschreibende Ebene des Commands.
• task-preset.json: Beschreibt “was dieses Preset insgesamt benötigt”. Es hält requirements (Liste der abhängigen Skills), Inputs-Definition, inputBindings sowie Metainformationen wie selectionMode. Dies ist die authoritative Liste auf Preset-Ebene.

Die Grenze zwischen den beiden Ebenen ist klar: Command ist dafür verantwortlich, zu sagen “ich brauche diesen Skill”, Preset ist dafür verantwortlich, zu sagen “welche Skills dieses Preset nutzen darf”. Wenn ein Command einen Skill deklariert, der aber nicht in den requirements des Presets steht, schlägt die Validierung fehl – das Diagnostic ist command-skill-not-in-requirements. Ein solcher expliziter Fehler ist viel besser als ein stillschweigender Rückfall.

Einzeilen-Injektion: /{skill} {prelude}

Was den Skill wirklich in den Ausführungsablauf integriert, ist ein unscheinbares kleines Mechanismus: Einzeilen-Injektion.

In PresetTaskCatalogProvider gibt es eine Methode namens CombineCommandSkillPrelude. Die Logik ist einfach: Wenn ein Command einen skill deklariert und seine gerenderte prelude-Zeile nicht mit /{skill} beginnt, dann wird /{skill} vorangestellt. Am Ende wird an den Executor Folgendes übergeben:

/last30days {commandPrelude}

Eine solche unabhängige Zeile. Danach folgt der von user.hbs gerenderte Haupttext: Modellierung, query, Ziel-Repository-Grenzen sowie die Einschränkung “nicht-interaktiv, Annahmen aufzeichnen”.

Warum das Ganze? Weil Skills wie last30days selbst darauf ausgelegt sind, bei Erhalt eines /{skill}-Befehls geladen und ausgeführt zu werden. Das Preset kann nicht annehmen, dass der Skill automatisch ausgelöst wird; es muss diesen Befehl explizit eingeben. Eine einzige Zeile, aber sie ist entscheidend dafür, dass die ganze Kette funktioniert.

Fünfstufige technische Kette

Wenn man das oben zusammenfasst, von der Benutzerübermittlung bis zur Rückverknüpfung der Schlussfolgerung mit dem Repository, sind es insgesamt fünf Stufen:

1. Frontend-Auswahl: Benutzer wählen im CreatePresetTaskDrawer den mode, schreiben die query, wählen Ziel-Repositories. resolveCommandPreview spiegelt die Backend-Zusammensetzungslogik und zeigt dem Benutzer in Echtzeit den Vorschaubefehl an; buildTargetScopeMarkdown gruppiert nach read/write und berechnet die Repository-Grenzen als einen Markdown-Abschnitt.
2. Backend-Validierung: Die Anfrage landet bei SessionsController.PresetTasks.TryResolvePresetTaskRequestAsync. Es validiert zuerst, ob die Schlüssel von inputs/targets/derived in der Whitelist sind, ob die command ID im Katalog ist, ob selectionMode single ist, dann läuft PresetTaskRequirementCheckService.CheckAsync: Für jeden Skill in requirements wird durch LocalSkillCommandAdapter das lokale skill inventory abgefragt, nach CacheKey dedupliziert.
3. Prompt-Rendering: Je nach locale wird das entsprechende user.hbs gerendert, last30daysMode, last30daysQuery, targetScopeMarkdown, targetRepositories werden injiziert. user.hbs verbietet explizit AskUserQuestion, verlangt vom Executor bei Unklarheiten, Annahmen aufzuzeichnen statt nachzufragen – dies ist die harte Grenze der nicht-interaktiven Ausführung.
4. Skill-Laden und Ausführung: Der Executor erhält den zusammengestellten prompt. /last30days als unabhängiger Befehl ganz vorne löst das Skill-Laden aus. Der Skill läuft intern nach seinen eigenen LAWs: Step 0.45 macht eine keyword-trap Vorprüfung (verhindert, dass query fälschlich als handle/subreddit interpretiert wird), Step 0.5/0.55 analysiert gezielte Kanäle, Step 0.75 lässt das Inferenzmodell selbst --plan generieren, dann läuft die Python-Engine, um Daten von Reddit/X/YouTube/TikTok/Instagram/HN/Polymarket/Web zu holen, Step 2 ergänzt mit WebSearch, Step 2.5 hängt an die raw-Datei an, schließlich werden Schlussfolgerungen nach LAWs synthetisiert.
5. Schlussfolgerung-Rückverknüpfung: Die synthetisierten Schlussfolgerungen werden zurück in den Kontext des Presets gebracht. Die read/write-Grenzen der Ziel-Repositories sind weiche Einschränkungen durch targetScopeMarkdown im prompt – das Preset sagt dem Skill “du kannst nur diese lesen, diese schreiben”, der Skill hält sich in seiner Ausführung an diese Grenze.

Einige praktische Punkte

• Nicht-interaktive Grenzen in die Vorlage schreiben. Das Verbieten von AskUserQuestion in user.hbs ist keine Empfehlung, sondern eine harte Einschränkung. Wenn ein Preset läuft, sitzt niemand vor dem Bildschirm, um Rückfragen zu beantworten, also müssen Unklarheiten durch “Annahmen aufzeichnen” verdaut werden.
• Flags, die voreingestellt werden können, voreinstellen. Der Wettbewerber-Mode schreibt --competitors direkt in die prelude, Benutzer müssen nicht wissen, dass dieses Flag existiert. Der Zweck eines Presets ist es, professionelle Parameter in die richtigen Hände zu geben.
• Skill-Deduplizierung durch CacheKey. Es ist egal, wenn derselbe Skill mehrfach in requirements auftaucht, PresetTaskRequirementCheckService dedupliziert nach CacheKey, prüft und lädt nicht mehrfach.
• Repository-Grenzen sind weiche Einschränkungen. read/write-Grenzen werden durch prompt injiziert, nicht durch Sandbox. Das bedeutet, ob der Skill “gehorsam” ist, hängt teilweise davon ab, wie gut er den prompt befolgt. Dies ist ein realistischer Kompromiss.
• Fehler sollen explizit sein, nicht stillschweigend. Wenn ein Skill fehlt, wird requirement check als fehlgeschlagen gemeldet, 400 zurückgegeben, und im Frontend wird ein “Ein-Klick-Installieren”-Einstieg angezeigt (openSkillGalleryForSkill). Den Benutzer wissen zu lassen, was kaputt ist und wie man es repariert, ist viel verantwortungsvoller als stillschweigend in “ohne Skill läuft es auch” abzufallen.
• Migration soll nicht destruktiv sein. Die Evolution von Preset-Level-Skill zu per-command-Skill ist rückwärtskompatibel. Alte Preset-Level-Deklarationen bleiben gültig, neue Command-Level-Deklarationen sind additive Fähigkeiten, kein Ersatz. Zu große Schritte können zum Reißen führen, wozu also.

---

Preset Task verwandelt einen Skill in vier Produktformen, nicht durch raffinierte Algorithmen, sondern durch einige sauber definierte Verträge: Command-selbstbeschreibung, Preset-authoritative Liste, Einzeilen-Injektion, nicht-interaktive harte Einschränkungen, explizite Fehler. Wenn man das zusammensetzt, wird “mit last30days soziale Netzwerk-Recherche machen” von einem Befehl, für den man sich Parameter merken muss, zu einer Funktion, die man einfach ausfüllen kann.

Was diese Stimmen zusammen eigentlich aussagen können, das ist die Arbeit von last30days selbst……

Tags:

• last30days
• hagicode
• skill

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

Präzises Routing für jeden Befehl: Praxis der Multi-Skill-Unterstützung in HagiCode Preset Task