[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GPFTBX0RSP5QXQ9DXQ17SV":3,"skill-same:01M6GPFTBX0RSP5QXQ9DXQ17SV":100},{"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":32,"publishedAt":54,"linkOnly":55,"markdownContent":56,"markdownBody":57,"frontMatter":58,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":6,"ownerHtmlUrl":64,"ownerBlogUrl":65,"ownerDescription":66,"updatedAt":67,"install":68,"resources":81},"01M6GPFTBX0RSP5QXQ9DXQ17SV","design-threat-review",null,"Threat-models a design BEFORE implementation — spec\u002FPRD\u002Fdata-model\u002Froute sketch in, THREAT-MODEL.md out with actor×asset inventory, data flows across trust boundaries, STRIDE sweep mapped to the repo's detection skills, per-persona abuse cases, and an audit contract (the actor×surface matrix + acceptance criteria) the future security-audit must disposition. Use when the user shares a design doc, spec, PRD, or architecture, or asks to threat-model a system before or during early build — before the code exists to audit.","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\u002Fchains\u002Fashrafiucse-design-threat-review\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fashrafiucse-design-threat-review\u002FSKILL.md",[19,24,29],{"categoryNo":20,"categoryName":21,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":25,"categoryName":26,"taxonomyType":27,"taxonomyTypeDesc":28},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":30,"categoryName":31,"taxonomyType":27,"taxonomyTypeDesc":28},"01JBSEEDCAT000000000000037","律师与法务",[33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53],"review","design","design threat review","threat","when","with","flows","contract","across","route","trust","use","repo","sweep","model","system","persona","inventory","acceptance","code","architecture","2026-11-10 10:12:30",false,"---\nname: design-threat-review\ndescription: Threat-models a design BEFORE implementation — spec\u002FPRD\u002Fdata-model\u002Froute sketch in, THREAT-MODEL.md out with actor×asset inventory, data flows across trust boundaries, STRIDE sweep mapped to the repo's detection skills, per-persona abuse cases, and an audit contract (the actor×surface matrix + acceptance criteria) the future security-audit must disposition. Use when the user shares a design doc, spec, PRD, or architecture, or asks to threat-model a system before or during early build — before the code exists to audit.\nlicense: MIT\n---\n\n# Design Threat Review\n\nSecurity decisions are cheapest before code exists. This skill runs at design\ntime and produces the ONE artifact that `..\u002Fsecurity-audit\u002FSKILL.md` Phase 0\u002F2\nconsumes at audit time — a shared actor×surface matrix plus acceptance\ncriteria. Design → implementation → audit: one artifact, no seams.\n\n## Ground rules\n\n- Input is prose\u002Fdiagrams as readily as code — absence of code is the point.\n- Output is ONE file: `THREAT-MODEL.md` in the project root (the only file you create).\n- Every threat gets a code-phase detector (sibling skill) AND an acceptance\n  criterion. A threat with no detector becomes a design-protected control —\n  never leave a threat with neither.\n\n## Step 0 — Gather inputs\n\nRead whatever exists: spec\u002FPRD, ERD\u002Fdata model, route sketches, integration\nlist, personas. If thin, ask or record assumptions:\n\n- Which account types\u002Froles exist? Who grants them?\n- What does each role SUBMIT that another role OPENS? (moderation surfaces)\n- Where does money\u002Fentitlement change hands? What artifact marks \"paid\"?\n- What PII\u002Fsecrets exist, and where do they flow — including logs, emails,\n  support tools, third parties?\n- What calls INTO the system (webhooks, SSO, imports, postbacks)?\n\n## Step 1 — Assets & actors\n\n- **ASSETS**: content\u002FIP, money & entitlements, PII, credentials\u002Fsecrets,\n  admin power, availability.\n- **ACTORS**: anonymous, authenticated user, staff\u002Fmoderator,\n  admin\u002Ftenant-admin, service\u002Fwebhook caller, third-party integration.\n- Build the actor×asset power matrix: each cell = the actor's legitimate\n  power over that asset. Illegitimate power is exactly what Step 3\u002F4 hunt.\n\n## Step 2 — Data flows & trust boundaries\n\nSketch the flows (e.g. student submits review → stored → pending queue →\nstaff opens detail view → approve → public page). Mark EVERY trust-boundary\ncrossing: browser↔app, app↔db, app↔third-party, queue\u002Fworker, email render,\nadmin origin. Each crossing becomes a coverage-matrix cell. Content that\ncrosses a boundary UNPURIFIED and is opened by a HIGHER-privilege actor is\nthe highest-priority cell class (see `..\u002Flaravel-security\u002FSKILL.md` Step 4\nprivilege-direction table and `..\u002Fcourse-platform-security\u002FSKILL.md` §6.5).\n\n## Step 3 — Threat sweep (STRIDE → repo detection skills)\n\nFor each flow element, sweep STRIDE; tag each credible threat with the\nsibling skill that must catch it in code:\n\n| STRIDE | Ask at each boundary | Detector skill |\n|---|---|---|\n| Spoofing | can a weaker actor pose as a stronger one at this boundary? | `..\u002Fauth-review\u002FSKILL.md` |\n| Tampering | does content cross unpurified and get rendered? (stored→rendered) | `..\u002Finjection-flaws\u002FSKILL.md` + framework skill (e.g. laravel Step 4) |\n| Repudiation | do money\u002Fstate transitions leave tamper-evident traces? | `..\u002Fflow-security\u002FSKILL.md` |\n| Info disclosure | does a boundary leak gated\u002FPII data (catalog, preview, logs)? | `..\u002Fdata-exposure\u002FSKILL.md`, `..\u002Fcourse-platform-security\u002FSKILL.md` |\n| DoS | can one cheap request cause expensive work? | `..\u002Fconfig-hardening\u002FSKILL.md`, `..\u002Fgraphql-security\u002FSKILL.md` |\n| Elevation | does unprivileged input reach privileged surfaces? | `..\u002Fauth-review\u002FSKILL.md` + course skill §6.5 |\n\nDomain lenses: course\u002Fe-learning → the course skill's three personas;\npayments\u002Fsubscriptions → flow-security state machines (what fulfills an\nentitlement, what can replay).\n\n## Step 4 — Abuse cases per persona\n\nFor each actor, write the attacker version: what do they WANT (free content,\nanother user's data, a staff session, a refund) and which cell do they\nabuse? Defaults that must not be argued away:\n\n- Unprivileged→privileged content flows (moderation) default to\n  **severity-if-missed: Critical** — the approval workflow itself is the\n  delivery mechanism (MISSES.md 2026-09-23: student review → staff detail\n  view → admin ATO).\n- Preview\u002Ffree-tier flows default to Critical-if-full-content.\n\n## Step 5 — Write THREAT-MODEL.md (the audit contract)\n\n1. Actor×asset power matrix (Step 1) and flows+boundaries (Step 2).\n2. Threat list — one section per threat, same shape as security-audit Phase 3\n   findings so the scorer and future audits parse both the same way\n   (`T-NNN` ids; the spec anchor is the citable `file:line` evidence):\n\n   ```markdown\n   ### T-01: \u003Cthreat title> — \u003Cseverity-if-missed>\n   - **Actor → Asset:** student → admin power\n   - **Surface:** moderation detail view\n   - **Spec anchor:** spec.md:17-19\n   - **Detector skill:** ..\u002Flaravel-security\u002FSKILL.md Step 4 (privilege direction) + ..\u002Fcourse-platform-security\u002FSKILL.md §6.5\n   - **Acceptance criterion:** \u003Cthe control implementation MUST show, stated as a checkable fact>\n   ```\n\n   The acceptance criterion is checkable — e.g. \"review body passes through\n   e() before any formatting in EVERY staff view — list AND detail — or is\n   stored purified\" — never \"input is handled safely\".\n3. The pre-seeded actor×surface coverage matrix, all cells ⬜ — the exact\n   artifact `..\u002Fsecurity-audit\u002FSKILL.md` Phase 0 loads and Phase 2 (gate v2)\n   forces to disposition.\n4. Handoff notes: acceptance criteria are the implementation's security\n   requirements; the first audit reads THREAT-MODEL.md, runs the detector\n   skills, and disposition-checks every threat row and every matrix cell.\n\n## Reporting\n\nEnd with a 3-line verbal summary: highest severity-if-missed threat, the\nsingle acceptance criterion most likely to be skipped in implementation,\nand the detector skill that will catch it later if it is.\n","# Design Threat Review\n\nSecurity decisions are cheapest before code exists. This skill runs at design\ntime and produces the ONE artifact that `..\u002Fsecurity-audit\u002FSKILL.md` Phase 0\u002F2\nconsumes at audit time — a shared actor×surface matrix plus acceptance\ncriteria. Design → implementation → audit: one artifact, no seams.\n\n## Ground rules\n\n- Input is prose\u002Fdiagrams as readily as code — absence of code is the point.\n- Output is ONE file: `THREAT-MODEL.md` in the project root (the only file you create).\n- Every threat gets a code-phase detector (sibling skill) AND an acceptance\n  criterion. A threat with no detector becomes a design-protected control —\n  never leave a threat with neither.\n\n## Step 0 — Gather inputs\n\nRead whatever exists: spec\u002FPRD, ERD\u002Fdata model, route sketches, integration\nlist, personas. If thin, ask or record assumptions:\n\n- Which account types\u002Froles exist? Who grants them?\n- What does each role SUBMIT that another role OPENS? (moderation surfaces)\n- Where does money\u002Fentitlement change hands? What artifact marks \"paid\"?\n- What PII\u002Fsecrets exist, and where do they flow — including logs, emails,\n  support tools, third parties?\n- What calls INTO the system (webhooks, SSO, imports, postbacks)?\n\n## Step 1 — Assets & actors\n\n- **ASSETS**: content\u002FIP, money & entitlements, PII, credentials\u002Fsecrets,\n  admin power, availability.\n- **ACTORS**: anonymous, authenticated user, staff\u002Fmoderator,\n  admin\u002Ftenant-admin, service\u002Fwebhook caller, third-party integration.\n- Build the actor×asset power matrix: each cell = the actor's legitimate\n  power over that asset. Illegitimate power is exactly what Step 3\u002F4 hunt.\n\n## Step 2 — Data flows & trust boundaries\n\nSketch the flows (e.g. student submits review → stored → pending queue →\nstaff opens detail view → approve → public page). Mark EVERY trust-boundary\ncrossing: browser↔app, app↔db, app↔third-party, queue\u002Fworker, email render,\nadmin origin. Each crossing becomes a coverage-matrix cell. Content that\ncrosses a boundary UNPURIFIED and is opened by a HIGHER-privilege actor is\nthe highest-priority cell class (see `..\u002Flaravel-security\u002FSKILL.md` Step 4\nprivilege-direction table and `..\u002Fcourse-platform-security\u002FSKILL.md` §6.5).\n\n## Step 3 — Threat sweep (STRIDE → repo detection skills)\n\nFor each flow element, sweep STRIDE; tag each credible threat with the\nsibling skill that must catch it in code:\n\n| STRIDE | Ask at each boundary | Detector skill |\n|---|---|---|\n| Spoofing | can a weaker actor pose as a stronger one at this boundary? | `..\u002Fauth-review\u002FSKILL.md` |\n| Tampering | does content cross unpurified and get rendered? (stored→rendered) | `..\u002Finjection-flaws\u002FSKILL.md` + framework skill (e.g. laravel Step 4) |\n| Repudiation | do money\u002Fstate transitions leave tamper-evident traces? | `..\u002Fflow-security\u002FSKILL.md` |\n| Info disclosure | does a boundary leak gated\u002FPII data (catalog, preview, logs)? | `..\u002Fdata-exposure\u002FSKILL.md`, `..\u002Fcourse-platform-security\u002FSKILL.md` |\n| DoS | can one cheap request cause expensive work? | `..\u002Fconfig-hardening\u002FSKILL.md`, `..\u002Fgraphql-security\u002FSKILL.md` |\n| Elevation | does unprivileged input reach privileged surfaces? | `..\u002Fauth-review\u002FSKILL.md` + course skill §6.5 |\n\nDomain lenses: course\u002Fe-learning → the course skill's three personas;\npayments\u002Fsubscriptions → flow-security state machines (what fulfills an\nentitlement, what can replay).\n\n## Step 4 — Abuse cases per persona\n\nFor each actor, write the attacker version: what do they WANT (free content,\nanother user's data, a staff session, a refund) and which cell do they\nabuse? Defaults that must not be argued away:\n\n- Unprivileged→privileged content flows (moderation) default to\n  **severity-if-missed: Critical** — the approval workflow itself is the\n  delivery mechanism (MISSES.md 2026-09-23: student review → staff detail\n  view → admin ATO).\n- Preview\u002Ffree-tier flows default to Critical-if-full-content.\n\n## Step 5 — Write THREAT-MODEL.md (the audit contract)\n\n1. Actor×asset power matrix (Step 1) and flows+boundaries (Step 2).\n2. Threat list — one section per threat, same shape as security-audit Phase 3\n   findings so the scorer and future audits parse both the same way\n   (`T-NNN` ids; the spec anchor is the citable `file:line` evidence):\n\n   ```markdown\n   ### T-01: \u003Cthreat title> — \u003Cseverity-if-missed>\n   - **Actor → Asset:** student → admin power\n   - **Surface:** moderation detail view\n   - **Spec anchor:** spec.md:17-19\n   - **Detector skill:** ..\u002Flaravel-security\u002FSKILL.md Step 4 (privilege direction) + ..\u002Fcourse-platform-security\u002FSKILL.md §6.5\n   - **Acceptance criterion:** \u003Cthe control implementation MUST show, stated as a checkable fact>\n   ```\n\n   The acceptance criterion is checkable — e.g. \"review body passes through\n   e() before any formatting in EVERY staff view — list AND detail — or is\n   stored purified\" — never \"input is handled safely\".\n3. The pre-seeded actor×surface coverage matrix, all cells ⬜ — the exact\n   artifact `..\u002Fsecurity-audit\u002FSKILL.md` Phase 0 loads and Phase 2 (gate v2)\n   forces to disposition.\n4. Handoff notes: acceptance criteria are the implementation's security\n   requirements; the first audit reads THREAT-MODEL.md, runs the detector\n   skills, and disposition-checks every threat row and every matrix cell.\n\n## Reporting\n\nEnd with a 3-line verbal summary: highest severity-if-missed threat, the\nsingle acceptance criterion most likely to be skipped in implementation,\nand the detector skill that will catch it later if it is.\n",{"name":5,"license":15,"description":7},"main","3df1d0d67b30ff15236561f8c0f9f06d33f42dfd","skills\u002Fchains\u002Fashrafiucse-design-threat-review",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-15 02:28:10",{"source":8,"skillName":5,"commands":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add jiayaoqijia\u002Fcryptoskill --skill design-threat-review",{"tool":74,"command":75},"bunx","bunx skills add jiayaoqijia\u002Fcryptoskill --skill design-threat-review",{"tool":77,"command":78},"pnpm","pnpm dlx skills add jiayaoqijia\u002Fcryptoskill --skill design-threat-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fashrafiucse-design-threat-review\u002FSKILL.md",true,[82,86,92,96],{"path":83,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":16},"LICENSE","许可证",1067,{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fpatterns.md","REFERENCE","参考文档",1917,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fashrafiucse-design-threat-review\u002Freferences\u002Fpatterns.md",{"path":93,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":94,"sourceHtmlUrl":95},"SOURCE.md",377,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fashrafiucse-design-threat-review\u002FSOURCE.md",{"path":97,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":98,"sourceHtmlUrl":99},"TRUST.auto.yaml",2217,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fashrafiucse-design-threat-review\u002FTRUST.auto.yaml",[101,129,152,170,183,193],{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":105,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":54},"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",[],[109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128],"performance","recipe performance","recipe","mm","sentry","harness","app","deterministic","recipes","flow","cold","critical","analysis","tasks","react","browser","layout","screen","network","metamask",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":133,"licenseFileUrl":134,"sourceHtmlUrl":135,"categories":136,"keywords":137,"publishedAt":54},"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",[],[138,139,140,141,142,143,144,145,146,147,148,149,150,151],"mexc spot websocket","spot","websocket","api","workflows","public","listen","streams","depth","keys","for","api keys","maintenance","protobuf",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":133,"licenseFileUrl":156,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":54},"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",[],[160,139,161,162,163,164,165,149,148,147,166,167,168,143,169,142,141],"mexc spot rest","REST","admin","signing","Wallet","requests","actions","secure","data","orders",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":133,"licenseFileUrl":174,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":54},"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",[],[178,179,140,180,181,150,148,182,146,145,143,142],"mexc futures websocket","futures","position","ping","subscriptions",{"skillNo":184,"name":185,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":186,"sourceHtmlUrl":187,"categories":188,"keywords":189,"publishedAt":54},"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",[],[190,191,192],"refresh","0xklen version and refresh sanctions lists","version",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":197,"sourceHtmlUrl":198,"categories":199,"keywords":200,"publishedAt":54},"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",[],[201,202,203,204,205,206,207,44,208,52,209],"tests","cover","verify tests cover changed lines","verify","coverage","pr","exercise","patch","share"]