[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AEB31ST2789QN6NHS9TZ7T":3,"skill-same:01M6AEB31ST2789QN6NHS9TZ7T":80},{"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":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":58,"updatedAt":59,"install":60,"resources":73},"01M6AEB31ST2789QN6NHS9TZ7T","verify-agent-action",null,"Review a proposed AI-agent action or human-approval packet before execution. Use when an agent wants to run a consequential tool, command, deployment, message, purchase, credential operation, or data mutation; when checking whether approval still matches the exact action; or when auditing action evidence for forged results, parameter swaps, replay, correlated reviewers, missing evidence, expiry, or stale monitoring. Produce an evidence-based review only—never execute or authorize the action.","github\u002Fawesome-copilot","github","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F9919?v=4","01M6AC83DS133TPXFSP1DHNCC6","GitHub","01M6AD3PBDYPK7NVFJNJ66Y8RS",41046,"MIT","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fverify-agent-action\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44],"action","verify agent action","verify","only","when","for","purchase","mutation","swaps","human","message","ai-agent","evidence","review","never","command","data","monitoring","produce","run","deployment","2026-11-10 10:12:30",false,"---\nname: verify-agent-action\ndescription: 'Review a proposed AI-agent action or human-approval packet before execution. Use when an agent wants to run a consequential tool, command, deployment, message, purchase, credential operation, or data mutation; when checking whether approval still matches the exact action; or when auditing action evidence for forged results, parameter swaps, replay, correlated reviewers, missing evidence, expiry, or stale monitoring. Produce an evidence-based review only—never execute or authorize the action.'\n---\n\n# Verify Agent Action\n\nTreat a plausible approval screen as a claim, not proof. Verify the complete\ndecision path before a human or an external enforcement point decides whether\nto act.\n\n## Preserve the safety boundary\n\n- Never execute, approve, sign, send, purchase, deploy, or mutate anything.\n- Never convert this review into execution authority.\n- Never infer missing evidence, identities, timestamps, or parameters.\n- Treat a valid schema, checksum, or signature as insufficient by itself.\n- Treat signatures as evidence of attribution and integrity, not factual truth.\n- Keep supporting and refuting evidence separate; do not average conflict away.\n- Fail closed on a material mismatch. Use `INCONCLUSIVE` when required evidence\n  is unavailable.\n\nSet this field in every final result:\n\n```json\n{\"execution_authorized\": false}\n```\n\n## Collect the review packet\n\nRequest only the artifacts needed for the review:\n\n1. The original user or system request.\n2. The exact proposed action:\n   - operation or tool name\n   - target resource\n   - complete parameters\n   - filesystem and network scope\n   - maximum execution count\n   - not-before and expiry times\n3. The assessment that claims the action is justified.\n4. The source evidence and policy used by that assessment.\n5. The approval record, including approver identity, role, action digest, nonce,\n   audience, issue time, expiry, and use count.\n6. The latest monitoring events and expected heartbeat interval.\n7. The current trusted time and any prior nonce-use record.\n\nList missing fields before analysis. Do not silently substitute defaults.\n\n## Build the exact action identity\n\nCreate one normalized action object without dropping fields:\n\n```json\n{\n  \"operation\": \"git.push\",\n  \"target\": \"owner\u002Frepository\",\n  \"parameters\": {\n    \"branch\": \"fix\u002Fexample\",\n    \"commit\": \"40-character-sha\",\n    \"remote\": \"origin\"\n  },\n  \"filesystem_scope\": [],\n  \"network_scope\": [\"github.com:443\"],\n  \"execution_count\": 1,\n  \"not_before\": \"RFC3339 timestamp\",\n  \"expires_at\": \"RFC3339 timestamp\"\n}\n```\n\nUse a project-specified canonicalization and digest algorithm when provided.\nOtherwise, report that cryptographic identity cannot be independently verified;\nstill compare every field structurally.\n\nNever normalize away a security-relevant distinction such as:\n\n- branch, commit, repository, environment, recipient, amount, currency, or host\n- recursive, force, overwrite, privileged, destructive, or dry-run flags\n- filesystem roots, CIDRs, ports, domains, execution counts, or expiry\n\n## Run the six controls\n\nEvaluate every control as `PASS`, `FAIL`, `INCONCLUSIVE`, or `NOT_APPLICABLE`.\n\n### 1. Recompute the assessment\n\n- Re-run the declared deterministic evaluator from the declared source inputs\n  when its implementation is available.\n- Compare the complete canonical result, not selected fields.\n- Mark `FAIL` if the received result differs from recomputation.\n- Mark `INCONCLUSIVE` when only schema validation, an internal checksum, or an\n  unverifiable evaluator claim is available.\n\n### 2. Match the exact approved action\n\n- Compare the proposed action with the action bound into the approval.\n- Compare the complete normalized object and its digest.\n- Mark `FAIL` if any material field changed after approval.\n- Treat a broad target or scope as a mismatch when the evidence justifies only\n  a narrower action.\n\n### 3. Reject replay and identity ambiguity\n\n- Verify the nonce is unique and unused.\n- Verify subject, audience, issuer, approver role, issue time, not-before time,\n  expiry, and maximum use count.\n- Mark `FAIL` for a reused nonce, wrong audience, expired approval, future-dated\n  approval, excessive use count, revoked identity, or role mismatch.\n- Mark `INCONCLUSIVE` if no trustworthy replay store or time source exists.\n\n### 4. Test reviewer independence\n\nBuild a dependence table for every reviewer or evaluator:\n\n| Dimension | Compare |\n|---|---|\n| Model | family, version, fine-tune |\n| Provider | account and control plane |\n| Prompt | shared template or ancestry |\n| Retrieval | overlapping sources and indexes |\n| Tools | shared evaluator code and runtime |\n| Operator | common owner or approval authority |\n\nDo not count correlated reviewers as independent quorum members. Mark `FAIL` if\nthe policy requires independent approval and the remaining independent set is\ntoo small.\n\n### 5. Preserve evidence and contradiction\n\n- Inventory every evidence identifier referenced by the assessment.\n- Confirm each item is present, authenticatable, within its validity window,\n  and relevant to the claim.\n- Record support and refutation independently:\n\n| Support | Refutation | Epistemic state |\n|---|---|---|\n| absent | absent | `UNDETERMINED` |\n| present | absent | `SUPPORTED_ONLY` |\n| absent | present | `REFUTED_ONLY` |\n| present | present | `CONFLICTED` |\n\n- Mark `FAIL` if evidence was removed, altered, expired, or concealed in a way\n  that changes the result.\n- Never convert `CONFLICTED` into a numeric average that appears safe.\n\n### 6. Verify lifecycle and monitoring\n\n- Confirm the action is inside its validity window.\n- Verify monitoring-event signatures or integrity evidence when available.\n- Check sequence numbers, previous-event digests, and expected heartbeat\n  cadence.\n- Treat missing, stale, reordered, or broken-chain telemetry as a failure when\n  policy requires continuous monitoring.\n- Do not interpret silence as health.\n\n## Challenge convenient conclusions\n\nBefore producing the final result, attempt these mutations mentally or with\nproject-provided test fixtures:\n\n1. Replace a blocked assessment with an allowed result.\n2. Change one approved target, parameter, scope, amount, or commit.\n3. Reuse an otherwise valid approval nonce.\n4. Replace independent reviewers with correlated copies.\n5. Remove one refuting evidence item.\n6. Stop the monitoring heartbeat after approval.\n\nIf any mutation would pass the reviewed controls, record the affected control\nas `FAIL`; do not merely recommend future hardening.\n\n## Determine the review result\n\nUse exactly one result:\n\n- `ELIGIBLE_FOR_HUMAN_DECISION`: all required controls pass.\n- `ELIGIBLE_WITH_CONTROLS`: no required control fails, and explicit external\n  controls can resolve the listed conditions before execution.\n- `BLOCKED`: at least one required control fails or the action exceeds the\n  justified scope.\n- `INCONCLUSIVE`: no required control is proven false, but evidence needed for\n  a safe decision is missing or unverifiable.\n\n`ELIGIBLE_FOR_HUMAN_DECISION` is not approval. A human authority and a separate\nenforcement point remain responsible for any real action.\n\n## Report in this format\n\n```markdown\n# Agent Action Review\n\n## Result\n- Review result: BLOCKED | INCONCLUSIVE | ELIGIBLE_WITH_CONTROLS |\n  ELIGIBLE_FOR_HUMAN_DECISION\n- Execution authorized: false\n- Exact action digest: \u003Cverified value or NOT_VERIFIED>\n\n## Action\n- Operation:\n- Target:\n- Material parameters:\n- Scope:\n- Validity window:\n- Maximum uses:\n\n## Control matrix\n| Control | Status | Evidence | Reason |\n|---|---|---|---|\n| Recomputed assessment | PASS\u002FFAIL\u002FINCONCLUSIVE\u002FN\u002FA | ... | ... |\n| Exact action binding | ... | ... | ... |\n| Replay and identity | ... | ... | ... |\n| Reviewer independence | ... | ... | ... |\n| Evidence completeness | ... | ... | ... |\n| Monitoring freshness | ... | ... | ... |\n\n## Supporting evidence\n- ...\n\n## Refuting evidence and defeaters\n- ...\n\n## Required next action\n- State the smallest concrete step that could change the result.\n\n## Boundaries\n- State what this review did not prove.\n```\n\nLead with the result and the exact reason. Prefer a reproducible blocker over a\nconfidence score.\n","# Verify Agent Action\n\nTreat a plausible approval screen as a claim, not proof. Verify the complete\ndecision path before a human or an external enforcement point decides whether\nto act.\n\n## Preserve the safety boundary\n\n- Never execute, approve, sign, send, purchase, deploy, or mutate anything.\n- Never convert this review into execution authority.\n- Never infer missing evidence, identities, timestamps, or parameters.\n- Treat a valid schema, checksum, or signature as insufficient by itself.\n- Treat signatures as evidence of attribution and integrity, not factual truth.\n- Keep supporting and refuting evidence separate; do not average conflict away.\n- Fail closed on a material mismatch. Use `INCONCLUSIVE` when required evidence\n  is unavailable.\n\nSet this field in every final result:\n\n```json\n{\"execution_authorized\": false}\n```\n\n## Collect the review packet\n\nRequest only the artifacts needed for the review:\n\n1. The original user or system request.\n2. The exact proposed action:\n   - operation or tool name\n   - target resource\n   - complete parameters\n   - filesystem and network scope\n   - maximum execution count\n   - not-before and expiry times\n3. The assessment that claims the action is justified.\n4. The source evidence and policy used by that assessment.\n5. The approval record, including approver identity, role, action digest, nonce,\n   audience, issue time, expiry, and use count.\n6. The latest monitoring events and expected heartbeat interval.\n7. The current trusted time and any prior nonce-use record.\n\nList missing fields before analysis. Do not silently substitute defaults.\n\n## Build the exact action identity\n\nCreate one normalized action object without dropping fields:\n\n```json\n{\n  \"operation\": \"git.push\",\n  \"target\": \"owner\u002Frepository\",\n  \"parameters\": {\n    \"branch\": \"fix\u002Fexample\",\n    \"commit\": \"40-character-sha\",\n    \"remote\": \"origin\"\n  },\n  \"filesystem_scope\": [],\n  \"network_scope\": [\"github.com:443\"],\n  \"execution_count\": 1,\n  \"not_before\": \"RFC3339 timestamp\",\n  \"expires_at\": \"RFC3339 timestamp\"\n}\n```\n\nUse a project-specified canonicalization and digest algorithm when provided.\nOtherwise, report that cryptographic identity cannot be independently verified;\nstill compare every field structurally.\n\nNever normalize away a security-relevant distinction such as:\n\n- branch, commit, repository, environment, recipient, amount, currency, or host\n- recursive, force, overwrite, privileged, destructive, or dry-run flags\n- filesystem roots, CIDRs, ports, domains, execution counts, or expiry\n\n## Run the six controls\n\nEvaluate every control as `PASS`, `FAIL`, `INCONCLUSIVE`, or `NOT_APPLICABLE`.\n\n### 1. Recompute the assessment\n\n- Re-run the declared deterministic evaluator from the declared source inputs\n  when its implementation is available.\n- Compare the complete canonical result, not selected fields.\n- Mark `FAIL` if the received result differs from recomputation.\n- Mark `INCONCLUSIVE` when only schema validation, an internal checksum, or an\n  unverifiable evaluator claim is available.\n\n### 2. Match the exact approved action\n\n- Compare the proposed action with the action bound into the approval.\n- Compare the complete normalized object and its digest.\n- Mark `FAIL` if any material field changed after approval.\n- Treat a broad target or scope as a mismatch when the evidence justifies only\n  a narrower action.\n\n### 3. Reject replay and identity ambiguity\n\n- Verify the nonce is unique and unused.\n- Verify subject, audience, issuer, approver role, issue time, not-before time,\n  expiry, and maximum use count.\n- Mark `FAIL` for a reused nonce, wrong audience, expired approval, future-dated\n  approval, excessive use count, revoked identity, or role mismatch.\n- Mark `INCONCLUSIVE` if no trustworthy replay store or time source exists.\n\n### 4. Test reviewer independence\n\nBuild a dependence table for every reviewer or evaluator:\n\n| Dimension | Compare |\n|---|---|\n| Model | family, version, fine-tune |\n| Provider | account and control plane |\n| Prompt | shared template or ancestry |\n| Retrieval | overlapping sources and indexes |\n| Tools | shared evaluator code and runtime |\n| Operator | common owner or approval authority |\n\nDo not count correlated reviewers as independent quorum members. Mark `FAIL` if\nthe policy requires independent approval and the remaining independent set is\ntoo small.\n\n### 5. Preserve evidence and contradiction\n\n- Inventory every evidence identifier referenced by the assessment.\n- Confirm each item is present, authenticatable, within its validity window,\n  and relevant to the claim.\n- Record support and refutation independently:\n\n| Support | Refutation | Epistemic state |\n|---|---|---|\n| absent | absent | `UNDETERMINED` |\n| present | absent | `SUPPORTED_ONLY` |\n| absent | present | `REFUTED_ONLY` |\n| present | present | `CONFLICTED` |\n\n- Mark `FAIL` if evidence was removed, altered, expired, or concealed in a way\n  that changes the result.\n- Never convert `CONFLICTED` into a numeric average that appears safe.\n\n### 6. Verify lifecycle and monitoring\n\n- Confirm the action is inside its validity window.\n- Verify monitoring-event signatures or integrity evidence when available.\n- Check sequence numbers, previous-event digests, and expected heartbeat\n  cadence.\n- Treat missing, stale, reordered, or broken-chain telemetry as a failure when\n  policy requires continuous monitoring.\n- Do not interpret silence as health.\n\n## Challenge convenient conclusions\n\nBefore producing the final result, attempt these mutations mentally or with\nproject-provided test fixtures:\n\n1. Replace a blocked assessment with an allowed result.\n2. Change one approved target, parameter, scope, amount, or commit.\n3. Reuse an otherwise valid approval nonce.\n4. Replace independent reviewers with correlated copies.\n5. Remove one refuting evidence item.\n6. Stop the monitoring heartbeat after approval.\n\nIf any mutation would pass the reviewed controls, record the affected control\nas `FAIL`; do not merely recommend future hardening.\n\n## Determine the review result\n\nUse exactly one result:\n\n- `ELIGIBLE_FOR_HUMAN_DECISION`: all required controls pass.\n- `ELIGIBLE_WITH_CONTROLS`: no required control fails, and explicit external\n  controls can resolve the listed conditions before execution.\n- `BLOCKED`: at least one required control fails or the action exceeds the\n  justified scope.\n- `INCONCLUSIVE`: no required control is proven false, but evidence needed for\n  a safe decision is missing or unverifiable.\n\n`ELIGIBLE_FOR_HUMAN_DECISION` is not approval. A human authority and a separate\nenforcement point remain responsible for any real action.\n\n## Report in this format\n\n```markdown\n# Agent Action Review\n\n## Result\n- Review result: BLOCKED | INCONCLUSIVE | ELIGIBLE_WITH_CONTROLS |\n  ELIGIBLE_FOR_HUMAN_DECISION\n- Execution authorized: false\n- Exact action digest: \u003Cverified value or NOT_VERIFIED>\n\n## Action\n- Operation:\n- Target:\n- Material parameters:\n- Scope:\n- Validity window:\n- Maximum uses:\n\n## Control matrix\n| Control | Status | Evidence | Reason |\n|---|---|---|---|\n| Recomputed assessment | PASS\u002FFAIL\u002FINCONCLUSIVE\u002FN\u002FA | ... | ... |\n| Exact action binding | ... | ... | ... |\n| Replay and identity | ... | ... | ... |\n| Reviewer independence | ... | ... | ... |\n| Evidence completeness | ... | ... | ... |\n| Monitoring freshness | ... | ... | ... |\n\n## Supporting evidence\n- ...\n\n## Refuting evidence and defeaters\n- ...\n\n## Required next action\n- State the smallest concrete step that could change the result.\n\n## Boundaries\n- State what this review did not prove.\n```\n\nLead with the result and the exact reason. Prefer a reproducible blocker over a\nconfidence score.\n",{"name":5,"description":7},"main","5269f7ea2d6c3a9bfda5ed878b6726cf509121fd","skills\u002Fverify-agent-action",5340,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot","https:\u002F\u002Fawesome-copilot.github.com\u002F","https:\u002F\u002Fgithub.com\u002Fgithub","https:\u002F\u002Fgithub.com\u002Fabout","How people build software.","2026-11-11 13:41:32",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add github\u002Fawesome-copilot --skill verify-agent-action",{"tool":66,"command":67},"bunx","bunx skills add github\u002Fawesome-copilot --skill verify-agent-action",{"tool":69,"command":70},"pnpm","pnpm dlx skills add github\u002Fawesome-copilot --skill verify-agent-action","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fverify-agent-action\u002FSKILL.md",true,[74],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"agents\u002Fopenai.yaml","REFERENCE","参考文档",43,"https:\u002F\u002Fgithub.com\u002FEvanston09\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002Fbro\u002Fagents\u002Fopenai.yaml",[81,110,137,166,200,217],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":91,"publishedAt":45},"01M70KXZNX9ES38N2A8M58ZZMZ","supabase-rls-policies","Write, review, and test Supabase Row Level Security (RLS) policies so that one user cannot read or change another user's rows. Use when creating or changing tables, policies, views, or security definer functions in a Supabase project, when reviewing a migration that touches RLS, or when asked to prove user isolation with pgTAP tests that sign in as two users.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fsupabase-rls-policies\u002FSKILL.md",[87,90],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[92,93,94,95,96,28,37,97,98,99,100,101,102,103,104,105,106,107,108,109],"supabase","rls","supabase rls","supabase rls policies","project","change","read","write","security","isolation","tables","as","tests","prove","use","users","functions","with",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":117,"publishedAt":45},"01M70KWA5YWXDV6V8DZ19E3T2Y","skill-distribution-audit","Audit a skill collection before release or investigate installer omissions, archived\u002Ftemplate leakage, duplicate identities, and manifest drift. Reconcile the intended public source set, distribution manifest, and actual discovery output for a specified consumer version. Includes a deterministic set-comparison helper.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fskill-distribution-audit\u002FSKILL.md",[116],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[118,119,120,121,122,123,29,124,125,126,127,128,129,130,131,132,133,134,135,136],"distribution","skill distribution audit","audit","SET","deterministic","installer","discovery","comparison","helper","manifest","version","collection","drift","output","investigate","duplicate","template","release","reconcile",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":141,"sourceHtmlUrl":142,"categories":143,"keywords":149,"publishedAt":45},"01M70KCJPFVW7PPQ49CC5R8JGK","logicapps-custom-code-net10-migration","Migrate Azure Logic Apps Standard local-function custom-code projects from .NET 8 to .NET 10. Use for legacy Logic Apps custom-code workspace upgrades, project\u002Fpackage configuration, custom-worker settings, publication, and integrated VS Code debugging. Not for ordinary .NET applications, standalone Azure Functions, Consumption workflows, or cloud deployment.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Flogicapps-custom-code-net10-migration\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Flogicapps-custom-code-net10-migration\u002FSKILL.md",[144],{"categoryNo":145,"categoryName":146,"taxonomyType":147,"taxonomyTypeDesc":148},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[150,151,152,153,154,155,29,96,44,156,157,158,159,160,161,106,162,163,164,165],"custom","code","logicapps custom code net10 migration","migration","projects","standalone","applications","local","azure","worker","upgrades","package","apps","Legacy","debugging","workflows",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":170,"sourceHtmlUrl":171,"categories":172,"keywords":177,"publishedAt":45},"01M6AEBN37RQMXJ3298PEY7PG1","winmd-api-search","Find and explore Windows desktop APIs. Use when building features that need platform capabilities — camera, file access, notifications, UI controls, AI\u002FML, sensors, networking, etc. Discovers the right API for a task and retrieves full type details (methods, properties, events, enumeration values).","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fwinmd-api-search\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fwinmd-api-search\u002FSKILL.md",[173,176],{"categoryNo":174,"categoryName":175,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":145,"categoryName":146,"taxonomyType":147,"taxonomyTypeDesc":148},[178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,28,193,194,195,196,197,29,198,199],"winmd api search","search","api","windows","desktop","file access","enumeration","ui","ml","file","networking","capabilities","notifications","explore","access","features","full","camera","events","platform","methods","controls",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":204,"licenseFileUrl":205,"sourceHtmlUrl":206,"categories":207,"keywords":213,"publishedAt":45},"01M6AE571R3SC1ZGE202B3NB5S","resemble-detect","Deepfake detection and media safety — detect AI-generated audio, images, video, and text, trace synthesis sources, apply watermarks, verify speaker identity, and analyze media intelligence using Resemble AI","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fresemble-detect\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fresemble-detect\u002FSKILL.md",[208,209,212],{"categoryNo":174,"categoryName":175,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":210,"categoryName":211,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[214,121,187,215,216],"resemble detect","https","identity",{"skillNo":218,"name":219,"nameZh":6,"description":220,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":204,"licenseFileUrl":221,"sourceHtmlUrl":222,"categories":223,"keywords":228,"publishedAt":45},"01M6AE30BSK2HCY4TQQ22Z8JRD","quality-playbook","Run a complete quality engineering audit on any codebase. Derives behavioral requirements from the code, generates spec-traced functional tests, runs a three-pass code review with regression tests, executes a multi-model spec audit (Council of Three), and produces a consolidated bug report with TDD-verified patches. Finds the 35% of real defects that structural code review alone cannot catch. Works with any language. Trigger on 'quality playbook', 'spec audit', 'Council of Three', 'fitness-to-purpose', or 'coverage theater'.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fquality-playbook\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fquality-playbook\u002FSKILL.md",[224,227],{"categoryNo":225,"categoryName":226,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[229,230,231,232,151,37,9,120,233,43,215,234,235,236,237,238,239,240,241,242,243,244,104,245,246,247,248],"playbook","quality playbook","quality","code review","tdd","report","spec","bug report","council","engineering","functional","spec audit","bug","verified","multi-model","three","coverage","model","regression","structural"]