feat: add the metamask-extension base skill set

[andrepimenta]

⚠️ Merge after #135

Stacked on feat/base-skills-mobile. The base flag this PR sets is introduced there — merge #135 first, then this retargets to main automatically.

What

Marks the 10 skills every metamask-extension engineer needs as base, so a fresh clone lands exactly those.

Four are already shared with Mobile and land in #135 — coding-guidelines, ui-development, controller-integration, pr-guidelines. This PR adds the six Extension-only ones:

Skill	Why base
extension-testing	Testing entrypoint — unit, integration (stub), Selenium E2E
controller-guidelines	BaseController patterns; complements controller-integration
perf-rendering	Performance is cross-cutting — same basis as Mobile's performance
perf-hooks-effects	ditto
perf-react-compiler	ditto
perf-state-management	ditto

Always-on cost: ~670 tokens per session.

On the four perf-* skills

They cover the same cross-cutting concern that makes Mobile's performance base; Extension's guidance is simply split across four skills rather than consolidated into one.

Two known caveats, included deliberately rather than treated as reasons for inclusion:

1. Descriptions are 34–39 characters and will not self-trigger. "Rendering performance optimization" doesn't match how anyone phrases the problem — people say "this screen is janky when I scroll". CI warns on each until rewritten, so the TODO cannot rot. The content behind them (17–25KB each) stays reachable by name in the meantime (/mms-perf-rendering).
2. Four listing slots for one concern, and ~20KB loaded per invocation. Mobile's pattern — one entrypoint plus on-demand reference files — is cheaper and less ambiguous. Worth considering after the descriptions land.

Scope

Proposed from the catalogue rather than from working in metamask-extension, so it needs owner review. Two things I could not judge from outside the repo:

• whether extension-testing is genuinely the right single testing entrypoint
• whether controller-guidelines and controller-integration overlap enough that only one should be base

Known Extension gaps (not addressed here)

Gap	Notes
Almost no PR automation	9 of 10 pr-workflow skills are Mobile-only, including create-pr. Extension gets PR standards but no PR automation. Overlay work on existing skills — likely the cheapest high-value win.
No component-scaffold equivalent	Design-system-first intent has no enforcement at generation time
No component-view test layer	The "steer agents toward component view tests" goal is Mobile-only today
Platform APIs	1 of ~11 areas covered
3 deprecated testing skills	e2e-testing, unit-testing, e2e-flakiness-patterns still install and compete with extension-testing
6 non-base skills with thin descriptions	incl. ab-testing (26 chars), test-i18n-usage (33)

Verified

Extension default path (--repo metamask-extension --domain none) installs exactly 10 skills. 65/65 tests, 0 lint errors.

🤖 Generated with Claude Code

[NicolasMassart]

One concern before treating the proposed Extension set as the default base.

[NicolasMassart]

suggestion: fix the perf trigger descriptions before making these base

The PR already calls out that the four perf-* descriptions are too thin to self-trigger.

That seems at odds with #135's rationale for the base-description guard: a base skill permanently consumes listing context, so installing one that rarely triggers gives us the cost without much benefit.

Could we either improve these descriptions in this PR before marking them base, or leave the perf skills opt-in until that cleanup is done?

[Qbandev]

Verified against a clone of feat/base-skills-extension: repo scoping is airtight (simulating the repos/${REPO}.md gate gives extension 10, mobile 10, core 0 — the body's claim is exact), and 65/65 tests / 0 lint errors reproduce. Three things before marking these base:

The thin-description problem covers 5 of the 6 skills, not 4.
@NicolasMassart's comment targets the four perf-* skills, but controller-guidelines has the identical defect — description is "BaseController development patterns", 35 chars — while being presented in the inclusion table without a caveat. Only extension-testing (389 chars) clears the 120-char BASE_DESCRIPTION_MIN floor that #135 introduces. Full audit on this branch: perf-rendering 34, controller-guidelines 35, perf-hooks-effects 36, perf-react-compiler 36, perf-state-management 39.

"CI warns on each until rewritten, so the TODO cannot rot" doesn't hold.
lint-skill-entry.mjs sets process.exitCode = errorCount > 0 ? 1 : 0 — warnings never fail the job. The audit on this branch reports 0 errors and 95 warnings; the five base-description warnings would sit invisibly inside a green check. If the intent is a real ratchet, the base-description rule needs to be an error for base: true skills.

The "~670 tokens/session" figure appears to be characters.
Summing name + description across the six skills gives 679 characters ≈ 170 tokens. #135's "~1,130 tokens" is a genuine token estimate (4,221 chars ÷ ~4), so the two headline numbers are on different scales.

Suggestion: mark extension-testing base now; hold the other five until the descriptions are rewritten to 120+ chars (which also resolves whether four separate perf slots vs. Mobile's single-entrypoint shape is the right structure). Separately: the five stubs omit maturity: entirely, so #135's new base + experimental guard never evaluates them — adding explicit maturity: stable makes the stability claim deliberate.