[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AE0PR2MR9WXC4FX4AY8XZD":3,"skill-same:01M6AE0PR2MR9WXC4FX4AY8XZD":93},{"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":31,"publishedAt":54,"linkOnly":55,"markdownContent":56,"markdownBody":57,"frontMatter":58,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":64,"ownerHtmlUrl":65,"ownerBlogUrl":66,"ownerDescription":67,"updatedAt":68,"install":69,"resources":82},"01M6AE0PR2MR9WXC4FX4AY8XZD","protobuf-grpc-api-review",null,"Review Protocol Buffer (.proto) and gRPC API changes for wire and JSON compatibility, safe schema evolution, rollout hazards, and RPC contract quality. Use when reviewing proto diffs, adding or changing messages and services, planning migrations, or diagnosing cross-version failures.","github\u002Fawesome-copilot","github","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F9919?v=4","01M6AC83DS133TPXFSP1DHNCC6","GitHub","01M6AD3PBDYPK7NVFJNJ66Y8RS",41028,"MIT","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fprotobuf-grpc-api-review\u002FSKILL.md",[18,23,28],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53],"api review","protobuf","grpc","review","protobuf grpc api review","api","services","when","for","buffer","contract","compatibility","schema","rollout","use","messages","rpc","protocol","planning","api changes","safe","diffs","2026-11-10 10:12:30",false,"---\nname: protobuf-grpc-api-review\ndescription: 'Review Protocol Buffer (.proto) and gRPC API changes for wire and JSON compatibility, safe schema evolution, rollout hazards, and RPC contract quality. Use when reviewing proto diffs, adding or changing messages and services, planning migrations, or diagnosing cross-version failures.'\n---\n\n# Protobuf and gRPC API Review\n\nReview `.proto` and related gRPC changes as long-lived contracts. Distinguish what the wire format permits from what generated clients, JSON users, stored data, and mixed-version deployments can safely tolerate.\n\n## Start With the Compatibility Envelope\n\nBefore deciding whether a change is safe, determine:\n\n- the old and new schema, not only the final file\n- whether payloads use binary protobuf, ProtoJSON, text format, or more than one encoding\n- whether messages persist in databases, queues, logs, caches, or events\n- whether clients exist outside the repository or release independently\n- the protobuf syntax or edition and the generated languages\u002Fruntime versions\n- whether HTTP\u002FJSON transcoding, reflection, service config, or schema registries expose the contract\n- the deployment order, rollback window, and duration of mixed-version operation\n\nIf context is missing, state the assumption and lower confidence. Do not call a change backward-compatible from the new schema alone.\n\n## Review Workflow\n\n### 1. Inventory Contract Changes\n\nCompare the old and new definitions by fully qualified symbol. Record:\n\n- message fields: number, name, type, cardinality, presence, `oneof`, defaults, and relevant options\n- enums: value name, number, aliases, reservations, and zero value\n- services: package, service, method, request and response types, and streaming mode\n- generated API inputs: package options, outer class names, namespaces, and custom options\n\nIgnore formatting-only changes after confirming they do not alter descriptors or generated APIs.\n\n### 2. Evaluate Four Compatibility Dimensions\n\nAssess each affected symbol independently:\n\n1. **Binary wire** — can old and new readers parse both old and new bytes without corruption or loss?\n2. **Named formats** — do ProtoJSON, text-format, REST-transcoded, or name-based consumers still work?\n3. **Source and generated API** — will regenerated clients compile and preserve presence, enum, and accessor behavior?\n4. **Behavior and operations** — do status codes, retry safety, deadlines, authorization, streaming, and resource bounds preserve the RPC contract?\n\nRead [protobuf compatibility rules](references\u002Fprotobuf-compatibility.md) for field, enum, presence, `oneof`, and serialization changes. Read [gRPC contract review](references\u002Fgrpc-contract-review.md) when services, methods, or runtime behavior change.\n\n### 3. Trace Mixed-Version Scenarios\n\nFor every non-trivial change, reason through these paths:\n\n- old writer -> new reader\n- new writer -> old reader\n- old reader modifies and reserializes a new message\n- rollback after new writers have emitted new values\n- persisted old data read after the migration\n\nFor conditionally compatible changes, identify the exact writer constraint and the point at which it may be relaxed. A safe rollout commonly requires deploying readers before writers and retaining the old field or method until rollback is no longer needed.\n\n### 4. Review Repository Evidence\n\nUse the repository's own tooling when available:\n\n- compile descriptors with the project's `protoc`, Buf, Gradle, Maven, Bazel, or language-specific task\n- run configured breaking-change or lint checks\n- inspect generated-code diffs only when they are committed by repository convention\n- search call sites for exhaustive enum switches, presence assumptions, JSON field names, method paths, status handling, and retry configuration\n- look for compatibility fixtures or descriptor baselines before proposing a new mechanism\n\nDo not claim a check passed unless you ran it. If a required tool or baseline is unavailable, name the unverified risk.\n\n### 5. Produce an Actionable Review\n\nLead with one verdict:\n\n- **Compatible** — safe within the stated compatibility envelope\n- **Rollout-dependent** — parseable, but safe only with explicit sequencing or value constraints\n- **Breaking** — causes wire, named-format, source, or behavioral incompatibility\n- **Insufficient context** — the old schema, encoding, consumers, or deployment model is unknown\n\nThen provide only evidence-backed findings. For each finding include:\n\n```text\n[severity] Short title\nLocation: file and symbol or changed lines\nDimension: binary | JSON\u002Ftext | source | behavior\u002Foperations\nChange: old contract -> new contract\nImpact: concrete failing mixed-version scenario\nRemediation: smallest safe schema change or staged migration\n```\n\nUse **blocker** for corruption, unparsable data, tag reuse, or an unavoidable production break; **high** for likely cross-version data loss or unsafe RPC behavior; **medium** for bounded compatibility or operability risks; and **low** for maintainability issues that do not break the contract. Do not inflate style preferences into compatibility findings.\n\nConclude with:\n\n- a compact compatibility matrix for changed symbols\n- the rollout\u002Frollback sequence if migration is required\n- targeted tests that would prove the remaining assumptions\n\n## Default Safety Principles\n\n- Never reuse a field or enum number, even after deletion; reserve deleted numbers and usually names.\n- Treat field-number changes and moving fields into an existing `oneof` as breaking.\n- Treat type and cardinality changes as migrations, even when their binary wire types are compatible.\n- Remember that adding a field or enum value can still break generated code or exhaustive consumers.\n- Review ProtoJSON separately: names and unknown-field behavior make its compatibility envelope narrower than binary protobuf.\n- Preserve unknown fields through read-modify-write paths when forward compatibility depends on them.\n- Prefer additive evolution: add a new field or RPC, migrate readers and writers, deprecate the old contract, then remove it only after the compatibility window closes.\n- Never recommend retries for a state-changing RPC without establishing idempotency or a deduplication mechanism.\n- Require realistic client deadlines and cancellation-aware server work for production RPCs.\n\n## Avoid False Positives\n\n- Do not require every service to use streaming, retries, health checks, or HTTP transcoding.\n- Do not flag a new optional field as breaking solely because old clients ignore it.\n- Do not call a wire-compatible type change safe without checking value ranges and rollout order.\n- Do not assume a renamed field is harmless when JSON, text format, reflection, or generated source APIs are consumers.\n- Do not demand reservations for fields that never shipped; ask for release history when that distinction matters.\n","# Protobuf and gRPC API Review\n\nReview `.proto` and related gRPC changes as long-lived contracts. Distinguish what the wire format permits from what generated clients, JSON users, stored data, and mixed-version deployments can safely tolerate.\n\n## Start With the Compatibility Envelope\n\nBefore deciding whether a change is safe, determine:\n\n- the old and new schema, not only the final file\n- whether payloads use binary protobuf, ProtoJSON, text format, or more than one encoding\n- whether messages persist in databases, queues, logs, caches, or events\n- whether clients exist outside the repository or release independently\n- the protobuf syntax or edition and the generated languages\u002Fruntime versions\n- whether HTTP\u002FJSON transcoding, reflection, service config, or schema registries expose the contract\n- the deployment order, rollback window, and duration of mixed-version operation\n\nIf context is missing, state the assumption and lower confidence. Do not call a change backward-compatible from the new schema alone.\n\n## Review Workflow\n\n### 1. Inventory Contract Changes\n\nCompare the old and new definitions by fully qualified symbol. Record:\n\n- message fields: number, name, type, cardinality, presence, `oneof`, defaults, and relevant options\n- enums: value name, number, aliases, reservations, and zero value\n- services: package, service, method, request and response types, and streaming mode\n- generated API inputs: package options, outer class names, namespaces, and custom options\n\nIgnore formatting-only changes after confirming they do not alter descriptors or generated APIs.\n\n### 2. Evaluate Four Compatibility Dimensions\n\nAssess each affected symbol independently:\n\n1. **Binary wire** — can old and new readers parse both old and new bytes without corruption or loss?\n2. **Named formats** — do ProtoJSON, text-format, REST-transcoded, or name-based consumers still work?\n3. **Source and generated API** — will regenerated clients compile and preserve presence, enum, and accessor behavior?\n4. **Behavior and operations** — do status codes, retry safety, deadlines, authorization, streaming, and resource bounds preserve the RPC contract?\n\nRead [protobuf compatibility rules](references\u002Fprotobuf-compatibility.md) for field, enum, presence, `oneof`, and serialization changes. Read [gRPC contract review](references\u002Fgrpc-contract-review.md) when services, methods, or runtime behavior change.\n\n### 3. Trace Mixed-Version Scenarios\n\nFor every non-trivial change, reason through these paths:\n\n- old writer -> new reader\n- new writer -> old reader\n- old reader modifies and reserializes a new message\n- rollback after new writers have emitted new values\n- persisted old data read after the migration\n\nFor conditionally compatible changes, identify the exact writer constraint and the point at which it may be relaxed. A safe rollout commonly requires deploying readers before writers and retaining the old field or method until rollback is no longer needed.\n\n### 4. Review Repository Evidence\n\nUse the repository's own tooling when available:\n\n- compile descriptors with the project's `protoc`, Buf, Gradle, Maven, Bazel, or language-specific task\n- run configured breaking-change or lint checks\n- inspect generated-code diffs only when they are committed by repository convention\n- search call sites for exhaustive enum switches, presence assumptions, JSON field names, method paths, status handling, and retry configuration\n- look for compatibility fixtures or descriptor baselines before proposing a new mechanism\n\nDo not claim a check passed unless you ran it. If a required tool or baseline is unavailable, name the unverified risk.\n\n### 5. Produce an Actionable Review\n\nLead with one verdict:\n\n- **Compatible** — safe within the stated compatibility envelope\n- **Rollout-dependent** — parseable, but safe only with explicit sequencing or value constraints\n- **Breaking** — causes wire, named-format, source, or behavioral incompatibility\n- **Insufficient context** — the old schema, encoding, consumers, or deployment model is unknown\n\nThen provide only evidence-backed findings. For each finding include:\n\n```text\n[severity] Short title\nLocation: file and symbol or changed lines\nDimension: binary | JSON\u002Ftext | source | behavior\u002Foperations\nChange: old contract -> new contract\nImpact: concrete failing mixed-version scenario\nRemediation: smallest safe schema change or staged migration\n```\n\nUse **blocker** for corruption, unparsable data, tag reuse, or an unavoidable production break; **high** for likely cross-version data loss or unsafe RPC behavior; **medium** for bounded compatibility or operability risks; and **low** for maintainability issues that do not break the contract. Do not inflate style preferences into compatibility findings.\n\nConclude with:\n\n- a compact compatibility matrix for changed symbols\n- the rollout\u002Frollback sequence if migration is required\n- targeted tests that would prove the remaining assumptions\n\n## Default Safety Principles\n\n- Never reuse a field or enum number, even after deletion; reserve deleted numbers and usually names.\n- Treat field-number changes and moving fields into an existing `oneof` as breaking.\n- Treat type and cardinality changes as migrations, even when their binary wire types are compatible.\n- Remember that adding a field or enum value can still break generated code or exhaustive consumers.\n- Review ProtoJSON separately: names and unknown-field behavior make its compatibility envelope narrower than binary protobuf.\n- Preserve unknown fields through read-modify-write paths when forward compatibility depends on them.\n- Prefer additive evolution: add a new field or RPC, migrate readers and writers, deprecate the old contract, then remove it only after the compatibility window closes.\n- Never recommend retries for a state-changing RPC without establishing idempotency or a deduplication mechanism.\n- Require realistic client deadlines and cancellation-aware server work for production RPCs.\n\n## Avoid False Positives\n\n- Do not require every service to use streaming, retries, health checks, or HTTP transcoding.\n- Do not flag a new optional field as breaking solely because old clients ignore it.\n- Do not call a wire-compatible type change safe without checking value ranges and rollout order.\n- Do not assume a renamed field is harmless when JSON, text format, reflection, or generated source APIs are consumers.\n- Do not demand reservations for fields that never shipped; ask for release history when that distinction matters.\n",{"name":5,"description":7},"main","5269f7ea2d6c3a9bfda5ed878b6726cf509121fd","skills\u002Fprotobuf-grpc-api-review",5335,"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 11:59:04",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add github\u002Fawesome-copilot --skill protobuf-grpc-api-review",{"tool":75,"command":76},"bunx","bunx skills add github\u002Fawesome-copilot --skill protobuf-grpc-api-review",{"tool":78,"command":79},"pnpm","pnpm dlx skills add github\u002Fawesome-copilot --skill protobuf-grpc-api-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fprotobuf-grpc-api-review\u002FSKILL.md",true,[83,89],{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fgrpc-contract-review.md","REFERENCE","参考文档",5747,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fprotobuf-grpc-api-review\u002Freferences\u002Fgrpc-contract-review.md",{"path":90,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fprotobuf-compatibility.md",6525,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fprotobuf-grpc-api-review\u002Freferences\u002Fprotobuf-compatibility.md",[94,124,151,177,208,225],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":106,"publishedAt":54},"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",[100,103],{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[107,108,109,110,111,39,35,112,113,114,115,116,117,118,119,120,46,121,122,123],"supabase","rls","supabase rls","supabase rls policies","project","change","read","write","security","isolation","tables","as","tests","prove","users","functions","with",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":131,"publishedAt":54},"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",[130],{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},[132,133,134,135,136,137,40,138,139,140,141,142,143,144,145,146,147,148,149,150],"distribution","skill distribution audit","audit","SET","deterministic","installer","discovery","comparison","helper","manifest","version","collection","drift","output","investigate","duplicate","template","release","reconcile",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":155,"sourceHtmlUrl":156,"categories":157,"keywords":159,"publishedAt":54},"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",[158],{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[160,161,162,163,164,165,40,111,166,167,168,169,170,171,172,46,173,174,175,176],"custom","code","logicapps custom code net10 migration","migration","projects","standalone","deployment","applications","local","azure","worker","upgrades","package","apps","Legacy","debugging","workflows",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":181,"sourceHtmlUrl":182,"categories":183,"keywords":186,"publishedAt":54},"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",[184,185],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[187,188,37,189,190,191,192,193,194,195,196,197,198,199,200,39,201,202,203,204,205,40,206,207],"winmd api search","search","windows","desktop","file access","enumeration","ui","ml","file","networking","capabilities","notifications","explore","access","features","full","camera","events","platform","methods","controls",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":212,"licenseFileUrl":213,"sourceHtmlUrl":214,"categories":215,"keywords":221,"publishedAt":54},"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",[216,217,220],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":218,"categoryName":219,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},[222,135,195,223,224],"resemble detect","https","identity",{"skillNo":226,"name":227,"nameZh":6,"description":228,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":212,"licenseFileUrl":229,"sourceHtmlUrl":230,"categories":231,"keywords":236,"publishedAt":54},"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",[232,235],{"categoryNo":233,"categoryName":234,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},[237,238,239,240,161,35,9,134,241,242,223,243,244,245,246,247,248,249,250,251,252,253,119,254,255,256,257],"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"]