Shadows Deploy Guardian
Pre-deployment verification checklist — tests, types, build, secrets scan, environment validation. Use before pushing to production or staging.
Like a lobster shell, security has layers — review code before you run it.
License
Runtime requirements
SKILL.md
Deploy Guardian — Pre-Deployment Verification
Version: 1.1.0 | Author: Shadows Company | License: MIT
WHEN TO TRIGGER
- Before deploying to production or staging
- User says "deploy check", "ready to deploy?", "pre-deploy", "deploy guardian"
- Before creating a release tag
- Before merging a major PR
WHEN NOT TO TRIGGER
- Local development iterations
- Draft PRs or WIP branches
- Exploratory prototyping with no deployment intent
PREREQUISITES
This skill requires git on PATH. Gates 2-4 auto-detect and run only the toolchain present in the project:
| Toolchain | Required for | Detection |
|---|---|---|
npm/npx | Node.js projects | package.json exists |
python/python3 | Python projects | setup.py, pyproject.toml, or requirements.txt exists |
cargo | Rust projects | Cargo.toml exists |
docker | Containerized builds | Dockerfile exists |
The agent MUST check which toolchain is available before running commands. Skip any gate sub-step whose toolchain is absent — do NOT fail the gate for missing optional toolchains.
PROTOCOL — 6 GATES
Each gate must PASS before proceeding. One FAIL = deployment blocked.
Gate 1 — GIT STATUS
git status
git log --oneline -5
git remote update --prune 2>/dev/null && git status -uno
Verify:
- Working tree is clean (no uncommitted changes)
- On the correct branch (main/release/deploy)
- Branch is up to date with remote (
git rev-parse HEAD==git rev-parse @{u}) - No merge conflicts pending
Gate 2 — TESTS
Detect the project type and run ONLY the matching test runner:
# Auto-detect: run the FIRST matching runner only
if [ -f package.json ]; then
npm test 2>&1
elif [ -f pyproject.toml ] || [ -f setup.py ] || [ -f requirements.txt ]; then
python -m pytest -v 2>&1 || python3 -m pytest -v 2>&1
elif [ -f Cargo.toml ]; then
cargo test 2>&1
else
echo "SKIP: No recognized test runner found"
fi
Verify:
- All tests pass (zero failures)
- No skipped critical tests
- Exit code is 0
Note: This executes project test scripts, which run code from the repository. Only run in trusted repositories or sandboxed environments.
Gate 3 — TYPE CHECK & LINT
Auto-detect and run ONLY the matching toolchain:
# TypeScript (if tsconfig.json exists)
[ -f tsconfig.json ] && npx tsc --noEmit 2>&1
# Python (if .py files exist)
[ -f pyproject.toml ] && python -m ruff check . 2>&1
# ESLint (if .eslintrc* exists)
ls .eslintrc* eslint.config.* 2>/dev/null && npx eslint . 2>&1
Verify:
- Zero type errors
- Zero lint errors (warnings acceptable)
- SKIP if no type checker / linter is configured (not a failure)
Gate 4 — BUILD
Auto-detect and run ONLY the matching build system:
if [ -f package.json ] && grep -q '"build"' package.json; then
npm run build 2>&1
elif [ -f Dockerfile ]; then
docker build --dry-run . 2>&1
elif [ -f Cargo.toml ]; then
cargo build --release 2>&1
else
echo "SKIP: No build step detected"
fi
Verify:
- Build completes with exit code 0
- Output artifacts generated in expected location
- SKIP if no build system detected (not a failure)
Note: Build commands execute project scripts. Same sandboxing considerations as Gate 2 apply.
Gate 5 — SECRETS SCAN
# Check for leaked secrets in recent commits (last 5)
git diff HEAD~5..HEAD -- . ':!*.lock' ':!*.sum' | grep -inE "(api[_-]?key|secret|token|password|private[_-]?key)\s*[:=]\s*['\"][^'\"]{8,}" || echo "PASS: No secrets pattern detected"
# Check .env files not committed to git
git ls-files | grep -E "\.env$|\.env\.\w+" | head -10
# Check .gitignore has secret patterns
if [ -f .gitignore ]; then
COVERAGE=$(grep -cE "\.env|secret|credential|\.pem|\.key" .gitignore)
echo "Gitignore secret coverage: $COVERAGE patterns"
fi
Verify:
- No secrets pattern in recent commits
- Zero
.envfiles tracked by git -
.gitignorecovers at least 3 secret patterns - No
.pem,.key,.p12files tracked
Limitations: This grep-based scan catches common patterns but is not a substitute for dedicated secret scanners (gitleaks, trufflehog, detect-secrets). For production environments, consider running a dedicated scanner as an additional step.
Warning: Command output may display matched secret-like patterns in the terminal. Run this gate in a secure terminal session where output is not logged to shared systems.
Gate 6 — ENVIRONMENT VALIDATION
Run concrete automated checks for the target environment:
# Check required env vars are documented
if [ -f .env.example ]; then
echo "PASS: .env.example exists ($(wc -l < .env.example) vars documented)"
else
echo "WARN: No .env.example — required variables not documented"
fi
# Check for pending database migrations (common frameworks)
[ -d migrations ] && ls -1t migrations/ | head -3
[ -d alembic/versions ] && ls -1t alembic/versions/ | head -3
# Check SSL cert validity (if curl available)
if command -v curl &>/dev/null && [ -n "$DEPLOY_URL" ]; then
curl -sI --max-time 5 "$DEPLOY_URL" | head -5
fi
# Check Docker health (if applicable)
[ -f docker-compose.yml ] && docker compose config --quiet 2>&1 && echo "PASS: docker-compose config valid"
Verify:
-
.env.exampleor equivalent documentation exists - No unapplied migrations in queue
- Target URL responds (if
$DEPLOY_URLis set) - Docker config valid (if applicable)
- SKIP individual checks when not applicable (not a failure)
SECURITY CONSIDERATIONS
-
Code execution: Gates 2-4 execute project scripts (
npm test,npm run build,cargo test). These commands run arbitrary code from the repository. Only run this skill on repositories you trust, or execute within a sandboxed environment (Docker container, CI/CD pipeline, OpenClaw sandbox mode). -
Secret exposure: Gate 5 scans diffs for secret patterns. Matched patterns are displayed in terminal output. Ensure your terminal session is not logged to shared monitoring systems.
-
Network access: Gate 6 optionally makes outbound HTTP requests (via
curl) only if$DEPLOY_URLis explicitly set. No other network access is required. -
No persistence: This skill does not modify any configuration files, install packages, store credentials, or make changes outside the terminal session. It is read-only except for the build artifacts produced by Gate 4.
-
Sandboxing recommendation: For maximum safety, run deploy-guardian inside a CI/CD pipeline or a sandboxed agent environment rather than directly on a developer workstation.
OUTPUT FORMAT
# Deploy Guardian Report
**Date**: [YYYY-MM-DD HH:MM]
**Branch**: [branch name]
**Commit**: [short SHA]
**Target**: [production/staging]
**Toolchain**: [detected: node/python/rust/docker]
## Gate Results
| # | Gate | Status | Details |
|---|------|--------|---------|
| 1 | Git Status | PASS/FAIL | [clean, correct branch, up to date] |
| 2 | Tests | PASS/FAIL/SKIP | [X passed, Y failed, or skipped reason] |
| 3 | Type Check & Lint | PASS/FAIL/SKIP | [errors count or skipped reason] |
| 4 | Build | PASS/FAIL/SKIP | [success or error summary] |
| 5 | Secrets Scan | PASS/FAIL | [patterns found or clean] |
| 6 | Environment | PASS/WARN/SKIP | [checks run and results] |
## Verdict: [CLEAR TO DEPLOY / BLOCKED / CLEAR WITH WARNINGS]
## Blockers (if any)
1. [What needs to be fixed — file:line reference]
## Warnings (if any)
1. [Non-blocking issues to be aware of]
## Recommended Deployment Command
[The actual deploy command to run]
RULES
- All gates must pass — no exceptions, no overrides
- Secrets gate is non-negotiable — one leaked secret = full stop
- Auto-detect toolchain — never run commands for absent toolchains
- SKIP is not FAIL — absent toolchains produce SKIP, not FAIL
- Test failures block deployment — even flaky tests must be investigated
- Document blockers — always explain WHY with file:line references
- Never auto-deploy — always wait for explicit user confirmation
- Trusted repos only — warn user if running on an unfamiliar repository
Published by Shadows Company — "We work in the shadows to serve the Light."
Files
1 totalComments
Loading comments…
