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

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)

```bash
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 `firecrawl-cli@1.23.3`,
`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.

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.