How to Use last30days for Social Network-Based AI Research Needs

Jun 27, 2026

How to Use last30days for Social Network-Based AI Research Needs

Every day, people express themselves on social networks: posting, voting, arguing, unsubscribing, and migrating. These voices scattered across Reddit, X, YouTube comments, TikTok, Hacker News, and Polymarket may seem like noise when viewed individually, but when gathered together, they form a remarkably authentic slice of public opinion. The problem is—no one is willing to manually scroll through thirty days of posts across eight platforms just to reach a research conclusion.

The last30days skill was born for this purpose. It pulls together content from the past thirty days across these channels and synthesizes it by topic. At the preset task layer, the act of “calling last30days” transforms from a command that requires memorizing parameters into a form that can be filled out and executed.

This article isn’t about how useful last30days itself is, but rather how HagiCode uses the preset task orchestration mechanism to solidify “orchestrating one skill into four research modes.” After all, skill is capability, and preset is the glue that turns capability into product.

Background: What Preset Really Saves Is That Phrase Repeated Over and Over

The preset task system initially bound one skill at the preset level. That is, one preset corresponded to one skill, with a relatively single way of invocation. But in reality, the same capability often needs to be used in different modes—with last30days, sometimes you want to do general research, sometimes you want to do competitive comparisons, and sometimes you only want to analyze prompt style for a specific product.

Forcing these different usage patterns into one interaction flow makes the interface increasingly messy; splitting them into four separate skills would reinvent the wheel. So the design took a middle step: allow binding skills at the command level. One preset hangs multiple commands, each command self-describes which skill it needs to call and with what parameters; while the preset layer’s requirements serve as an authoritative list, declaring which skills this preset depends on overall.

This way, interface is interface, execution is execution. Who wants to mix interface styles with execution logic anyway?

One Skill, Four Modes

The last30days preset is the model for this paradigm: one skill, four commands. The four commands correspond to four research modes:

• general (General Research): Provide a query, let last30days pull relevant discussions from the past thirty days across platforms, then synthesize conclusions.
• comparison (Comparison): Clearly specify the objects to compare, let the skill organize materials around “who’s better/who’s worse/each’s pain points.”
• competitors (Competitors): Focus on the competitive ecosystem of a specific product, calling last30days’s built-in --competitors flag.
• prompting (Prompt Style): Focus on how people actually use and ask questions, leaning toward usage patterns and mental models.

All four commands declare "skill": "last30days" in commands.json, but their preludes (parameters and prompts) differ. In the frontend drawer, users select mode, write query, and check target repositories; as for which command is assembled behind the scenes, the preset decides itself. Users don’t need to remember parameters, nor do they need to know about the existence of flags like --competitors.

Two Data Layers: commands.json and task-preset.json

The preset package shares responsibilities across two files, divided quite cleanly:

• commands.json: Describes “what commands exist and what each command looks like.” Each command comes with a skill field, indicating which skill it needs to call; it also carries its own prelude template, explaining how to assemble this command into a single-line instruction. This is command-level self-description.
• task-preset.json: Describes “what this preset overall needs.” It holds requirements (declaring the list of dependent skills), inputs definitions, inputBindings, and metadata like selectionMode. This is the preset-level authoritative list.

The boundaries between the two layers are quite clear: command is responsible for saying “I need this skill,” preset is responsible for saying “which skills this preset allows using.” If a command declares a skill but it’s not in the preset’s requirements, validation will throw an error—the diagnostic is command-skill-not-in-requirements. Such explicit failure is much better than silent degradation.

Single-Line Injection: /{skill} {prelude}

What actually plugs the skill into the execution flow is an unassuming small mechanism: single-line injection.

PresetTaskCatalogProvider has a method called CombineCommandSkillPrelude. The logic is simple: if a command declares skill, and the rendered prelude line doesn’t start with /{skill}, then prepend /{skill}. What’s finally handed to the executor is a single independent instruction like:

/last30days {commandPrelude}

Immediately following this is the body rendered by user.hbs: mode shaping, query, target repository boundaries, and the constraint of “non-interactive, record assumptions.”

Why do this? Because skills like last30days themselves are designed to load and run upon “receiving a /{skill} instruction.” Presets cannot assume skills will be automatically triggered; they must explicitly feed this instruction in. Just one line, but it’s the key to making the entire chain work.

Five-Stage Technical Chain

Putting this all together, from user clicking submit to conclusion linking back to repository, there are five stages:

1. Frontend Selection: User selects mode, writes query, and checks target repositories in CreatePresetTaskDrawer. resolveCommandPreview mirrors the backend’s assembly logic, displaying the preview command to users in real time; buildTargetScopeMarkdown groups by read/write, calculating repository boundaries into a markdown segment.
2. Backend Validation: Request lands in SessionsController.PresetTasks.TryResolvePresetTaskRequestAsync. It first validates whether keys for inputs/targets/derived are in the whitelist, whether command id is in the catalog, whether selectionMode is single, then runs PresetTaskRequirementCheckService.CheckAsync: for each skill in requirements, it checks the local skill inventory through LocalSkillCommandAdapter, deduplicating by CacheKey.
3. Prompt Rendering: Renders corresponding user.hbs according to locale, injecting last30daysMode, last30daysQuery, targetScopeMarkdown, targetRepositories. user.hbs explicitly disables AskUserQuestion, requiring the executor to record assumptions rather than ask back when encountering ambiguity—this is the hard boundary of non-interactive execution.
4. Skill Loading and Execution: Executor receives the assembled prompt. /last30days serves as an independent instruction at the front, triggering skill loading. Inside the skill, it runs according to its own LAWs: Step 0.45 does keyword-trap pre-check (preventing query from being mistaken as handle/subreddit), Step 0.5/0.55 parses targeted channels, Step 0.75 lets the reasoning model generate --plan itself, then runs Python engine to pull data from Reddit/X/YouTube/TikTok/Instagram/HN/Polymarket/Web, Step 2 supplements with WebSearch, Step 2.5 appends to raw file, finally synthesizes conclusions according to LAWs.
5. Conclusion Link Back: Synthesized conclusions are brought back into the preset’s context. The read/write boundaries of target repositories are softly constrained by targetScopeMarkdown in the prompt—preset tells skill “you can only read these and write those,” and the skill observes this boundary during its own execution.

Several Practical Points

• Non-interactive boundary should be written into the template. Disabling AskUserQuestion in user.hbs is not a suggestion, it’s a hard constraint. When preset is running, no one sits in front of the screen to answer follow-up questions, so ambiguity must be digested by “recording assumptions.”
• Preconfigure flags that can be preconfigured. Competitors mode directly writes --competitors into prelude; users don’t need to know about this flag’s existence. The meaning of preset is to hide professional parameters in the right hands.
• Skill deduplication relies on CacheKey. It doesn’t matter if the same skill appears multiple times in requirements; PresetTaskRequirementCheckService deduplicates by CacheKey, without duplicate checking or duplicate loading.
• Repository boundaries are soft constraints. Read/write boundaries rely on prompt injection, not sandbox. This means whether the skill listens depends partly on its compliance with the prompt. This is a realistic compromise.
• Fail explicitly, don’t fail silently. If skill is missing, report requirement check failure, return 400, and provide a “one-click install” entry in the frontend (openSkillGalleryForSkill). Letting users know what’s broken and how to fix it is much more responsible than quietly degrading to “can run without skill.”
• Migration should be non-breaking. The evolution from preset-level skill to per-command skill is backward compatible. Old preset-level declarations remain valid; new command-level declarations are additive capabilities, not replacements. Too big a step risks tearing things apart—why bother?

---

Preset task transforms one skill into four product forms, relying not on sophisticated algorithms but on a few cleanly bounded contracts: command self-description, preset authoritative list, single-line injection, non-interactive hard constraints, explicit failure. Putting these together, “using last30days for social network research” transforms from a command that requires memorizing parameters into a feature that can be executed by filling a form.

As for what these gathered voices actually indicate—that’s last30days’s own job…

Tags:

• last30days
• hagicode
• skill

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

Precise Routing for Every Command: HagiCode Preset Task Multi-Skill Support in Practice