[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AD858ZM2XH3ERCYEV07BH4":3,"skill-same:01M6AD858ZM2XH3ERCYEV07BH4":104},{"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":28,"publishedAt":53,"linkOnly":54,"markdownContent":55,"markdownBody":56,"frontMatter":57,"refName":58,"commitSha":59,"skillDirectory":60,"forksCount":61,"repositoryHtmlUrl":62,"repositoryHomepageUrl":63,"ownerHtmlUrl":64,"ownerBlogUrl":65,"ownerDescription":66,"updatedAt":67,"install":68,"resources":81},"01M6AD858ZM2XH3ERCYEV07BH4","azure-developer-cli",null,"Design, create, review, migrate, or troubleshoot Azure Developer CLI (azd) projects using current Microsoft guidance. Use for azd, azure.yaml, AZD templates, Bicep or Terraform under infra, AZD environments and secrets, hooks, deployment workflows, and azd-managed CI\u002FCD.","github\u002Fawesome-copilot","github","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F9919?v=4","01M6AC83DS133TPXFSP1DHNCC6","GitHub","01M6AD3PBDYPK7NVFJNJ66Y8RS",41133,"MIT","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fazure-developer-cli\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52],"cli","azure","azure developer cli","developer","yaml","managed","for","environments","CI\u002FCD","infra","hooks","projects","migrate","secrets","ci","design","bicep","terraform","create","deployment","workflows","microsoft","troubleshoot","review","2026-11-10 10:12:30",false,"---\nname: azure-developer-cli\ndescription: 'Design, create, review, migrate, or troubleshoot Azure Developer CLI (azd) projects using current Microsoft guidance. Use for azd, azure.yaml, AZD templates, Bicep or Terraform under infra, AZD environments and secrets, hooks, deployment workflows, and azd-managed CI\u002FCD.'\nlicense: MIT\n---\n\n# Azure Developer CLI best practices\n\nUse this skill to produce maintainable, secure, environment-aware `azd` projects. Prefer repository conventions when they are already coherent, and make the smallest complete change that improves the project.\n\n## Start with repository discovery\n\nBefore editing:\n\n1. Find `azure.yaml`, the configured `infra.path`, source projects, deployment scripts, `.gitignore`, and pipeline definitions.\n2. Read `azure.yaml` before inferring services or the IaC provider.\n3. Identify whether the task is to create, migrate, review, deploy, or troubleshoot.\n4. Identify the active environment only when an environment-specific operation is required.\n5. Read the relevant reference:\n   - Repository layout or `azure.yaml`: [references\u002Fproject-structure.md](references\u002Fproject-structure.md)\n   - Bicep, Terraform, parameters, outputs, or environments: [references\u002Fiac-and-environments.md](references\u002Fiac-and-environments.md)\n   - Secrets, hooks, CI\u002FCD, deployment, or troubleshooting: [references\u002Fsecurity-cicd-operations.md](references\u002Fsecurity-cicd-operations.md)\n   - Product details that may have changed: [references\u002Fofficial-docs.md](references\u002Fofficial-docs.md)\n\nDo not assume the default `infra` path, the default Bicep provider, or a single service when `azure.yaml` says otherwise.\n\n## Apply safety guardrails\n\n- Never commit `.azure`, environment `.env` files, credentials, deployment outputs containing secrets, local Terraform state, or generated deployment artifacts.\n- Never put literal secrets in `azure.yaml`, IaC parameter files, hooks, source control, command arguments that will be logged, or IaC outputs.\n- Prefer managed identities and RBAC. Use Key Vault references and `azd env set-secret` when a secret is unavoidable.\n- Before a command that can create, modify, or delete Azure resources, confirm the target environment, subscription, tenant, region, and expected scope.\n- Treat an explicit user request to deploy, provision, destroy, or configure a pipeline as approval for that named action. Otherwise, ask before running `azd up`, `azd provision`, `azd deploy`, `azd down`, or `azd pipeline config`.\n- Do not replace Bicep with Terraform, Terraform with Bicep, or an established hosting service unless the user requests that architectural change.\n- Preserve resources and state owned outside the current `azd` project.\n\n## Use these defaults\n\n| Concern | Preferred default |\n| --- | --- |\n| Project manifest | One `azure.yaml` at the repository root |\n| Application code | `src\u002F\u003Cservice-name>` per independently deployable service |\n| Infrastructure | `infra` with a thin entry point and reusable modules |\n| IaC provider | Bicep unless the repository or user chooses Terraform |\n| Deployment environments | Separate named environments for dev, test, staging, and production |\n| Local AZD state | `.azure\u002F\u003Cenvironment-name>` and excluded from source control |\n| Shared environment state | AZD remote environments backed by Azure Blob Storage |\n| Secrets | Managed identity\u002FRBAC first, then Key Vault references |\n| Automation scripts | Short, idempotent scripts under `scripts\u002Fazd` |\n| CI authentication | Workload identity federation\u002FOIDC where supported |\n| Routine development | `azd up` for simple workflows; separate phases for controlled workflows |\n\n## Implementation workflow\n\n### 1. Model the application\n\n- Define one `services` entry for each independently deployable component.\n- Keep service keys stable because they participate in resource discovery and deployment.\n- Map each service to its actual `project`, `language`, and `host`.\n- Keep shared infrastructure in IaC rather than inventing a fake deployable service.\n- Declare dependencies with supported `azure.yaml` fields instead of relying on file order.\n\n### 2. Model infrastructure\n\n- Keep `main.bicep` or `main.tf` as the orchestration entry point.\n- Split reusable or independently understandable infrastructure into modules.\n- Parameterize environment-specific values; do not fork the IaC tree per environment.\n- Output only stable, nonsecret values required by deployment or application configuration.\n- Use deterministic naming and consistent tags that include the project and environment.\n- Add role assignments to identities rather than distributing service keys.\n- Use infrastructure layers only when separate scopes or lifecycle dependencies justify them.\n\n### 3. Model environments\n\n- Use predictable names such as `\u003Cproject>-dev` for shared environments and `\u003Calias>-dev` for personal environments.\n- Use `azd env set`, `azd env unset`, and `azd env set-secret` rather than editing `.env` directly.\n- Use `-e` or `--environment` in scripts and automation so the target is explicit.\n- Use `azd env refresh` to synchronize deployment outputs after another actor changes an environment.\n- Configure AZD remote state when a team shares environment state.\n\n### 4. Add hooks only for lifecycle gaps\n\n- Prefer declarative IaC and native service configuration over hooks.\n- Use root hooks for project-wide behavior and service hooks for service-specific behavior.\n- Keep nontrivial hook logic in versioned scripts under `scripts\u002Fazd`.\n- Set `shell` explicitly. Provide `windows` and `posix` variants when necessary.\n- Make hooks idempotent, noninteractive in CI, and fail on errors unless failure is intentionally nonblocking.\n- Test a hook independently with `azd hooks run \u003Chook-name>`.\n\n### 5. Build CI\u002FCD deliberately\n\n- Keep the pipeline definition with the template and review generated changes from `azd pipeline config`.\n- Use short-lived federated credentials where the provider supports them.\n- Run tests and IaC validation before provisioning.\n- Use explicit environments and `--no-prompt` in automation.\n- Add protected production environments and approval gates.\n- For Terraform, configure protected remote state before pipeline setup and account for current AZD authentication limitations.\n\n## Validate before finishing\n\nRun only checks applicable to the repository:\n\n```text\nApplication: existing formatter, linter, type-check, build, and tests\nBicep:      az bicep build --file infra\u002Fmain.bicep\nTerraform:  terraform fmt -check -recursive\n            terraform init -backend=false\n            terraform validate\nAZD hooks:  azd hooks run \u003Chook-name>\nPackaging:  azd package\n```\n\nFor a Bicep what-if or Terraform plan, choose the correct deployment scope and environment. These checks can authenticate to Azure or read remote state, so follow the safety guardrails.\n\nVerify that:\n\n- `azure.yaml` paths exist and service settings match the source projects.\n- The IaC entry point and provider agree with `azure.yaml`.\n- Required deployment outputs match the variables consumed by services, hooks, and pipelines.\n- `.gitignore` excludes `.azure`, secrets, local state, and generated artifacts.\n- No secret appears in tracked content or command output.\n- Documentation explains prerequisites, environment creation, deployment, verification, and cleanup.\n\n## Report the result\n\nState:\n\n- The files and behavior changed.\n- The IaC provider and environment assumptions.\n- The checks performed.\n- Any cloud-changing command deliberately not run.\n- Any beta or preview feature the solution relies on.\n\nDo not claim deployment success unless the target environment was actually deployed and verified.\n","# Azure Developer CLI best practices\n\nUse this skill to produce maintainable, secure, environment-aware `azd` projects. Prefer repository conventions when they are already coherent, and make the smallest complete change that improves the project.\n\n## Start with repository discovery\n\nBefore editing:\n\n1. Find `azure.yaml`, the configured `infra.path`, source projects, deployment scripts, `.gitignore`, and pipeline definitions.\n2. Read `azure.yaml` before inferring services or the IaC provider.\n3. Identify whether the task is to create, migrate, review, deploy, or troubleshoot.\n4. Identify the active environment only when an environment-specific operation is required.\n5. Read the relevant reference:\n   - Repository layout or `azure.yaml`: [references\u002Fproject-structure.md](references\u002Fproject-structure.md)\n   - Bicep, Terraform, parameters, outputs, or environments: [references\u002Fiac-and-environments.md](references\u002Fiac-and-environments.md)\n   - Secrets, hooks, CI\u002FCD, deployment, or troubleshooting: [references\u002Fsecurity-cicd-operations.md](references\u002Fsecurity-cicd-operations.md)\n   - Product details that may have changed: [references\u002Fofficial-docs.md](references\u002Fofficial-docs.md)\n\nDo not assume the default `infra` path, the default Bicep provider, or a single service when `azure.yaml` says otherwise.\n\n## Apply safety guardrails\n\n- Never commit `.azure`, environment `.env` files, credentials, deployment outputs containing secrets, local Terraform state, or generated deployment artifacts.\n- Never put literal secrets in `azure.yaml`, IaC parameter files, hooks, source control, command arguments that will be logged, or IaC outputs.\n- Prefer managed identities and RBAC. Use Key Vault references and `azd env set-secret` when a secret is unavoidable.\n- Before a command that can create, modify, or delete Azure resources, confirm the target environment, subscription, tenant, region, and expected scope.\n- Treat an explicit user request to deploy, provision, destroy, or configure a pipeline as approval for that named action. Otherwise, ask before running `azd up`, `azd provision`, `azd deploy`, `azd down`, or `azd pipeline config`.\n- Do not replace Bicep with Terraform, Terraform with Bicep, or an established hosting service unless the user requests that architectural change.\n- Preserve resources and state owned outside the current `azd` project.\n\n## Use these defaults\n\n| Concern | Preferred default |\n| --- | --- |\n| Project manifest | One `azure.yaml` at the repository root |\n| Application code | `src\u002F\u003Cservice-name>` per independently deployable service |\n| Infrastructure | `infra` with a thin entry point and reusable modules |\n| IaC provider | Bicep unless the repository or user chooses Terraform |\n| Deployment environments | Separate named environments for dev, test, staging, and production |\n| Local AZD state | `.azure\u002F\u003Cenvironment-name>` and excluded from source control |\n| Shared environment state | AZD remote environments backed by Azure Blob Storage |\n| Secrets | Managed identity\u002FRBAC first, then Key Vault references |\n| Automation scripts | Short, idempotent scripts under `scripts\u002Fazd` |\n| CI authentication | Workload identity federation\u002FOIDC where supported |\n| Routine development | `azd up` for simple workflows; separate phases for controlled workflows |\n\n## Implementation workflow\n\n### 1. Model the application\n\n- Define one `services` entry for each independently deployable component.\n- Keep service keys stable because they participate in resource discovery and deployment.\n- Map each service to its actual `project`, `language`, and `host`.\n- Keep shared infrastructure in IaC rather than inventing a fake deployable service.\n- Declare dependencies with supported `azure.yaml` fields instead of relying on file order.\n\n### 2. Model infrastructure\n\n- Keep `main.bicep` or `main.tf` as the orchestration entry point.\n- Split reusable or independently understandable infrastructure into modules.\n- Parameterize environment-specific values; do not fork the IaC tree per environment.\n- Output only stable, nonsecret values required by deployment or application configuration.\n- Use deterministic naming and consistent tags that include the project and environment.\n- Add role assignments to identities rather than distributing service keys.\n- Use infrastructure layers only when separate scopes or lifecycle dependencies justify them.\n\n### 3. Model environments\n\n- Use predictable names such as `\u003Cproject>-dev` for shared environments and `\u003Calias>-dev` for personal environments.\n- Use `azd env set`, `azd env unset`, and `azd env set-secret` rather than editing `.env` directly.\n- Use `-e` or `--environment` in scripts and automation so the target is explicit.\n- Use `azd env refresh` to synchronize deployment outputs after another actor changes an environment.\n- Configure AZD remote state when a team shares environment state.\n\n### 4. Add hooks only for lifecycle gaps\n\n- Prefer declarative IaC and native service configuration over hooks.\n- Use root hooks for project-wide behavior and service hooks for service-specific behavior.\n- Keep nontrivial hook logic in versioned scripts under `scripts\u002Fazd`.\n- Set `shell` explicitly. Provide `windows` and `posix` variants when necessary.\n- Make hooks idempotent, noninteractive in CI, and fail on errors unless failure is intentionally nonblocking.\n- Test a hook independently with `azd hooks run \u003Chook-name>`.\n\n### 5. Build CI\u002FCD deliberately\n\n- Keep the pipeline definition with the template and review generated changes from `azd pipeline config`.\n- Use short-lived federated credentials where the provider supports them.\n- Run tests and IaC validation before provisioning.\n- Use explicit environments and `--no-prompt` in automation.\n- Add protected production environments and approval gates.\n- For Terraform, configure protected remote state before pipeline setup and account for current AZD authentication limitations.\n\n## Validate before finishing\n\nRun only checks applicable to the repository:\n\n```text\nApplication: existing formatter, linter, type-check, build, and tests\nBicep:      az bicep build --file infra\u002Fmain.bicep\nTerraform:  terraform fmt -check -recursive\n            terraform init -backend=false\n            terraform validate\nAZD hooks:  azd hooks run \u003Chook-name>\nPackaging:  azd package\n```\n\nFor a Bicep what-if or Terraform plan, choose the correct deployment scope and environment. These checks can authenticate to Azure or read remote state, so follow the safety guardrails.\n\nVerify that:\n\n- `azure.yaml` paths exist and service settings match the source projects.\n- The IaC entry point and provider agree with `azure.yaml`.\n- Required deployment outputs match the variables consumed by services, hooks, and pipelines.\n- `.gitignore` excludes `.azure`, secrets, local state, and generated artifacts.\n- No secret appears in tracked content or command output.\n- Documentation explains prerequisites, environment creation, deployment, verification, and cleanup.\n\n## Report the result\n\nState:\n\n- The files and behavior changed.\n- The IaC provider and environment assumptions.\n- The checks performed.\n- Any cloud-changing command deliberately not run.\n- Any beta or preview feature the solution relies on.\n\nDo not claim deployment success unless the target environment was actually deployed and verified.\n",{"name":5,"license":15,"description":7},"main","5269f7ea2d6c3a9bfda5ed878b6726cf509121fd","skills\u002Fazure-developer-cli",5354,"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-14 05:37:52",{"source":8,"skillName":5,"commands":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add github\u002Fawesome-copilot --skill azure-developer-cli",{"tool":74,"command":75},"bunx","bunx skills add github\u002Fawesome-copilot --skill azure-developer-cli",{"tool":77,"command":78},"pnpm","pnpm dlx skills add github\u002Fawesome-copilot --skill azure-developer-cli","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fazure-developer-cli\u002FSKILL.md",true,[82,88,92,96,100],{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"examples\u002Fazure.yaml","REFERENCE","参考文档",767,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fazure-developer-cli\u002Fexamples\u002Fazure.yaml",{"path":89,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fiac-and-environments.md",6914,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fazure-developer-cli\u002Freferences\u002Fiac-and-environments.md",{"path":93,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Fofficial-docs.md",3724,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fazure-developer-cli\u002Freferences\u002Fofficial-docs.md",{"path":97,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fproject-structure.md",5442,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fazure-developer-cli\u002Freferences\u002Fproject-structure.md",{"path":101,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fsecurity-cicd-operations.md",7428,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fazure-developer-cli\u002Freferences\u002Fsecurity-cicd-operations.md",[105,137,164,186,220,237],{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":117,"publishedAt":53},"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",[111,114],{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":115,"categoryName":116,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[118,119,120,121,122,123,52,124,125,126,127,128,129,130,131,132,133,134,135,136],"supabase","rls","supabase rls","supabase rls policies","project","when","change","read","write","security","isolation","tables","as","tests","prove","use","users","functions","with",{"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":6,"sourceHtmlUrl":141,"categories":142,"keywords":144,"publishedAt":53},"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",[143],{"categoryNo":115,"categoryName":116,"taxonomyType":21,"taxonomyTypeDesc":22},[145,146,147,148,149,150,35,151,152,153,154,155,156,157,158,159,160,161,162,163],"distribution","skill distribution audit","audit","SET","deterministic","installer","discovery","comparison","helper","manifest","version","collection","drift","output","investigate","duplicate","template","release","reconcile",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":168,"sourceHtmlUrl":169,"categories":170,"keywords":172,"publishedAt":53},"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",[171],{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[173,174,175,176,40,177,35,122,48,178,179,30,180,181,182,133,183,184,185,49],"custom","code","logicapps custom code net10 migration","migration","standalone","applications","local","worker","upgrades","package","apps","Legacy","debugging",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":190,"sourceHtmlUrl":191,"categories":192,"keywords":197,"publishedAt":53},"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",[193,196],{"categoryNo":194,"categoryName":195,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,123,213,214,215,216,217,35,218,219],"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":221,"name":222,"nameZh":6,"description":223,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":224,"licenseFileUrl":225,"sourceHtmlUrl":226,"categories":227,"keywords":233,"publishedAt":53},"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",[228,229,232],{"categoryNo":194,"categoryName":195,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":230,"categoryName":231,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":115,"categoryName":116,"taxonomyType":21,"taxonomyTypeDesc":22},[234,148,207,235,236],"resemble detect","https","identity",{"skillNo":238,"name":239,"nameZh":6,"description":240,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":224,"licenseFileUrl":241,"sourceHtmlUrl":242,"categories":243,"keywords":248,"publishedAt":53},"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",[244,247],{"categoryNo":245,"categoryName":246,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":115,"categoryName":116,"taxonomyType":21,"taxonomyTypeDesc":22},[249,250,251,252,174,52,9,147,253,254,235,255,256,257,258,259,260,261,262,263,264,265,131,266,267,268,269],"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"]