Implement and Deploy
Overview
Full lifecycle: implement feature, containerize, CI/CD pipeline, deploy to Azure, verify live.
Core principle: Modular phases with skip-if-done checks and user prompts at decision points.
Announce at start: "I'm using the implement-and-deploy skill to build and deploy this feature."
Phase 1: Repo Setup
Skip if: Already in a git repo with remote configured.
- Ask user: create new repo or use existing?
- If new:
gh repo create <name> --public --cloneand scaffold project - If existing: verify
git remote -vhas a GitHub remote - Create feature branch:
git checkout -b feat/<feature-name>
Phase 2: Implement Feature
Skip if: User confirms feature code is already complete.
- If frontend work: invoke
frontend-designskill for UI quality - Implement the feature following existing project patterns
- Write tests if test framework exists
- Commit work:
git add . && git commit -m "feat: <description>"
Phase 3: Local Test
Skip if: User confirms local testing passed.
- Run project test suite if it exists
- Start app locally and test with
curlor equivalent - If frontend: use
agent-browserto visually verify the UI - Fix any failures before proceeding
Phase 4: Docker + CI/CD
Skip if: Dockerfile and .github/workflows/deploy.yml already exist and are correct.
- Create
Dockerfile(multi-stage build, minimal final image) - Build and test locally:
docker build -t <app> . && docker run -p 8080:8080 <app> - Create
.github/workflows/deploy.yml:- Trigger on push to
main - Build Docker image
- Push to Azure Container Registry (ACR)
- Deploy to Azure Container Apps
- Trigger on push to
- Commit CI/CD files and push branch
- Open PR:
gh pr create --title "feat: <description>" --body "<summary>"
Phase 5: CI/CD Monitor
Skip if: PR checks already passing.
- Delegate to
/aurora: "Monitor CI/CD pipeline for PR #N in <owner>/<repo>. Report status every 30s until complete." - If pipeline fails: read logs, fix issue, push fix, re-monitor
- Once green: merge PR via
gh pr merge --squash
Phase 6: Azure Deploy
Skip if: App already deployed and running at expected URL.
- Ask user for: Azure resource group, ACR name, region (or use defaults)
- Ensure Azure resources exist (create if needed):
az group create --name <rg> --location <region> az acr create --name <acr> --resource-group <rg> --sku Basic az containerapp env create --name <env> --resource-group <rg> - Build and push image:
az acr build --registry <acr> --image <app>:latest . - Deploy container app:
az containerapp create --name <app> --resource-group <rg> \ --environment <env> --image <acr>.azurecr.io/<app>:latest \ --target-port 8080 --ingress external - Capture the live URL from output
Phase 7: Verify Deployment
Skip if: Live URL responds correctly.
- Test live URL with
curl— check HTTP 200 - If frontend: use
agent-browserto visually verify deployed UI - Delegate to
/aurora: "Check logs for <app> in resource group <rg> — report any errors." - If verification fails: analyze logs, fix, push, wait for CI/CD, redeploy, re-verify (max 3 retries)
- Present final summary: live URL, resource group, container app name
When to Stop and Ask
- Azure credentials not configured (
az loginneeded) - User hasn't specified which feature to build
- Deployment target ambiguous (Container Apps vs App Service vs ACI)
- Budget/cost concerns about Azure resources
Integration
- frontend-design — Invoke for any UI work in Phase 2
- superpowers:verification-before-completion — Run before declaring done
- /aurora — Delegate CI/CD monitoring (Phase 5) and Azure log checks (Phase 7)
- agent-browser — Visual testing in Phases 3 and 7