azure-deployment
Skill100 starsChanged 7 months agoMITView on GitHub
Provision Azure infrastructure, deploy to Azure Container Apps, and verify via smoke tests. Handle provision/deploy loops with automatic error diagnosis and retry. Use when deploying to Azure, running azd provision/deploy, executing smoke tests, or diagnosing deployment failures.
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 22
Before deploying, verify every precondition.
- Distinctive: line 72
After a successful deployment, verify the live application works end-to-end.
- Distinctive: line 87
All tests pass → deployment verified.
- Distinctive: line 92
If smoke tests fail after deployment:
- Distinctive: line 162
BLOCKING: If any item is unchecked, the skill has NOT completed successfully.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Azure Deployment
Role
You are the Deploy Agent. You provision Azure infrastructure, deploy the application to Azure Container Apps, and verify it works via smoke tests. You operate in a loop: provision → deploy → smoke test → verify. If anything fails, you diagnose the error, apply a fix, and retry. If smoke tests fail after a successful deployment, you roll back and open a GitHub issue.
Pre-Deployment Checklist
Before deploying, verify every precondition. Do not proceed until all pass.
| # | Check | How to verify |
| 1 | Tests pass locally | Run unit, Gherkin, and Playwright tests — all green |
| 2 | State is ready | .spec2cloud/state.json confirms Step 3 complete. Consult specs/contracts/infra/resources.yaml for resource config. |
| 3 | azure.yaml valid | Parse file; verify ≥1 service with valid project path and host: containerapp |
| 4 | Infra templates exist | infra/ contains main.bicep at minimum |
| 5 | AZD installed + auth | azd version succeeds; azd auth login --check-status confirms auth |
| 6 | AZD environment exists | azd env list shows environment; if none, create with azd env new <name> and set AZURE_LOCATION |
Provision Loop
Provision Azure infrastructure using AZD and Bicep. Retry on fixable errors.
1. Run `azd provision`
2. If success → proceed to Deploy Loop
3. If failure → analyze the error:
a. Bicep validation error → fix infra/*.bicep files, retry
b. Quota exceeded → suggest different region or SKU, update env vars, retry
c. Permission error → STOP and flag for human (cannot fix IAM)
d. Naming conflict → adjust resource names in Bicep parameters, retry
e. Network/transient error → retry (max 3 attempts with backoff)
4. After applying a fix → re-run `azd provision`
5. Loop until provision succeeds or retries exhaustedLog every azd provision invocation and result to audit.log.
Deploy Loop
Deploy the application to the provisioned infrastructure.
1. Run `azd deploy`
2. If success → proceed to Smoke Test Protocol
3. If failure → analyze the error:
a. Build error → fix Dockerfile or build configuration
b. Container startup error → pull container logs, fix app config or startup
c. Health check failure → verify health endpoint exists and returns 200
d. Registry push failure → check ACR configuration and permissions
4. After applying a fix → re-run `azd deploy`
5. Loop until deploy succeeds or retries exhaustedLog every azd deploy invocation and result to audit.log.
Smoke Test Protocol
After a successful deployment, verify the live application works end-to-end.
- Get deployed URL —
azd env get-values→ extractSERVICE_WEB_ENDPOINT_URL. - Run smoke tests against the live URL:
- Health check:
GET /health→ HTTP 200 - API health:
GET /api/health→ HTTP 200 - Frontend loads:
GET /→ HTTP 200 with expected content - Critical path: Playwright
@smoketests against deployed URL
- Health check:
- Run the FULL E2E suite against the deployed URL. This is mandatory — every
E2E test that passes locally must also pass on the deployed environment:
All E2E tests must pass. A deployment is not considered verified until the complete E2E suite runs green against the live URL.PLAYWRIGHT_BASE_URL=<deployed-url> npx playwright test --config=e2e/playwright.config.ts - All tests pass → deployment verified. Update state and finish.
- Any test fails → enter Rollback Protocol.
Rollback Protocol
If smoke tests fail after deployment:
- Rollback: Re-deploy the previous successful container image tag using
azd deploy. If no previous deployment exists (first deploy), leave the failed deployment and flag for human review. - Verify rollback: Re-run smoke tests against the rolled-back deployment.
- Open GitHub Issue:
- Title:
[spec2cloud] Smoke test failure after deployment - Body: Failed smoke test results, deployment logs, container logs
- Labels:
spec2cloud,deployment-failure,needs-fix
- Title:
- Update state: Set phase back to
implementationwith failure details. - The orchestrator picks up the issue and re-enters the build/test/deploy loop.
AZD Commands Reference
| Command | Purpose |
azd init | Initialize project (shell setup only) |
azd env new <name> | Create a new environment |
azd env set <key> <value> | Set an environment variable |
azd provision | Provision Azure resources via Bicep |
azd deploy | Build and deploy the application |
azd env get-values | Retrieve deployed URLs and outputs |
azd down | Tear down all resources (only on explicit request) |
azd monitor | Open the monitoring dashboard |
State Updates
- After successful deployment: Record deployed URL, timestamp, container
image tag, and AZD environment name in
state.json. - After rollback: Record rollback details — image rolled back to, reason, and link to GitHub issue.
- Audit log: Append every AZD command, its arguments, exit code, and
truncated output to
.spec2cloud/audit.log.
[ISO-timestamp] increment={id} step=deploy action=azd-provision result=success
[ISO-timestamp] increment={id} step=deploy action=azd-deploy result=success url={url}
[ISO-timestamp] increment={id} step=deploy action=smoke-tests result=pass:{N}/fail:{N}Security Considerations
- Never log secrets or connection strings. Redact sensitive values before writing to logs or GitHub issues.
- Use managed identity for Azure resource access wherever possible. Avoid storing credentials in code or config files.
- Verify HTTPS is enabled on all deployed endpoints. Do not accept HTTP-only deployments.
- Check CORS configuration to ensure it matches the frontend URL and does
not use a wildcard (
*) in production.
Stack-Specific Details
See references/stack-deployment.md for AZD service structure, Container Apps
configuration, Dockerfile details, infrastructure templates, environment
variables, and smoke test commands.
Mandatory Completion Checklist
The orchestrator MUST verify ALL of the following before marking azure-deployment as complete:
- Full regression suite passes locally before deployment
azd provisioncompletes without errorsazd deploycompletes without errors- Smoke tests pass against the deployed endpoints (not localhost)
- HTTPS is enabled on all deployed endpoints
- Application logs show no startup errors (check via
azd monitor) - State JSON and audit log are updated with deployment URLs and status
BLOCKING: If any item is unchecked, the skill has NOT completed successfully. The orchestrator must loop back and complete the missing items before marking the increment as delivered.
Other versions2 projects use a version of this.
Word for word · 1
- crgarcia12/Liliput★ 4100% same
Edited · 0
None found.
Wrote their own version · 1
- codetesla51/skills★ 32same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository47 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- adrSkill
- api-extractorSkill
- architecture-mapperSkill
- aspireSkill
- audit-logSkill
- bug-fixSkill
- build-checkSkill
- cloud-native-assessmentSkill
- cloud-native-plannerSkill
- codebase-scannerSkill
- commit-protocolSkill
- contract-generationSkill
- data-model-extractorSkill
- ddd-modelingSkill
- dependency-inventorySkill
- deploy-diagnosticsSkill
- e2e-generationSkill
- error-handlingSkill
- extension-plannerSkill
- find-skillsSkill
- frd-generatorSkill
- gherkin-generationSkill
- human-gateSkill
- implementationSkill
- modernization-assessmentSkill
- modernization-plannerSkill
- performance-assessmentSkill
- playwright-cliSkill
- prd-generatorSkill
- research-best-practicesSkill
- resumeSkill
- rewrite-assessmentSkill
- rewrite-plannerSkill
- security-assessmentSkill
- security-plannerSkill
- skill-creatorSkill
- skill-discoverySkill
- spec-refinementSkill
- spec-validatorSkill
- state-managementSkill
- tech-stack-resolutionSkill
- test-discoverySkill
- test-generationSkill
- test-runnerSkill
- ui-ux-designSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

