// Use webspec-index to query WHATWG, W3C, IETF and TC39 web specifications from the command line
| name | webspec-index |
| description | Use webspec-index to query WHATWG, W3C, IETF and TC39 web specifications from the command line |
Query WHATWG, W3C, IETF and TC39 web specifications from the command line.
Use webspec-index whenever you need to understand what a web spec says — algorithm steps, section content, cross-references, or whether a spec anchor exists. Specs are fetched and cached locally on first use.
Assume that all specs from WHATWG, W3C, IETF and TC39 are indexed. If in doubt, run webspec-index specs to list all spec names and their base URLs.
If webspec-index is not already available in your environment, you can install it via cargo:
cargo binstall webspec-index
# or
cargo install webspec-index
Always put the section identifier in quotes to avoid shell interpretation of #.
webspec-index query 'HTML#navigate'
webspec-index query 'DOM#concept-tree'
webspec-index query 'CSS-GRID#grid-container'
webspec-index query 'https://html.spec.whatwg.org/#navigate'
webspec-index query 'DOM#concept-tree'
webspec-index query "RFC9000#section-22"
webspec-index query "draft-ietf-tsvwg-sctp-dtls-chunk#name-security-considerations"
Returns the section's title, type (heading/algorithm/definition), full content as markdown, navigation tree (parent/prev/next/children), and cross-references. This is the primary command — use it to read what a spec section says.
Use --format markdown for human-readable output, or default --format json for structured data.
webspec-index search "tree order"
webspec-index search "navigate" --spec HTML --limit 5
Full-text search with snippets. Use --spec to narrow to one spec.
webspec-index exists 'HTML#navigate'
Exit code 0 = found, 1 = not found. Use this to validate anchor names before referencing them.
webspec-index anchors "*-tree" --spec DOM
webspec-index anchors "concept-*" --spec HTML
webspec-index anchors "dom-*assign*"
Glob matching (* wildcard). Useful when you know part of an anchor name but not the exact id.
webspec-index list DOM
Returns all heading-level sections with their anchors, titles, types, and depths.
webspec-index refs 'HTML#navigate' --direction incoming
webspec-index refs 'HTML#navigate' --direction outgoing
webspec-index refs 'HTML#navigate'
Shows which sections reference this one (incoming), which sections this one references (outgoing), or both (default). Useful for understanding how a concept connects across specs.
webspec-index update
webspec-index update --spec HTML
webspec-index update --force
Fetches latest spec versions. Uses 24h cache unless --force is given. Specs are auto-fetched on first query, so you rarely need this.
When working on a bug that references a spec algorithm:
# Read the algorithm you need to implement
webspec-index query 'HTML#navigate' --format markdown
# Check what concepts it references
webspec-index refs 'HTML#navigate' --direction outgoing
# Look up a referenced concept you don't understand
webspec-index query 'INFRA#ordered-set'
When you see a spec URL in code comments (e.g., https://html.spec.whatwg.org/#navigate), or a step comment like // Step 3.2, query the section to understand the algorithm:
webspec-index query 'https://html.spec.whatwg.org/#navigate'
When you know a concept but not its exact anchor:
# Search by text
webspec-index search "tree order" --spec DOM
# Or find by anchor pattern
webspec-index anchors "*tree*order*" --spec DOM
Before adding a spec URL to a code comment, verify the anchor exists:
webspec-index exists 'HTML#navigate' && echo "valid"
To see what other specs depend on a concept you're changing:
webspec-index refs 'DOM#concept-tree' --direction incoming
Steps to reliably split a commit/change using the jj (jujutsu) VCS
Analyze a range of local commits, and reorganize them to minimize latency and friction in the review and landing process. To achieve this, commits can be split, reordered, squashed / grouped, or even rewritten. In the final commit series / "patch stack", the codebase should build, lint, and test cleanly after every commit, and each individual commit should stand on its own.
Structured performance opportunity investigation for SpiderMonkey (the Firefox JavaScript engine). Use this skill when the user wants to investigate JS engine performance, profile SpiderMonkey, find optimization opportunities, write performance patches, or evaluate benchmark regressions. Trigger on mentions of: profiling JS, SpiderMonkey performance, JIT optimization, benchmark regression analysis, shell benchmarking, or any request to make JS workloads faster. The methodolgy is described mostly for the JS shell but can be adapted to browser investigation.
Analyze Firefox performance profiles using the profiler-cli CLI tool. Trigger when given a profiler.firefox.com or share.firefox.dev link, a local profile path, or when the user wants to investigate an issue in a Firefox profile. Always use this skill instead of WebFetch for Firefox profiler URLs; WebFetch only retrieves the profiler UI's HTML shell and cannot access profile data, whereas profiler-cli downloads and parses the actual profile into a local daemon that supports structured queries over stacks, markers, threads, and samples.
Guide for creating new Android gradle modules in the android-components project.
Map relationships between a web spec section, its Firefox implementation code, and Web Platform Tests. Use when starting work on a spec feature, checking implementation coverage, or finding which WPTs to enable.