[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699YRFWQZ0M85KBAV6BQFAP":3,"skill-same:01M699YRFWQZ0M85KBAV6BQFAP":90},{"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":50,"linkOnly":51,"markdownContent":52,"markdownBody":53,"frontMatter":54,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":64,"repositoryHtmlUrl":65,"repositoryHomepageUrl":6,"ownerHtmlUrl":66,"ownerBlogUrl":67,"ownerDescription":68,"updatedAt":69,"install":70,"resources":83},"01M699YRFWQZ0M85KBAV6BQFAP","deployment-compliance-check",null,"Checks whether Azure Container App deployments comply with the organization's CI\u002FCD-only deployment policy. Uses three signals: Activity Log caller identity, Docker image labels (tamper-proof), and resource tags.\nQueryLogAnalyticsByWorkspaceId","microsoft\u002Fsre-agent","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699YP84JQDX8CY79ZD1TTEF",188,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fsre-agent\u002Fblob\u002Fmain\u002Flabs\u002Fdeployment-compliance\u002Fskills\u002Fdeployment-compliance-check\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49],"deployment compliance check","compliance check","deployment","compliance","check","labels","image","comply","tags","app","three","deployments","log","container","only","activity log","ci","azure","identity","policy","docker","2026-11-10 10:12:30",false,"---\nname: deployment-compliance-check\ndescription: |\n  Checks whether Azure Container App deployments comply with the organization's CI\u002FCD-only deployment policy. Uses three signals: Activity Log caller identity, Docker image labels (tamper-proof), and resource tags.\n  QueryLogAnalyticsByWorkspaceId\ntools:\n  - QueryLogAnalyticsByWorkspaceId\n  - GetAzCliHelp\n  - RunAzCliReadCommands\n  - RunAzCliWriteCommands\n---\n\n\u003C!-- Add your skill instructions here -->\nOrganization Policy\nAll Container App deployments MUST go through the approved CI\u002FCD pipeline (GitHub Actions).\n\nDeployments via Azure Portal, interactive Azure CLI, or PowerShell are non-compliant.\nOnly service principal \u002F managed identity deployments from the CI\u002FCD pipeline are compliant.\nNon-compliant deployments should be flagged, reported, and reverted (with user approval).\nThis policy ensures every production change is traceable to a code commit, reviewed via PR, and auditable through the pipeline.\n\nHow the Pipeline Works\nGitHub Actions builds the Docker image with immutable compliance labels, pushes to ACR, which fires an Event Grid event. An Automation Runbook (running under a managed identity) picks up the event and updates the Container App via ARM. The key point: GitHub never authenticates to Azure AD directly — all Azure-side auth happens through managed identities inside Azure.\n\nData Sources\nActivity Logs in Log Analytics\nActivity Logs flow to the Log Analytics workspace via diagnostic settings. Use QueryLogAnalyticsByWorkspaceId to run KQL against the AzureActivity table.\n\nTo discover the workspace ID if needed:\n\naz monitor log-analytics workspace show --resource-group rg-compliancedemo --workspace-name law-compliance-compliancedemo --query customerId -o tsv\nContainer App Resource Tags\nUse RunAzCliReadCommands to check tags on the Container App.\n\nDocker Image Labels in ACR\nThe CI\u002FCD pipeline bakes labels into every image at build time (deployed-by, commit-sha, pipeline-run-id, branch, repository, workflow). These are immutable once pushed — they cannot be added or changed after the fact. An image pushed manually (via Portal or docker push) will NOT have these labels.\n\nHow to Detect Compliance\nSee compliance_detection.md for the detailed decision tree and well-known app IDs.\n\nStep 1: Query Activity Logs\nQuery the AzureActivity table for Container App write operations. Extract claims.appid and Caller to identify who made the deployment. See compliance_detection.md for the KQL template.\n\nStep 2: Classify each deployment by caller\nWell-known Azure Portal \u002F CLI \u002F PowerShell app IDs → NON-COMPLIANT\nCaller contains @ (user principal) → NON-COMPLIANT\nKnown pipeline managed identity → proceed to Step 3\nUnknown service principal → INVESTIGATE\nCaller identity ALWAYS takes precedence over tags.\n\nStep 3: Verify Docker image labels (the tamper-proof check)\nThis is the most important step. Even if the caller is the pipeline's managed identity, the image itself might have been pushed to ACR manually (bypassing the CI\u002FCD build). When that happens, Event Grid still fires, the Automation Runbook still deploys it, and the Activity Log looks legitimate — but the image was never built by GitHub Actions.\n\nTo catch this:\n\nGet the currently running image tag from the Container App\nRetrieve the image config from ACR and check for the expected labels (deployed-by=pipeline, commit-sha, pipeline-run-id, etc.)\nIf labels are missing or invalid → NON-COMPLIANT regardless of caller\nThis closes the \"portal push via Event Grid\" bypass.\n\nStep 4: Verify resource tags (secondary)\nCompliant pipelines stamp tags like deployed-by=pipeline, pipeline-run-id, commit-sha, repository. Missing deployed-by tag is additional non-compliance evidence — but tags alone are weak because the Automation Runbook stamps them on every deploy, including ones triggered by manual ACR pushes.\n\nStep 5: Generate compliance report\nReport should include scan timestamp, time range, total\u002Fcompliant\u002Fnon-compliant counts, image label check results, and details of any violations.\n\nRevert Procedures\nIMPORTANT: Always get user approval before any revert action.\n\nOption A — Reactivate previous Container App revision: list revisions, activate the last known-good one, shift traffic, deactivate the non-compliant revision.\n\nOption B — Re-run the CI\u002FCD pipeline to redeploy the last known compliant image from the approved pipeline.\n\nNotes\nActivity Logs may take 5-15 minutes to appear in Log Analytics\nclaims.appid values for Portal\u002FCLI\u002FPowerShell are well-known Microsoft constants (see compliance_detection.md)\nCaller identity is authoritative; tags can be stale from previous deploys\nDocker image labels are the strongest signal — immutable once pushed to ACR\nThe \"portal push\" attack path: manual ACR push → Event Grid → Automation → looks compliant but image labels are missing\nNever revert without user approval","\u003C!-- Add your skill instructions here -->\nOrganization Policy\nAll Container App deployments MUST go through the approved CI\u002FCD pipeline (GitHub Actions).\n\nDeployments via Azure Portal, interactive Azure CLI, or PowerShell are non-compliant.\nOnly service principal \u002F managed identity deployments from the CI\u002FCD pipeline are compliant.\nNon-compliant deployments should be flagged, reported, and reverted (with user approval).\nThis policy ensures every production change is traceable to a code commit, reviewed via PR, and auditable through the pipeline.\n\nHow the Pipeline Works\nGitHub Actions builds the Docker image with immutable compliance labels, pushes to ACR, which fires an Event Grid event. An Automation Runbook (running under a managed identity) picks up the event and updates the Container App via ARM. The key point: GitHub never authenticates to Azure AD directly — all Azure-side auth happens through managed identities inside Azure.\n\nData Sources\nActivity Logs in Log Analytics\nActivity Logs flow to the Log Analytics workspace via diagnostic settings. Use QueryLogAnalyticsByWorkspaceId to run KQL against the AzureActivity table.\n\nTo discover the workspace ID if needed:\n\naz monitor log-analytics workspace show --resource-group rg-compliancedemo --workspace-name law-compliance-compliancedemo --query customerId -o tsv\nContainer App Resource Tags\nUse RunAzCliReadCommands to check tags on the Container App.\n\nDocker Image Labels in ACR\nThe CI\u002FCD pipeline bakes labels into every image at build time (deployed-by, commit-sha, pipeline-run-id, branch, repository, workflow). These are immutable once pushed — they cannot be added or changed after the fact. An image pushed manually (via Portal or docker push) will NOT have these labels.\n\nHow to Detect Compliance\nSee compliance_detection.md for the detailed decision tree and well-known app IDs.\n\nStep 1: Query Activity Logs\nQuery the AzureActivity table for Container App write operations. Extract claims.appid and Caller to identify who made the deployment. See compliance_detection.md for the KQL template.\n\nStep 2: Classify each deployment by caller\nWell-known Azure Portal \u002F CLI \u002F PowerShell app IDs → NON-COMPLIANT\nCaller contains @ (user principal) → NON-COMPLIANT\nKnown pipeline managed identity → proceed to Step 3\nUnknown service principal → INVESTIGATE\nCaller identity ALWAYS takes precedence over tags.\n\nStep 3: Verify Docker image labels (the tamper-proof check)\nThis is the most important step. Even if the caller is the pipeline's managed identity, the image itself might have been pushed to ACR manually (bypassing the CI\u002FCD build). When that happens, Event Grid still fires, the Automation Runbook still deploys it, and the Activity Log looks legitimate — but the image was never built by GitHub Actions.\n\nTo catch this:\n\nGet the currently running image tag from the Container App\nRetrieve the image config from ACR and check for the expected labels (deployed-by=pipeline, commit-sha, pipeline-run-id, etc.)\nIf labels are missing or invalid → NON-COMPLIANT regardless of caller\nThis closes the \"portal push via Event Grid\" bypass.\n\nStep 4: Verify resource tags (secondary)\nCompliant pipelines stamp tags like deployed-by=pipeline, pipeline-run-id, commit-sha, repository. Missing deployed-by tag is additional non-compliance evidence — but tags alone are weak because the Automation Runbook stamps them on every deploy, including ones triggered by manual ACR pushes.\n\nStep 5: Generate compliance report\nReport should include scan timestamp, time range, total\u002Fcompliant\u002Fnon-compliant counts, image label check results, and details of any violations.\n\nRevert Procedures\nIMPORTANT: Always get user approval before any revert action.\n\nOption A — Reactivate previous Container App revision: list revisions, activate the last known-good one, shift traffic, deactivate the non-compliant revision.\n\nOption B — Re-run the CI\u002FCD pipeline to redeploy the last known compliant image from the approved pipeline.\n\nNotes\nActivity Logs may take 5-15 minutes to appear in Log Analytics\nclaims.appid values for Portal\u002FCLI\u002FPowerShell are well-known Microsoft constants (see compliance_detection.md)\nCaller identity is authoritative; tags can be stale from previous deploys\nDocker image labels are the strongest signal — immutable once pushed to ACR\nThe \"portal push\" attack path: manual ACR push → Event Grid → Automation → looks compliant but image labels are missing\nNever revert without user approval",{"name":5,"tools":55,"description":60},[56,57,58,59],"QueryLogAnalyticsByWorkspaceId","GetAzCliHelp","RunAzCliReadCommands","RunAzCliWriteCommands","Checks whether Azure Container App deployments comply with the organization's CI\u002FCD-only deployment policy. Uses three signals: Activity Log caller identity, Docker image labels (tamper-proof), and resource tags.\nQueryLogAnalyticsByWorkspaceId\n","main","f3dccc6bae8c932ff4f21e6d4117e14285da4db3","labs\u002Fdeployment-compliance\u002Fskills\u002Fdeployment-compliance-check",197,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fsre-agent","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-10 10:20:55",{"source":8,"skillName":5,"commands":71,"prompt":81,"zipAvailable":82},[72,75,78],{"tool":73,"command":74},"npx","npx skills add microsoft\u002Fsre-agent --skill deployment-compliance-check",{"tool":76,"command":77},"bunx","bunx skills add microsoft\u002Fsre-agent --skill deployment-compliance-check",{"tool":79,"command":80},"pnpm","pnpm dlx skills add microsoft\u002Fsre-agent --skill deployment-compliance-check","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fsre-agent\u002Fblob\u002Fmain\u002Flabs\u002Fdeployment-compliance\u002Fskills\u002Fdeployment-compliance-check\u002FSKILL.md",true,[84],{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"compliance_detection.md","REFERENCE","参考文档",4094,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fsre-agent\u002Fblob\u002Fmain\u002Flabs\u002Fdeployment-compliance\u002Fskills\u002Fdeployment-compliance-check\u002Fcompliance_detection.md",[91,118,152,176,202,221],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":50},"01M699ZY06GBDPEYW1HEDRAVK8","zava-reporting","Use to package a completed Zava Learning incident analysis for the audience. First present a branded in-thread executive summary (markdown with the before\u002Fafter visuals inline), then produce the downloadable deliverables — a PowerPoint deck, an HTML email, and a Teams notification — using the Zava corporate template. The calling agent may narrow this to a subset (e.g. only the HTML report). Produces content and artifacts; it does not send them. Assembles the output of rca-analysis, evidence-before-after, recommendations-next-steps, and pr-delivery.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fsre-agent\u002Fblob\u002Fmain\u002Flabs\u002Fzava-learning\u002Fsre-config\u002Fagent-config\u002Fskills\u002Fzava-reporting\u002FSKILL.md",[],[98,99,100,101,102,103,104,105,106,107,108,43,109,110,111,112,113,114,115,116,117],"zava reporting","reporting","rca","visuals","powerpoint","executive summary","analysis","markdown","html report","template","html","evidence","before-after","next","delivery","incident","recommendations","present","inline","send",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":133,"publishedAt":50},"01M699ZWCMAF3M8P4A8P0VXEF7","zava-audit-report","Use to package a completed Zava Learning weekly governance audit (NSG \u002F network security, RBAC \u002F least-privilege, or cloud cost) into a single branded, downloadable PowerPoint deck in the Zava house style. The calling audit agent passes its findings (a list of rows with severity) and a short posture summary; this skill renders the deck, applies redaction, and returns the attachment download link. Produces the artifact; it does not send it.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fsre-agent\u002Fblob\u002Fmain\u002Flabs\u002Fzava-learning\u002Fsre-config\u002Fagent-config\u002Fskills\u002Fzava-audit-report\u002FSKILL.md",[124,127,130],{"categoryNo":125,"categoryName":126,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":128,"categoryName":129,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":131,"categoryName":132,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000034","行政与办公人员",[134,135,136,137,138,139,140,102,141,142,143,144,145,146,147,148,149,150,117,151],"zava audit report","report","audit","audit report","security","network security","rbac","network","least-privilege","severity","learning","returns","short","list","deck","artifact","weekly","single",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":50},"01M699ZV3DK2HK74MMKABQBNC7","servicenow-change-management","Use whenever a Zava Learning investigation produces a durable fix that needs change management — after a GitHub PR is opened for an Infrastructure-as-Code or application code root cause, raise a ServiceNow Change Request referencing the PR and attach the RCA report. The single owner of ServiceNow Change Request and attachment operations.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fsre-agent\u002Fblob\u002Fmain\u002Flabs\u002Fzava-learning\u002Fsre-config\u002Fagent-config\u002Fskills\u002Fservicenow-change-management\u002FSKILL.md",[],[159,160,161,162,163,164,100,165,166,167,144,168,169,170,171,172,173,174,151,175],"change","servicenow change management","servicenow","change management","management","github","pr","code","infrastructure-as-code","fix","use","attach","github pr","as","infrastructure-as","for","root cause",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":50},"01M699ZSQAYXNM5YXH35GQXG2E","redaction-guard","Use whenever you are about to emit operator-visible content — a chat\u002Fthread message, a PagerDuty or ServiceNow note, a commit message or pull-request body, or any report artifact (HTML, PowerPoint, Teams card). Deterministically masks secrets, credentials, tokens, private keys, URI-embedded passwords, and PII so they never appear in the thread or in any deliverable. This is a cross-cutting guardrail invoked by the output-producing skills, not a runbook step.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fsre-agent\u002Fblob\u002Fmain\u002Flabs\u002Fzava-learning\u002Fsre-config\u002Fagent-config\u002Fskills\u002Fredaction-guard\u002FSKILL.md",[],[183,184,185,186,187,188,189,190,191,169,192,193,194,195,196,197,198,199,200,201],"redaction guard","guard","redaction","commit","teams","commit message","pull","runbook","pii","never","pagerduty","chat","tokens","guardrail","card","output","you","passwords","thread",{"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":15,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":208,"publishedAt":50},"01M699ZRHD3XNYX412M7613ACM","recommendations-next-steps","Use to produce the forward-looking recommendations and next steps for a Zava Learning incident — prioritized preventive, detective, and process actions with owners, target dates, and the risk of inaction. Its output is used in the zava-reporting deliverables.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fsre-agent\u002Fblob\u002Fmain\u002Flabs\u002Fzava-learning\u002Fsre-config\u002Fagent-config\u002Fskills\u002Frecommendations-next-steps\u002FSKILL.md",[],[209,111,114,210,211,9,212,213,214,215,99,216,144,217,169,113,198,218,219,174,220],"recommendations next steps","next steps","docs","learn","produce","search","actions","risk","process","with","deliverables","dates",{"skillNo":222,"name":223,"nameZh":6,"description":224,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":225,"categories":226,"keywords":227,"publishedAt":50},"01M699ZQBV3ECBCA58WSBCJE54","rca-analysis","Use to produce the root-cause analysis narrative for a resolved or mitigated Zava Learning incident — the incident timeline, the trigger vs. latent root cause (5-Whys), contributing factors, and how to present them. Defines the RCA section format; its output is used in the before\u002Fafter, recommendations, and reporting deliverables.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fsre-agent\u002Fblob\u002Fmain\u002Flabs\u002Fzava-learning\u002Fsre-config\u002Fagent-config\u002Fskills\u002Frca-analysis\u002FSKILL.md",[],[100,228,104,213,229,230,144,231,169,232,113,114,233,234,235,198,219,174,236,175],"rca analysis","contributing","how","format","root-cause","trigger","how to","narrative","section"]