ワンクリックで
specmap
// 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.
// 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.
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.
Use webspec-index to query WHATWG, W3C, IETF and TC39 web specifications from the command line
| name | specmap |
| description | 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. |
| argument-hint | [spec-url-or-fragment] [optional: specific-algorithm] |
| allowed-tools | ["Bash(searchfox-cli:*)","Bash(webspec-index:*)","Bash(curl:*)","Bash(jq:*)","Read","Grep","Glob"] |
Spec URL or fragment: $0 Specific algorithm (optional): $1
If you have a spec URL (from a bug report, code comment, etc.), query it directly:
webspec-index query 'https://html.spec.whatwg.org/#navigate' --format markdown
webspec-index refs 'https://html.spec.whatwg.org/#navigate'
If you only have a feature name, search for it:
webspec-index search "FEATURE_NAME" --limit 5
webspec-index search "FEATURE_NAME" --spec HTML --limit 5
If the exact fragment is unknown, find it by pattern or by listing sections:
webspec-index anchors '*navigate*' --spec HTML
webspec-index list HTML
For WebIDL interface definitions (not provided by webspec-index), use the spec shortname (visible in search results or derivable from the URL hostname/path):
curl -s "https://w3c.github.io/webref/ed/idl/SHORTNAME.idl"
Use searchfox-cli to find files referencing the spec section, split by file type:
# Implementation code (excludes test and generated files)
searchfox-cli -q "DOMAIN.*#FRAGMENT" --only-normal -l 200
searchfox-cli -q "#FRAGMENT" --only-normal --path "dom\|html\|layout\|widget" -l 200
searchfox-cli --id InterfaceName --only-normal -l 100
# Test files only
searchfox-cli -q "DOMAIN.*#FRAGMENT" --only-tests -l 200
searchfox-cli -q "#FRAGMENT" --only-tests -l 200
If results are sparse, try alternative fragment spellings or the IDL interface/method
name from the webref IDL extract. If results are too broad, narrow with --path.
Cross-reference the webref algorithm steps from Step 1 against the searchfox results from Step 2 to identify:
WPT is the preferred test location for web platform features. Do NOT flag the absence of Mozilla-specific tests (mochitest, browser-chrome, etc.) as a gap when there is adequate WPT coverage. Mozilla tests are only expected for Firefox-specific behavior that WPT cannot cover (e.g. chrome-privileged APIs, internal pref gating, process architecture).
To check WPT status, look for .ini expectation files using dedicated tools
(avoid bash loops which trigger permission prompts):
.ini files: testing/web-platform/meta/PATH/*.ini.ini file found, use Grep with output_mode: "count" to count
expected: and disabled: lines.No .ini file means the test fully passes. An .ini with disabled: lines means
skipped tests. Count expected: lines for the number of non-default expectations.
Output a structured report:
## SpecMap: [Feature Name]
Spec: [full spec URL with fragment]
### Implementation Code
| File | Function/Class | Line | Notes |
|------|---------------|------|-------|
| dom/Foo.cpp | Foo::Bar() | 123 | Step 4 of algorithm |
### Web Platform Tests
| Test File | Status | Tests |
|-----------|--------|-------|
| .../feature.html | PASS (no .ini) | 12 subtests |
| .../feature-edge.html | PARTIAL (.ini has 3 expected fails) | 8 subtests |
### Mozilla Tests
| Test File | Type | Notes |
|-----------|------|-------|
| dom/tests/mochitest/test_feature.html | mochitest | ... |
### Coverage Summary
- Spec steps with implementation: N/M
- WPT files found: N (K passing, J partial, L failing)
- Gaps: [list spec steps or areas with no code or test coverage]
Split test results: files under testing/web-platform/ are WPT, other test files
are Mozilla tests (mochitest, browser-chrome, xpcshell).
If implementation code lacks a spec URL comment or step annotations, offer to add them. Ask for confirmation before making edits. Before inserting any spec URL, verify the anchor exists:
webspec-index exists 'SHORTNAME#FRAGMENT' && echo "valid"
# e.g.:
webspec-index exists 'HTML#navigate' && echo "valid"
Examples of references to add:
// https://spec.example.org/#section at the top of an implementing function// Step N. comments for algorithm implementations.webidl files next to interface/method definitions#dom-interface-method, #the-element-name-element, #concept-name// https://html.spec.whatwg.org/#fragment or // Step N of https://...webspec-index query 'URL' to read the referenced section