[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H3BZJ0MS1T94FD60SHRKA3":3,"skill-same:01M6H3BZJ0MS1T94FD60SHRKA3":146},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":16,"sourceHtmlUrl":17,"categories":18,"keywords":19,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":69},"01M6H3BZJ0MS1T94FD60SHRKA3","recipe-qa",null,"Validate the runtime effects of a PR, a base\u002Fhead range (a release is a range), or a window of landed changes: derive the acceptance criteria from that scope, then prove them through the shared Recipe Cook checklist.","jiayaoqijia\u002Fcryptoskill","jiayaoqijia","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1453879?v=4","01M6GMYTX7Q7S504VC6E756ENR","YQ","01M6GMYV1QKJ1CC75MTTGT9PR0",81,"MIT","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002FSKILL.md",[],[20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"qa","recipe","recipe qa","base","prove","effects","window","changes","true","scope","head","runtime","shared","validate","acceptance criteria","recipe cook","checklist","cook","acceptance","release","pr","2026-11-10 10:12:30",false,"---\nname: recipe-qa\ndescription: \"Validate the runtime effects of a PR, a base\u002Fhead range (a release is a range), or a window of landed changes: derive the acceptance criteria from that scope, then prove them through the shared Recipe Cook checklist.\"\ndisable-model-invocation: true\nmaturity: experimental\n---\n\n# QA from a frozen change scope\n\nUse only when explicitly named by the user or selected workflow. Read the installed `mms-recipe-cook\u002FSKILL.md` as this entry point's declared dependency. Cook proves and the team library owns recipes; this entry point owns the scope and the criteria.\n\nFor daily domain checks or release validation, read [Domain QA across changes](references\u002Fdomain-qa.md). These use this same entry point and `qa\u002Fdefault`: validate the assembled app at one frozen head using domain smoke plus change-specific recipes.\n\n## 1. Scope, optional\n\n- PR: `{ \"kind\": \"pr\", \"url\": \"https:\u002F\u002Fgithub.com\u002Fowner\u002Frepo\u002Fpull\u002F42\" }`.\n- Range: `{ \"kind\": \"range\", \"base\": \"\u003Cbaseline ref>\", \"head\": \"\u003Ctarget ref>\" }`. A release is the previous release to the release head.\n- Window: `{ \"kind\": \"window\", \"ref\": \"\u003Cbranch\u002Fref>\", \"hours\": 24 }`. Explicit ISO `since`\u002F`until` pin a historical window and override `hours`.\n- Ref: `{ \"kind\": \"ref\", \"ref\": \"\u003Ccommit or branch>\" }`. Any commit, no diff: a daily or release regression. Criteria come from the domain plan or the caller.\n- Any kind may add `\"remoteFeatureFlags\": { \"\u003Cflag>\": \"\u003Cvariant>\" | true | false | { … } }` to pin remote-config overrides for the run, the way an A\u002FB test needs its `treatment` arm. The resolver freezes it as `remoteFlagSpec`, the exact `--remote-flag` value every launch carries. When the diff gates its behaviour on a flag the request does not name, derive the criteria anyway, name the flag and the arm each criterion needs in the report, and let the caller rerun with the field set; never guess a variant.\n- Any kind may add `\"proofLane\": \"source-dev\" | \"official-unmodified\" | \"official-qa-derived\"` (default `source-dev`) and `\"mainnetOptIn\": true`. Both freeze with the scope; [Domain QA](references\u002Fdomain-qa.md) says what each changes.\n\nWith no scope, take the checkout's current PR from `gh pr view --json url,headRefName,headRefOid` and require exactly one match; with no PR, range the checkout branch against its base. Use a checkout of that repository and refresh moving refs before freezing, fetching missing objects without resetting unrelated work. A fork head stays untrusted for runtime execution until the isolated-checkout and authorization requirements are met.\n\nThen compare the checkout with the scope head. Already on the PR branch (or at the range or ref head): continue without asking. Anywhere else: say which branch and commit the checkout is on and whether it is clean, and ask before switching; on yes, fetch the head and check it out (a PR branch by name, a bare commit detached; fetch the exact object when the branch is gone). Never switch a tree with uncommitted changes: stop instead. Cook never switches checkouts. This is a gate: do not derive criteria or initialize a task until the checkout is at the scope head, so a \"no\" leaves nothing behind.\n\n## 2. Domain, optional\n\n`--domain \u003Cname>` selects the team library whose recipes, checklist and test plan apply. It is not a Git author or path filter. For a domain-only request, record the included changes and the team-owned criteria or supplied selectors that make them relevant; retain excluded changes and selection uncertainty in the report. Shared wallet changes may affect the domain even when another team authored them.\n\n## 3. Derive the acceptance criteria, before any template\n\nBuild one numbered list from the scope:\n\n- `pr`: the PR body and its linked tickets. Keep authored criteria verbatim, labelled `authored`; only when none exist, derive candidates from the description and changed files, labelled `derived`. Caller-supplied criteria replace extraction and stay verbatim.\n- `range` \u002F `window`: the union over the PRs landed in that scope, each row keeping its PR reference. When the caller explicitly limits validation to a domain or PR set, retain the full change inventory and derive coverage for that recorded selection; never silently drop a selected criterion. Include integration criteria where the selected changes share a user journey, labelled `derived`, without replacing the original criteria.\n- With a domain: also that library's test-plan cases, keeping their stable case IDs. A range plus a domain is that domain's plan, run on this release.\n- `ref`: the domain's test-plan cases or caller-supplied criteria only; with neither, stop and ask for one.\n\nPass the list as the task text (`--task-text` or `--task-file`) and as separate, verbatim `--acceptance` flags to Cook's initializer. This records the criteria in `TASK.md` and the handoff. Never reword, split, merge or weaken a criterion to fit a recipe.\n\n## 4. Materialize the task\n\nIf TASK\u002FCHECKLIST already exist, run Cook's `scripts\u002Finit-template --resume-task-dir \u003Ctask>` to verify its retained tooling and continue the recorded checklist without changing task files. Otherwise run `scripts\u002Finit-template --task-kind qa [--domain \u003Cname>]` with that task text, forwarding the supplied project\u002Fprovider selectors. Use `qa\u002Fdefault`; only a `--template \u003Cid>` the caller passed selects another, and a team library may shadow a template by ID. Never ask which template to use. Initialization does not run QA: never pass `--prepare` or create a second task.\n\n## 5. Freeze the scope\n\nSave the scope input as `\u003Ctask>\u002Finputs\u002Fqa-scope-request.json`, or reuse it when supplied, then run from the repository:\n\n```bash\nnode \u003Cinstalled-skill>\u002Fscripts\u002Fresolve-scope.mjs --input \u003Ctask>\u002Finputs\u002Fqa-scope-request.json --out \u003Ctask>\u002Fartifacts\u002Fqa-scope.json\n```\n\nFor a dispatched task, run `node \u003Cinstalled-skill>\u002Fscripts\u002Fresolve-scope.mjs --farm-input \u003Ctask>\u002Finputs\u002Fqa.json --out \u003Ctask>\u002Finputs\u002Fqa-scope-request.json`. The adapter overlays admitted scope on matching-kind preset defaults, maps `proof_lane` to `proofLane`, and binds `source` base\u002Fhead only to `kind: pr`. Ranges, windows and refs use their own revisions.\n\n`expectedHeadSha`\u002F`expectedBaseSha` bind the request to known commits; the resolver rejects a mismatch, reads Git and provider data without checking out code or launching an app, and never overwrites a frozen scope. On resume, reuse the artifact and its SHA. A request whose scope input differs from a frozen `qa-scope-request.json` for the same target (any key, `remoteFeatureFlags` included) is a new task, never a resume.\n\n## 6. Execute and finalize\n\nFollow the materialized checklist and `\u002Fmms-recipe-cook\u002Freferences\u002Fqa.md`. Save an index containing `packages` (case id → retained run package dir) and `smoke` (`caseId`, `proofTarget`), then run `node \u003Cinstalled-skill>\u002Fscripts\u002Ffinalize-qa.mjs --task \u003Ctask> --index \u003Cindex.json>`. It validates the retained packages and emits portable `artifacts\u002Fqa-proof.json`; missing or failed packages block finalization, so preserve their evidence and report the gap.\n\nFor the template's early smoke gate, use the same command with `--check-only` and a smoke-only index. It validates retained packages without creating or replacing the final suite or QA result; do not write a custom validator wrapper.\n\nAfter a corrective replay, write a new index changing only attempt paths and run `node \u003Cinstalled-skill>\u002Fscripts\u002Ffinalize-qa.mjs --task \u003Ctask> --index \u003Cnew-index.json> --reselect` against the existing farm binding; never combine with `--suite` or `--check-only`. Keep original attempts and replay COMPLETE afterward to recapture the result; this grants no review or publication approval.\n\nIf a required ref, runtime target, Cook template or declared recipe capability is unavailable, report that missing input or blocked capability. Never substitute a successful static review for runtime QA.\n\nSelect a risk-based proof plan for the requested assurance level before feature execution. For `qa\u002Fdefault`, register its selected cases through Cook's existing `qa-cases` child-checklist instructions to track individual case progress; completed cases are assessed outcomes, not automatic passes. Explicit alternative templates keep their own checklist contract unless they declare a child binding. Daily\u002Frelease smoke does not automatically require replaying every prior PR's full AC suite; retain full inventory and explicit omitted-detail rationale. Do not stop selected coverage at existing recipes. Compose supported actions for the selected checks and attempt prerequisites already within the caller's authority. Distinguish not attempted, incomplete proof, and an observed blocker; an unmet prerequisite or missing recipe is not by itself evidence that a criterion is untestable. Retain the attempted setup\u002Fcapability check and concrete failure, or the explicit budget\u002Fscope reason execution stopped.\n\n## 7. Report\n\nRead [QA report reference](references\u002Freport-example.md) for presentation and delivery guidance. Keep Cook's verdict rules and artifact contract. Daily, release, range and ref runs save the report locally with findings, gaps and evidence; publication is a separate authorized action.\n\nRender structured evidence as self-contained `artifacts\u002Freport.html`, the sole human report, following the [HTML reference](references\u002Freport-example.html) and [rendering instructions](references\u002Fhtml-report.md). Include PR titles\u002Flinks and full frozen criteria; keep IDs secondary. Contents, collapsible criteria and criterion images must work offline. Preserve machine proof, raw outputs and historical reports.\n\nWhen Cook completes, return the report and evidence paths. For a `pr` scope with a domain whose static review skill is installed (perps: `\u002Fmms-perps-review-pr \u003CPR URL>`), run it too and report its source findings in their own section, never merged with the runtime verdicts. Then ask what to do next; the usual path is posting the report as one PR comment through `\u002Fmms-recipe-pretty-pr`'s evidence-comment target, which hosts the manifest-indexed screenshots and refreshes the same comment on a rerun. Cook stays silent; posting and cleanup are separate explicit actions.\n","# QA from a frozen change scope\n\nUse only when explicitly named by the user or selected workflow. Read the installed `mms-recipe-cook\u002FSKILL.md` as this entry point's declared dependency. Cook proves and the team library owns recipes; this entry point owns the scope and the criteria.\n\nFor daily domain checks or release validation, read [Domain QA across changes](references\u002Fdomain-qa.md). These use this same entry point and `qa\u002Fdefault`: validate the assembled app at one frozen head using domain smoke plus change-specific recipes.\n\n## 1. Scope, optional\n\n- PR: `{ \"kind\": \"pr\", \"url\": \"https:\u002F\u002Fgithub.com\u002Fowner\u002Frepo\u002Fpull\u002F42\" }`.\n- Range: `{ \"kind\": \"range\", \"base\": \"\u003Cbaseline ref>\", \"head\": \"\u003Ctarget ref>\" }`. A release is the previous release to the release head.\n- Window: `{ \"kind\": \"window\", \"ref\": \"\u003Cbranch\u002Fref>\", \"hours\": 24 }`. Explicit ISO `since`\u002F`until` pin a historical window and override `hours`.\n- Ref: `{ \"kind\": \"ref\", \"ref\": \"\u003Ccommit or branch>\" }`. Any commit, no diff: a daily or release regression. Criteria come from the domain plan or the caller.\n- Any kind may add `\"remoteFeatureFlags\": { \"\u003Cflag>\": \"\u003Cvariant>\" | true | false | { … } }` to pin remote-config overrides for the run, the way an A\u002FB test needs its `treatment` arm. The resolver freezes it as `remoteFlagSpec`, the exact `--remote-flag` value every launch carries. When the diff gates its behaviour on a flag the request does not name, derive the criteria anyway, name the flag and the arm each criterion needs in the report, and let the caller rerun with the field set; never guess a variant.\n- Any kind may add `\"proofLane\": \"source-dev\" | \"official-unmodified\" | \"official-qa-derived\"` (default `source-dev`) and `\"mainnetOptIn\": true`. Both freeze with the scope; [Domain QA](references\u002Fdomain-qa.md) says what each changes.\n\nWith no scope, take the checkout's current PR from `gh pr view --json url,headRefName,headRefOid` and require exactly one match; with no PR, range the checkout branch against its base. Use a checkout of that repository and refresh moving refs before freezing, fetching missing objects without resetting unrelated work. A fork head stays untrusted for runtime execution until the isolated-checkout and authorization requirements are met.\n\nThen compare the checkout with the scope head. Already on the PR branch (or at the range or ref head): continue without asking. Anywhere else: say which branch and commit the checkout is on and whether it is clean, and ask before switching; on yes, fetch the head and check it out (a PR branch by name, a bare commit detached; fetch the exact object when the branch is gone). Never switch a tree with uncommitted changes: stop instead. Cook never switches checkouts. This is a gate: do not derive criteria or initialize a task until the checkout is at the scope head, so a \"no\" leaves nothing behind.\n\n## 2. Domain, optional\n\n`--domain \u003Cname>` selects the team library whose recipes, checklist and test plan apply. It is not a Git author or path filter. For a domain-only request, record the included changes and the team-owned criteria or supplied selectors that make them relevant; retain excluded changes and selection uncertainty in the report. Shared wallet changes may affect the domain even when another team authored them.\n\n## 3. Derive the acceptance criteria, before any template\n\nBuild one numbered list from the scope:\n\n- `pr`: the PR body and its linked tickets. Keep authored criteria verbatim, labelled `authored`; only when none exist, derive candidates from the description and changed files, labelled `derived`. Caller-supplied criteria replace extraction and stay verbatim.\n- `range` \u002F `window`: the union over the PRs landed in that scope, each row keeping its PR reference. When the caller explicitly limits validation to a domain or PR set, retain the full change inventory and derive coverage for that recorded selection; never silently drop a selected criterion. Include integration criteria where the selected changes share a user journey, labelled `derived`, without replacing the original criteria.\n- With a domain: also that library's test-plan cases, keeping their stable case IDs. A range plus a domain is that domain's plan, run on this release.\n- `ref`: the domain's test-plan cases or caller-supplied criteria only; with neither, stop and ask for one.\n\nPass the list as the task text (`--task-text` or `--task-file`) and as separate, verbatim `--acceptance` flags to Cook's initializer. This records the criteria in `TASK.md` and the handoff. Never reword, split, merge or weaken a criterion to fit a recipe.\n\n## 4. Materialize the task\n\nIf TASK\u002FCHECKLIST already exist, run Cook's `scripts\u002Finit-template --resume-task-dir \u003Ctask>` to verify its retained tooling and continue the recorded checklist without changing task files. Otherwise run `scripts\u002Finit-template --task-kind qa [--domain \u003Cname>]` with that task text, forwarding the supplied project\u002Fprovider selectors. Use `qa\u002Fdefault`; only a `--template \u003Cid>` the caller passed selects another, and a team library may shadow a template by ID. Never ask which template to use. Initialization does not run QA: never pass `--prepare` or create a second task.\n\n## 5. Freeze the scope\n\nSave the scope input as `\u003Ctask>\u002Finputs\u002Fqa-scope-request.json`, or reuse it when supplied, then run from the repository:\n\n```bash\nnode \u003Cinstalled-skill>\u002Fscripts\u002Fresolve-scope.mjs --input \u003Ctask>\u002Finputs\u002Fqa-scope-request.json --out \u003Ctask>\u002Fartifacts\u002Fqa-scope.json\n```\n\nFor a dispatched task, run `node \u003Cinstalled-skill>\u002Fscripts\u002Fresolve-scope.mjs --farm-input \u003Ctask>\u002Finputs\u002Fqa.json --out \u003Ctask>\u002Finputs\u002Fqa-scope-request.json`. The adapter overlays admitted scope on matching-kind preset defaults, maps `proof_lane` to `proofLane`, and binds `source` base\u002Fhead only to `kind: pr`. Ranges, windows and refs use their own revisions.\n\n`expectedHeadSha`\u002F`expectedBaseSha` bind the request to known commits; the resolver rejects a mismatch, reads Git and provider data without checking out code or launching an app, and never overwrites a frozen scope. On resume, reuse the artifact and its SHA. A request whose scope input differs from a frozen `qa-scope-request.json` for the same target (any key, `remoteFeatureFlags` included) is a new task, never a resume.\n\n## 6. Execute and finalize\n\nFollow the materialized checklist and `\u002Fmms-recipe-cook\u002Freferences\u002Fqa.md`. Save an index containing `packages` (case id → retained run package dir) and `smoke` (`caseId`, `proofTarget`), then run `node \u003Cinstalled-skill>\u002Fscripts\u002Ffinalize-qa.mjs --task \u003Ctask> --index \u003Cindex.json>`. It validates the retained packages and emits portable `artifacts\u002Fqa-proof.json`; missing or failed packages block finalization, so preserve their evidence and report the gap.\n\nFor the template's early smoke gate, use the same command with `--check-only` and a smoke-only index. It validates retained packages without creating or replacing the final suite or QA result; do not write a custom validator wrapper.\n\nAfter a corrective replay, write a new index changing only attempt paths and run `node \u003Cinstalled-skill>\u002Fscripts\u002Ffinalize-qa.mjs --task \u003Ctask> --index \u003Cnew-index.json> --reselect` against the existing farm binding; never combine with `--suite` or `--check-only`. Keep original attempts and replay COMPLETE afterward to recapture the result; this grants no review or publication approval.\n\nIf a required ref, runtime target, Cook template or declared recipe capability is unavailable, report that missing input or blocked capability. Never substitute a successful static review for runtime QA.\n\nSelect a risk-based proof plan for the requested assurance level before feature execution. For `qa\u002Fdefault`, register its selected cases through Cook's existing `qa-cases` child-checklist instructions to track individual case progress; completed cases are assessed outcomes, not automatic passes. Explicit alternative templates keep their own checklist contract unless they declare a child binding. Daily\u002Frelease smoke does not automatically require replaying every prior PR's full AC suite; retain full inventory and explicit omitted-detail rationale. Do not stop selected coverage at existing recipes. Compose supported actions for the selected checks and attempt prerequisites already within the caller's authority. Distinguish not attempted, incomplete proof, and an observed blocker; an unmet prerequisite or missing recipe is not by itself evidence that a criterion is untestable. Retain the attempted setup\u002Fcapability check and concrete failure, or the explicit budget\u002Fscope reason execution stopped.\n\n## 7. Report\n\nRead [QA report reference](references\u002Freport-example.md) for presentation and delivery guidance. Keep Cook's verdict rules and artifact contract. Daily, release, range and ref runs save the report locally with findings, gaps and evidence; publication is a separate authorized action.\n\nRender structured evidence as self-contained `artifacts\u002Freport.html`, the sole human report, following the [HTML reference](references\u002Freport-example.html) and [rendering instructions](references\u002Fhtml-report.md). Include PR titles\u002Flinks and full frozen criteria; keep IDs secondary. Contents, collapsible criteria and criterion images must work offline. Preserve machine proof, raw outputs and historical reports.\n\nWhen Cook completes, return the report and evidence paths. For a `pr` scope with a domain whose static review skill is installed (perps: `\u002Fmms-perps-review-pr \u003CPR URL>`), run it too and report its source findings in their own section, never merged with the runtime verdicts. Then ask what to do next; the usual path is posting the report as one PR comment through `\u002Fmms-recipe-pretty-pr`'s evidence-comment target, which hosts the manifest-indexed screenshots and refreshes the same comment on a rerun. Cook stays silent; posting and cleanup are separate explicit actions.\n",{"name":5,"maturity":46,"description":7,"disable-model-invocation":47},"experimental",true,"main","3df1d0d67b30ff15236561f8c0f9f06d33f42dfd","skills\u002Fwallets\u002Fmetamask-official-recipe-qa",17,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia","https:\u002F\u002Feth2030.com","Hardcore infra. Building @alt-research and applied cryptography.","2026-11-12 02:28:42",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":47},[59,62,65],{"tool":60,"command":61},"npx","npx skills add jiayaoqijia\u002Fcryptoskill --skill recipe-qa",{"tool":63,"command":64},"bunx","bunx skills add jiayaoqijia\u002Fcryptoskill --skill recipe-qa",{"tool":66,"command":67},"pnpm","pnpm dlx skills add jiayaoqijia\u002Fcryptoskill --skill recipe-qa","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002FSKILL.md",[70,74,80,84,88,92,96,102,106,110,114,118,122,126,130,134,138,142],{"path":71,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":16},"LICENSE","许可证",1065,{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fdomain-qa.md","REFERENCE","参考文档",10889,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002Freferences\u002Fdomain-qa.md",{"path":81,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fhtml-report.md",8119,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002Freferences\u002Fhtml-report.md",{"path":85,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Freport-example.html",14395,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002Freferences\u002Freport-example.html",{"path":89,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Freport-example.json",3866,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002Freferences\u002Freport-example.json",{"path":93,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Freport-example.md",2272,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002Freferences\u002Freport-example.md",{"path":97,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":100,"sourceHtmlUrl":101},"scripts\u002Facquire-official-artifact.mjs","SCRIPT","脚本",7440,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002Fscripts\u002Facquire-official-artifact.mjs",{"path":103,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":104,"sourceHtmlUrl":105},"scripts\u002Facquire-official-artifact.test.mjs",6943,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002Fscripts\u002Facquire-official-artifact.test.mjs",{"path":107,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":108,"sourceHtmlUrl":109},"scripts\u002Ffinalize-qa.mjs",8946,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002Fscripts\u002Ffinalize-qa.mjs",{"path":111,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":112,"sourceHtmlUrl":113},"scripts\u002Ffinalize-qa.test.mjs",14255,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002Fscripts\u002Ffinalize-qa.test.mjs",{"path":115,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":116,"sourceHtmlUrl":117},"scripts\u002Frender-report.mjs",27511,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002Fscripts\u002Frender-report.mjs",{"path":119,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":120,"sourceHtmlUrl":121},"scripts\u002Frender-report.test.mjs",13159,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002Fscripts\u002Frender-report.test.mjs",{"path":123,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":124,"sourceHtmlUrl":125},"scripts\u002Freselect-qa.mjs",3910,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002Fscripts\u002Freselect-qa.mjs",{"path":127,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":128,"sourceHtmlUrl":129},"scripts\u002Fresolve-scope.mjs",13005,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002Fscripts\u002Fresolve-scope.mjs",{"path":131,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":132,"sourceHtmlUrl":133},"scripts\u002Fresolve-scope.test.mjs",15133,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002Fscripts\u002Fresolve-scope.test.mjs",{"path":135,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":136,"sourceHtmlUrl":137},"scripts\u002Fwrite-new-file.mjs",249,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002Fscripts\u002Fwrite-new-file.mjs",{"path":139,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":140,"sourceHtmlUrl":141},"SOURCE.md",358,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002FSOURCE.md",{"path":143,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":144,"sourceHtmlUrl":145},"TRUST.auto.yaml",2264,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-qa\u002FTRUST.auto.yaml",[147,174,197,215,228,238],{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":151,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":41},"01M712C436EQYE43342Q4E7GG1","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\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-performance\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-performance\u002FSKILL.md",[],[155,156,21,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173],"performance","recipe performance","mm","sentry","harness","app","deterministic","recipes","flow","cold","critical","analysis","tasks","react","browser","layout","screen","network","metamask",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":178,"licenseFileUrl":179,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":41},"01M70XT2F8A5CQZ81JBP98KSW3","mexc-spot-websocket","MEXC Spot WebSocket workflows for public streams, protobuf handling, depth maintenance, listen keys, and private streams without exposing API keys.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-websocket\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-websocket\u002FSKILL.md",[],[183,184,185,186,187,188,189,190,191,192,193,194,195,196],"mexc spot websocket","spot","websocket","api","workflows","public","listen","streams","depth","keys","for","api keys","maintenance","protobuf",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":178,"licenseFileUrl":201,"sourceHtmlUrl":202,"categories":203,"keywords":204,"publishedAt":41},"01M70XT0MBXN3WZY1BKN0CPNKR","mexc-spot-rest","MEXC Spot REST workflows for public data, signed account requests, orders, wallet\u002Fadmin actions, and secure signing without exposing API keys.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-rest\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-rest\u002FSKILL.md",[],[205,184,206,207,208,209,210,194,193,192,211,212,213,188,214,187,186],"mexc spot rest","REST","admin","signing","Wallet","requests","actions","secure","data","orders",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":178,"licenseFileUrl":219,"sourceHtmlUrl":220,"categories":221,"keywords":222,"publishedAt":41},"01M70XSYSVZ2N0N91XCAR2CAK0","mexc-futures-websocket","MEXC Futures WebSocket workflows for public streams, private account\u002Forder\u002Fposition streams, ping\u002Fpong, subscriptions, and depth maintenance.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-futures-websocket\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-futures-websocket\u002FSKILL.md",[],[223,224,185,225,226,195,193,227,191,190,188,187],"mexc futures websocket","futures","position","ping","subscriptions",{"skillNo":229,"name":230,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":231,"sourceHtmlUrl":232,"categories":233,"keywords":234,"publishedAt":41},"01M6H0ZWHVE5W04WG2DKQE2SQC","0xklen-version-and-refresh-sanctions-lists","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-version-and-refresh-sanctions-lists\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-version-and-refresh-sanctions-lists\u002FSKILL.md",[],[235,236,237],"refresh","0xklen version and refresh sanctions lists","version",{"skillNo":239,"name":240,"nameZh":6,"description":241,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":242,"sourceHtmlUrl":243,"categories":244,"keywords":245,"publishedAt":41},"01M6H0Z28Q3R8J0S799GJQWXM3","verify-tests-cover-changed-lines","Use when a PR adds code that the existing suite may not exercise. Measures patch coverage — the share of newly changed lines hit by tests — before approving.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-verify-tests-cover-changed-lines\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-verify-tests-cover-changed-lines\u002FSKILL.md",[],[246,247,248,249,250,40,251,252,253,254,255],"tests","cover","verify tests cover changed lines","verify","coverage","exercise","use","patch","code","share"]