[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CGC53RA4ZBYCTZPM2R69RY":3,"skill-same:01M6CGC53RA4ZBYCTZPM2R69RY":69},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":39,"repositoryHtmlUrl":40,"repositoryHomepageUrl":6,"ownerHtmlUrl":41,"ownerBlogUrl":42,"ownerDescription":43,"updatedAt":44,"install":45,"resources":58},"01M6CGC53RA4ZBYCTZPM2R69RY","sentry-quota",null,"Catch quota-risky Sentry span instrumentation in code and PRs — fan-out × ungated × no-kill-switch — before it blows the span budget","MetaMask\u002Fskills","MetaMask","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F11744586?v=4","01M6CGATQAN8ZP8HWEZH2379WJ","01M6CGATVJDE1ZMSRM20CFJ5S8",25,"MIT","https:\u002F\u002Fgithub.com\u002FMetaMask\u002Fskills\u002Fblob\u002Fmain\u002Fdomains\u002Fobservability\u002Fskills\u002Fsentry-quota\u002Fskill.md",[],[18,19,20,21,22,23,24,25,26,27,28,29],"sentry","quota","sentry quota","code","Budget","kill-switch","kill","switch","instrumentation","it","catch","prs","2026-11-10 10:12:30",false,"---\nmaturity: experimental\nname: sentry-quota\ndescription: Catch quota-risky Sentry span instrumentation in code and PRs — fan-out × ungated × no-kill-switch — before it blows the span budget\n---\n\n# Sentry Span Quota Guard\n\nFind and fix custom Sentry span instrumentation that blows the project span budget. Operates on **code and PRs**, not Sentry dashboards — you spot the culprit in Sentry (`sentry-mcp-queries`), this skill fixes it in code.\n\n## When To Use\n\n- A PR adds custom Sentry spans (`trace()` calls \u002F `TraceName` entries) — review it before merge.\n- A custom span\u002Ftransaction dominates span volume in Sentry — locate where it's emitted and fix it.\n- Auditing controllers\u002FUI for always-on, fan-out-prone instrumentation.\n- A custom span is the top span-count contributor and must be cut fast (release blocker).\n\n## Do Not Use When\n\n- Reading the live span counts themselves — that's `sentry-mcp-queries` (Volume Estimation).\n- Product-analytics events (Segment \u002F `trackEvent`) — that's `instrumentation`, with data domain `knowledge\u002Fsegment-governance.md` for Segment governance.\n- The span is already behind a per-trace sample gate **and** a kill-switch — already mitigated.\n- Error volume. Errors are metered separately from spans and transactions, so no change here moves the error quota.\n\n## Breach Triad\n\nA custom span is a quota risk when these stack. The first three together are the breach profile.\n\n| Signal | Static signature | Why it blows quota |\n|---|---|---|\n| **Fan-out** | span created in a loop \u002F `.map` \u002F `.forEach` \u002F per-asset \u002F per-account \u002F per-chain \u002F poller | N spans per trace, not 1 |\n| **Always-on** | no `tracesSampleRate` sub-rate, no hash gate before the span | every qualifying call emits |\n| **No kill-switch** | not guarded by an env flag | disabling needs a release, not a config flip |\n| Hot path | data-source \u002F update-pipeline \u002F network callback, not a discrete user action | high call frequency |\n\nLow fan-out + discrete user action + already gated = fine. Don't flag healthy spans.\n\n**The subtlest fan-out has no visible loop: a memoized selector.** A `trace` passed into a memoized selector (`createSelector` \u002F `reselect`, or any function called from `useSelector`) fires on every input change by reference. If the selector also iterates entities, it is fan-out × recompute-frequency. Its volume tracks internal state-churn, not user action, so no user-facing metric predicts it — you cannot capacity-plan it. Treat any `trace` reaching a selector as fan-out.\n\n## Workflow\n\n### PR review (pre-merge gate)\n1. `gh pr diff \u003Cn>` — scan **added** lines for three things, not two: new `TraceName` entries, new `trace(` call sites, **and a `trace`\u002Ftrace-callback passed as an *argument*** into a call (`fn(…, trace)`). The third is the one reviews miss — a caller wiring up a function's optional `trace?` param adds instrumentation with no `trace(` site and no `TraceName` entry.\n2. Check what already emits. For every trace name the diff adds, maps or reroutes, query the target project over the last 90 days (`sentry-mcp-queries`). A name that already emits is not new instrumentation. Review it as a change to measured volume, and say so first in the verdict, because a reviewer who believes it is new will look for a history that already exists. For a name that is new to the target, the other client where it already ships is the reference class. Before carrying that client's volume over, list which of its top names the diff can actually start in the target.\n3. Score each against the breach triad: is the enclosing scope a loop, poller, **or selector**? is there a gate? a kill-switch?\n4. Block if a new always-on span has no gate — require a sub-sample gate (`span-sub-sampling`) before merge. Cheaper than a post-ship cherry-pick.\n5. If the diff adds no `trace(` sites, no `TraceName` entries, **no `trace` argument passed into a call, bumps no dependency, and adds or changes no SDK integration** → \"no new instrumentation\", stop. A dependency bump brings whatever instrumentation the package carries at the adopted version, which no grep of this diff can see, and that volume can be `http.client` traffic the tracing context surfaces rather than wrapper spans. An SDK integration such as `browserTracingIntegration()` emits `pageload`, `navigation` and `http.client` spans with no `trace(` site at all.\n\n> **Instrumentation is not always added by an instrumentation PR.** The costliest spans arrive incidentally — a caller passes a `trace` argument into an existing function during an unrelated change (a bug fix, a refactor), so the PR's stated purpose gives no signal to review it for quota. Do not gate this scan on the PR *looking* like instrumentation. And accept the limit: a `trace` argument buried in a bug-fix diff will slip a human reviewer, which is why a runtime backstop is needed. Sentry metric alerts cannot target one transaction name's billed volume, only project and category totals, so the backstop belongs in the sampler (the per-name budget below). This skill lowers the rate; it does not eliminate the class.\n\n### Locate (incident)\n1. Grep the span name \u002F `TraceName.X` across the consuming repo **and** the controller package source.\n2. Open the call site; read the enclosing scope for the fan-out verdict (loop\u002Fpoller?).\n3. **No grep hits ≠ safe** — the culprit may be on a release ref not checked out. Verify the package version \u002F `gh pr checkout` the shipping ref before concluding clean.\n\n### Audit\n1. Sweep the span registries (`TraceName` enums) + `trace(` call sites.\n2. Rank by breach triad — surface ungated × hot-path × fan-out first.\n\n### Mitigate\nPick the lowest tier that stops the bleed.\n\n## Mitigation Ladder\n\n| Tier | When | Action |\n|---|---|---|\n| **0 — Immediate** | a span fans out and is actively breaching on the live release | disable the `trace()` call at source (or env-guard it) + **cherry-pick to the release branch** + file a sev-1 release blocker on the in-flight release milestone |\n| **1 — Release containment** | spike concentrated in an old, already-patched release with lingering users. A sampler fix in a newer build does not change that release's rates unless it reads its rate remotely | Sentry **inbound filter** dropping `release:\u003Cbad>` spans + force-update. The only dashboard action. Filters target a whole release, not one span — don't filter a release you still want data from. There is no inbound filter by transaction name, only a fixed health-check one. Filtered events do not consume quota, so confirm the drop in the filtered outcomes (`stats_v2` grouped by `reason`), not in Explore. It is not instant: one recorded release filter took 3.8 days from filing to taking effect |\n| **2 — Durable** | the span is justified long-term but ungated | deterministic `traceId`-hash sub-sample gate before the span (`span-sub-sampling`) |\n| **3 — Wrong tool** | the metric needs full fidelity; sampling loses the signal | move the metric off trace spans — they are the wrong substrate for always-on high-cardinality metrics. Segment is the usual target, but its events can ship unregistered, with no CI check and no billing review (data domain `knowledge\u002Fsegment-governance.md`), so it is not a free lunch |\n\nTier 0 + 1 stop the bleed; Tier 2 is the follow-up so the metric returns.\n\n**Prevent the next one, not just this one.** Every tier above requires *naming* the offender first, so a new one runs unbounded until someone catches it. A per-transaction-name budget in the sampler — sample the first N of a name per session, then decay — bounds *any* name with no advance knowledge of which will misbehave. It is the only control that acts before the offender is named, and the only one that catches instrumentation added incidentally rather than deliberately.\n\n## Common Pitfalls\n\n| Mistake | Correct approach |\n|---|---|\n| Per-call random sampling (`Math.random()` per span) | Deterministic `traceId`-hash bucket — all gated spans in a trace kept-or-dropped together |\n| Gate the span in Sentry config | Gate at the call site; for an injected-callback controller span, gate in the callback so every consumer inherits the cap |\n| Inbound-filter a release you still need data from | Filters drop the whole release — fix in code (Tier 0\u002F2) instead |\n| \"No grep hits, so it's safe\" | The culprit may be on a release ref not checked out — verify the version\u002Fref |\n| Disable the span on `main` only | Cherry-pick to the active release branch — `main` alone leaves the live release breaching |\n| Treat \"move to Segment\" as free | Segment events ship without CI governance or billing review (data domain `knowledge\u002Fsegment-governance.md`) |\n| Ship new always-on instrumentation with no kill-switch | Add an env disable flag on day one — turns a future cut into a config flip, not a cherry-pick |\n| An optional `trace?` param passes review because it emits nothing | It is a dormant fan-out — it detonates when any caller supplies the argument. Remove the *param*, not just the argument, so one line can't re-arm it. |\n| Disable one entry point of a multi-path change | One change can reach the backend by more than one path (a controller callback *and* a selector param). Audit every entry point it added, not just the one that fired. |\n| Read a span that \"fires N million times\" as one triggered too often | A total is transactions × spans per transaction. Check spans per trace before blaming the trigger: fan-out multiplies the count with no change in how often the trigger fires |\n| Filter a release before its successor is fixed | The filter redirects users onto the next build; if that carries the same span, volume only moves. Filter a release only once the build users update to is clean. |\n","# Sentry Span Quota Guard\n\nFind and fix custom Sentry span instrumentation that blows the project span budget. Operates on **code and PRs**, not Sentry dashboards — you spot the culprit in Sentry (`sentry-mcp-queries`), this skill fixes it in code.\n\n## When To Use\n\n- A PR adds custom Sentry spans (`trace()` calls \u002F `TraceName` entries) — review it before merge.\n- A custom span\u002Ftransaction dominates span volume in Sentry — locate where it's emitted and fix it.\n- Auditing controllers\u002FUI for always-on, fan-out-prone instrumentation.\n- A custom span is the top span-count contributor and must be cut fast (release blocker).\n\n## Do Not Use When\n\n- Reading the live span counts themselves — that's `sentry-mcp-queries` (Volume Estimation).\n- Product-analytics events (Segment \u002F `trackEvent`) — that's `instrumentation`, with data domain `knowledge\u002Fsegment-governance.md` for Segment governance.\n- The span is already behind a per-trace sample gate **and** a kill-switch — already mitigated.\n- Error volume. Errors are metered separately from spans and transactions, so no change here moves the error quota.\n\n## Breach Triad\n\nA custom span is a quota risk when these stack. The first three together are the breach profile.\n\n| Signal | Static signature | Why it blows quota |\n|---|---|---|\n| **Fan-out** | span created in a loop \u002F `.map` \u002F `.forEach` \u002F per-asset \u002F per-account \u002F per-chain \u002F poller | N spans per trace, not 1 |\n| **Always-on** | no `tracesSampleRate` sub-rate, no hash gate before the span | every qualifying call emits |\n| **No kill-switch** | not guarded by an env flag | disabling needs a release, not a config flip |\n| Hot path | data-source \u002F update-pipeline \u002F network callback, not a discrete user action | high call frequency |\n\nLow fan-out + discrete user action + already gated = fine. Don't flag healthy spans.\n\n**The subtlest fan-out has no visible loop: a memoized selector.** A `trace` passed into a memoized selector (`createSelector` \u002F `reselect`, or any function called from `useSelector`) fires on every input change by reference. If the selector also iterates entities, it is fan-out × recompute-frequency. Its volume tracks internal state-churn, not user action, so no user-facing metric predicts it — you cannot capacity-plan it. Treat any `trace` reaching a selector as fan-out.\n\n## Workflow\n\n### PR review (pre-merge gate)\n1. `gh pr diff \u003Cn>` — scan **added** lines for three things, not two: new `TraceName` entries, new `trace(` call sites, **and a `trace`\u002Ftrace-callback passed as an *argument*** into a call (`fn(…, trace)`). The third is the one reviews miss — a caller wiring up a function's optional `trace?` param adds instrumentation with no `trace(` site and no `TraceName` entry.\n2. Check what already emits. For every trace name the diff adds, maps or reroutes, query the target project over the last 90 days (`sentry-mcp-queries`). A name that already emits is not new instrumentation. Review it as a change to measured volume, and say so first in the verdict, because a reviewer who believes it is new will look for a history that already exists. For a name that is new to the target, the other client where it already ships is the reference class. Before carrying that client's volume over, list which of its top names the diff can actually start in the target.\n3. Score each against the breach triad: is the enclosing scope a loop, poller, **or selector**? is there a gate? a kill-switch?\n4. Block if a new always-on span has no gate — require a sub-sample gate (`span-sub-sampling`) before merge. Cheaper than a post-ship cherry-pick.\n5. If the diff adds no `trace(` sites, no `TraceName` entries, **no `trace` argument passed into a call, bumps no dependency, and adds or changes no SDK integration** → \"no new instrumentation\", stop. A dependency bump brings whatever instrumentation the package carries at the adopted version, which no grep of this diff can see, and that volume can be `http.client` traffic the tracing context surfaces rather than wrapper spans. An SDK integration such as `browserTracingIntegration()` emits `pageload`, `navigation` and `http.client` spans with no `trace(` site at all.\n\n> **Instrumentation is not always added by an instrumentation PR.** The costliest spans arrive incidentally — a caller passes a `trace` argument into an existing function during an unrelated change (a bug fix, a refactor), so the PR's stated purpose gives no signal to review it for quota. Do not gate this scan on the PR *looking* like instrumentation. And accept the limit: a `trace` argument buried in a bug-fix diff will slip a human reviewer, which is why a runtime backstop is needed. Sentry metric alerts cannot target one transaction name's billed volume, only project and category totals, so the backstop belongs in the sampler (the per-name budget below). This skill lowers the rate; it does not eliminate the class.\n\n### Locate (incident)\n1. Grep the span name \u002F `TraceName.X` across the consuming repo **and** the controller package source.\n2. Open the call site; read the enclosing scope for the fan-out verdict (loop\u002Fpoller?).\n3. **No grep hits ≠ safe** — the culprit may be on a release ref not checked out. Verify the package version \u002F `gh pr checkout` the shipping ref before concluding clean.\n\n### Audit\n1. Sweep the span registries (`TraceName` enums) + `trace(` call sites.\n2. Rank by breach triad — surface ungated × hot-path × fan-out first.\n\n### Mitigate\nPick the lowest tier that stops the bleed.\n\n## Mitigation Ladder\n\n| Tier | When | Action |\n|---|---|---|\n| **0 — Immediate** | a span fans out and is actively breaching on the live release | disable the `trace()` call at source (or env-guard it) + **cherry-pick to the release branch** + file a sev-1 release blocker on the in-flight release milestone |\n| **1 — Release containment** | spike concentrated in an old, already-patched release with lingering users. A sampler fix in a newer build does not change that release's rates unless it reads its rate remotely | Sentry **inbound filter** dropping `release:\u003Cbad>` spans + force-update. The only dashboard action. Filters target a whole release, not one span — don't filter a release you still want data from. There is no inbound filter by transaction name, only a fixed health-check one. Filtered events do not consume quota, so confirm the drop in the filtered outcomes (`stats_v2` grouped by `reason`), not in Explore. It is not instant: one recorded release filter took 3.8 days from filing to taking effect |\n| **2 — Durable** | the span is justified long-term but ungated | deterministic `traceId`-hash sub-sample gate before the span (`span-sub-sampling`) |\n| **3 — Wrong tool** | the metric needs full fidelity; sampling loses the signal | move the metric off trace spans — they are the wrong substrate for always-on high-cardinality metrics. Segment is the usual target, but its events can ship unregistered, with no CI check and no billing review (data domain `knowledge\u002Fsegment-governance.md`), so it is not a free lunch |\n\nTier 0 + 1 stop the bleed; Tier 2 is the follow-up so the metric returns.\n\n**Prevent the next one, not just this one.** Every tier above requires *naming* the offender first, so a new one runs unbounded until someone catches it. A per-transaction-name budget in the sampler — sample the first N of a name per session, then decay — bounds *any* name with no advance knowledge of which will misbehave. It is the only control that acts before the offender is named, and the only one that catches instrumentation added incidentally rather than deliberately.\n\n## Common Pitfalls\n\n| Mistake | Correct approach |\n|---|---|\n| Per-call random sampling (`Math.random()` per span) | Deterministic `traceId`-hash bucket — all gated spans in a trace kept-or-dropped together |\n| Gate the span in Sentry config | Gate at the call site; for an injected-callback controller span, gate in the callback so every consumer inherits the cap |\n| Inbound-filter a release you still need data from | Filters drop the whole release — fix in code (Tier 0\u002F2) instead |\n| \"No grep hits, so it's safe\" | The culprit may be on a release ref not checked out — verify the version\u002Fref |\n| Disable the span on `main` only | Cherry-pick to the active release branch — `main` alone leaves the live release breaching |\n| Treat \"move to Segment\" as free | Segment events ship without CI governance or billing review (data domain `knowledge\u002Fsegment-governance.md`) |\n| Ship new always-on instrumentation with no kill-switch | Add an env disable flag on day one — turns a future cut into a config flip, not a cherry-pick |\n| An optional `trace?` param passes review because it emits nothing | It is a dormant fan-out — it detonates when any caller supplies the argument. Remove the *param*, not just the argument, so one line can't re-arm it. |\n| Disable one entry point of a multi-path change | One change can reach the backend by more than one path (a controller callback *and* a selector param). Audit every entry point it added, not just the one that fired. |\n| Read a span that \"fires N million times\" as one triggered too often | A total is transactions × spans per transaction. Check spans per trace before blaming the trigger: fan-out multiplies the count with no change in how often the trigger fires |\n| Filter a release before its successor is fixed | The filter redirects users onto the next build; if that carries the same span, volume only moves. Filter a release only once the build users update to is clean. |\n",{"name":5,"maturity":35,"description":7},"experimental","main","a0ec29ada8d53edf5a3f24370bec058767157433","domains\u002Fobservability\u002Fskills\u002Fsentry-quota",11,"https:\u002F\u002Fgithub.com\u002FMetaMask\u002Fskills","https:\u002F\u002Fgithub.com\u002FMetaMask","https:\u002F\u002Fmetamask.io","MetaMask brings Ethereum to your web browser","2026-11-11 08:15:52",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":57},[47,50,53],{"tool":48,"command":49},"npx","npx skills add MetaMask\u002Fskills --skill sentry-quota",{"tool":51,"command":52},"bunx","bunx skills add MetaMask\u002Fskills --skill sentry-quota",{"tool":54,"command":55},"pnpm","pnpm dlx skills add MetaMask\u002Fskills --skill sentry-quota","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMetaMask\u002Fskills\u002Fblob\u002Fmain\u002Fdomains\u002Fobservability\u002Fskills\u002Fsentry-quota\u002Fskill.md",true,[59,65],{"path":60,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":63,"sourceHtmlUrl":64},"metadata.json","REFERENCE","参考文档",731,"https:\u002F\u002Fgithub.com\u002FPeter-code-bot\u002FPROJECT-VICINO\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Fcapgo-skills\u002Fskills\u002Fdebugging-capacitor\u002Fmetadata.json",{"path":66,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":67,"sourceHtmlUrl":68},"repos\u002Fmetamask-extension.md",3484,"https:\u002F\u002Fgithub.com\u002FMetaMask\u002Fskills\u002Fblob\u002Fmain\u002Fdomains\u002Fobservability\u002Fskills\u002Fsentry-quota\u002Frepos\u002Fmetamask-extension.md",[70,96,116,123,160,185],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":30},"01M70PKJH3WSTFMSA8VYQWNDW9","recipe-performance","Diagnose a specific MetaMask user flow's real-app performance and Sentry critical-user-flow telemetry with deterministic mm-harness recipes. Use for CUF boundaries, cold\u002Fwarm\u002Fbackground-resume behavior, latency regressions, lifecycle tags, duplicate or blocking network requests, long tasks, layout\u002Fpaint cost, screen redraws, React rerenders, or browser trace analysis where tests alone cannot prove the real app.","https:\u002F\u002Fgithub.com\u002FMetaMask\u002Fskills\u002Fblob\u002Fmain\u002Fdomains\u002Fagentic\u002Fskills\u002Frecipe-performance\u002Fskill.md",[],[77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,18],"performance","recipe performance","recipe","app","cold","critical","analysis","tasks","react","browser","layout","screen","network","metamask","flow","recipes","deterministic","harness","mm",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":30},"01M6CGJ7AEJCZSRGF3PBE6EWBG","x402-payments","Build x402 payment flows using MetaMask Smart Accounts Kit, machine to machine payments over HTTP with ERC-7710 delegations and ERC-7715 Advanced Permissions","https:\u002F\u002Fgithub.com\u002FMetaMask\u002Fskills\u002Fblob\u002Fmain\u002Fdomains\u002Fweb3-tools\u002Fskills\u002Fx402-payments\u002Fskill.md",[],[103,104,105,106,107,108,109,110,111,112,113,114,90,115],"payments","x402 payments","x402","permissions","smart accounts kit","http","build","with","payment","advanced","flows","machine","kit",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":30},"01M6CGJ4AEKJZJWJ704SZTWQ5T","smart-accounts-kit","Build dApps with MetaMask Smart Accounts Kit — ERC-4337 smart accounts, delegations, and Advanced Permissions (ERC-7715)","https:\u002F\u002Fgithub.com\u002FMetaMask\u002Fskills\u002Fblob\u002Fmain\u002Fdomains\u002Fweb3-tools\u002Fskills\u002Fsmart-accounts-kit\u002Fskill.md",[],[107,115,106,109,110,112,90],{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":134,"publishedAt":30},"01M6CGJ11KGB6862Z1ADYTMKYZ","oh-my-opencode","Multi-agent orchestration plugin for OpenCode. Use when the user wants to install, configure, or operate oh-my-opencode — including agent delegation, ultrawork mode, Prometheus planning, background tasks, category-based task routing, model resolution, tmux integration, or any oh-my-opencode feature. Covers installation, configuration, all agents (Sisyphus, Oracle, Librarian, Explore, Atlas, Prometheus, Metis, Momus), all categories, slash commands, hooks, skills, MCPs, and troubleshooting.","https:\u002F\u002Fgithub.com\u002FMetaMask\u002Fskills\u002Fblob\u002Fmain\u002Fdomains\u002Fweb3-tools\u002Fskills\u002Foh-my-opencode\u002Fskill.md",[129],{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[135,136,137,138,139,140,141,142,143,144,145,146,21,84,147,148,149,150,151,152,153,154,155,156,157,158,159],"opencode","oh my opencode","my","model","explore","hooks","delegation","librarian","agent orchestration","oracle","orchestration","configure","ultrawork","install","multi-agent","tmux","prometheus","planning","use","categories","operate","mode","metis","momus","when",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":30},"01M6CGHY9SVTXK2DK18H794EHE","gator-cli","Use when you need to operate the @metamask\u002Fgator-cli to initialize profiles, upgrade EOA to EIP-7702, grant, redeem, and revoke ERC-7710 delegations, or inspect balances and delegations. Covers commands, required flags, grant scopes, redeem action types, configuration locations, and common usage flows.","https:\u002F\u002Fgithub.com\u002FMetaMask\u002Fskills\u002Fblob\u002Fmain\u002Fdomains\u002Fweb3-tools\u002Fskills\u002Fgator-cli\u002Fskill.md",[],[167,168,169,170,171,148,172,153,173,174,175,155,176,177,178,179,113,180,115,181,159,182,183,184],"cli","gator cli","initialize","https","node","flags","docs","configuration","common","usage","types","balances","inspect","profiles","upgrade","you","io","commands",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":196,"publishedAt":30},"01M6CGHVB2A8SMD9X84ZTH9RHV","ui-development","UI component development standards for MetaMask clients: the strict design-system-first component hierarchy, availability checks before building custom components, styling with design tokens, and required imports. Use when building, restyling, or reviewing any UI component, or when choosing between a design-system, component-library, or custom component.","https:\u002F\u002Fgithub.com\u002FMetaMask\u002Fskills\u002Fblob\u002Fmain\u002Fdomains\u002Fui\u002Fskills\u002Fui-development\u002Fskill.md",[191],{"categoryNo":192,"categoryName":193,"taxonomyType":194,"taxonomyTypeDesc":195},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[197,198,199,200,201,202,203,204,205,206,207,208,209,153,210,211,212,213,214,215,216,217,159,110,218,219],"development","ui development","ui","standards","component","first","system","before building","ui component","design","design tokens","design-system","styling","library","components","availability","for","component development","tokens","custom","true","hierarchy","imports"]