Rapid Onboard

Turn a documentation URL into the smallest set of knowledge a developer needs to start building today. The output is six sections, produced in order. Optimize for "what do I type to make something real happen," not for completeness.

The input is a documentation URL. If the user gave a topic but no URL, ask for the canonical docs URL (or do a quick web search to find it and confirm) before starting.

Phase 1 — Resolve the docs root, then crawl exhaustively

Resolve the docs root first. Before crawling, strip the URL to the documentation root and look for a full page inventory: try /sitemap.xml, then the top-level nav / table-of-contents on the root page. The goal is to see the complete set of doc pages before fetching, not to start crawling from whatever deep page the user happened to paste. Strip tracking query params (everything after ?) before fetching.

Crawl exhaustively with an explicit frontier. Maintain two structures: a visited set and a queue. Process: pop a URL, fetch it, extract every in-domain documentation link on the page, add any not in visited to the queue, repeat until the queue is empty or you reach a cap of 40 pages. Rules:

• Stay within the docs path (same host + docs prefix); never follow blog, marketing, changelog, or external links.
• Skip pagination, version-archive, and anchor-only (#section) links.
• Do not stop early because pages "seem sufficient." Completeness is the queue draining, not your judgment that you've read enough.
• Report at the end: total pages crawled, and any pages skipped due to the cap (so the user knows coverage was truncated).

Prefer WebFetch for reading pages. If a docs site exposes an llms.txt / llms-full.txt, fetch that first — it is often the whole corpus in one file.

Fetch quickstart and tutorial pages first, and weight them. Within the crawl, prioritize any page whose URL or title contains quickstart, getting-started, get-started, introduction, tutorial, or first. These represent the authors' own bet on the minimum viable surface and are the strongest available signal for what's core.

Phase 2 — Build the mental model

Write one paragraph answering two things: what this technology is, and the single core abstraction a beginner must hold in their head to use it (e.g. "everything is a stream," "the unit is a resource you reconcile," "you describe state and it diffs"). No marketing language, no feature lists, no "blazingly fast." Plain, concrete, honest about what category of tool it is.

Phase 3 — Derive the core surface

Derive the core surface from two signals, not from page size or your impression:

1. Quickstart presence — any class, function, or import appearing in a quickstart/tutorial page is core by default.
2. Cross-page recurrence — count how many distinct pages each API symbol (import, class, function) appears on. Rank by this count. Symbols recurring across many pages are core; symbols appearing on a single reference page are not.

Present the core surface as the 5–8 highest-ranked symbols by combined quickstart-presence + page-recurrence. Show the recurrence count next to each so the ranking is auditable. For each symbol, give:

• Signature/syntax — the call shape or command form.
• What it does — one line.
• Minimal example — the shortest snippet that shows it in use.
• Recurrence — number of distinct pages it appeared on (and whether it's in the quickstart).

Present as a numbered list or table, ordered by combined rank.

Phase 4 — Surface the gotchas

List 3–6 things that most commonly trip up beginners: footguns, surprising defaults, required setup steps that are easy to miss, naming or conceptual confusions (two things that sound the same but aren't), ordering constraints, async pitfalls, auth/config that fails silently. Each gotcha is one or two lines: the trap, then how to avoid it. Pull these from "note/warning/caution" callouts in the docs and from anything where the docs over-explain — that usually marks a common mistake.

Phase 5 — Produce a runnable spike

Write the smallest complete, runnable program that does one real thing — a real call producing a real, observable result (a fetched record, a started server returning a response, a transformed file). Not a stub, not pseudocode.

It must include:

• The complete source (every import, no ... elisions).
• Exact setup/install commands (e.g. npm i foo, pip install foo, env vars / API keys needed and how to obtain them).
• Exact run command and what the user should expect to see as output.

If credentials are required, make that obvious and show where the placeholder goes — never invent a key. Keep dependencies minimal. Verify the API calls against what you actually read in the docs (correct function names, argument order, current syntax for the version you crawled) — do not pattern-match from memory.

Phase 6 — Cheat sheet

Condense Phases 3 and 4 into a single scannable reference the user can keep open while building — a compact table or tight list. Each row: the operation/gotcha and the one-glance reminder. This is the artifact they'll actually pin; make it dense and skimmable, no prose.

---

Output format

Produce the six sections under clear headers, in order:

1. Mental model (one paragraph)
2. Core surface (as the docs present it) (5–8 items)
3. Gotchas (3–6 items)
4. Runnable spike (code + setup + run)
5. Cheat sheet (table/tight list)

Label the deliverable accurately. Call the core section "Core surface (as the docs present it)," not "most-used." State explicitly that the ranking reflects documentation emphasis and cross-page recurrence, not measured real-world usage. If the user wants true usage frequency, note that it requires external sources (GitHub code search, example-repo analysis) outside this skill's scope.

Lead with a one-line note on what you crawled (page count + docs version), including any pages skipped due to the 40-page cap. Keep prose minimal everywhere except the mental model. If the docs were thin or the crawl was blocked, say so plainly and produce the best brief you can from what you read, flagging which parts are inferred.