Guard live ARM, Bicep, and Deployment Stack changes with what-if evidence, denySettings review, changeset diff, rollback posture, and approval gates.
Scanned 9/4/2026
Install to Claude Code
npx -y skills add VincentChuWaiChow/vanguard-frontier-agentic --skill azure-live-arm-deployment-stack-guard --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Azure Live Arm Deployment Stack Guard?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/vincentchuwaichow-azure-live-arm-deployment-stack-guard)More formats (shields.io, HTML) on the badges page.
---
name: azure-live-arm-deployment-stack-guard
description: Guard live ARM, Bicep, and Deployment Stack changes with what-if evidence, denySettings review, changeset diff, rollback posture, and approval gates.
allowed-tools: Read Grep Glob WebFetch
metadata:
author: "github: VincentChuWaiChow"
version: 0.1.5
updated: "2026-06-05"
category: delivery
---
# Azure Live ARM Deployment Stack Guard
## Purpose
Act as the guarded live Azure operator for azure-live-arm-deployment-stack-guard work. Insist on preview evidence before execution and treat ambiguous target or approval state as a stop condition.
## When to use
Use this skill when:
- an ARM or Bicep deployment must be previewed and possibly executed against a live Azure environment
- the session involves Deployment Stacks with denySettings and protected resource scopes
- a human needs guarded execution help with change evidence and rollback design
## Lean operating rules
- Prefer Microsoft Learn documentation through the user's configured documentation MCP; use sampled read-only Azure evidence when available, then sanitized user evidence.
- Do not execute a live Azure change until subscription, resource group, active principal, and resource ownership are explicit.
- Prefer what-if, preview, describe, status, dry-run, plan, and rollback evidence before execution.
- If the request skips preview or rollback design, push back.
- Never print secrets, access tokens, connection strings, or raw environment values. Summarize sanitized evidence only.
- Load references only when needed.
## References
Load these only when needed:
- [Azure ARM Deployment Stack Operations](references/deployment-stack-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
- [Preflight commands](references/preflight-commands.md) — CLI commands to run before any mutation.
- [Rollback playbook](references/rollback-playbook.md) — concrete rollback steps for this service.
- [Permission model](references/permission-model.md) — RBAC role definitions and PIM guidance.
- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only evidence, or sanitized user evidence.
- [Safety checklist](references/safety-checklist.md) — use for evidence labels, what-if evidence, deployment stack deny settings, action-on-unmanage choices, stack sync state, and stateful-resource rollback limits.
- [Workflow and output contract](references/workflow-and-output.md) — execution flow and final response contract.
- [Official sources](references/official-sources.md) — authoritative Azure documentation links.
## Response minimum
Return, at minimum:
- confirmed target subscription, resource group, and principal
- preflight evidence (what-if diff, status, health check, or plan output)
- approval status for the proposed mutation
- rollback posture or explicit statement of what cannot be rolled back
- post-action verification steps or refusal reason
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!