fix(planning): install planning skills on MetaMask Extension and narrow triggers

CHANGELOG.md

@@ -21,10 +21,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 - Update the `testing/mobile-visual-testing` skill for `@metamask/client-mcp-core` 0.13.1 and `@metamask/device-mcp` 0.7.0: remove the knowledge store commands, the knowledge-reuse step and the `--goal` / `--flow-tags` launch flags, and document the global `--observe` and `--pretty` flags, one-line JSON output, observations without app state, the partial mobile `get-state`, `run-steps` `observe` (replaces `includeObservations`) and the 30 s `batchTimeoutMs` cap, timed-out calls being cancelled, calling `node_modules/.bin/mm` directly, and the Android `helper-first` snapshot default.
 - Update the `testing/visual-testing` skill for `@metamask/client-mcp-core` 0.13.1: remove the knowledge store commands and the mandatory knowledge-reuse step, and document the global `--observe` and `--pretty` flags, one-line JSON output, observations without app state, `run-steps` `observe` (replaces `includeObservations`), timed-out calls being cancelled, and one element per ref. Replace the removed `yarn build:test:webpack` script with `yarn build:test`.
+- Narrow `planning` (`mms-planning`) to run only when scope is ambiguous, the change is large, the work is security-sensitive or performance-sensitive, a contract or API is being changed, or the engineer asks. A contract or API change stops for a brief even when fully specified. Security and performance stop for agreement before the edit, even when fully specified, and get a spec only when also large. Reading an existing selector to show a value already in the store is not performance-sensitive, even on a screen. A new or changed selector is. `large` means only a new product area or a cross-system design whose scope is not decided. Cheap uncertainty proceeds with one confirmation line; risk uncertainty stops for a one-line short brief. Uncertainty about whether the work is performance-sensitive is risk uncertainty. On MetaMask Mobile, read `mms-performance` when the work is performance-sensitive. Once the skill applies, the catalog is read on every path before the edit, brief, or yes/no. Drop the `A Jira ticket would improve this context.` line; `jira-brief` still reads a ticket when one is identified. Mark `planning`, `planning-spec`, and `jira-brief` `maturity: experimental` and remove `base: true`, so a default stable sync installs none of them. An installed copy keeps the old always-on trigger until a sync with `--maturity experimental` or a prune. Drop the `-pt.md` sibling instruction from `planning-spec`. ([#219](https://github.com/MetaMask/skills/pull/219))
+- Install `planning`, `planning-spec`, and `jira-brief` for MetaMask Extension as well as MetaMask Mobile, with the same rules in both repos. Core stays out of scope. Assess every installed `mms-*` skill by its description, follow an `mms-*` skill over a non-`mms-*` one when both fit, and drop the fixed `mms-performance` read, which does not install for MetaMask Extension. ([#219](https://github.com/MetaMask/skills/pull/219))
 - Update the MetaMask Mobile performance overlay and animation references for React Native 0.86.x, Expo SDK 57, and Reanimated 4.x with `react-native-worklets`. From a worklet, call `scheduleOnRN` (`runOnJS` is a deprecated alias). Static-ESM tree-shaking stays off. ([#203](https://github.com/MetaMask/skills/pull/203))
 - Require every revert yes/no to be one line that names the pull request or commit, the files, and exactly one yes/no question, whether or not security or privacy is involved. A shorter message is not that step.
-- Keep a new public method or other contract change on the brief and spec path when the objection is that another package should own the edit. Put that objection in the brief.
-- Skip a planning brief for an unkept spike or POC and for routine CI-only work, including a workflow edit that changes how jobs or E2E launch. A CI change that is a new design, a contract or API change, or multi-surface work still stops for a brief and a spec. For a revert of a merged pull request or commit, name the target and files, then ask one yes/no, and name the risk when security or privacy is involved. Recommend a spec for a new design, a contract or API change, or multi-surface work even when the ask is fully specified or single-file; any other fully specified ask gets one line of scope and one yes/no instead of a brief, unless it touches auth, secrets, logs or exports of state, permissions, keyring or vault, migrations, or persisted state, which still gets a brief. Always read the installed skill catalog, including for reverts and fully specified asks.
+- Keep a new public method or other contract change on the brief path, not the yes/no, when the objection is that another package should own the edit. Put that objection in the brief.
+- Skip a brief for an unkept spike or POC and for routine CI-only work, including a workflow edit that changes how jobs or E2E launch. A CI change that is large or a contract or API change still stops for a brief, and gets a spec recommendation only when it is large. For a revert of a merged pull request or commit, name the target and files, then ask one yes/no, and name the risk when security or privacy is involved. A fully specified ask that is not large, is not a contract or API change, and does not touch auth, secrets, logs or exports of state, permissions, keyring or vault, migrations, or persisted state gets one line of scope and one yes/no instead of a brief. Always read the installed skill catalog, including for reverts and fully specified asks.
 - Add component-view rules to `testing/mobile-testing` from the Predict flake investigation: clear call history before call-count assertions, re-query after a remount instead of holding a `findBy*` result, keep time-dependent behaviour in unit tests or target-state fixtures, require a named async boundary for any explicit `{ timeout }`, and a Fixing a Flake section (name the cause, reproduce it, prove the fix; a longer timeout alone is not a fix).
 - Document confirmed Appium interaction-stability patterns in `testing/mobile-testing` (`references/appium-e2e.md`): child readiness, fresh interactive queries, shared open retries, virtualized-list proof, native control state, action postconditions, and single assertions for short-lived alerts.
 

domains/planning/skills/jira-brief/repos/metamask-extension.md

@@ -0,0 +1,8 @@
+---
+repo: metamask-extension
+parent: jira-brief
+---
+
+# Jira brief — MetaMask Extension
+
+This skill installs for MetaMask Mobile and MetaMask Extension.

domains/planning/skills/jira-brief/repos/metamask-mobile.md

@@ -5,4 +5,4 @@ parent: jira-brief
 
 # Jira brief — MetaMask Mobile
 
-This skill installs only for MetaMask Mobile.
+This skill installs for MetaMask Mobile and MetaMask Extension.

domains/planning/skills/jira-brief/skill.md

@@ -6,8 +6,7 @@ description: >-
   .briefs/<ISSUE-KEY>.md with the Goal, Decisions Already Made, Open
   Decisions, and Code Surfaces sections. Name the path in chat. Do not paste the
   file or write to Jira. Do not edit product code, and do not say that in chat.
-base: true
-maturity: stable
+maturity: experimental
 ---
 
 # Jira brief
@@ -33,4 +32,4 @@ Installed name: `mms-jira-brief`. `mms-planning` calls it for ticket identificat
 10. Do not copy secrets, tokens, credentials, or customer data into the file.
 11. In chat, name the path. Do not paste the file. Do not write to Jira. Do not say that code will not change.
 
-`A Jira ticket would improve this context.` belongs to `mms-planning`. That skill adds the line only when no brief was actually read and the change stops for a brief. A revert does not get that line. This skill does not add that line.
+When `mms-planning` delegates and no ticket is identified, return no ticket identified and stop. Do not ask for a ticket. Do not suggest creating one. `mms-planning` then continues. A revert does not call this skill.

domains/planning/skills/planning-spec/repos/metamask-extension.md

@@ -0,0 +1,8 @@
+---
+repo: metamask-extension
+parent: planning-spec
+---
+
+# Planning spec — MetaMask Extension
+
+This skill installs for MetaMask Mobile and MetaMask Extension.

domains/planning/skills/planning-spec/repos/metamask-mobile.md

@@ -5,4 +5,4 @@ parent: planning-spec
 
 # Planning spec — MetaMask Mobile
 
-This skill installs only for MetaMask Mobile.
+This skill installs for MetaMask Mobile and MetaMask Extension.

domains/planning/skills/planning-spec/skill.md

@@ -5,11 +5,9 @@ description: >-
   when the user asks for a planning spec. Ask one unblocked product or
   engineering question at a time, the one that most reduces uncertainty,
   then write one English file at
-  .specs/spec-XXX-short-description.md in the MetaMask Mobile checkout. Do
-  not edit product code, and do not say that in chat. Do not write a -pt.md
-  sibling.
-base: true
-maturity: stable
+  .specs/spec-XXX-short-description.md in the MetaMask Mobile or MetaMask
+  Extension checkout. Do not edit product code, and do not say that in chat.
+maturity: experimental
 ---
 
 # Planning spec
@@ -27,7 +25,7 @@ Installed name: `mms-planning-spec`. Use it only after `mms-planning` recommends
 2. Ask when the question can be stated precisely now, even if the answer is unknown. When an in-scope area cannot be stated precisely because it depends on an open answer, keep it as not yet specified. Do not split that area into questions. When the blocking answer arrives, state any question that is now precise, then ask the unblocked one that most reduces uncertainty.
 3. Stop asking when every precise unknown is decided, explicitly deferred, or recorded as an open question, and every remaining in-scope area is not yet specified. State the direction.
 4. When the direction is ready, state it and wait. Write the file only after the engineer approves. If they do not approve, ask the next unblocked question.
-5. After approval, and before writing, use the same catalog rule as `mms-planning`. Read the installed `mms-*` catalog. Read every skill whose area the spec touches, including a partial fit. Skip a skill only when the spec has no surface for it. Run an explicit performance check. Read `mms-performance` when the change has a performance surface. The named routing list in `mms-planning` is a floor, not an allowlist. Name a matching skill that is unavailable. Do not pretend it was applied.
+5. After approval, and before writing, use the same catalog rule as `mms-planning`. Read the installed `mms-*` catalog. Assess every installed `mms-*` skill by its description. Read the body of every skill whose area the spec touches, including a partial fit. Skip a skill only when the spec has no surface for it. Follow an installed `mms-*` skill over a skill outside that catalog when both fit. Name a matching skill that is unavailable. Do not pretend it was applied.
 6. Write one English file at `.specs/spec-XXX-short-description.md` in the checkout. `.specs/` is local and not team-shared storage. Do not stage it. Sharing the file is a manual step outside this skill.
 
 Numbering is the highest existing `.specs/spec-*.md` plus one. If none exist, start at `001`. The slug is two to five kebab-case words. The H1 is `# spec-XXX: <short name>`.

domains/planning/skills/planning/repos/metamask-extension.md

@@ -0,0 +1,8 @@
+---
+repo: metamask-extension
+parent: planning
+---
+
+# Planning — MetaMask Extension
+
+This skill installs for MetaMask Mobile and MetaMask Extension.

domains/planning/skills/planning/repos/metamask-mobile.md

@@ -5,4 +5,6 @@ parent: planning
 
 # Planning — MetaMask Mobile
 
-This skill installs only for MetaMask Mobile.
+This skill installs for MetaMask Mobile and MetaMask Extension.
+
+When the work is performance-sensitive, read `mms-performance` before the edit, brief, or yes/no.