last30flames

last30flames

Research a topic across the recent web and write a short, source-grounded brief.

This skill is a thin engine plus your synthesis. The engine gathers sources and prints a clean, numbered research context; you (the model running this skill) read that context and write the brief.

No keys are required. The engine never calls an LLM (you do the synthesis), and it reaches Firecrawl through the Firecrawl CLI, which runs on a keyless free tier when no key is set. If FIRECRAWL_API_KEY is in the environment the CLI uses it automatically for higher limits and concurrency - so a key is a speed upgrade, never a requirement. A user who starts keyless and later sets FIRECRAWL_API_KEY (or runs firecrawl login) is authenticated on the very next run, with nothing to reinstall.

How it works

Five sources run in parallel:

• Firecrawl Search - web results scraped into full-page markdown, not snippets.
• Hacker News (public Algolia API) - points + comment counts.
• Lobste.rs (public JSON feeds) - points + comment counts.
• Bluesky (public AT Protocol API) - likes + reposts + replies.
• GitHub (official API) - stars + recent push activity.

Engagement numbers come only from APIs that publish them openly. The skill never touches Reddit, X, TikTok, Instagram, or anything behind a login or cookie.

Run the engine

This works in any agent harness that supports skills. You already know the absolute path of this SKILL.md because you just read it; call scripts/run.sh next to it. It self-locates, installs deps on first run, and takes the topic plus an optional --days N window (any number - 7, 30, 365; default 30):

bash <SKILL_DIR>/scripts/run.sh "<TOPIC>" --days 30

Replace <SKILL_DIR> with the directory this file is in. Do not rely on $CLAUDE_PLUGIN_ROOT or the current working directory - the launcher handles both. The only requirement is the bun binary; no API key is needed (set FIRECRAWL_API_KEY only if you want higher Firecrawl limits).

Progress prints to stderr; the numbered research context prints to stdout. Read the stdout - that is your evidence.

Resolve ambiguous topics first (recommended)

If the topic could point at more than one thing - a person's name, a product that shares a name with something common ("Apple", "Cursor"), a bare handle - run a cheap resolution pass before the main gather:

bash <SKILL_DIR>/scripts/run.sh --resolve "<TOPIC>"

It prints candidate identities (web titles + descriptions, GitHub repo and user candidates) without scraping any pages. Read them and decide:

• 2-4 refined subqueries that pin down the intended entity (e.g. for "Cursor" the AI editor: "Cursor AI editor", "Cursor IDE agent"). Each subquery multiplies the Firecrawl search/scrape work, so runtime scales with query count - use the fewest that pin down the entity, usually 2.
• If the topic is a person or project, the matching GitHub login and/or owner/name repo.

Then run the main gather with those, passing --query once per subquery:

bash <SKILL_DIR>/scripts/run.sh "<TOPIC>" --days 30 \
  --query "<subquery 1>" --query "<subquery 2>" \
  --github-user <login> --github-repo <owner/name>

The engine searches the web, Hacker News, Lobste.rs, and Bluesky with each subquery (up to 4, deduplicating overlapping results), and scopes GitHub to the given login/repo. All flags are optional - a clear, specific topic can skip resolution entirely and run one-shot as before. The resolution pass never decides anything itself; you do.

Comparison topics ("X vs Y")

When the topic pits two or three things against each other ("cursor vs zed", "bun versus deno"), the engine runs a full gather per side in one pass and groups the research context per side, with continuous citation numbering.

A topic containing "vs"/"versus" in any capitalization auto-splits, so the simple form just works. The one carve-out is all-caps "VS", so topics like "best VS Code extensions" stay a single side; use --compare to compare things whose names contain "VS":

bash <SKILL_DIR>/scripts/run.sh "cursor vs zed" --days 30

The web-scrape budget (--limit) is shared across sides, so each side of a comparison scrapes fewer pages than a dedicated run would; pass a higher --limit (e.g. --limit 10 for two sides) when you want full per-side depth.

For sharper sides, pass --compare once per side; any --query, --github-user, or --github-repo flags that follow a --compare scope to that side (run --resolve per side first if a name is ambiguous):

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

Synthesize a side-by-side brief from the grouped context: what moved for each side in the window, then a direct comparison (traction via the engagement numbers, notable shipping activity, best-for). Cite both sides inline as usual; the numbering never collides because it is continuous across sides.

Save & reuse the context (optional)

By default, do not write any files - just synthesize the brief. Only save when the user asks (e.g. "save the context", "I'll want this again later").

Saved contexts live under ~/.last30flames/, grouped into thread folders so a run of related calls can be reloaded as one set. A thread is just a named subdirectory; each call saves its own file, which keeps every call's [1], [2] citation numbering intact (never concatenate two contexts into one file - the numbering would collide):

~/.last30flames/<thread>/
  <slug>-<YYYY-MM-DD>.md      # one file per engine call

On save: redirect the engine's stdout so the raw numbered research context is preserved (that is the reusable evidence - not the brief). Pick the thread folder first:

• If the user names a thread ("save this to my ai-agents research"), slugify it as <thread>.
• Otherwise reuse the thread from earlier saves in this same conversation, so related calls land together.
• If neither applies, derive <thread> from the topic and tell the user the name you chose so they can reference it later.

Derive <slug> by slugifying the topic (lowercase, spaces to hyphens, drop punctuation) so the filename tells you what the call was about. Then create the folder and write the file, and report the exact path afterward:

mkdir -p ~/.last30flames/<thread>
bash <SKILL_DIR>/scripts/run.sh "<TOPIC>" --days 30 > ~/.last30flames/<thread>/<slug>-<YYYY-MM-DD>.md

Because the redirect sends the research context to the file instead of stdout, the Bash output shows only stderr progress. If the user also wants the brief this session, Read the saved file first to get the context, then synthesize as usual.

If the user explicitly names a different path, honor it instead.

On reuse (a later session): the user need not recall exact names. If they reference saved research even loosely ("load my ai-agents research"), list the thread folders under ~/.last30flames/ and match on the thread name; then Read every .md file in that folder and synthesize across all of them, keeping citations namespaced by source file so numbers from different calls don't clash. To reload a single call rather than the whole thread, match one file by its <slug>-<date> name. If nothing matches, ask where they saved it.

Because each filename is <slug>-<YYYY-MM-DD>.md, both topic and save date are recoverable from the name alone - no external memory needed. Before synthesizing, check each file's date against the --days window: if today is more than that many days past the saved date, the recency claim no longer holds - warn the user that context is stale and offer to re-run fresh.

Reuse-shaped prompts to handle this way (do not re-run the engine):

last30flames load my ai-agents research
last30flames using my saved ai-agents research, what did I find on local inference?

Write the brief

From the numbered sources, write a few tight paragraphs that:

• Lead with what is genuinely new or moving in the window. Not background.
• Ground every claim in the sources and cite inline like [1], [3].
• Use the engagement numbers (HN points/comments, GitHub stars) as a signal of what people actually care about - weight high-engagement items.
• Say plainly where evidence is thin rather than inventing detail. If HN or GitHub returned little, that honesty is part of the answer.

After the brief, end with a compact Sources list so every inline citation is clickable. One line per source you actually cited, keeping the same numbers used inline, as markdown links:

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

List only cited sources - this is a reference list for the reader, not a dump of the research context. Never paste the raw research context back.

Shareable HTML brief (optional)

When the user asks for a shareable version of the brief ("make this shareable", "give me an HTML file", "something I can drop in Slack/email/Notion"), emit the synthesis as a self-contained dark-mode HTML file alongside the normal chat response. The file has inline CSS, no JavaScript, and no external assets, so it works offline and renders the same everywhere.

First write the brief you synthesized - including its Sources: list with the same numbering - as markdown into the thread folder, picking <thread> and <slug> exactly as in the save flow above:

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

The converter turns headings, paragraphs, lists, links, and inline [N] citations into HTML - each citation becomes a clickable jump to its entry in the Sources list - writes <slug>-<YYYY-MM-DD>-brief.html next to the markdown, and prints the output path. Report that path to the user. If the user names a different output location, pass it with -o <path>.

This converts your synthesized brief, not the raw research context - never htmlify the engine's stdout.