[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AD90ACSJ224NBHC5EGTHVD":3,"skill-same:01M6AD90ACSJ224NBHC5EGTHVD":60},{"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":18,"publishedAt":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":39,"repositoryHtmlUrl":40,"repositoryHomepageUrl":41,"ownerHtmlUrl":42,"ownerBlogUrl":43,"ownerDescription":44,"updatedAt":45,"install":46,"resources":59},"01M6AD90ACSJ224NBHC5EGTHVD","azure-well-architected-review",null,"Perform an Azure Well-Architected Framework review of the current workload IaC and architecture, generating findings and GitHub issues for improvements.","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\u002Fazure-well-architected-review\u002FSKILL.md",[],[19,20,21,22,23,9,24,25,26,27,28,29,30],"review","azure","azure well architected review","well architected","azure well architected","architecture","workload","github issues","issues","framework","iac","for","2026-11-10 10:12:30",false,"---\nname: azure-well-architected-review\ndescription: 'Perform an Azure Well-Architected Framework review of the current workload IaC and architecture, generating findings and GitHub issues for improvements.'\n---\n\n# Azure Well-Architected Review\n\nThis workflow performs a structured Azure Well-Architected Framework (WAF) review against your workload's IaC files and deployed infrastructure. It identifies risks across all 5 WAF pillars and creates GitHub issues to track remediation.\n\n## Prerequisites\n- Azure CLI (`az`) configured and authenticated\n- IaC files present in the repository (Bicep, Terraform, or ARM templates)\n- GitHub MCP server configured and authenticated\n\n## Workflow Steps\n\n### Step 1: Load Well-Architected Framework Reference\nFetch current Azure WAF best practices:\n- `https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002F`\n- Service guides for the Azure services in use (`https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fservice-guides\u002F`)\n- Workload-specific guidance relevant to the workload type (SaaS, mission-critical, AI, etc.)\n\nIf the `microsoft.docs.mcp` MCP server is available, use it to query the latest pillar checklists and service-specific recommendations.\n\n### Step 2: Discover IaC & Architecture\nEstablish the review scope, then inventory both the code and the live environment:\n\n1. **Confirm the Azure scope**: Ask the user which subscription(s)\u002Fresource group(s) are in scope, or infer them from IaC parameters and confirm.\n2. **Scan the repository for IaC files**:\n   - Bicep: `**\u002F*.bicep`, `bicepconfig.json`\n   - Terraform: `**\u002F*.tf` (azurerm\u002Fazapi providers)\n   - ARM templates: `**\u002Fazuredeploy*.json`, `**\u002F*.template.json`, files with `$schema` containing `deploymentTemplate`\n3. **Inventory live resources** (always, even when IaC exists): `az resource list --resource-group \u003Crg> --output json` (or subscription-wide), plus targeted `az \u003Cservice> show` calls for configuration details the pillar checks need.\n4. **Compare IaC with live inventory**: Flag drift — resources present in Azure but absent from IaC (portal-created), resources defined in IaC but not deployed, and configuration mismatches. Record drift findings for Step 3 (they typically map to the Operational Excellence pillar).\n\nIdentify key Azure services in use (compute, data, networking, security, observability) and generate a Mermaid architecture diagram.\n\n### Step 3: Pillar-by-Pillar Review\n\n#### Pillar 1: Reliability\n- [ ] Availability zones enabled for zonal services (VMs, VMSS, AKS node pools, App Service, SQL, Storage ZRS)\n- [ ] Production SKUs support the required SLA (no Basic\u002FFree tiers on critical paths)\n- [ ] Azure SQL \u002F Cosmos DB backup and point-in-time restore configured with appropriate retention\n- [ ] Geo-redundancy configured where RPO requires it (GRS\u002FRA-GRS storage, SQL failover groups, Cosmos DB multi-region)\n- [ ] Autoscale rules configured for App Service plans, VMSS, AKS (no fixed single instance for production)\n- [ ] Health probes configured on Load Balancer \u002F Application Gateway \u002F Front Door backends\n- [ ] Dead-lettering enabled for Service Bus queues\u002Fsubscriptions and Event Grid subscriptions\n- [ ] Retry policies with exponential backoff implemented for transient fault handling\n- [ ] Disaster recovery plan defined (documented RTO\u002FRPO, tested failover)\n\n#### Pillar 2: Security\n- [ ] Managed identities used instead of service principals with secrets or connection strings\n- [ ] No hardcoded credentials, keys, or connection strings in IaC or code\n- [ ] Secrets stored in Azure Key Vault with RBAC authorization (not access policies)\n- [ ] Storage accounts deny public blob access and disallow shared key access where possible\n- [ ] Private endpoints (or at minimum service endpoints + firewall rules) for PaaS data services\n- [ ] NSGs restrict inbound traffic to minimum required ports\u002FCIDRs (no `*` → `*` allow rules)\n- [ ] TLS 1.2+ enforced on all endpoints (`minimumTlsVersion`, `httpsOnly`)\n- [ ] Azure RBAC follows least privilege (no Owner\u002FContributor at subscription scope for workload identities)\n- [ ] Microsoft Defender for Cloud enabled on relevant resource types (`az security pricing list`)\n- [ ] Azure WAF (Application Gateway or Front Door) configured for public-facing web endpoints\n- [ ] Diagnostic settings send security logs to Log Analytics \u002F Microsoft Sentinel\n\n#### Pillar 3: Cost Optimization\n- [ ] Reservations or savings plans evaluated for steady-state compute (VMs, App Service, SQL)\n- [ ] Storage lifecycle management policies move blobs to cool\u002Farchive tiers\n- [ ] Right-sized SKUs based on actual utilization (no oversized VMs\u002FApp Service plans)\n- [ ] Dev\u002Ftest environments use auto-shutdown schedules and Dev\u002FTest pricing where eligible\n- [ ] Azure Budgets and cost alerts configured (`az consumption budget list`)\n- [ ] Unattached managed disks and orphaned public IPs identified and removed\n- [ ] Consumption\u002Fserverless tiers used for spiky or low-volume workloads (Functions, Container Apps, SQL serverless)\n- [ ] Log Analytics retention and data-cap settings tuned to avoid ingestion overruns\n\n#### Pillar 4: Operational Excellence\n- [ ] All infrastructure defined as IaC (no manual portal changes; deny assignments or policy where feasible)\n- [ ] Consistent tagging strategy applied across all resources (owner, environment, cost center)\n- [ ] Azure Monitor alerts defined for key metrics and service health\n- [ ] Automated deployment pipeline present (GitHub Actions \u002F Azure Pipelines, no manual deployments)\n- [ ] Azure Activity Log and resource diagnostic settings routed to Log Analytics\n- [ ] Application Insights (or OpenTelemetry equivalent) instrumented for application workloads\n- [ ] Azure Policy assignments enforce organizational standards (allowed locations, SKUs, tags)\n- [ ] Runbooks or operational documentation present\n\n#### Pillar 5: Performance Efficiency\n- [ ] Right-sized compute SKUs validated against load requirements\n- [ ] Caching implemented where beneficial (Azure Cache for Redis, CDN\u002FFront Door caching)\n- [ ] Azure Front Door or CDN used for global static content delivery\n- [ ] Autoscale based on load metrics rather than fixed instance counts\n- [ ] Database performance tier appropriate (DTU vs vCore, elastic pools, Cosmos DB RU autoscale)\n- [ ] Premium\u002Fzone-redundant storage used for latency-sensitive disk workloads\n- [ ] Connection pooling and async patterns used for database and HTTP clients\n\n### Step 4: Risk Classification\nFor each finding, classify:\n- **High Risk**: Security vulnerability, single point of failure, no backup\u002Frecovery\n- **Medium Risk**: Suboptimal reliability, cost inefficiency, performance concern\n- **Low Risk**: Best practice deviation, minor optimization opportunity\n\n### Step 5: User Confirmation\n\n```\n?️ Azure Well-Architected Review Summary\n\n? Review Results:\n• IaC Files Analyzed: X\n• Azure Services Identified: Y\n• Total Findings: Z\n  • High Risk: A (immediate action required)\n  • Medium Risk: B (should address soon)\n  • Low Risk: C (nice to have)\n\n? Top High Risk Findings:\n1. [Pillar]: [Finding] — [Why it matters]\n2. [Pillar]: [Finding] — [Why it matters]\n\n? This will create Z individual GitHub issues + 1 EPIC issue.\n\n❓ Proceed with creating GitHub issues? (y\u002Fn)\n```\n\n**Gate**: Only proceed to Steps 6–7 if the user gives an explicit affirmative response (e.g. \"y\", \"yes\"). On a negative, ambiguous, or missing response, do **not** create any GitHub issues — output the full findings as formatted markdown to the console and stop.\n\n### Step 6: Create Individual Finding Issues\nLabel with \"well-architected\" and the pillar name (e.g., \"security\", \"reliability\").\n\n**Title**: `[WAF-\u003CPILLAR>] [Brief Finding] — [Risk Level]`\n\n**Body**:\n````markdown\n## ?️ Well-Architected Finding: [Brief Title]\n\n**Pillar**: [Name] | **Risk Level**: [High\u002FMedium\u002FLow] | **Effort**: [Low\u002FMedium\u002FHigh]\n\n### ? Description\n[Clear explanation of the finding and why it matters]\n\n### ? Remediation\n\n**IaC Fix** (preferred):\n```bicep\n\u002F\u002F Bicep example\nresource storageAccount 'Microsoft.Storage\u002FstorageAccounts@2023-05-01' = {\n  name: storageAccountName\n  location: location\n  sku: { name: 'Standard_ZRS' }\n  kind: 'StorageV2'\n  properties: {\n    minimumTlsVersion: 'TLS1_2'\n    allowBlobPublicAccess: false\n    supportsHttpsTrafficOnly: true\n  }\n}\n```\n\n**Azure CLI fallback**:\n```bash\naz storage account update --name \u003Cname> --resource-group \u003Crg> \\\n  --min-tls-version TLS1_2 --allow-blob-public-access false --https-only true\n```\n\n### ? Azure Reference\n- [WAF Best Practice Link]\n- [Microsoft Learn Documentation Link]\n\n### ✅ Validation\n- [ ] Change implemented in IaC and deployed\n- [ ] Azure Policy compliance passes (if applicable)\n- [ ] Microsoft Defender for Cloud recommendation resolved (if applicable)\n\n**Well-Architected Recommendation**: [WAF checklist item this maps to]\n````\n\n### Step 7: Create EPIC Tracking Issue\nLabel with \"well-architected\" and \"epic\".\n\n**Title**: `[EPIC] Azure Well-Architected Review — X findings across 5 pillars`\n\n**Body**: Executive summary with pillar breakdown table (finding counts by pillar and risk level), Mermaid architecture diagram, prioritized checklist linking all individual issues (High → Medium → Low), and success criteria:\n- All High-risk findings resolved\n- Medium findings have accepted mitigation plans\n- No regression in existing Azure Monitor alerts or Azure Policy compliance\n\n## Error Handling\n- **No IaC Files Found**: Limit review to live resource discovery via Azure CLI (`az resource list`) and note the gap\n- **Insufficient Azure Permissions**: List required read-only roles for the review (Reader, Security Reader)\n- **GitHub Creation Failure**: Output all findings as formatted markdown to console\n\n## Success Criteria\n- ✅ All 5 WAF pillars reviewed against IaC and live infrastructure\n- ✅ All findings classified by risk level and pillar\n- ✅ Actionable remediation steps with IaC examples for each finding\n- ✅ GitHub issues created for team tracking\n- ✅ Architecture diagram generated for EPIC context\n- ✅ Microsoft Learn documentation references included\n","# Azure Well-Architected Review\n\nThis workflow performs a structured Azure Well-Architected Framework (WAF) review against your workload's IaC files and deployed infrastructure. It identifies risks across all 5 WAF pillars and creates GitHub issues to track remediation.\n\n## Prerequisites\n- Azure CLI (`az`) configured and authenticated\n- IaC files present in the repository (Bicep, Terraform, or ARM templates)\n- GitHub MCP server configured and authenticated\n\n## Workflow Steps\n\n### Step 1: Load Well-Architected Framework Reference\nFetch current Azure WAF best practices:\n- `https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002F`\n- Service guides for the Azure services in use (`https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fservice-guides\u002F`)\n- Workload-specific guidance relevant to the workload type (SaaS, mission-critical, AI, etc.)\n\nIf the `microsoft.docs.mcp` MCP server is available, use it to query the latest pillar checklists and service-specific recommendations.\n\n### Step 2: Discover IaC & Architecture\nEstablish the review scope, then inventory both the code and the live environment:\n\n1. **Confirm the Azure scope**: Ask the user which subscription(s)\u002Fresource group(s) are in scope, or infer them from IaC parameters and confirm.\n2. **Scan the repository for IaC files**:\n   - Bicep: `**\u002F*.bicep`, `bicepconfig.json`\n   - Terraform: `**\u002F*.tf` (azurerm\u002Fazapi providers)\n   - ARM templates: `**\u002Fazuredeploy*.json`, `**\u002F*.template.json`, files with `$schema` containing `deploymentTemplate`\n3. **Inventory live resources** (always, even when IaC exists): `az resource list --resource-group \u003Crg> --output json` (or subscription-wide), plus targeted `az \u003Cservice> show` calls for configuration details the pillar checks need.\n4. **Compare IaC with live inventory**: Flag drift — resources present in Azure but absent from IaC (portal-created), resources defined in IaC but not deployed, and configuration mismatches. Record drift findings for Step 3 (they typically map to the Operational Excellence pillar).\n\nIdentify key Azure services in use (compute, data, networking, security, observability) and generate a Mermaid architecture diagram.\n\n### Step 3: Pillar-by-Pillar Review\n\n#### Pillar 1: Reliability\n- [ ] Availability zones enabled for zonal services (VMs, VMSS, AKS node pools, App Service, SQL, Storage ZRS)\n- [ ] Production SKUs support the required SLA (no Basic\u002FFree tiers on critical paths)\n- [ ] Azure SQL \u002F Cosmos DB backup and point-in-time restore configured with appropriate retention\n- [ ] Geo-redundancy configured where RPO requires it (GRS\u002FRA-GRS storage, SQL failover groups, Cosmos DB multi-region)\n- [ ] Autoscale rules configured for App Service plans, VMSS, AKS (no fixed single instance for production)\n- [ ] Health probes configured on Load Balancer \u002F Application Gateway \u002F Front Door backends\n- [ ] Dead-lettering enabled for Service Bus queues\u002Fsubscriptions and Event Grid subscriptions\n- [ ] Retry policies with exponential backoff implemented for transient fault handling\n- [ ] Disaster recovery plan defined (documented RTO\u002FRPO, tested failover)\n\n#### Pillar 2: Security\n- [ ] Managed identities used instead of service principals with secrets or connection strings\n- [ ] No hardcoded credentials, keys, or connection strings in IaC or code\n- [ ] Secrets stored in Azure Key Vault with RBAC authorization (not access policies)\n- [ ] Storage accounts deny public blob access and disallow shared key access where possible\n- [ ] Private endpoints (or at minimum service endpoints + firewall rules) for PaaS data services\n- [ ] NSGs restrict inbound traffic to minimum required ports\u002FCIDRs (no `*` → `*` allow rules)\n- [ ] TLS 1.2+ enforced on all endpoints (`minimumTlsVersion`, `httpsOnly`)\n- [ ] Azure RBAC follows least privilege (no Owner\u002FContributor at subscription scope for workload identities)\n- [ ] Microsoft Defender for Cloud enabled on relevant resource types (`az security pricing list`)\n- [ ] Azure WAF (Application Gateway or Front Door) configured for public-facing web endpoints\n- [ ] Diagnostic settings send security logs to Log Analytics \u002F Microsoft Sentinel\n\n#### Pillar 3: Cost Optimization\n- [ ] Reservations or savings plans evaluated for steady-state compute (VMs, App Service, SQL)\n- [ ] Storage lifecycle management policies move blobs to cool\u002Farchive tiers\n- [ ] Right-sized SKUs based on actual utilization (no oversized VMs\u002FApp Service plans)\n- [ ] Dev\u002Ftest environments use auto-shutdown schedules and Dev\u002FTest pricing where eligible\n- [ ] Azure Budgets and cost alerts configured (`az consumption budget list`)\n- [ ] Unattached managed disks and orphaned public IPs identified and removed\n- [ ] Consumption\u002Fserverless tiers used for spiky or low-volume workloads (Functions, Container Apps, SQL serverless)\n- [ ] Log Analytics retention and data-cap settings tuned to avoid ingestion overruns\n\n#### Pillar 4: Operational Excellence\n- [ ] All infrastructure defined as IaC (no manual portal changes; deny assignments or policy where feasible)\n- [ ] Consistent tagging strategy applied across all resources (owner, environment, cost center)\n- [ ] Azure Monitor alerts defined for key metrics and service health\n- [ ] Automated deployment pipeline present (GitHub Actions \u002F Azure Pipelines, no manual deployments)\n- [ ] Azure Activity Log and resource diagnostic settings routed to Log Analytics\n- [ ] Application Insights (or OpenTelemetry equivalent) instrumented for application workloads\n- [ ] Azure Policy assignments enforce organizational standards (allowed locations, SKUs, tags)\n- [ ] Runbooks or operational documentation present\n\n#### Pillar 5: Performance Efficiency\n- [ ] Right-sized compute SKUs validated against load requirements\n- [ ] Caching implemented where beneficial (Azure Cache for Redis, CDN\u002FFront Door caching)\n- [ ] Azure Front Door or CDN used for global static content delivery\n- [ ] Autoscale based on load metrics rather than fixed instance counts\n- [ ] Database performance tier appropriate (DTU vs vCore, elastic pools, Cosmos DB RU autoscale)\n- [ ] Premium\u002Fzone-redundant storage used for latency-sensitive disk workloads\n- [ ] Connection pooling and async patterns used for database and HTTP clients\n\n### Step 4: Risk Classification\nFor each finding, classify:\n- **High Risk**: Security vulnerability, single point of failure, no backup\u002Frecovery\n- **Medium Risk**: Suboptimal reliability, cost inefficiency, performance concern\n- **Low Risk**: Best practice deviation, minor optimization opportunity\n\n### Step 5: User Confirmation\n\n```\n?️ Azure Well-Architected Review Summary\n\n? Review Results:\n• IaC Files Analyzed: X\n• Azure Services Identified: Y\n• Total Findings: Z\n  • High Risk: A (immediate action required)\n  • Medium Risk: B (should address soon)\n  • Low Risk: C (nice to have)\n\n? Top High Risk Findings:\n1. [Pillar]: [Finding] — [Why it matters]\n2. [Pillar]: [Finding] — [Why it matters]\n\n? This will create Z individual GitHub issues + 1 EPIC issue.\n\n❓ Proceed with creating GitHub issues? (y\u002Fn)\n```\n\n**Gate**: Only proceed to Steps 6–7 if the user gives an explicit affirmative response (e.g. \"y\", \"yes\"). On a negative, ambiguous, or missing response, do **not** create any GitHub issues — output the full findings as formatted markdown to the console and stop.\n\n### Step 6: Create Individual Finding Issues\nLabel with \"well-architected\" and the pillar name (e.g., \"security\", \"reliability\").\n\n**Title**: `[WAF-\u003CPILLAR>] [Brief Finding] — [Risk Level]`\n\n**Body**:\n````markdown\n## ?️ Well-Architected Finding: [Brief Title]\n\n**Pillar**: [Name] | **Risk Level**: [High\u002FMedium\u002FLow] | **Effort**: [Low\u002FMedium\u002FHigh]\n\n### ? Description\n[Clear explanation of the finding and why it matters]\n\n### ? Remediation\n\n**IaC Fix** (preferred):\n```bicep\n\u002F\u002F Bicep example\nresource storageAccount 'Microsoft.Storage\u002FstorageAccounts@2023-05-01' = {\n  name: storageAccountName\n  location: location\n  sku: { name: 'Standard_ZRS' }\n  kind: 'StorageV2'\n  properties: {\n    minimumTlsVersion: 'TLS1_2'\n    allowBlobPublicAccess: false\n    supportsHttpsTrafficOnly: true\n  }\n}\n```\n\n**Azure CLI fallback**:\n```bash\naz storage account update --name \u003Cname> --resource-group \u003Crg> \\\n  --min-tls-version TLS1_2 --allow-blob-public-access false --https-only true\n```\n\n### ? Azure Reference\n- [WAF Best Practice Link]\n- [Microsoft Learn Documentation Link]\n\n### ✅ Validation\n- [ ] Change implemented in IaC and deployed\n- [ ] Azure Policy compliance passes (if applicable)\n- [ ] Microsoft Defender for Cloud recommendation resolved (if applicable)\n\n**Well-Architected Recommendation**: [WAF checklist item this maps to]\n````\n\n### Step 7: Create EPIC Tracking Issue\nLabel with \"well-architected\" and \"epic\".\n\n**Title**: `[EPIC] Azure Well-Architected Review — X findings across 5 pillars`\n\n**Body**: Executive summary with pillar breakdown table (finding counts by pillar and risk level), Mermaid architecture diagram, prioritized checklist linking all individual issues (High → Medium → Low), and success criteria:\n- All High-risk findings resolved\n- Medium findings have accepted mitigation plans\n- No regression in existing Azure Monitor alerts or Azure Policy compliance\n\n## Error Handling\n- **No IaC Files Found**: Limit review to live resource discovery via Azure CLI (`az resource list`) and note the gap\n- **Insufficient Azure Permissions**: List required read-only roles for the review (Reader, Security Reader)\n- **GitHub Creation Failure**: Output all findings as formatted markdown to console\n\n## Success Criteria\n- ✅ All 5 WAF pillars reviewed against IaC and live infrastructure\n- ✅ All findings classified by risk level and pillar\n- ✅ Actionable remediation steps with IaC examples for each finding\n- ✅ GitHub issues created for team tracking\n- ✅ Architecture diagram generated for EPIC context\n- ✅ Microsoft Learn documentation references included\n",{"name":5,"description":7},"main","5269f7ea2d6c3a9bfda5ed878b6726cf509121fd","skills\u002Fazure-well-architected-review",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":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add github\u002Fawesome-copilot --skill azure-well-architected-review",{"tool":52,"command":53},"bunx","bunx skills add github\u002Fawesome-copilot --skill azure-well-architected-review",{"tool":55,"command":56},"pnpm","pnpm dlx skills add github\u002Fawesome-copilot --skill azure-well-architected-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fazure-well-architected-review\u002FSKILL.md",true,[],[61,95,122,151,185,202],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":75,"publishedAt":31},"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",[67,72],{"categoryNo":68,"categoryName":69,"taxonomyType":70,"taxonomyTypeDesc":71},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":73,"categoryName":74,"taxonomyType":70,"taxonomyTypeDesc":71},"01JBSEEDCAT000000000000023","Skill与智能体开发",[76,77,78,79,80,81,19,82,83,84,85,86,87,88,89,90,91,92,93,94],"supabase","rls","supabase rls","supabase rls policies","project","when","change","read","write","security","isolation","tables","as","tests","prove","use","users","functions","with",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":102,"publishedAt":31},"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",[101],{"categoryNo":73,"categoryName":74,"taxonomyType":70,"taxonomyTypeDesc":71},[103,104,105,106,107,108,30,109,110,111,112,113,114,115,116,117,118,119,120,121],"distribution","skill distribution audit","audit","SET","deterministic","installer","discovery","comparison","helper","manifest","version","collection","drift","output","investigate","duplicate","template","release","reconcile",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":126,"sourceHtmlUrl":127,"categories":128,"keywords":134,"publishedAt":31},"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",[129],{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[135,136,137,138,139,140,30,80,141,142,143,20,144,145,146,91,147,148,149,150],"custom","code","logicapps custom code net10 migration","migration","projects","standalone","deployment","applications","local","worker","upgrades","package","apps","Legacy","debugging","workflows",{"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":162,"publishedAt":31},"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",[158,161],{"categoryNo":159,"categoryName":160,"taxonomyType":70,"taxonomyTypeDesc":71},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},[163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,81,178,179,180,181,182,30,183,184],"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":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":189,"licenseFileUrl":190,"sourceHtmlUrl":191,"categories":192,"keywords":198,"publishedAt":31},"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",[193,194,197],{"categoryNo":159,"categoryName":160,"taxonomyType":70,"taxonomyTypeDesc":71},{"categoryNo":195,"categoryName":196,"taxonomyType":70,"taxonomyTypeDesc":71},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":73,"categoryName":74,"taxonomyType":70,"taxonomyTypeDesc":71},[199,106,172,200,201],"resemble detect","https","identity",{"skillNo":203,"name":204,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":189,"licenseFileUrl":206,"sourceHtmlUrl":207,"categories":208,"keywords":213,"publishedAt":31},"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",[209,212],{"categoryNo":210,"categoryName":211,"taxonomyType":70,"taxonomyTypeDesc":71},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":73,"categoryName":74,"taxonomyType":70,"taxonomyTypeDesc":71},[214,215,216,217,136,19,9,105,218,219,200,220,221,222,223,224,225,226,227,228,229,230,89,231,232,233,234],"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"]