Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Developer Index skill documents four id prefixes; a fifth (web:) is the majority of unscoped results

Open
  • Is something wrong?
#213 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@gaurav-init is already working on this.

Since Sep 5, 2026.

  • #218 by @gaurav-init — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
68/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
cli, documentation

Research direction

Start by locating the firecrawl-developer-index skill, the developer feature documentation, the API reference, and the firecrawl developer CLI entry point. Compare their documented type behavior with the reproduction and CLI output in this issue. Done means the affected guidance and surfaces accurately explain or prevent web: results, with the documented behavior verified against the provided commands.

Written by the indexing model from the issue text.

Description

The firecrawl-developer-index skill (and docs.firecrawl.dev/features/developer) both state
that the artifact kind is the id prefix, and enumerate four: doc:, issue:, pull_request:,
readme:.

In practice a fifth prefix, web:, is returned, and on unscoped queries it is frequently the
majority of results. It does not appear in the skill file, the feature docs, or the API reference.

Reproduction (keyless, no API key needed)
curl -s -X POST https://api.firecrawl.dev/v2/search/developer \
  -H "Content-Type: application/json" \
  -d '{"query":"drizzle orm mysql connection pool exhausted","k":8}' \
| python3 -c "import sys,json,collections; d=json.load(sys.stdin); print(collections.Counter(r['id'].split(':')[0] for r in d['results']))"

Measured 2026-08-28 against api.firecrawl.dev/v2:

Request Prefix distribution
unscoped, k=8 {'issue': 3, 'doc': 2, 'web': 3}
unscoped, k=8, different query {'issue': 3, 'doc': 2, 'web': 3}
same query + types:["doc","issue","pull_request","readme"] {'issue': 4, 'doc': 3, 'pull_request': 1} — no web:
types:["web"] 400 {"code":"BAD_REQUEST","error":"unknown type: web (expected doc, issue, pull_request, readme)"}

So web: can be excluded, but only by naming all four valid types explicitly. It cannot be
requested, and it is not documented.

Why this matters for agent behaviour

Three things in the shipped guidance combine badly:

  1. The skill tells the agent the kind is one of four prefixes.
  2. The skill's stated bar is "quote the passage, cite the url" as a primary source.
  3. The skill says "Scope last, not first — search the whole index, then narrow."

Following (3) produces the unscoped call, which returns majority web: — ordinary web pages.
The agent then satisfies (2) by quoting one, believing per (1) that it is a curated artifact.
The net effect is that the recommended first move is the one most likely to return
non-primary sources, with nothing in the guidance to flag it.

Also worth noting: the CLI surface cannot mitigate this. On [email protected],
firecrawl developer exposes only --limit, -o, --json, --pretty, -k, and its help says
to put scoping intent in the query text. There is no --types, so a CLI user cannot exclude
web: at all. A live CLI run returned {issue: 3, doc: 2, web: 3}.

Suggested fix (any one of these would close it)
  • Document web: as a possible prefix in the skill file, the feature page, and the API reference,
    and say plainly that it is an open web page rather than a curated index artifact; or
  • have the skill recommend sending all four types by default, rather than "scope last"; or
  • add a --types flag to the CLI developer command so the CLI surface can exclude it too; or
  • exclude web: from /search/developer and leave it to /search.

Happy to send the raw responses if useful.

One more control, added after drafting

The distribution is identical authenticated and keyless, so this is not an auth-tier artifact:

surface prefixes
authenticated CLI, unscoped {issue: 3, doc: 2, web: 3}
keyless HTTP, same query, unscoped {issue: 3, doc: 2, web: 3}
keyless HTTP, same query, + types {issue: 4, doc: 3, pull_request: 1}

The variable is types, not the key. A different query returned {issue: 4, doc: 4} on both
surfaces, so web: is query-dependent rather than always present.

Dominant language
TypeScript
Stars
643
Forks
110
Avg merge
4h 16m
Merged PRs (30d)
48

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from firecrawl/cli

All issues in firecrawl/cli

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.