[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ADPTPMDNTA357C4V49E06M":3,"skill-same:01M6ADPTPMDNTA357C4V49E06M":73},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M6ADPTPMDNTA357C4V49E06M","harness-engineering",null,"Adopt repository-level harness engineering for coding agents. Use when a user wants to prevent repeated AI coding-agent mistakes by turning failures into durable instructions, drift checks, regression tests, failure memory, and adoption reports tailored to the target repository.","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\u002Fharness-engineering\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],"harness","engineering","harness engineering","use","when","mistakes","for","tests","adopt","drift","ai coding","reports","Coding-Agent","coding agents","instructions","coding","regression","adoption","repository","memory","2026-11-10 10:12:30",false,"---\nname: harness-engineering\ndescription: 'Adopt repository-level harness engineering for coding agents. Use when a user wants to prevent repeated AI coding-agent mistakes by turning failures into durable instructions, drift checks, regression tests, failure memory, and adoption reports tailored to the target repository.'\n---\n\n# Harness Engineering\n\nHarness engineering turns repeated coding-agent mistakes into durable\nrepository artifacts:\n\n```text\nHarness = Instructions + Constraints + Feedback + Memory + Evaluation + Governance\n```\n\nUse this skill when the user asks to:\n\n- make a repository more reliable for GitHub Copilot or other coding agents\n- add durable agent instructions, repository rules, or guardrails\n- prevent repeated AI coding-agent mistakes\n- record known failure paths and the checks that prevent recurrence\n- add lightweight drift checks for project rules\n- review, refresh, or update an existing agent harness\n\nDo not use this skill for ordinary feature implementation unless the user asks\nto improve the repository's agent operating environment.\n\n## Core Principles\n\n- Treat the target repository as the source of truth.\n- Inspect before editing. Preserve the existing stack, package manager, CI,\n  docs, naming, and architecture.\n- Add the smallest useful harness. Prefer updating existing files over adding\n  duplicate guidance.\n- Make important rules enforceable where practical through tests, linters,\n  type checks, CI, pre-commit hooks, or drift scripts.\n- Use manual review points only when automation would be brittle or misleading.\n- Record high-risk failures that should not recur, and name the check or review\n  point that catches recurrence.\n- Do not copy generic templates blindly. Adapt every artifact to real evidence\n  in the target repository.\n\n## Discovery\n\nBefore proposing or making harness changes, inspect the repository for existing\nrules and evidence.\n\nRead these files and folders when they exist:\n\n- `README.md`\n- `AGENTS.md`\n- `.github\u002Fcopilot-instructions.md`\n- `.github\u002Finstructions\u002F`\n- `.github\u002Fworkflows\u002F`\n- `CONTRIBUTING.md`\n- package manifests such as `package.json`, `pyproject.toml`, `go.mod`,\n  `Cargo.toml`, `pom.xml`, or `build.gradle`\n- existing docs under `docs\u002F`\n- existing scripts under `scripts\u002F`\n- existing tests and CI checks\n\nThen summarize:\n\n- stack, package manager, and entry points\n- existing development and verification commands\n- current agent instructions or repository conventions\n- known failures, incidents, flaky paths, or repeated review comments\n- gaps where project rules are not enforced\n\n## Adoption Workflow\n\nFollow this sequence:\n\n1. Choose the harness surface that fits the target repository.\n2. Write target-specific agent instructions.\n3. Add enforceable checks for high-value rules.\n4. Record failure memory for high-risk or recurring failures.\n5. Add drift checks for guidance that can silently become stale.\n6. Report the adoption with evidence, assumptions, and follow-up.\n\n### 1. Choose the Harness Surface\n\nPick only the surfaces that fit the target repository:\n\n| Need | Preferred artifact |\n| --- | --- |\n| Always-on agent behavior | `AGENTS.md` or `.github\u002Fcopilot-instructions.md` |\n| File-scoped guidance | `.github\u002Finstructions\u002F*.instructions.md` |\n| Recurring project checks | `scripts\u002Fcheck_*.py`, shell scripts, or package scripts |\n| CI enforcement | existing workflow files or a small new workflow |\n| Known failures | `docs\u002Ffailures\u002F*.md` |\n| Architecture or process decisions | `docs\u002Fdecisions\u002F*.md` |\n| Adoption evidence | `docs\u002Fharness\u002Fadoption-report.md` or similar |\n\nIf the repository already has an equivalent location, update it instead of\ncreating a parallel system.\n\n### 2. Write Agent Instructions\n\nAgent instructions should be concrete and operational. Include:\n\n- project purpose and major ownership boundaries\n- setup, test, lint, build, and verification commands\n- package manager and dependency rules\n- safe editing rules, generated file rules, and forbidden paths\n- testing expectations for changed code\n- PR and commit conventions if the repo has them\n- how to record new failures or decisions\n\nAvoid broad personality guidance, generic best practices, and rules that cannot\nbe checked or reviewed.\n\n### 3. Add Enforceable Checks\n\nConvert high-value rules into checks. Good harness checks are:\n\n- narrow enough to avoid false positives\n- fast enough to run locally and in CI\n- named clearly so agents can run them before finishing\n- documented with the rule they protect\n\nExamples:\n\n```text\nRule: Do not edit generated API clients.\nCheck: script scans diffs for generated paths and fails with a clear message.\n\nRule: Every failure memory note names a regression check.\nCheck: script validates docs\u002Ffailures\u002F*.md for a \"Detection\" section.\n\nRule: Profile docs and templates must stay aligned.\nCheck: test compares profile README files to expected template files.\n```\n\n### 4. Record Failure Memory\n\nRecord failures when they are user-visible, high-risk, or likely to recur.\nUse a new file under `docs\u002Ffailures\u002F` unless an existing note already covers\nthe same root cause.\n\nRecommended structure:\n\n```markdown\n# Short Failure Title\n\n## Summary\n\nWhat failed, who saw it, and why it matters.\n\n## Root Cause\n\nThe technical or process cause. Avoid blame.\n\n## Prevention\n\nInstruction, test, drift check, CI gate, fixture, or manual review point that\nprevents or detects recurrence.\n\n## Evidence\n\nLinks to issue, PR, test, log, command output, or file paths.\n```\n\nIf no automated check is practical, record the manual review point and why\nautomation would be unsafe or misleading.\n\n### 5. Add Drift Checks\n\nUse drift checks for guidance that can silently become stale. Common examples:\n\n- docs mention commands that no longer exist\n- profile snippets and generated examples diverge\n- failure notes omit regression checks\n- decision records are missing for structural changes\n- CI references stale scripts or package commands\n\nPrefer small scripts using the repository's existing language. If the repo has\nno scripting convention, Python with only the standard library is a portable\ndefault.\n\n### 6. Report the Adoption\n\nFinish substantial harness work with an adoption report that includes:\n\n- files changed\n- rules added or updated\n- checks added or reused\n- commands run and results\n- assumptions and manual follow-up\n- failure memory created or intentionally skipped\n- how effectiveness will be measured\n\n## Review Workflow\n\nWhen asked to review a harness change, take an opposing perspective. Look for:\n\n- generic rules copied without evidence from the target repository\n- duplicate or conflicting instruction files\n- broad checks that are likely to fail on valid changes\n- unenforced high-risk rules\n- missing failure memory for repeated mistakes or runtime failures\n- generated docs not refreshed after source changes\n- CI gates that do not run the relevant checks\n- target repository conventions being overwritten by harness defaults\n\nReport findings first, ordered by severity, with file and line references when\navailable. Do not modify files during a review unless the user explicitly asks\nfor fixes.\n\n## Output Contract\n\nBefore finishing harness adoption work, verify:\n\n- the target repository was inspected before edits\n- new guidance is specific to the target repository\n- changed checks can be run locally or have a documented manual substitute\n- failure memory was recorded when required, or the final response explains why\n  it was skipped\n- generated docs or indexes are refreshed\n- the final report names every command run and its result\n\n## Optional Reference\n\nThe prompt-first workflow in\n`https:\u002F\u002Fgithub.com\u002Fbaskduf\u002Fharness-starter-kit` is a reference implementation\nof these ideas. Use it as reference material only when the user asks for it or\nwhen the repository already includes it. The target repository remains the\nsource of truth.\n","# Harness Engineering\n\nHarness engineering turns repeated coding-agent mistakes into durable\nrepository artifacts:\n\n```text\nHarness = Instructions + Constraints + Feedback + Memory + Evaluation + Governance\n```\n\nUse this skill when the user asks to:\n\n- make a repository more reliable for GitHub Copilot or other coding agents\n- add durable agent instructions, repository rules, or guardrails\n- prevent repeated AI coding-agent mistakes\n- record known failure paths and the checks that prevent recurrence\n- add lightweight drift checks for project rules\n- review, refresh, or update an existing agent harness\n\nDo not use this skill for ordinary feature implementation unless the user asks\nto improve the repository's agent operating environment.\n\n## Core Principles\n\n- Treat the target repository as the source of truth.\n- Inspect before editing. Preserve the existing stack, package manager, CI,\n  docs, naming, and architecture.\n- Add the smallest useful harness. Prefer updating existing files over adding\n  duplicate guidance.\n- Make important rules enforceable where practical through tests, linters,\n  type checks, CI, pre-commit hooks, or drift scripts.\n- Use manual review points only when automation would be brittle or misleading.\n- Record high-risk failures that should not recur, and name the check or review\n  point that catches recurrence.\n- Do not copy generic templates blindly. Adapt every artifact to real evidence\n  in the target repository.\n\n## Discovery\n\nBefore proposing or making harness changes, inspect the repository for existing\nrules and evidence.\n\nRead these files and folders when they exist:\n\n- `README.md`\n- `AGENTS.md`\n- `.github\u002Fcopilot-instructions.md`\n- `.github\u002Finstructions\u002F`\n- `.github\u002Fworkflows\u002F`\n- `CONTRIBUTING.md`\n- package manifests such as `package.json`, `pyproject.toml`, `go.mod`,\n  `Cargo.toml`, `pom.xml`, or `build.gradle`\n- existing docs under `docs\u002F`\n- existing scripts under `scripts\u002F`\n- existing tests and CI checks\n\nThen summarize:\n\n- stack, package manager, and entry points\n- existing development and verification commands\n- current agent instructions or repository conventions\n- known failures, incidents, flaky paths, or repeated review comments\n- gaps where project rules are not enforced\n\n## Adoption Workflow\n\nFollow this sequence:\n\n1. Choose the harness surface that fits the target repository.\n2. Write target-specific agent instructions.\n3. Add enforceable checks for high-value rules.\n4. Record failure memory for high-risk or recurring failures.\n5. Add drift checks for guidance that can silently become stale.\n6. Report the adoption with evidence, assumptions, and follow-up.\n\n### 1. Choose the Harness Surface\n\nPick only the surfaces that fit the target repository:\n\n| Need | Preferred artifact |\n| --- | --- |\n| Always-on agent behavior | `AGENTS.md` or `.github\u002Fcopilot-instructions.md` |\n| File-scoped guidance | `.github\u002Finstructions\u002F*.instructions.md` |\n| Recurring project checks | `scripts\u002Fcheck_*.py`, shell scripts, or package scripts |\n| CI enforcement | existing workflow files or a small new workflow |\n| Known failures | `docs\u002Ffailures\u002F*.md` |\n| Architecture or process decisions | `docs\u002Fdecisions\u002F*.md` |\n| Adoption evidence | `docs\u002Fharness\u002Fadoption-report.md` or similar |\n\nIf the repository already has an equivalent location, update it instead of\ncreating a parallel system.\n\n### 2. Write Agent Instructions\n\nAgent instructions should be concrete and operational. Include:\n\n- project purpose and major ownership boundaries\n- setup, test, lint, build, and verification commands\n- package manager and dependency rules\n- safe editing rules, generated file rules, and forbidden paths\n- testing expectations for changed code\n- PR and commit conventions if the repo has them\n- how to record new failures or decisions\n\nAvoid broad personality guidance, generic best practices, and rules that cannot\nbe checked or reviewed.\n\n### 3. Add Enforceable Checks\n\nConvert high-value rules into checks. Good harness checks are:\n\n- narrow enough to avoid false positives\n- fast enough to run locally and in CI\n- named clearly so agents can run them before finishing\n- documented with the rule they protect\n\nExamples:\n\n```text\nRule: Do not edit generated API clients.\nCheck: script scans diffs for generated paths and fails with a clear message.\n\nRule: Every failure memory note names a regression check.\nCheck: script validates docs\u002Ffailures\u002F*.md for a \"Detection\" section.\n\nRule: Profile docs and templates must stay aligned.\nCheck: test compares profile README files to expected template files.\n```\n\n### 4. Record Failure Memory\n\nRecord failures when they are user-visible, high-risk, or likely to recur.\nUse a new file under `docs\u002Ffailures\u002F` unless an existing note already covers\nthe same root cause.\n\nRecommended structure:\n\n```markdown\n# Short Failure Title\n\n## Summary\n\nWhat failed, who saw it, and why it matters.\n\n## Root Cause\n\nThe technical or process cause. Avoid blame.\n\n## Prevention\n\nInstruction, test, drift check, CI gate, fixture, or manual review point that\nprevents or detects recurrence.\n\n## Evidence\n\nLinks to issue, PR, test, log, command output, or file paths.\n```\n\nIf no automated check is practical, record the manual review point and why\nautomation would be unsafe or misleading.\n\n### 5. Add Drift Checks\n\nUse drift checks for guidance that can silently become stale. Common examples:\n\n- docs mention commands that no longer exist\n- profile snippets and generated examples diverge\n- failure notes omit regression checks\n- decision records are missing for structural changes\n- CI references stale scripts or package commands\n\nPrefer small scripts using the repository's existing language. If the repo has\nno scripting convention, Python with only the standard library is a portable\ndefault.\n\n### 6. Report the Adoption\n\nFinish substantial harness work with an adoption report that includes:\n\n- files changed\n- rules added or updated\n- checks added or reused\n- commands run and results\n- assumptions and manual follow-up\n- failure memory created or intentionally skipped\n- how effectiveness will be measured\n\n## Review Workflow\n\nWhen asked to review a harness change, take an opposing perspective. Look for:\n\n- generic rules copied without evidence from the target repository\n- duplicate or conflicting instruction files\n- broad checks that are likely to fail on valid changes\n- unenforced high-risk rules\n- missing failure memory for repeated mistakes or runtime failures\n- generated docs not refreshed after source changes\n- CI gates that do not run the relevant checks\n- target repository conventions being overwritten by harness defaults\n\nReport findings first, ordered by severity, with file and line references when\navailable. Do not modify files during a review unless the user explicitly asks\nfor fixes.\n\n## Output Contract\n\nBefore finishing harness adoption work, verify:\n\n- the target repository was inspected before edits\n- new guidance is specific to the target repository\n- changed checks can be run locally or have a documented manual substitute\n- failure memory was recorded when required, or the final response explains why\n  it was skipped\n- generated docs or indexes are refreshed\n- the final report names every command run and its result\n\n## Optional Reference\n\nThe prompt-first workflow in\n`https:\u002F\u002Fgithub.com\u002Fbaskduf\u002Fharness-starter-kit` is a reference implementation\nof these ideas. Use it as reference material only when the user asks for it or\nwhen the repository already includes it. The target repository remains the\nsource of truth.\n",{"name":5,"description":7},"main","5269f7ea2d6c3a9bfda5ed878b6726cf509121fd","skills\u002Fharness-engineering",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":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add github\u002Fawesome-copilot --skill harness-engineering",{"tool":65,"command":66},"bunx","bunx skills add github\u002Fawesome-copilot --skill harness-engineering",{"tool":68,"command":69},"pnpm","pnpm dlx skills add github\u002Fawesome-copilot --skill harness-engineering","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fharness-engineering\u002FSKILL.md",true,[],[74,102,128,158,192,209],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":84,"publishedAt":44},"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",[80,83],{"categoryNo":81,"categoryName":82,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[85,86,87,88,89,28,90,91,92,93,94,95,96,97,31,98,27,99,100,101],"supabase","rls","supabase rls","supabase rls policies","project","review","change","read","write","security","isolation","tables","as","prove","users","functions","with",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":109,"publishedAt":44},"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",[108],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[110,111,112,113,114,115,30,116,117,118,119,120,121,33,122,123,124,125,126,127],"distribution","skill distribution audit","audit","SET","deterministic","installer","discovery","comparison","helper","manifest","version","collection","output","investigate","duplicate","template","release","reconcile",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":132,"sourceHtmlUrl":133,"categories":134,"keywords":140,"publishedAt":44},"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",[135],{"categoryNo":136,"categoryName":137,"taxonomyType":138,"taxonomyTypeDesc":139},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[141,142,143,144,145,146,30,89,147,148,149,150,151,152,153,27,154,155,156,157],"custom","code","logicapps custom code net10 migration","migration","projects","standalone","deployment","applications","local","azure","worker","upgrades","package","apps","Legacy","debugging","workflows",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":162,"sourceHtmlUrl":163,"categories":164,"keywords":169,"publishedAt":44},"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",[165,168],{"categoryNo":166,"categoryName":167,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":136,"categoryName":137,"taxonomyType":138,"taxonomyTypeDesc":139},[170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,28,185,186,187,188,189,30,190,191],"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":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":196,"licenseFileUrl":197,"sourceHtmlUrl":198,"categories":199,"keywords":205,"publishedAt":44},"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",[200,201,204],{"categoryNo":166,"categoryName":167,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":202,"categoryName":203,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[206,113,179,207,208],"resemble detect","https","identity",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":196,"licenseFileUrl":213,"sourceHtmlUrl":214,"categories":215,"keywords":220,"publishedAt":44},"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",[216,219],{"categoryNo":217,"categoryName":218,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[221,222,223,224,142,90,9,112,225,226,207,227,228,229,230,25,231,232,233,234,235,236,31,237,238,40,239],"playbook","quality playbook","quality","code review","tdd","run","report","spec","bug report","council","functional","spec audit","bug","verified","multi-model","three","coverage","model","structural"]