After any setup skill install, check for an API key (env var or stored
credentials). Authenticated users see nothing. Otherwise: --browser runs
the browser login directly, an interactive terminal offers it (default
yes), and non-interactive runs print a one-line hint — never a prompt,
so agents, scripts, and CI are unaffected. The bundle flow defers the
offer until every step has run so it never asks twice.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
firecrawl setup developer-index # firecrawl- prefix optional
firecrawl setup firecrawl-scrape
Group subcommands keep precedence, so `setup build` means the group and
`setup firecrawl-build` reaches the skill.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
One short command per skill family:
firecrawl setup core # primitives + index skills ("skills" stays as alias)
firecrawl setup build # app-integration skills (previously not installable via setup)
firecrawl setup workflows # unchanged
The build family had no install path since init dropped it; BUILD_SKILLS
mirrors the five build skills in the catalog. All groups install from the
catalog by name, so skills.sh counters stay consolidated.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Route all init skill installs through the firecrawl/skills catalog with
name-based --skill selection so install volume accrues to catalog
counters. Interactive init now offers a multi-select of the 16 workflow
skills; build skills are no longer installed (they target SDK
integration, not CLI users, and remain one command away). Promote
npx skills add firecrawl/skills and the contributor routing rule in the
README.
Make download examples safe for non-interactive flows and correct agent JSON guidance in the README. Include skill Markdown in Prettier scripts so formatting drift is caught.
* fix(research): describe the real paper corpus in CLI help
Why: over 40 agent traces, 8/8 biomedical CLI runs read the root-help
research line ("Research arXiv papers and GitHub history"), concluded the
index was arXiv-only, and hand-scraped PubMed instead of ever running
`firecrawl research`. The index is ~43M abstracts, ~90% biomedical. The
group description is the single highest-leverage string: it renders both
in `firecrawl --help` and as the `firecrawl research --help` header.
Summary:
- research group description now names the corpus (PubMed/bioRxiv/medRxiv
plus arXiv), its scale, and routes agents away from hand-scraping.
- search-papers description drops the three "arXiv" claims and names the
multi-source id forms it actually returns; keeps the load-bearing
"run several distinct framings" guidance verbatim.
- search-papers --categories only claims what is true: arXiv-style
taxonomy labels, not applicable to biomedical records.
- search --categories disambiguates `research` (a ~web-domain filter)
from the paper index, pointing at `research search-papers`. The wire
value 'research' is unchanged.
- related-papers accepts pmid:/pmcid:/doi:/arxiv: forms in its docs, in
line with inspect-paper and read-paper.
- research examples now include biomedical ids, not arXiv only.
- cli-argv tests gain the research pair that mirrored `developer`, plus a
regression guard that root help names the biomedical corpus.
* docs(readme): route paper search to `research`, add its command section
Why: the README taught the wrong tool. "# Find research papers" was
followed by `firecrawl search --categories research`, which is only a
website filter over ordinary web results, not the paper index. README
also had a `###` section for every command except `research`, so the
index had no documentation surface at all, and the tagline omitted both
`research` and `developer`.
Summary:
- the "Find research papers" example now leads with `research
search-papers`; the `--categories research` example stays but is
labelled as the website filter it is.
- same disambiguation added to the category example block and the search
options table.
- new `### research` section beside `developer`: corpus and scale, the
explicit "not the same as --categories research" note, all five
subcommands, search-papers options, and workflow tips.
- line-3 tagline now mentions research papers and developer sources.
* chore: add research vocabulary to package metadata, bump to 1.20.0
Why: npm search and package listings carried no research, paper, or
biomedical vocabulary, so the paper index was undiscoverable from outside
the CLI too. Behavioural metadata change across help text, docs, and
skills -> minor bump.
Summary:
- package.json description names the paper index and its sources.
- keywords gain research, paper/literature search, biomedical, pubmed,
biorxiv, medrxiv, arxiv, life sciences.
- 1.19.31 -> 1.20.0.
- nfpm.yaml and homebrew/firecrawl-cli.rb carry the same one-line
description; both updated. The brew `desc` is kept under the 80-char
audit limit.
Note: homebrew/firecrawl-cli.rb `version` is 1.10.0 and is not written by
any release tooling in this repo; left as found rather than guessed at.
* docs(skills): give paper search a routing surface in the CLI skills
Why: agents load skills before they load `--help`. firecrawl-search had a
full "Developer search" section and nothing for research; its options
table listed `research` with no elaboration, so the naming collision with
the paper index was invisible. firecrawl-cli's routing table and "When to
Load References" omitted research entirely, so nothing ever pointed an
agent at `firecrawl research`.
Summary:
- firecrawl-search: new "## Paper search" section parallel to "##
Developer search" — states plainly that `--categories research` is not
the paper index, routes to `research search-papers`, and shows the
find/expand/verify loop with real id forms.
- firecrawl-search: `--categories` options row and "When to use" now
disambiguate the two; frontmatter description gains literature triggers
so the skill actually loads on a biomedical task.
- firecrawl-cli: research rows added to the routing table and to "When to
Load References", both stating the anti-pattern (hand-scraping PubMed).
* docs: stop pinning stale CLI versions in install commands
Why: cubic flagged the README install example pinning firecrawl-cli@1.19.6
while this PR ships 1.20.0. The pin was already 25 patches behind npm's
published 1.19.31, and the same stale pin appeared in five more places in
the bundled skills rules.
Summary: install and run commands now use @latest, matching the convention
the public docs already use in all 30 of their occurrences. That removes the
drift permanently rather than trading one stale pin for another — and avoids
pinning 1.20.0, which is not published yet and would break the documented
one-shot install until release. The illustrative `--status` sample output now
shows the version this PR ships.
Test Plan: pnpm test 422/422, prettier clean, no hard-pinned versions remain
in any markdown file.
The developer command called /v2/developer/search. That mount rejects a
keyless caller, so keyless developer search never reached the index. It
is also the path that may be withdrawn. Call /v2/search/developer, the
public path, which accepts a keyless caller.
The API returns 10 results by default, not 20. Correct the help text and
the README.
The developer index now has two surfaces, the same as research: the
`developer` category on `firecrawl search`, and a dedicated command.
The command mirrors the research commands. It calls GET
/v2/developer/search, keeps the keyless free-tier path, and renders the
ranked hits as markdown blocks with the passages clipped at 1200
characters; `--json` keeps the full envelope. It takes a query and
`--limit` only; the endpoint accepts no filters, and that narrow
surface is deliberate.
New tests cover the request URL, the readable and JSON output, and the
error path. Two argv tests prove the command appears in the root help
and parses, so a wrapper cannot drop it the way `executeSearch` once
dropped the category group.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C4vZ6XH65bUJDkLthyfmvC
`firecrawl search <query> --categories developer` searches an index built
for coding agents: GitHub issues, merged pull requests, repository
READMEs, and curated documentation sites.
The API already served the category. The CLI rejected the value, and
`executeSearch` copied only `web`, `images`, and `news` out of the
payload. A developer group therefore never reached the caller.
The category is an extra arm, not a filter on the web results, so the API
returns its hits in `data.developer`. The command copies that group
through, prints it under its own heading, and labels the web group when
both are present.
A matched passage runs to several KB. The readable output clips it at 500
characters and names `--json`, which keeps the full text. Without the
clip, three hits flood a terminal.
Add support for scoping init/setup to a single agent/harness. README documents one-shot usage. scripts/install.sh forwards installer args to `firecrawl init` (non-interactive) and runs `init --yes` when piped. init.ts: add interactive harness picker, detectInstalledAgentNames, and installRepoAcrossAgents to allow routing skills/workflows to a subset of detected agents or a single --agent. skills-native.ts: canonicalize per-agent global skills dirs (fixes several agent paths), add detectInstalledAgentNames helper. This enables one-shot, non-interactive, and interactive per-harness installs.
* feat(cli): add generic feedback command
* chore: bump version to 1.19.7
* chore: bump version to 1.19.8
* feat(cli): add endpoint feedback opt-out
* chore: bump version to 1.19.9
* chore: bump version to 1.19.10
Add a "Docs webhook" example showing how to create a monitor that posts webhook notifications (using --webhook-url and --webhook-events) with schedule, goal, and page options. Updated README.md and skills/firecrawl-cli/SKILL.md to include the webhook notification example.
Add examples showing how to use --scrape-urls to monitor multiple pages (e.g. pricing, docs, changelog) in README.md and skills/firecrawl-cli/SKILL.md. Also update the CLI help text in src/commands/monitor.ts to clarify the --scrape-urls description to "Comma-separated page URLs to scrape on each check."
Export and update monitor creation helpers to accept a --goal and single --page shorthand (constructs urls from page when provided) and include goal in the request body. Add CLI options and help text for --goal and --page, support goal on monitor update, and adjust example usage. Add unit tests for buildCreateBody covering goal and page behavior. Update README and SKILL docs to document monitor usage and guidance. Bump package version to 1.18.1.
During install, show "Installing core firecrawl skills..." and
"Installing skills to build with firecrawl..." instead of the raw repo
names firecrawl/cli and firecrawl/skills. SKILL_REPO_LABELS map drives
the friendly text.
In the next-steps summary, split into two distinct groupings:
1. "Connect & interact with the web (direct or in your AI agent)"
with scrape/search/interact examples showing the natural language
prompt next to the equivalent CLI command.
2. "Building with firecrawl?" at the bottom, pointing at the build
skills with a concrete business example.
MCP + --help entries sit between the two sections as general utilities.
Bumped to 1.14.7.
Parse '(Found|Installed) N skills' from captured npx skills output and
sum across both repos so the post-install summary shows
"✓ Installed 14 skills across your AI coding agents" instead of vague
text.
Collapse the next-steps block from 18 lines to 7: drop the 4 example
prompts in favor of one of each (AI prompt + direct CLI), plus the
MCP install hint and the --help pointer. Each entry uses padded labels
("Ask your AI:", "Run direct: ", "Add MCP: ", "All commands:") so
the commands align in a column.
stepIntegrations and runNonInteractive both thread the count through
to printNextSteps. Tests still mock execSync as undefined, so
parseSkillCount handles the empty case. Bumped to 1.14.3.
Replace the noisy 'npx skills add' inherited stdout (banner, +/symlink
table, security report, ~80 lines per repo) with a single line per repo:
" ✓ firecrawl/cli" / " ✓ firecrawl/skills". TTY runs get a transient
"↓ <repo>" indicator while the install is in flight; non-TTY runs (CI,
piped) get only the final line.
Replace the trailing "Setup complete!" line with a printNextSteps()
block that surfaces:
- what just happened (skills installed globally)
- what firecrawl is for (search, scrape, crawl, interact)
- 4 example prompts (2 build-skill triggers, 2 direct CLI calls)
- pointer to firecrawl --help
Both interactive and non-interactive init paths use the same helpers,
so output is consistent regardless of how users enter the flow.
Bumped to 1.14.2.
when this cli is launched via 'npx -y firecrawl-cli@VERSION', npm injects
npm_command/npm_lifecycle_event/npm_execpath/INIT_CWD into the process
env. those vars leak into nested execSync('npx -y skills add ...') calls
and cause the loop's second iteration to silently exit after the first
install completes — published 1.14.0 only installs from firecrawl/cli
even though SKILL_REPOS contains both repos.
cleanNpmEnv() in skills-install.ts strips those vars; init.ts and
setup.ts pass it as the env to every nested execSync. added a
regression test that primes process.env with the leaking vars and
asserts every install call sees a clean env. bumped to 1.14.1.
Eric Ciarla