plugin/skills/deploy-staging/SKILL.md
Use this skill when deploying a completed feature to staging for smoke-testing and verification before a production release — the deploy-to-staging workflow that builds, deploys to a staging environment, runs smoke tests, and verifies.
npx skillsauth add avav25/ai-assets deploy-stagingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Structured workflow for deploying to staging environment. Builds the application, deploys, runs smoke tests, and verifies the deployment.
Before running an imperative helm upgrade / kubectl apply against staging, check whether the cluster has a controller-driven flow.
| Marker | Implication |
|---|---|
| Application / Kustomization CRDs (Argo CD / Flux) | Push manifest changes to the staging git path; controller reconciles. See /deploy-production Step 0a for details. |
| ApplicationSet with pullRequest generator | Argo CD per-PR ephemeral environments — staging deploy creates a per-PR namespace automatically on PR open. |
| vcluster config or Loft Space CRDs | Loft / vCluster — virtual ephemeral staging clusters per branch. |
| tilt.yaml (root) | Tilt — local dev loop; staging usually still flows through Argo CD/Flux. |
Use the cloud-platforms skill for platform-specific kubectl/helm context (GKE/AKS/EKS).
For supply-chain integrity — staging is the natural validation gate for image signing (Cosign sign + verify), SBOM generation (Syft → CycloneDX), and SLSA provenance attestation. If the project ships any of these in CI, verify they ran successfully on the staging artefact before promoting to production.
// turbo
git branch --show-current
// turbo
git status --short
main or a release branchInvoke /run-tests sub-workflow. All tests must pass before deploying.
Read CLAUDE.md and project config to determine:
| Signal | Method |
|---|---|
| Dockerfile + K8s manifests | Container → Kubernetes |
| Dockerfile + docker-compose | Container → Docker Compose |
| Helm charts | Container → Helm |
| Terraform | Infrastructure as Code |
| Serverless config (serverless.yml, SAM) | Serverless deployment |
| Static site (Next.js, Vite) | CDN / static hosting |
| Platform config (Netlify, Vercel, Railway) | Platform deployment |
Build the application artifact:
| Stack | Command |
|---|---|
| Node.js | npm run build or pnpm build |
| Java | ./mvnw clean package -DskipTests |
| Python | docker build -t <image>:<tag> . |
| Go | go build -o bin/app ./cmd/api |
| .NET | dotnet publish -c Release |
docker build -t <registry>/<image>:<tag> .
Tag with git SHA or version:
docker tag <image> <registry>/<image>:<git-sha>
⚠️ Present deployment plan and request APPROVE before executing.
helm upgrade --install <release> <chart> \
-n staging \
-f values-staging.yaml \
--set image.tag=<tag> \
--dry-run
After APPROVE:
helm upgrade --install <release> <chart> \
-n staging \
-f values-staging.yaml \
--set image.tag=<tag>
docker compose -f docker-compose.staging.yml up -d
Follow platform-specific CLI or git-based deployment.
// turbo
kubectl get pods -n staging -o wide
Or curl health endpoint:
curl -s <staging-url>/health
Run critical path smoke tests:
// turbo
kubectl logs -n staging -l app=<app-name> --tail=50
Check for errors, warnings, or unexpected behavior in the first 2–5 minutes.
Append a deploy event to .ai-skills-memory/runs.jsonl per memory-discipline.md retention rules:
{"ts": "<ISO8601>", "event": "deploy", "env": "staging", "service": "<name>", "version": "<tag>", "method": "k8s|helm|docker|platform", "status": "success|fail", "duration_ms": N, "rollback": false}
## Staging Deployment Summary
- **Version**: [version/tag]
- **Branch**: [branch name]
- **Environment**: staging
- **Method**: [K8s/Helm/Docker/Platform]
- **Build**: [success/fail]
- **Deploy**: [success/fail]
- **Health check**: [pass/fail]
- **Smoke tests**: [pass/fail]
- **Staging URL**: [url]
- **Next steps**: [QA testing / production deploy]
If all checks pass, suggest:
/deploy-production/pre-commit, /create-pr (code ready)/deploy-productionAgent(devops-engineer), Agent(devops-architect) (deployment strategy design)runs.jsonl (deploy event per Step 5)development
Use this skill when running the recurring (daily) knowledge-base rescan for a repo that already has knowledge/.knowledge-sync.yml — the main-thread dispatcher that reads the config, computes the git delta since last_scanned_sha, maps changed paths to affected doc areas, early-exits cheaply when nothing changed, then fans out one Agent(content-writer) per affected area, applies the propose/direct update policy, advances the baseline only on success, and writes an L4 run log — all with the G1 untrusted-content choke-point, secret-scan, deny-list, and budget controls woven in. For first-time setup use /knowledge-sync-init.
development
Use this skill when bootstrapping scheduled knowledge-base sync for a repo that has no knowledge/.knowledge-sync.yml yet — to run one-time setup that detects the knowledge_root from CLAUDE.md/AGENTS.md, maps doc areas to source globs, records opt-in external sources (Linear/Notion/WebFetch, all disabled by default), captures a baseline last_scanned_sha, sets the per-area update policy, generates or seeds knowledge/CONVENTIONS.md, provisions the L4 memory dir, and offers to register the daily routine. Routes ongoing recurring sync operations to /knowledge-sync.
tools
Use this skill when bootstrapping a target repository to be ai-skills-aware — on the first run of any ai-skills workflow in a fresh repo, when adopting the ai-skills plugin in an existing repo, or after upgrading to a plugin version that adds new memory paths or templates, including when the user does not say "init" but asks to "set up" or "onboard" the repo — to detect codebase type, create CLAUDE.md + AGENTS.md scaffolding, initialize the .ai-skills-memory/ directory tree from L1 templates, and configure .gitignore. Idempotent — safe to re-run. Accepts `--codebase-type <type>` and `--overwrite`. Not for re-initializing only memory — use `/memory-init` instead.
tools
Use this skill when extending, repairing, or improving plugin assets, when ingesting a `/feedback` report as a fix-cycle backlog, or when you do not remember which lower-level command is right for the job — the umbrella workflow for ai-skills plugin-asset authoring and maintenance: creating, auditing, fixing, improving, refactoring, and migrating skills, agents, rules, hooks, prompts, schemas, and rubrics inside the plugin. Auto-classifies the request, loads the right knowledge skills (`@prompt-engineering`, `@context-engineering`, `@team-protocols`), and spawns the right subagents (`prompt-engineer`, `system-architect`, `python-engineer`, `software-engineer`, `qa-engineer`, `eval-judge`) via the `Agent` tool.