last30flames について
ウェブ上の最近の情報を調査し、出典に基づくブリーフを作成するスキルです。ウェブページ、Hacker News、Lobste.rs、Bluesky、GitHub から並行して情報を集め、対象の特定、比較調査、コンテキスト保存にも対応します。
主な機能
- 015 種類の情報源から並行収集
- 02ウェブページを全文 Markdown 化
- 03公開 API による反応数の取得
- 04曖昧な対象の特定と検索語の調整
- 05比較トピックの自動分割
- 06調査コンテキストの保存と再利用
活用シーン
- 01最近のトピックについて出典付きブリーフを作成
- 02複数製品の最近の動向を比較
- 03GitHub の活動とコミュニティの反応を追跡
- 04後のセッション向けに調査コンテキストを保存
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ firecrawl/ last30flames --skill last30flamesインストール後、Claude Code で/last30flamesを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
.env.examplebun.lockpackage.jsontsconfig.jsonscripts/bluesky.tsconfig.tsderive-sides.test.tsderive-sides.tsfirecrawl.tsformat.test.tsformat.tsgithub.tshackernews.tshtmlify.tsindex.tslobsters.tsresolve.tsrun.shtypes.tsurl.ts詳細
last30flames
最近のウェブ上の情報を調査し、出典に基づいた短い概要を作成します。
このスキルは、シンプルなエンジンとあなたの情報統合で構成されています。エンジンが情報源を収集し、整理された番号付きの調査コンテキストを出力します。あなた(このスキルを実行しているモデル)がそのコンテキストを読み、概要を作成します。
キーは不要です。 エンジンはLLMを呼び出しません(情報統合はあなたが行います)。また、Firecrawl CLIを通じてFirecrawlに接続します。このCLIは、キーが設定されていない場合、無料のキー不要プランで動作します。環境にFIRECRAWL_API_KEYが設定されていれば、CLIが自動的に使用し、上限と同時実行数が増えます。つまり、キーがあれば速度が向上しますが、必須ではありません。キーなしで使い始めたユーザーが、後からFIRECRAWL_API_KEYを設定するか、firecrawl loginを実行すれば、再インストールなしで次回の実行から認証されます。
仕組み
5つの情報源を並行して処理します。
- Firecrawl Search - ウェブ検索結果をスニペットではなく、ページ全体のMarkdownとしてスクレイピングします。
- Hacker News(公開Algolia API) - ポイント数とコメント数。
- Lobste.rs(公開JSONフィード) - ポイント数とコメント数。
- Bluesky(公開AT Protocol API) - いいね、リポスト、返信。
- GitHub(公式API) - スター数と最近のプッシュ活動。
エンゲージメント数は、公開APIで取得できるもののみ使用します。このスキルがReddit、X、TikTok、Instagram、その他ログインやCookieを必要とするものにアクセスすることはありません。
エンジンを実行する
これは、スキルに対応したあらゆるエージェントハーネスで動作します。このSKILL.mdを読んだので、その絶対パスはすでにわかっています。同じディレクトリにあるrun.shを呼び出してください。エンジンは自身の場所を特定し、初回実行時に依存関係をインストールします。トピックと、任意で指定する期間--days N(任意の数値を指定できます。7、30、365など。デフォルトは30)を受け取ります。
bash <SKILL_DIR>/scripts/run.sh "<TOPIC>" --days 30
<SKILL_DIR>を、このファイルがあるディレクトリに置き換えてください。$CLAUDE_PLUGIN_ROOTや現在の作業ディレクトリを前提にしないでください。ランチャーがどちらにも対応します。必要なのはbunバイナリだけです。APIキーは不要です(Firecrawlの上限を増やしたい場合にのみFIRECRAWL_API_KEYを設定してください)。
進捗はstderrに出力され、番号付きの調査コンテキストはstdoutに出力されます。stdoutを読み取ってください。そこに根拠があります。
あいまいなトピックは先に特定する(推奨)
トピックが複数の対象を指す可能性がある場合(人名、よく知られたものと同じ名前の商品(「Apple」「Cursor」など)、単独のハンドル名など)は、メインの情報収集の前に、低コストの特定処理を実行してください。
bash <SKILL_DIR>/scripts/run.sh --resolve "<TOPIC>"
ページをスクレイピングせずに、候補となる対象(ウェブ上のタイトルと説明、GitHubのリポジトリとユーザーの候補)が出力されます。それを読んで、次の内容を決めてください。
- 対象を特定するための2~4個の絞り込んだサブクエリ(たとえばAIエディターの「Cursor」なら、
"Cursor AI editor"、"Cursor IDE agent")。サブクエリごとにFirecrawlの検索とスクレイピングの処理量が増えるため、実行時間はクエリ数に応じて長くなります。対象を特定できる最小限の数を使ってください。通常は2個です。 - トピックが人物またはプロジェクトの場合、一致するGitHubログイン名および/またはowner/name形式のリポジトリ名。
次に、サブクエリごとに--queryを指定して、メインの情報収集を実行します。
bash <SKILL_DIR>/scripts/run.sh "<TOPIC>" --days 30 \
--query "<subquery 1>" --query "<subquery 2>" \
--github-user <login> --github-repo <owner/name>
エンジンは各サブクエリでウェブ、Hacker News、Lobste.rs、Blueskyを検索します(最大4件で、重複する結果は統合します)。GitHubの検索対象は指定したログイン名またはリポジトリに絞られます。すべてのフラグは任意です。明確で具体的なトピックなら、特定処理を省略して、これまでどおり1回で実行できます。特定処理で判断が行われることはありません。判断するのはあなたです。
比較トピック(「X vs Y」)
トピックで2つまたは3つの対象を比較する場合(「cursor vs zed」、 「bun versus deno」など)、エンジンは1回の実行で各対象について調査全体を行い、 引用番号を連続させながら、調査コンテキストを対象ごとにまとめます。
大文字・小文字を問わず「vs」または「versus」を含むトピックは自動で分割されるため、
シンプルな形式のままで機能します。例外はすべて大文字の「VS」です。そのため、
「best VS Code extensions」のようなトピックは1つの対象として扱われます。「VS」を
名前に含む対象を比較する場合は、--compare を使用してください。
bash <SKILL_DIR>/scripts/run.sh "cursor vs zed" --days 30
ウェブスクレイピングの上限(--limit)は対象間で共有されるため、比較の各対象で
スクレイピングされるページ数は、単独で実行した場合より少なくなります。対象ごとに
十分な深さで調査したい場合は、より高い --limit を指定してください(例:2対象なら
--limit 10)。
比較対象をより明確にするには、対象ごとに --compare を指定してください。
その後に続く --query、--github-user、--github-repo フラグは、その対象に
適用されます(名前が曖昧な場合は、対象ごとに先に --resolve を実行してください)。
bash <SKILL_DIR>/scripts/run.sh "cursor vs zed" \
--compare "Cursor" --query "Cursor AI editor" --github-repo getcursor/cursor \
--compare "Zed" --query "Zed editor" --github-repo zed-industries/zed
まとめたコンテキストから、対象を並べて比較する概要を作成します。期間中に各対象で 何が変化したかを示し、その後に直接比較します(エンゲージメント数に基づく勢い、 注目すべきリリース活動、適した用途)。 通常どおり両方の対象をインラインで引用してください。番号は対象間で連続しているため、 重複しません。
コンテキストの保存と再利用(任意)
デフォルトでは、ファイルは書き込まず、概要を作成するだけです。保存するのは、 ユーザーから依頼があった場合のみです(例:「コンテキストを保存して」、 「後でもう一度使います」)。
保存したコンテキストは ~/.last30flames/ の下に、スレッドフォルダーごとに
格納されます。これにより、関連する複数の呼び出しを1つのセットとして再読み込みできます。
スレッドは名前付きサブディレクトリで、各呼び出しは個別のファイルに保存されます。
各呼び出しの引用番号 [1]、[2] が維持されます(2つのコンテキストを1つのファイルに
連結しないでください。番号が重複します)。
~/.last30flames/<thread>/
<slug>-<YYYY-MM-DD>.md # one file per engine call
保存時: エンジンの標準出力をリダイレクトし、番号付きの生の調査コンテキストを 保存します(再利用できる根拠情報であり、概要ではありません)。まずスレッドフォルダーを 決めます。
- ユーザーがスレッド名を指定した場合(「これを ai-agents research に保存して」など)、
<thread>としてスラッグ化します。 - それ以外の場合は、同じ会話内で以前に保存したスレッドを再利用し、関連する呼び出しを 同じ場所に格納します。
- どちらにも当てはまらない場合は、トピックから
<thread>を作成し、後で参照できるよう、 選んだ名前をユーザーに伝えます。
トピックをスラッグ化して <slug> を作成します(小文字にし、空白をハイフンに置き換え、
句読点を削除)。これにより、ファイル名から呼び出しの内容がわかります。次にフォルダーを
作成してファイルを書き込み、正確なパスを報告します。
mkdir -p ~/.last30flames/<thread>
bash <SKILL_DIR>/scripts/run.sh "<TOPIC>" --days 30 > ~/.last30flames/<thread>/<slug>-<YYYY-MM-DD>.md
リダイレクトによって調査コンテキストは標準出力ではなくファイルに送られるため、
Bash の出力には標準エラーの進捗情報だけが表示されます。このセッションで概要も必要な
場合は、まず保存したファイルを Read してコンテキストを取得し、その後、通常どおり
概要を作成します。
ユーザーが別のパスを明示的に指定した場合は、そのパスを使用してください。
再利用時(後のセッション): ユーザーは正確な名前を思い出す必要はありません。
保存した調査について曖昧な形で言及された場合(「ai-agents research を読み込んで」など)、
~/.last30flames/ の下にあるスレッドフォルダーを一覧表示し、スレッド名で照合します。
次に、そのフォルダー内のすべての .md ファイルを Read し、すべてを対象に概要を
作成します。異なる呼び出しの番号が重複しないよう、引用はソースファイルごとに名前空間を
分けます。スレッド全体ではなく単一の呼び出しを再読み込みする場合は、
<slug>-<date> という名前でファイルを照合します。一致するものがなければ、
保存場所を尋ねてください。
各ファイル名は <slug>-<YYYY-MM-DD>.md の形式なので、トピックと保存日はファイル名だけで
確認できます。外部の記憶は必要ありません。概要を作成する前に、各ファイルの日付を
--days の期間と照らし合わせてください。今日が保存日からその日数を超えて経過している
場合、情報の新しさは保たれていません。コンテキストが古くなっていることをユーザーに警告し、
最新の情報で再実行することを提案してください。
以下のような再利用を求めるプロンプトには、この方法で対応してください(エンジンを再実行 しないでください)。
last30flames load my ai-agents research
last30flames using my saved ai-agents research, what did I find on local inference?
ブリーフを書く
番号付きのソースをもとに、次の内容を含む簡潔な段落をいくつか書いてください。
- この期間に実際に新しく登場したこと、または動きのあったことから始めます。 背景説明ではありません。
- すべての主張をソースに基づかせ、
[1]、[3]のように文中で引用します。 - エンゲージメント数(HN のポイント数・コメント数、GitHub のスター数)を、人々が実際に関心を寄せていることを示す指標として使います。エンゲージメントの高い項目を重視してください。
- 根拠が乏しい場合は、詳細を作り上げず、そのことを明確に伝えます。 HN や GitHub から得られた情報が少ない場合、その点を正直に伝えることも回答の一部です。
ブリーフの後に、すべての文中引用からリンクできる、簡潔な Sources リストを付けてください。実際に引用したソースを1行ずつ記載し、文中引用と同じ番号を使って、Markdown リンクにします。
Sources:
[1] [Title of the page](https://example.com/article) - example.com
[3] [Show HN: Something](https://news.ycombinator.com/item?id=123) - news.ycombinator.com
引用したソースだけを記載してください。これは読者向けの参考資料リストであり、調査コンテキストをそのまま列挙するものではありません。調査コンテキストをそのまま貼り付けないでください。
共有可能な HTML ブリーフ(任意)
ユーザーがブリーフの共有可能なバージョン(「共有できる形にして」「HTML ファイルを作って」「Slack/メール/Notion に貼れるもの」など)を求めた場合は、通常のチャットでの回答に加えて、自己完結型のダークモード HTML ファイルとして要約を出力します。 ファイルにはインライン CSS を含め、JavaScript と外部アセットは使用しないため、オフラインでも動作し、どこでも同じように表示されます。
まず、スレッドフォルダーに、合成したブリーフを Sources: リスト(番号は同じもの)とともに Markdown として書き込みます。保存フローと同じように、<thread> と <slug> を選んでください。
mkdir -p ~/.last30flames/<thread>
# Write the brief markdown to ~/.last30flames/<thread>/<slug>-<YYYY-MM-DD>-brief.md
bun <SKILL_DIR>/scripts/htmlify.ts ~/.last30flames/<thread>/<slug>-<YYYY-MM-DD>-brief.md
コンバーターは、見出し、段落、リスト、リンク、インラインの [N] 引用を HTML に変換します。各引用は Sources リスト内の項目へのクリック可能なジャンプリンクになり、Markdown ファイルと同じ場所に <slug>-<YYYY-MM-DD>-brief.html を書き込み、出力パスを表示します。
そのパスをユーザーに伝えてください。
ユーザーが別の出力先を指定した場合は、-o <path> を渡してください。
変換するのは合成したブリーフであり、調査コンテキストそのものではありません。エンジンの標準出力を HTML 化しないでください。