[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ADTP9C9353PSFSHF7HN38Y":3,"skill-same:01M6ADTP9C9353PSFSHF7HN38Y":77},{"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":26,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":58,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M6ADTP9C9353PSFSHF7HN38Y","mcp-release-qa",null,"Verify an MCP server before release by exercising a real protocol session, comparing runtime capabilities with source and documentation, testing failure paths, and recording reproducible evidence. Use when shipping or reviewing an MCP server, tool, resource, prompt, catalog, or install path.","github\u002Fawesome-copilot","github","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F9919?v=4","01M6AC83DS133TPXFSP1DHNCC6","GitHub","01M6AD3PBDYPK7NVFJNJ66Y8RS",41081,"MIT","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-release-qa\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"MCP","release","qa","mcp release qa","when","testing","source","path","recording","paths","runtime","evidence","install","session","Reproducible","server","protocol","capabilities","shipping","documentation","mcp server","2026-11-10 10:12:30",false,"---\nname: mcp-release-qa\ndescription: 'Verify an MCP server before release by exercising a real protocol session, comparing runtime capabilities with source and documentation, testing failure paths, and recording reproducible evidence. Use when shipping or reviewing an MCP server, tool, resource, prompt, catalog, or install path.'\n---\n\n# MCP Release QA\n\nTest the server that users will run. A schema review or a passing unit test is\nnot runtime evidence.\n\nThis skill complements security review. It focuses on protocol behavior,\npublished-contract drift, transport correctness, and reproducible release\nevidence.\n\n## Rules\n\n- Run checks against a fresh server process built from the candidate revision.\n- Keep `initialize`, `notifications\u002Finitialized`, discovery, and invocation in\n  the same session. A new process is a new STDIO session.\n- Treat source registrations as implementation truth and public documentation\n  as a contract that must match it.\n- Record exact commands and raw responses. Do not replace missing evidence with\n  \"looks correct.\"\n- Do not invoke mutation-capable tools against production data. Use fixtures, a\n  sandbox, or stop and name the missing safe test environment.\n- Derive the expected capability inventory from the candidate source on every\n  run.\n\n## 1. Establish the release surface\n\nIdentify:\n\n- candidate commit and build command;\n- server entry point and transport: STDIO, Streamable HTTP, or SSE;\n- supported MCP protocol versions;\n- source files that register tools, resources, resource templates, and prompts;\n- generated catalogs, manifests, README tables, and install instructions;\n- existing protocol, integration, and smoke-test commands.\n\nPrefer repository-native commands. Inspect `package.json`, `pyproject.toml`,\n`Makefile`, CI workflows, and contributor instructions before inventing a test\nharness.\n\n## 2. Start a clean server\n\nBuild the candidate and start the documented entry point with test-safe\nconfiguration. Capture:\n\n- the exact command;\n- commit SHA;\n- environment variable names, with values redacted;\n- stdout, stderr, and exit status;\n- the endpoint or child-process transport used by the client.\n\nFor STDIO, stdout is protocol-only. Logs, banners, and stack traces belong on\nstderr. For HTTP transports, record the status, relevant MCP headers, and\nsession identifier handling without printing credentials.\n\nIf the server cannot start from its documented instructions, report that as a\nrelease failure and preserve the startup error verbatim.\n\n## 3. Exercise one complete session\n\nRun this sequence through a real MCP client or the repository's integration\nharness:\n\n1. `initialize` with a protocol version the server claims to support.\n2. Confirm the negotiated version and advertised capabilities.\n3. Send `notifications\u002Finitialized`.\n4. Call `ping`.\n5. Call each supported discovery method:\n   - `tools\u002Flist`\n   - `resources\u002Flist`\n   - `resources\u002Ftemplates\u002Flist`\n   - `prompts\u002Flist`\n6. Exercise at least one representative read-only item from every advertised\n   capability class.\n7. Follow pagination until no cursor remains when a list method is paginated.\n\nDo not send post-initialization requests through separate one-shot processes.\nThat accidentally tests several incomplete sessions instead of one valid\nsession.\n\n## 4. Prove inventory parity\n\nBuild four inventories from current evidence:\n\n| Surface | Evidence |\n|---|---|\n| Source | Registered tool, resource, template, and prompt definitions |\n| Runtime | Results from the live discovery methods |\n| Generated metadata | Catalogs, manifests, or generated indexes |\n| Documentation | README, reference pages, and install output |\n\nCompare by stable identifier. Report:\n\n- source entries missing at runtime;\n- runtime entries absent from metadata or documentation;\n- stale names, descriptions, arguments, URIs, or prompt parameters;\n- documented install commands that do not start the candidate server.\n\nRegenerate derived files with the repository's own build command, then fail if\nthe working tree still contains unexplained generated changes.\n\n## 5. Check published contracts\n\nFor every discovered item, verify the runtime definition against its source:\n\n### Tools\n\n- Name and description are stable and specific.\n- `inputSchema` defines types, required fields, enums, and bounds where needed.\n- Unknown properties are rejected when the tool contract is closed.\n- Mutation, idempotence, read-only, and open-world annotations match behavior.\n- Successful calls conform to `outputSchema` when one is published.\n- Errors are protocol errors or structured tool failures, not leaked stack\n  traces.\n\n### Resources and templates\n\n- URIs and MIME types match the registered definitions.\n- Static resources are readable.\n- Template parameters are validated before resolution.\n- Missing or forbidden resources fail explicitly.\n\n### Prompts\n\n- Required and optional arguments match discovery output.\n- `prompts\u002Fget` returns usable messages for valid arguments.\n- Missing required arguments and unknown prompt names fail explicitly.\n\n## 6. Test failure paths\n\nAt minimum, probe:\n\n- a request before initialization completes;\n- malformed JSON or an invalid JSON-RPC envelope;\n- an unknown method;\n- an unsupported protocol version;\n- repeated initialization;\n- unknown tool, resource, and prompt names;\n- missing, extra, wrong-type, and out-of-bounds arguments;\n- a request at the documented transport-size limit and one beyond it;\n- a controlled internal failure with credentials and stack traces redacted.\n\nVerify that each response has the correct request ID, a useful error message,\nand no successful side effect. For STDIO, also confirm every stdout line is a\ncomplete protocol message and a healthy session leaves stderr clean unless the\nserver explicitly documents diagnostic output.\n\n## 7. Smoke-test installation\n\nWhen the project publishes an install command:\n\n1. Create a temporary destination outside the source checkout.\n2. Run the public install command exactly as documented.\n3. Start the installed artifact without relying on files from the source tree.\n4. Repeat initialization, discovery, and one read-only invocation.\n5. Remove the temporary destination after preserving the command output.\n\nAn install string that was only inspected is unverified.\n\n## 8. Report the evidence\n\nUse this format:\n\n```markdown\n# MCP Release QA\n\nCandidate: [commit]\nTransport: [STDIO | Streamable HTTP | SSE]\nVerdict: PASS | PASS WITH CAVEATS | FAIL\n\n## Commands and results\n- `[exact command]` — [exit status and result]\n\n## Session transcript\n- initialize: [result]\n- discovery: [result]\n- representative calls: [result]\n- negative paths: [result]\n\n## Parity\n| Identifier | Source | Runtime | Metadata | Docs | Result |\n|---|---|---|---|---|---|\n\n## Findings\n| Severity | Evidence | Impact | Narrowest fix |\n|---|---|---|---|\n\n## Missing evidence\n- [check that could not run and why]\n```\n\nUse `FAIL` for a server that cannot start, complete a valid session, keep the\ntransport parseable, or safely reject invalid input. Use `PASS WITH CAVEATS`\nonly for bounded documentation or metadata drift that does not misrepresent a\ndangerous capability. Otherwise use `PASS`.\n","# MCP Release QA\n\nTest the server that users will run. A schema review or a passing unit test is\nnot runtime evidence.\n\nThis skill complements security review. It focuses on protocol behavior,\npublished-contract drift, transport correctness, and reproducible release\nevidence.\n\n## Rules\n\n- Run checks against a fresh server process built from the candidate revision.\n- Keep `initialize`, `notifications\u002Finitialized`, discovery, and invocation in\n  the same session. A new process is a new STDIO session.\n- Treat source registrations as implementation truth and public documentation\n  as a contract that must match it.\n- Record exact commands and raw responses. Do not replace missing evidence with\n  \"looks correct.\"\n- Do not invoke mutation-capable tools against production data. Use fixtures, a\n  sandbox, or stop and name the missing safe test environment.\n- Derive the expected capability inventory from the candidate source on every\n  run.\n\n## 1. Establish the release surface\n\nIdentify:\n\n- candidate commit and build command;\n- server entry point and transport: STDIO, Streamable HTTP, or SSE;\n- supported MCP protocol versions;\n- source files that register tools, resources, resource templates, and prompts;\n- generated catalogs, manifests, README tables, and install instructions;\n- existing protocol, integration, and smoke-test commands.\n\nPrefer repository-native commands. Inspect `package.json`, `pyproject.toml`,\n`Makefile`, CI workflows, and contributor instructions before inventing a test\nharness.\n\n## 2. Start a clean server\n\nBuild the candidate and start the documented entry point with test-safe\nconfiguration. Capture:\n\n- the exact command;\n- commit SHA;\n- environment variable names, with values redacted;\n- stdout, stderr, and exit status;\n- the endpoint or child-process transport used by the client.\n\nFor STDIO, stdout is protocol-only. Logs, banners, and stack traces belong on\nstderr. For HTTP transports, record the status, relevant MCP headers, and\nsession identifier handling without printing credentials.\n\nIf the server cannot start from its documented instructions, report that as a\nrelease failure and preserve the startup error verbatim.\n\n## 3. Exercise one complete session\n\nRun this sequence through a real MCP client or the repository's integration\nharness:\n\n1. `initialize` with a protocol version the server claims to support.\n2. Confirm the negotiated version and advertised capabilities.\n3. Send `notifications\u002Finitialized`.\n4. Call `ping`.\n5. Call each supported discovery method:\n   - `tools\u002Flist`\n   - `resources\u002Flist`\n   - `resources\u002Ftemplates\u002Flist`\n   - `prompts\u002Flist`\n6. Exercise at least one representative read-only item from every advertised\n   capability class.\n7. Follow pagination until no cursor remains when a list method is paginated.\n\nDo not send post-initialization requests through separate one-shot processes.\nThat accidentally tests several incomplete sessions instead of one valid\nsession.\n\n## 4. Prove inventory parity\n\nBuild four inventories from current evidence:\n\n| Surface | Evidence |\n|---|---|\n| Source | Registered tool, resource, template, and prompt definitions |\n| Runtime | Results from the live discovery methods |\n| Generated metadata | Catalogs, manifests, or generated indexes |\n| Documentation | README, reference pages, and install output |\n\nCompare by stable identifier. Report:\n\n- source entries missing at runtime;\n- runtime entries absent from metadata or documentation;\n- stale names, descriptions, arguments, URIs, or prompt parameters;\n- documented install commands that do not start the candidate server.\n\nRegenerate derived files with the repository's own build command, then fail if\nthe working tree still contains unexplained generated changes.\n\n## 5. Check published contracts\n\nFor every discovered item, verify the runtime definition against its source:\n\n### Tools\n\n- Name and description are stable and specific.\n- `inputSchema` defines types, required fields, enums, and bounds where needed.\n- Unknown properties are rejected when the tool contract is closed.\n- Mutation, idempotence, read-only, and open-world annotations match behavior.\n- Successful calls conform to `outputSchema` when one is published.\n- Errors are protocol errors or structured tool failures, not leaked stack\n  traces.\n\n### Resources and templates\n\n- URIs and MIME types match the registered definitions.\n- Static resources are readable.\n- Template parameters are validated before resolution.\n- Missing or forbidden resources fail explicitly.\n\n### Prompts\n\n- Required and optional arguments match discovery output.\n- `prompts\u002Fget` returns usable messages for valid arguments.\n- Missing required arguments and unknown prompt names fail explicitly.\n\n## 6. Test failure paths\n\nAt minimum, probe:\n\n- a request before initialization completes;\n- malformed JSON or an invalid JSON-RPC envelope;\n- an unknown method;\n- an unsupported protocol version;\n- repeated initialization;\n- unknown tool, resource, and prompt names;\n- missing, extra, wrong-type, and out-of-bounds arguments;\n- a request at the documented transport-size limit and one beyond it;\n- a controlled internal failure with credentials and stack traces redacted.\n\nVerify that each response has the correct request ID, a useful error message,\nand no successful side effect. For STDIO, also confirm every stdout line is a\ncomplete protocol message and a healthy session leaves stderr clean unless the\nserver explicitly documents diagnostic output.\n\n## 7. Smoke-test installation\n\nWhen the project publishes an install command:\n\n1. Create a temporary destination outside the source checkout.\n2. Run the public install command exactly as documented.\n3. Start the installed artifact without relying on files from the source tree.\n4. Repeat initialization, discovery, and one read-only invocation.\n5. Remove the temporary destination after preserving the command output.\n\nAn install string that was only inspected is unverified.\n\n## 8. Report the evidence\n\nUse this format:\n\n```markdown\n# MCP Release QA\n\nCandidate: [commit]\nTransport: [STDIO | Streamable HTTP | SSE]\nVerdict: PASS | PASS WITH CAVEATS | FAIL\n\n## Commands and results\n- `[exact command]` — [exit status and result]\n\n## Session transcript\n- initialize: [result]\n- discovery: [result]\n- representative calls: [result]\n- negative paths: [result]\n\n## Parity\n| Identifier | Source | Runtime | Metadata | Docs | Result |\n|---|---|---|---|---|---|\n\n## Findings\n| Severity | Evidence | Impact | Narrowest fix |\n|---|---|---|---|\n\n## Missing evidence\n- [check that could not run and why]\n```\n\nUse `FAIL` for a server that cannot start, complete a valid session, keep the\ntransport parseable, or safely reject invalid input. Use `PASS WITH CAVEATS`\nonly for bounded documentation or metadata drift that does not misrepresent a\ndangerous capability. Otherwise use `PASS`.\n",{"name":5,"description":7},"main","5269f7ea2d6c3a9bfda5ed878b6726cf509121fd","skills\u002Fmcp-release-qa",5344,"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-13 02:05:36",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add github\u002Fawesome-copilot --skill mcp-release-qa",{"tool":69,"command":70},"bunx","bunx skills add github\u002Fawesome-copilot --skill mcp-release-qa",{"tool":72,"command":73},"pnpm","pnpm dlx skills add github\u002Fawesome-copilot --skill mcp-release-qa","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-release-qa\u002FSKILL.md",true,[],[78,106,133,163,196,213],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":86,"publishedAt":48},"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",[84,85],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[87,88,89,90,91,31,92,93,94,95,96,97,98,99,100,101,102,103,104,105],"supabase","rls","supabase rls","supabase rls policies","project","review","change","read","write","security","isolation","tables","as","tests","prove","use","users","functions","with",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":113,"publishedAt":48},"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",[112],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,28,132],"distribution","skill distribution audit","audit","SET","deterministic","installer","for","discovery","comparison","helper","manifest","version","collection","drift","output","investigate","duplicate","template","reconcile",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":137,"sourceHtmlUrl":138,"categories":139,"keywords":145,"publishedAt":48},"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",[140],{"categoryNo":141,"categoryName":142,"taxonomyType":143,"taxonomyTypeDesc":144},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[146,147,148,149,150,151,120,91,152,153,154,155,156,157,158,102,159,160,161,162],"custom","code","logicapps custom code net10 migration","migration","projects","standalone","deployment","applications","local","azure","worker","upgrades","package","apps","Legacy","debugging","workflows",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":167,"sourceHtmlUrl":168,"categories":169,"keywords":174,"publishedAt":48},"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",[170,173],{"categoryNo":171,"categoryName":172,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":141,"categoryName":142,"taxonomyType":143,"taxonomyTypeDesc":144},[175,176,177,178,179,180,181,182,183,184,185,44,186,187,188,31,189,190,191,192,193,120,194,195],"winmd api search","search","api","windows","desktop","file access","enumeration","ui","ml","file","networking","notifications","explore","access","features","full","camera","events","platform","methods","controls",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":200,"licenseFileUrl":201,"sourceHtmlUrl":202,"categories":203,"keywords":209,"publishedAt":48},"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",[204,205,208],{"categoryNo":171,"categoryName":172,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":206,"categoryName":207,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[210,117,184,211,212],"resemble detect","https","identity",{"skillNo":214,"name":215,"nameZh":6,"description":216,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":200,"licenseFileUrl":217,"sourceHtmlUrl":218,"categories":219,"keywords":224,"publishedAt":48},"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",[220,223],{"categoryNo":221,"categoryName":222,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[225,226,227,228,147,92,9,116,229,230,211,231,232,233,234,235,236,237,238,239,240,241,100,242,243,244,245],"playbook","quality playbook","quality","code review","tdd","run","report","spec","bug report","council","engineering","functional","spec audit","bug","verified","multi-model","three","coverage","model","regression","structural"]