last30days を使ってソーシャルネットワークベースの AI リサーチを完了する方法

2026/06/27

last30days を使ってソーシャルネットワークベースの AI リサーチを完了する方法

ソーシャルネットワークでは毎日誰かが表明しています：投稿、投票、議論、退会、移行。これらの Reddit、X、YouTube コメント、TikTok、Hacker News、Polymarket に散らばる声は、個別に見ればただのノイズですが、まとめて見ればかなり現実的な世論の断面になります。問題はただ一点——あるリサーチ結論を得るために、8 つのプラットフォームで 30 日分の投稿を手動で漁りたい人はいないということです。

last30days という skill はまさにこのために生まれました。上記のチャネルの過去 30 日間のコンテンツをまとめて引き出し、テーマ別に合成します。そして preset task という層は、「last30days を呼び出す」ことを、パラメータを覚える必要のある命令から、記入するだけで動くフォームに変えます。

この記事で話したいのは、last30days 自体がどれだけ使いやすいかではなく、HagiCode が preset task というオーケストレーションメカニズムを使って、「1 つの skill を 4 種類のリサーチ姿勢に編成する」ことをいかに確実に行っているかです。結局、skill は能力であり、preset は能力を製品にする接着剤なのです。

背景：preset が省きたいのは、実際には何度も言われるあの言葉

preset task システムは最初、preset レベルで skill に紐付いていました。つまり、1 つの preset が 1 つの skill に対応し、呼び出し方法は比較的単一でした。しかし現実には、同じ能力を異なる姿勢で使う必要がよくあります——last30days でも、一般的なリサーチをしたいとき、競合比較をしたいとき、特定の製品に対してプロンプトスタイルの分析をしたいときがあります。

これらの異なる使用方法を 1 つのインタラクションフローに無理やり押し込むと、インターフェースがだんだん混乱します；4 つの独立した skill に分けると、車輪の再発明になります。そこで設計では中間へ進みました：command レベルでの skill バインディングを許可します。1 つの preset に複数の command をぶら下げ、各 command は自分がどの skill を呼び出し、どのパラメータを使うかを自己記述します；一方、preset レベルの requirements は権威あるリストとして、この preset が合計でどの skill に依存するかを宣言します。

こうして、インターフェースはインターフェース、実行は実行と分離されます。誰がインターフェーススタイルと実行ロジックを一つの塊に混ぜ合わせたいでしょうか。

1 つの skill、4 つの mode

last30days という preset はまさにこのパラダイムの見本です：1 つの skill、4 つの command。4 つの command は 4 種類のリサーチ姿勢に対応します：

• general（一般調査）：query を与え、last30days に各プラットフォームの過去 30 日間の関連議論を引き出させ、結論を合成させます。
• comparison（比較）：比較対象を明確に与え、skill に「誰がより良い/悪い/各々の痛みポイント」を中心に素材を構成させます。
• competitors（競合）：特定の製品の競合エコシステムに焦点を当て、last30days 組み込みの --competitors フラグを呼び出します。
• prompting（プロンプトスタイル）：人々が実際にどう使って、どう質問しているかに焦点を当て、使用法とメンタルモデルに偏ります。

4 つの command は commands.json ですべて "skill": "last30days" を宣言しますが、それぞれの prelude（パラメータとヒント）は異なります。フロントエンドドロワーでユーザーが選択するのは mode、記入するのは query、チェックするのは対象リポジトリ；背後でどの命令を組み立てるかは preset 自身が決定します。ユーザーはパラメータを覚える必要も、--competitors のようなフラグの存在を知る必要もありません。

2 層のデータ：commands.json と task-preset.json

preset パッケージには 2 つのファイルが職務を分担し、かなりきれいに分かれています：

• commands.json：「どの command があるか、各 command がどのような形か」を記述します。各 command は skill フィールドを持ち、どの skill を呼び出すかを示します；また独自の prelude テンプレートを持ち、この command をどう 1 行の命令に組み立てるかを示します。これは command レベルの自己記述です。
• task-preset.json：「この preset 全体で何が必要か」を記述します。requirements（依存する skill リストの宣言）、inputs 定義、inputBindings、および selectionMode などのメタ情報を持ちます。これは preset レベルの権威あるリストです。

2 層のそれぞれの境界は明確です：command は「この skill が必要」と言い、preset は「私の preset でどの skill を使用できるか」と言います。もしある command が skill を宣言したが、preset の requirements にない場合、検証はエラーを報告します——diagnostic は command-skill-not-in-requirements です。このような明示的な失敗は、静かに劣化するよりはるかに良いです。

1 行注入：/{skill} {prelude}

skill を実際に実行フローに接続するのは、目立たない小さなメカニズムです：1 行注入。

PresetTaskCatalogProvider には CombineCommandSkillPrelude というメソッドがあります。ロジックは単純です：ある command が skill を宣言し、レンダリングされた prelude 行が /{skill} で始まらない場合、/{skill} を前置します。最後にエグゼキュータに渡されるのは、次のような 1 行の独立命令です：

/last30days {commandPrelude}

その後に続くのは user.hbs からレンダリングされた本文：モード形成、query、対象リポジトリ境界、および「非対話、仮説を記録」という制約です。

なぜこれをするのか？last30days のような skill 自体が「/{skill} 命令を受信した」ことでロードして実行するからです。preset は skill が自動的にトリガーされると仮定できず、この命令を明示的に渡す必要があります。たった 1 行ですが、チェーン全体が通る鍵です。

5 段階の技術チェーン

上記をすべて繋げると、ユーザーが送信をクリックして結論がリポジトリに戻るまで、全部で 5 段階です：

1. フロントエンド選択：ユーザーは CreatePresetTaskDrawer で mode を選択し、query を記入し、対象リポジトリをチェックします。resolveCommandPreview はバックエンドの組立ロジックをミラーリングし、プレビュー命令をリアルタイムでユーザーに表示します；buildTargetScopeMarkdown は read/write でグループ化し、リポジトリ境界を markdown のセグメントに計算します。
2. バックエンド検証：リクエストは SessionsController.PresetTasks.TryResolvePresetTaskRequestAsync に落ちます。最初に inputs/targets/derived のキーがホワイトリストにあるか、command id が catalog 内にあるか、selectionMode が single かを検証し、次に PresetTaskRequirementCheckService.CheckAsync を実行します：requirements の各 skill について、LocalSkillCommandAdapter を通じてローカル skill inventory をクエリし、CacheKey で重複を排除します。
3. プロンプトレンダリング：locale に基づいて対応する user.hbs をレンダリングし、last30daysMode、last30daysQuery、targetScopeMarkdown、targetRepositories を注入します。user.hbs は AskUserQuestion を明確に禁止し、エグゼキュータが曖昧さに遭遇したときに質問するのではなく、仮説を記録するよう要求します——これは非対話実行の硬い境界です。
4. skill ロードと実行：エグゼキュータは組み立てられた prompt を受信します。/last30days は独立命令として最初にあり、skill ロードをトリガーします。skill 内部は独自の LAWs で実行されます：Step 0.45 で keyword-trap 事前検査（query が handle/subreddit として誤認されるのを防ぐ）、Step 0.5/0.55 で定向チャネル解析、Step 0.75 で推論モデルに --plan を生成させ、次に Python エンジンを実行して Reddit/X/YouTube/TikTok/Instagram/HN/Polymarket/Web からデータを引き出し、Step 2 で WebSearch で補充し、Step 2.5 で raw ファイルに追加し、最後に LAWs で結論を合成します。
5. 結論回結：合成された結論は preset のコンテキストに戻されます。対象リポジトリの read/write 境界は、prompt 内の targetScopeMarkdown によるソフト制約に依存します——preset は skill に「これらだけ読んで、あれらだけ書いていい」と伝え、skill は自分の実行でこの境界を守ります。

いくつかの実践ポイント

• 非対話境界はテンプレートに記述する必要があります。user.hbs で AskUserQuestion を無効にするのは提案ではなく、硬い制約です。preset が実行された後、画面の前で質問に答える人がいないため、曖昧さは「仮説を記録」で消化する必要があります。
• プリセットできるフラグはプリセットします。競合 mode は --competitors を直接 prelude に記述し、ユーザーはこのフラグの存在を知る必要がありません。preset の意味は専門的なパラメータを適切な人の手に隠すことです。
• skill 重複排除は CacheKey に依存します。requirements で同じ skill が複数回出現しても問題ありません、PresetTaskRequirementCheckService は CacheKey で重複排除し、重複チェックや重複ロードをしません。
• リポジトリ境界はソフト制約です。read/write 境界は prompt 注入に依存し、サンドボックスには依存しません。つまり、skill が従順かどうかは、prompt への従順度に部分的に依存します。これは現実的な妥協です。
• 失敗は明確に、静かにしないでください。skill が欠落していると requirement check 失敗を報告し、400 を返し、フロントエンドで「ワンクリックインストール」入口（openSkillGalleryForSkill）を提供します。ユーザーにどこが壊れているか、どう直すかを知らせることは、静かに「skill がなくても動く」に劣化させるよりはるかに責任があります。
• 移行は破壊的であってはなりません。preset レベルの skill から per-command skill への進化は、後方互換性があります。古い preset レベル宣言は依然として有効で、新しい command レベル宣言は能力の追加であり、置換ではありません。歩幅を大きくしすぎると、引っかかりやすくなります。どうでしょう。

preset task は 1 つの skill を 4 種類の製品形態に変えますが、それは巧妙なアルゴリズムによるものではなく、境界がきれいに分けられたいくつかの契約によるものです：command 自己記述、preset 権威リスト、1 行注入、非対話硬制約、明示的失敗。これらを組み合わせると、「last30days を使ってソーシャルネットワークリサーチをする」ことは、パラメータを覚える必要のある命令から、フォームを記入して実行できる機能になります。

これらの声をまとめて何が言えるかについては、それは last30days 自身の仕事です……

Tags:

• last30days
• hagicode
• skill

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

すべてのコマンドを正確にルーティングする：HagiCode Preset Task のマルチスキル対応実践