[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BX5BYTASKFERFC4HZZTSAY":3,"skill-same:01M6BX5BYTASKFERFC4HZZTSAY":51},{"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":22,"linkOnly":23,"markdownContent":24,"markdownBody":25,"frontMatter":26,"refName":29,"commitSha":30,"skillDirectory":31,"forksCount":14,"repositoryHtmlUrl":32,"repositoryHomepageUrl":6,"ownerHtmlUrl":33,"ownerBlogUrl":34,"ownerDescription":35,"updatedAt":36,"install":37,"resources":50},"01M6BX5BYTASKFERFC4HZZTSAY","unslop",null,"Cut AI tells from any writing. Must always apply.","yrahul3910\u002Fdotfiles","yrahul3910","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F8930954?v=4","01M6BX4Q28SQREB3XFY3BAQ6YC","Rahul Yedida","01M6BX4Q737JXBCN69KPPT5TG9",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fyrahul3910\u002Fdotfiles\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Funslop\u002FSKILL.md",[],[5,19,20,21],"writing","cut","apply","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":27,"description":28},"azure-well-architected-review","Perform an Azure Well-Architected Framework review of the current workload IaC and architecture, generating findings and GitHub issues for improvements.","main","5269f7ea2d6c3a9bfda5ed878b6726cf509121fd",".agents\u002Fskills\u002Funslop","https:\u002F\u002Fgithub.com\u002Fyrahul3910\u002Fdotfiles","https:\u002F\u002Fgithub.com\u002Fyrahul3910","https:\u002F\u002Fryedida.me","CS PhD @ NC State; Sr. Data Scientist @ LexisNexis","2026-11-09 03:52:22",{"source":8,"skillName":27,"commands":38,"prompt":48,"zipAvailable":49},[39,42,45],{"tool":40,"command":41},"npx","npx skills add yrahul3910\u002Fdotfiles --skill azure-well-architected-review",{"tool":43,"command":44},"bunx","bunx skills add yrahul3910\u002Fdotfiles --skill azure-well-architected-review",{"tool":46,"command":47},"pnpm","pnpm dlx skills add yrahul3910\u002Fdotfiles --skill azure-well-architected-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fyrahul3910\u002Fdotfiles\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Funslop\u002FSKILL.md",true,[],[52,84,116,151,172,200],{"skillNo":53,"name":54,"nameZh":6,"description":55,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":56,"categories":57,"keywords":58,"publishedAt":22},"01M6BX5T7VBBNA50W28PGXFVBK","pr-babysit","Watch a GitHub pull request through CI and bot reviews (Copilot, Codex, Claude, Greptile), fix feedback locally as it arrives, and push only once everything has settled. Use when asked to babysit, shepherd, or watch a PR until it is green and reviewed. Not for a one-off look at PR comments or CI status.","https:\u002F\u002Fgithub.com\u002Fyrahul3910\u002Fdotfiles\u002Fblob\u002Fmaster\u002F.pi\u002Fagent\u002Fskills\u002Fpr-babysit\u002FSKILL.md",[],[59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83],"pr","pr babysit","babysit","bot","github","codex","status","copilot","pull request","pull","push","ci","pr comments","feedback","ci status","fix","use","only","green","shepherd","as","comments","reviews","for","when",{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":22},"01M6BX5PZTGZCZMWB46DEZY1RB","okf","Read, create, and update Open Knowledge Format (OKF) knowledge bundles — wikis of markdown concept files with YAML frontmatter, per Google's OKF v0.1 spec. Use when browsing or consuming an OKF bundle, when asked to create a knowledge wiki for a codebase or data system, or when editing a directory of .md files that carry `type:` frontmatter alongside index.md\u002Flog.md files. Covers the frontmatter schema, bundle-root-relative linking, index.md maintenance, and log.md changelog conventions.","https:\u002F\u002Fgithub.com\u002Fyrahul3910\u002Fdotfiles\u002Fblob\u002Fmaster\u002F.pi\u002Fagent\u002Fskills\u002Fokf\u002FSKILL.md",[],[86,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,75,107,108,109,110,111,112,113,114,82,115,83],"directory","google","spec","create","update","changelog","index","yaml","data","open","markdown","wiki","knowledge","system","format","editing","schema","maintenance","log","files","type","wikis","with","concept","browsing",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":132,"publishedAt":22},"01M6BX5MWN3YRXQ447DBGGTHM5","design-doc","Write an explicit design document, RFC, or consequential architecture proposal with adversarial review. Use for decisions with material ownership, compatibility, migration, or operational consequences. Do not activate for ordinary comparisons, syntax questions, or small implementation choices.","https:\u002F\u002Fgithub.com\u002Fyrahul3910\u002Fdotfiles\u002Fblob\u002Fmaster\u002F.pi\u002Fagent\u002Fskills\u002Fdesign-doc\u002FSKILL.md",[122,127],{"categoryNo":123,"categoryName":124,"taxonomyType":125,"taxonomyTypeDesc":126},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":128,"categoryName":129,"taxonomyType":130,"taxonomyTypeDesc":131},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[133,134,135,136,137,138,139,140,141,142,75,143,144,145,146,147,148,113,149,82,150],"design","doc","design doc","review","architecture","adversarial review","RFC","syntax","decisions","write","migration","document","activate","do","material","proposal","questions","adversarial",{"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":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":22},"01M6BX5K2H9A93MD355DKQ21MV","background-terminals","Run and manage long-lived shell commands in background terminals. Use for dev servers, watchers, streaming builds, and other commands that should keep running while the agent continues working.","https:\u002F\u002Fgithub.com\u002Fyrahul3910\u002Fdotfiles\u002Fblob\u002Fmaster\u002F.pi\u002Fagent\u002Fskills\u002Fbackground-terminals\u002FSKILL.md",[],[158,159,160,161,162,163,75,164,165,166,167,168,169,82,170,171],"background terminals","background","run","dev","streaming","shell","manage","commands","watchers","long","keep","dev servers","servers","running",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":187,"publishedAt":22},"01M6BX5H39CTKJKDXRA35MNGRW","writing-for-agents","Write or revise skills, AGENTS.md, CLAUDE.md, prompts, and other instructions consumed by coding agents. Use when agent behavior, skill routing, instruction structure, or prompt maintenance is part of the task.","https:\u002F\u002Fgithub.com\u002Fyrahul3910\u002Fdotfiles\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[178,181,184],{"categoryNo":179,"categoryName":180,"taxonomyType":125,"taxonomyTypeDesc":126},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":182,"categoryName":183,"taxonomyType":125,"taxonomyTypeDesc":126},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":185,"categoryName":186,"taxonomyType":130,"taxonomyTypeDesc":131},"01JBSEEDCAT000000000000036","内容创作者",[19,188,82,189,190,191,192,142,193,194,75,195,108,196,197,198,199,83],"writing for agents","coding agents","routing","coding","prompt","instructions","behavior","prompts","task","structure","revise","skill routing",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":206,"publishedAt":22},"01M6BX5FE0MPK7EXN5ZT590428","wait-what","Stop. That last message did not land: re-pitch it.","https:\u002F\u002Fgithub.com\u002Fyrahul3910\u002Fdotfiles\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Fwait-what\u002FSKILL.md",[],[207,208,209,210,211,212,213,214,215,216],"wait what","wait","land","stop","message","pitch","it","re","last","true"]