[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CGC2V1V359CB7ZP5PRK2Y9":3,"skill-same:01M6CGC2V1V359CB7ZP5PRK2Y9":71},{"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":22,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":48,"ownerDescription":49,"updatedAt":50,"install":51,"resources":64},"01M6CGC2V1V359CB7ZP5PRK2Y9","sentry-mcp-queries",null,"Query Sentry via MCP — error triage, tag distribution, volume estimation, replay retrieval","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-mcp-queries\u002Fskill.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35],"MCP","sentry","queries","sentry mcp queries","triage","replay","query","estimation","volume","distribution","via","error","retrieval","2026-11-10 10:12:30",false,"---\nmaturity: experimental\nname: sentry-mcp-queries\ndescription: Query Sentry via MCP — error triage, tag distribution, volume estimation, replay retrieval\n---\n\n# Sentry MCP Queries\n\n## When To Use\n\n- Investigating a production error before attributing root cause\n- Checking dist (MV3 vs MV2) error distribution\n- Estimating event or span volume from production data\n- Comparing error rates release-over-release for regression detection\n- Retrieving session replay or profiling data\n\n## Do Not Use When\n\n- The error reproduces locally with a full stack trace\n- Reading product analytics (Segment events, not Sentry errors\u002Fspans)\n- Pre-merge investigation — Sentry data is post-merge only\n\n## Setup\n\nRun once per session:\n\n```\nmcp__sentry__whoami            → confirm auth\nmcp__sentry__find_organizations → org slug\nmcp__sentry__find_projects     → project slug(s)\n```\n\nAll subsequent tools require `organization_slug` and usually `project_slug`. Slug mismatch causes silent empty results. A filter on an attribute the dataset does not carry also returns an empty result with no error, so run the query without that filter as a control before reading a zero. `mcp__sentry__search_events` returns at most 100 rows per call, has no cursor, and accepts only a relative `period` such as `90d`.\n\n## Workflow: Error Triage\n\n1. `mcp__sentry__search_issues` — find by title, fingerprint, or keyword. An issue is a grouping bucket, not a fault: Sentry groups by stack trace, which the issue list does not return, so two issues with matching titles are not shown to be one fault.\n2. `mcp__sentry__get_issue_tag_values` — check `dist` distribution **before** attributing root cause. An error's tag distribution does not reflect the user population's, so also compare `count_unique(user.id)` by that tag.\n3. If 99%+ one dist → platform lifecycle root cause (see `extension-errors-debugging`)\n4. `mcp__sentry__search_issue_events` — individual events for stack trace detail\n5. `mcp__sentry__analyze_issue_with_seer` — AI-assisted hypothesis (validate against code)\n\n## Workflow: Volume Estimation\n\nSegment event volume is invisible from Sentry, but a correlated `http.client` span is not. Anchor estimation on an HTTP endpoint the event's controller calls **1:1** with the event firing.\n\n1. Identify the correlated endpoint — the one that fires **once per event**, not per sub-call (e.g. a per-init call, not a per-account call). Picking a per-sub-call endpoint over-counts.\n2. `mcp__sentry__search_events` aggregate mode, filter `span.op:http.client` + endpoint\n3. Read the `count()` aggregate. Span datasets already extrapolate it by each span's sample weight (see *Longer-Range (30D+) Queries and Percentile Fidelity*), so it is the volume estimate.\n4. Do not multiply it by `1 \u002F tracesSampleRate`. That extrapolates twice, and the weight Sentry applies can differ from the configured rate (a per-name sampler rate, a remote override, a trace continued as sampled).\n5. Treat as an **upper bound** — the endpoint may have callers beyond the event path. Sample population = MetaMetrics-opted-in users only (Sentry opt-in is tied to MetaMetrics).\n\n## Workflow: Release Comparison\n\nCompare error rates or metrics across releases for regression detection:\n\n1. `mcp__sentry__find_releases` — list releases sorted by date\n2. **Filter out unreliable releases** (see below) before comparing\n3. `mcp__sentry__search_events` with `release:12.5.0` for baseline\n4. `mcp__sentry__search_events` with `release:12.6.0` for comparison\n5. **Normalize by sessions or users** — raw counts conflate traffic changes with error rate changes:\n   ```\n   rate = events \u002F sessions_for_that_release\n   ```\n6. Report delta against baseline with sample-size caveat\n\nSentry's Endpoint Regression detector checks p95 transaction duration only for server operations (`http.server`, `serverless.function`, `asgi.server`, `rails.request`, `function.aws`, `function.aws.lambda`), so a browser transaction such as `pageload` gets no automatic regression issue and needs this comparison.\n\n## Filtering Unreliable Releases\n\nPatch releases have uneven adoption — comparing raw counts against them produces false signal. Skip a release before comparing if:\n\n| Filter | Threshold | Reason |\n|---|---|---|\n| Age since publish | \u003C 48–72h | Browser auto-update rollout still ramping (Chrome\u002FFirefox\u002FEdge) |\n| Session count | \u003C ~50% of previous stable release | Sample too small for meaningful rates |\n| Stored span count | \u003C ~few hundred for p75, \u003C ~few thousand for p95+ | Tail percentiles are computed over the *stored* sample — extrapolated counts hide how few events back them |\n| Superseded patch | a higher patch in the same `X.Y.*` line exists **and** the active window (`first_seen`→`last_seen`) is short | Hotfixed-past releases collect few spans, biased to early-updaters during the rollout\u002Fmigration window |\n| Release stage | `dev`, `canary`, `nightly` | Non-production build — different error profile |\n| Environment | not `production` | Development \u002F staging noise |\n| Manifest split | compare only within same `dist` | MV3 and MV2 populations have different error distributions |\n\n**Rule of thumb:** use the newest release that has ≥ 3 days of production adoption **and** session volume comparable to the previous stable release. Everything in between is hotfix noise — skip it for regression comparisons unless investigating that specific patch.\n\n## Longer-Range (30D+) Queries and Percentile Fidelity\n\nWidening the window past ~30 days to gain sample size trades it back for **fidelity loss on older releases**. Three effects compound:\n\n- **Sample-rate drift** — `tracesSampleRate` changes between releases, so absolute span counts across a 30D+ window mix different capture rates. Normalize each release by *its own* sample rate (or by sessions\u002Fusers), never a single global rate.\n- **Extrapolation hides thin samples** — span datasets report sample-rate-weighted (extrapolated) counts. A release with 40 stored spans at 0.75% extrapolates to ~5,300 — a real-looking number backed by 40 events. Always check the **stored** sample count (`count_sample()`), not the extrapolated total, before trusting a release. A group backed by a single stored span reports that span's extrapolation weight, not 1, so a per-entity ranking at high cardinality (`groupBy` trace, user or session) or a ratio such as `count()` \u002F `count_unique(trace)` measures sample weight rather than volume. For one trace's stored span count, read `GET \u002Fapi\u002F0\u002Forganizations\u002F{org}\u002Ftrace-meta\u002F{trace_id}\u002F?project=-1&statsPeriod=\u003Cwindow>`, which does not extrapolate.\n- **Retention downsampling** — spans near the retention boundary are partially evicted, so an old release's count is truncated, not representative. Treat the oldest releases in a 30D+ window as lower bounds only. Span listings over a long window undercount as well, not only aggregate counts.\n\n**For p75+ analysis** (any tail percentile — p75\u002Fp90\u002Fp95\u002Fp99), sample size *and* quality both matter:\n\n- **Size** — percentiles are computed over stored events. p50 stabilizes in the low hundreds; p75 needs more; p95\u002Fp99 need thousands of stored spans. Below that, a handful of outliers move the number — don't report a tail percentile you can't back with stored count.\n- **Quality** — rollout-window spans (first-launch, cold cache, state migration) skew the tail high. A superseded patch release's spans are disproportionately these, so its p75+ reads worse than its steady state would. In the extension project, 84.8% of `span.op:pageload` transactions were measured as not user-visible page loads, and the service worker's `pageload` adopts every request made before `finalTimeout` as a child. Scope a pageload percentile by transaction name.\n\n**Resolving the size-vs-fidelity tension:** when a single release lacks the sample to support p75+, **collapse the patch chain** — aggregate `release:X.Y.*` across the minor line, or compare against the last *widely-adopted* patch — rather than extending the window into aged, downsampled, sample-rate-drifted territory. Reach for sample size *across adjacent stable patches inside the retention-safe window*, not by going further back in time. Use a longer (90d) window as the **primary, comparable-across-releases** source for p75\u002Fp95 and a 30d window only as **secondary context** — 30d over-weights the users still lingering on old versions and inflates baselines. A 90d query has returned `meta.dataScanned: partial` from the events API, meaning Sentry scanned only part of the window, and the `mcp__sentry__search_events` output does not show that field.\n\nFor attributing a confirmed p75\u002Fp95 movement to specific code changes, see the `performance-attribution` skill.\n\n## Workflow: Replay and Profile\n\n1. `mcp__sentry__search_issue_events` — find an event ID with replay\u002Fprofile\n2. `mcp__sentry__get_replay_details` \u002F `mcp__sentry__get_profile_details` for that event ID\n\nThe extension's `setupSentry.js` configures no profiling integration or `profilesSampleRate`, and browser profiling needs a `Document-Policy` response header that an MV3 extension cannot set, so the extension has no profiles to retrieve.\n\n## Tag Filters\n\n| Tag | Values | Use |\n|-----|--------|-----|\n| `dist` | `mv3`, `mv2` | Isolate by manifest version |\n| `environment` | `production`, `staging` | Exclude non-prod noise |\n| `installType` | `normal`, `development`, `sideload`, `admin` | Exclude developer-loaded builds |\n\n**Do not conflate `environment` and `installType`** — a production build can have `installType:development` if loaded unpacked.\n\n## Common Pitfalls\n\n| Mistake | Correct Approach |\n|---------|-----------------|\n| Attribute root cause before checking `dist` distribution | Check tag values first — 99%+ MV3 → lifecycle, not app logic |\n| Multiply a span `count()` by `1 \u002F tracesSampleRate` | `count()` is already extrapolated, so read it as the estimate |\n| Filter `environment:development` for dev builds | Filter `installType:normal` — environment ≠ install method |\n| Skip `whoami` and guess org slug | Slug mismatch causes silent empty results |\n| Treat Seer analysis as ground truth | Use as hypothesis to validate against code\u002Ftraces |\n| Compare raw event counts across releases | Normalize by sessions — traffic changes masquerade as regressions |\n| Include a \u003C48h-old release in a regression comparison | Wait for rollout; auto-update adoption takes 2–7 days |\n| Treat every patch release as a comparison point | Most patches have low adoption — compare to the last *widely-adopted* release |\n| Treat a release absent from a `sort:-count()` top-N result as filtered out | It fell below the volume cut, which is not an exclusion. Query it by name |\n| Trust a release's p95 because its (extrapolated) span count looks large | Check the *stored* sample — p75+ needs hundreds-to-thousands of stored events to be stable |\n| Compare span counts across a 30D+ window at face value | Normalize per-release sample rate; older releases are downsampled \u002F retention-truncated |\n| Read the newest minutes of a window that ends now as complete | Ingestion lag was measured at ~14 min, so those minutes read low |\n| Anchor a percentile on a `.0` release | `.0` releases have 10–100× fewer samples — use the highest-sample patch in the minor line |\n","# Sentry MCP Queries\n\n## When To Use\n\n- Investigating a production error before attributing root cause\n- Checking dist (MV3 vs MV2) error distribution\n- Estimating event or span volume from production data\n- Comparing error rates release-over-release for regression detection\n- Retrieving session replay or profiling data\n\n## Do Not Use When\n\n- The error reproduces locally with a full stack trace\n- Reading product analytics (Segment events, not Sentry errors\u002Fspans)\n- Pre-merge investigation — Sentry data is post-merge only\n\n## Setup\n\nRun once per session:\n\n```\nmcp__sentry__whoami            → confirm auth\nmcp__sentry__find_organizations → org slug\nmcp__sentry__find_projects     → project slug(s)\n```\n\nAll subsequent tools require `organization_slug` and usually `project_slug`. Slug mismatch causes silent empty results. A filter on an attribute the dataset does not carry also returns an empty result with no error, so run the query without that filter as a control before reading a zero. `mcp__sentry__search_events` returns at most 100 rows per call, has no cursor, and accepts only a relative `period` such as `90d`.\n\n## Workflow: Error Triage\n\n1. `mcp__sentry__search_issues` — find by title, fingerprint, or keyword. An issue is a grouping bucket, not a fault: Sentry groups by stack trace, which the issue list does not return, so two issues with matching titles are not shown to be one fault.\n2. `mcp__sentry__get_issue_tag_values` — check `dist` distribution **before** attributing root cause. An error's tag distribution does not reflect the user population's, so also compare `count_unique(user.id)` by that tag.\n3. If 99%+ one dist → platform lifecycle root cause (see `extension-errors-debugging`)\n4. `mcp__sentry__search_issue_events` — individual events for stack trace detail\n5. `mcp__sentry__analyze_issue_with_seer` — AI-assisted hypothesis (validate against code)\n\n## Workflow: Volume Estimation\n\nSegment event volume is invisible from Sentry, but a correlated `http.client` span is not. Anchor estimation on an HTTP endpoint the event's controller calls **1:1** with the event firing.\n\n1. Identify the correlated endpoint — the one that fires **once per event**, not per sub-call (e.g. a per-init call, not a per-account call). Picking a per-sub-call endpoint over-counts.\n2. `mcp__sentry__search_events` aggregate mode, filter `span.op:http.client` + endpoint\n3. Read the `count()` aggregate. Span datasets already extrapolate it by each span's sample weight (see *Longer-Range (30D+) Queries and Percentile Fidelity*), so it is the volume estimate.\n4. Do not multiply it by `1 \u002F tracesSampleRate`. That extrapolates twice, and the weight Sentry applies can differ from the configured rate (a per-name sampler rate, a remote override, a trace continued as sampled).\n5. Treat as an **upper bound** — the endpoint may have callers beyond the event path. Sample population = MetaMetrics-opted-in users only (Sentry opt-in is tied to MetaMetrics).\n\n## Workflow: Release Comparison\n\nCompare error rates or metrics across releases for regression detection:\n\n1. `mcp__sentry__find_releases` — list releases sorted by date\n2. **Filter out unreliable releases** (see below) before comparing\n3. `mcp__sentry__search_events` with `release:12.5.0` for baseline\n4. `mcp__sentry__search_events` with `release:12.6.0` for comparison\n5. **Normalize by sessions or users** — raw counts conflate traffic changes with error rate changes:\n   ```\n   rate = events \u002F sessions_for_that_release\n   ```\n6. Report delta against baseline with sample-size caveat\n\nSentry's Endpoint Regression detector checks p95 transaction duration only for server operations (`http.server`, `serverless.function`, `asgi.server`, `rails.request`, `function.aws`, `function.aws.lambda`), so a browser transaction such as `pageload` gets no automatic regression issue and needs this comparison.\n\n## Filtering Unreliable Releases\n\nPatch releases have uneven adoption — comparing raw counts against them produces false signal. Skip a release before comparing if:\n\n| Filter | Threshold | Reason |\n|---|---|---|\n| Age since publish | \u003C 48–72h | Browser auto-update rollout still ramping (Chrome\u002FFirefox\u002FEdge) |\n| Session count | \u003C ~50% of previous stable release | Sample too small for meaningful rates |\n| Stored span count | \u003C ~few hundred for p75, \u003C ~few thousand for p95+ | Tail percentiles are computed over the *stored* sample — extrapolated counts hide how few events back them |\n| Superseded patch | a higher patch in the same `X.Y.*` line exists **and** the active window (`first_seen`→`last_seen`) is short | Hotfixed-past releases collect few spans, biased to early-updaters during the rollout\u002Fmigration window |\n| Release stage | `dev`, `canary`, `nightly` | Non-production build — different error profile |\n| Environment | not `production` | Development \u002F staging noise |\n| Manifest split | compare only within same `dist` | MV3 and MV2 populations have different error distributions |\n\n**Rule of thumb:** use the newest release that has ≥ 3 days of production adoption **and** session volume comparable to the previous stable release. Everything in between is hotfix noise — skip it for regression comparisons unless investigating that specific patch.\n\n## Longer-Range (30D+) Queries and Percentile Fidelity\n\nWidening the window past ~30 days to gain sample size trades it back for **fidelity loss on older releases**. Three effects compound:\n\n- **Sample-rate drift** — `tracesSampleRate` changes between releases, so absolute span counts across a 30D+ window mix different capture rates. Normalize each release by *its own* sample rate (or by sessions\u002Fusers), never a single global rate.\n- **Extrapolation hides thin samples** — span datasets report sample-rate-weighted (extrapolated) counts. A release with 40 stored spans at 0.75% extrapolates to ~5,300 — a real-looking number backed by 40 events. Always check the **stored** sample count (`count_sample()`), not the extrapolated total, before trusting a release. A group backed by a single stored span reports that span's extrapolation weight, not 1, so a per-entity ranking at high cardinality (`groupBy` trace, user or session) or a ratio such as `count()` \u002F `count_unique(trace)` measures sample weight rather than volume. For one trace's stored span count, read `GET \u002Fapi\u002F0\u002Forganizations\u002F{org}\u002Ftrace-meta\u002F{trace_id}\u002F?project=-1&statsPeriod=\u003Cwindow>`, which does not extrapolate.\n- **Retention downsampling** — spans near the retention boundary are partially evicted, so an old release's count is truncated, not representative. Treat the oldest releases in a 30D+ window as lower bounds only. Span listings over a long window undercount as well, not only aggregate counts.\n\n**For p75+ analysis** (any tail percentile — p75\u002Fp90\u002Fp95\u002Fp99), sample size *and* quality both matter:\n\n- **Size** — percentiles are computed over stored events. p50 stabilizes in the low hundreds; p75 needs more; p95\u002Fp99 need thousands of stored spans. Below that, a handful of outliers move the number — don't report a tail percentile you can't back with stored count.\n- **Quality** — rollout-window spans (first-launch, cold cache, state migration) skew the tail high. A superseded patch release's spans are disproportionately these, so its p75+ reads worse than its steady state would. In the extension project, 84.8% of `span.op:pageload` transactions were measured as not user-visible page loads, and the service worker's `pageload` adopts every request made before `finalTimeout` as a child. Scope a pageload percentile by transaction name.\n\n**Resolving the size-vs-fidelity tension:** when a single release lacks the sample to support p75+, **collapse the patch chain** — aggregate `release:X.Y.*` across the minor line, or compare against the last *widely-adopted* patch — rather than extending the window into aged, downsampled, sample-rate-drifted territory. Reach for sample size *across adjacent stable patches inside the retention-safe window*, not by going further back in time. Use a longer (90d) window as the **primary, comparable-across-releases** source for p75\u002Fp95 and a 30d window only as **secondary context** — 30d over-weights the users still lingering on old versions and inflates baselines. A 90d query has returned `meta.dataScanned: partial` from the events API, meaning Sentry scanned only part of the window, and the `mcp__sentry__search_events` output does not show that field.\n\nFor attributing a confirmed p75\u002Fp95 movement to specific code changes, see the `performance-attribution` skill.\n\n## Workflow: Replay and Profile\n\n1. `mcp__sentry__search_issue_events` — find an event ID with replay\u002Fprofile\n2. `mcp__sentry__get_replay_details` \u002F `mcp__sentry__get_profile_details` for that event ID\n\nThe extension's `setupSentry.js` configures no profiling integration or `profilesSampleRate`, and browser profiling needs a `Document-Policy` response header that an MV3 extension cannot set, so the extension has no profiles to retrieve.\n\n## Tag Filters\n\n| Tag | Values | Use |\n|-----|--------|-----|\n| `dist` | `mv3`, `mv2` | Isolate by manifest version |\n| `environment` | `production`, `staging` | Exclude non-prod noise |\n| `installType` | `normal`, `development`, `sideload`, `admin` | Exclude developer-loaded builds |\n\n**Do not conflate `environment` and `installType`** — a production build can have `installType:development` if loaded unpacked.\n\n## Common Pitfalls\n\n| Mistake | Correct Approach |\n|---------|-----------------|\n| Attribute root cause before checking `dist` distribution | Check tag values first — 99%+ MV3 → lifecycle, not app logic |\n| Multiply a span `count()` by `1 \u002F tracesSampleRate` | `count()` is already extrapolated, so read it as the estimate |\n| Filter `environment:development` for dev builds | Filter `installType:normal` — environment ≠ install method |\n| Skip `whoami` and guess org slug | Slug mismatch causes silent empty results |\n| Treat Seer analysis as ground truth | Use as hypothesis to validate against code\u002Ftraces |\n| Compare raw event counts across releases | Normalize by sessions — traffic changes masquerade as regressions |\n| Include a \u003C48h-old release in a regression comparison | Wait for rollout; auto-update adoption takes 2–7 days |\n| Treat every patch release as a comparison point | Most patches have low adoption — compare to the last *widely-adopted* release |\n| Treat a release absent from a `sort:-count()` top-N result as filtered out | It fell below the volume cut, which is not an exclusion. Query it by name |\n| Trust a release's p95 because its (extrapolated) span count looks large | Check the *stored* sample — p75+ needs hundreds-to-thousands of stored events to be stable |\n| Compare span counts across a 30D+ window at face value | Normalize per-release sample rate; older releases are downsampled \u002F retention-truncated |\n| Read the newest minutes of a window that ends now as complete | Ingestion lag was measured at ~14 min, so those minutes read low |\n| Anchor a percentile on a `.0` release | `.0` releases have 10–100× fewer samples — use the highest-sample patch in the minor line |\n",{"name":5,"maturity":41,"description":7},"experimental","main","a0ec29ada8d53edf5a3f24370bec058767157433","domains\u002Fobservability\u002Fskills\u002Fsentry-mcp-queries",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":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add MetaMask\u002Fskills --skill sentry-mcp-queries",{"tool":57,"command":58},"bunx","bunx skills add MetaMask\u002Fskills --skill sentry-mcp-queries",{"tool":60,"command":61},"pnpm","pnpm dlx skills add MetaMask\u002Fskills --skill sentry-mcp-queries","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMetaMask\u002Fskills\u002Fblob\u002Fmain\u002Fdomains\u002Fobservability\u002Fskills\u002Fsentry-mcp-queries\u002Fskill.md",true,[65],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"repos\u002Fmetamask-extension.md","REFERENCE","参考文档",2272,"https:\u002F\u002Fgithub.com\u002FMetaMask\u002Fskills\u002Fblob\u002Fmain\u002Fdomains\u002Fobservability\u002Fskills\u002Fsentry-mcp-queries\u002Frepos\u002Fmetamask-extension.md",[72,98,118,125,159,184],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":36},"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",[],[79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,24],"performance","recipe performance","recipe","app","cold","critical","analysis","tasks","react","browser","layout","screen","network","metamask","flow","recipes","deterministic","harness","mm",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":36},"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",[],[105,106,107,108,109,110,111,112,113,114,115,116,92,117],"payments","x402 payments","x402","permissions","smart accounts kit","http","build","with","payment","advanced","flows","machine","kit",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":36},"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",[],[109,117,108,111,112,114,92],{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":132,"publishedAt":36},"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",[131],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[133,134,135,136,137,138,139,140,141,142,143,144,145,86,146,147,148,149,150,151,152,153,154,155,156,157,158],"opencode","oh my opencode","my","model","explore","hooks","delegation","librarian","agent orchestration","oracle","orchestration","configure","code","ultrawork","install","multi-agent","tmux","prometheus","planning","use","categories","operate","mode","metis","momus","when",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":36},"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",[],[166,167,168,169,170,147,171,152,172,173,174,154,175,176,177,178,115,179,117,180,158,181,182,183],"cli","gator cli","initialize","https","node","flags","docs","configuration","common","usage","types","balances","inspect","profiles","upgrade","you","io","commands",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":195,"publishedAt":36},"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",[190],{"categoryNo":191,"categoryName":192,"taxonomyType":193,"taxonomyTypeDesc":194},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[196,197,198,199,200,201,202,203,204,205,206,207,208,152,209,210,211,212,213,214,215,216,158,112,217,218],"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"]