Menu
Deploy phase. Push to the deployment target, verify it's live, write README and DELIVERY.md.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Analyze phase. Turns scope.md and design.md into readiness.md with traceability, truths, build order, and scope-risk checks before BUILD.
Audit preferences.md stack choices against input docs for orthodox, idiomatic fit. Use before /expand when you want to validate that your technology choices match the problem domain.
Execute BUILD, ITERATE, or verify-fix work in small, test-first vertical slices. Use for multi-file implementation, failing tests, root-cause debugging, scope-creep risk, or when maintainability matters.
Build phase. Takes scope.md, design.md, and readiness.md and writes the actual code, tests, and deployment config in vertical slices.
Design phase. Takes scope.md and produces design.md with architecture, directory structure, interfaces, integration details, and justified complexity exceptions.
Distill raw input materials into structured reference docs. Use when docs/input/ contains messy client briefs, API specs, meeting notes, or domain knowledge that needs structuring before EXPAND.
| name | deploy |
| description | Deploy phase. Push to the deployment target, verify it's live, write README and DELIVERY.md. |
| disable-model-invocation | true |
Deploy the verified software to its target.
Read scaffolding/scope.md for deployment target
Read scaffolding/design.md for deployment config details
Pre-flight check — before attempting deploy, verify access for the target in scope.md:
Generic checks (all targets):
which <tool>)docker-compose.yml, Dockerfile, GitHub Actions workflow, platform config)Platform-specific examples:
git remote -v shows valid remote with push accessdocker-compose.yml exists, .env on hostIf any pre-flight check fails: STOP. Do not attempt deploy. Report what's missing.
Identify the rollback command before deploying. Write it down:
If this deploy breaks, rollback command: [specific command]
Examples:
git push origin main (re-triggers build from last good state)docker compose up -d --no-deps <service> with previous image tag pinned in .env or compose filedocker tag <prev> <latest> && docker push or redeploy previous imageThe rollback command goes into DELIVERY.md under "Incident Response."
Deploy to the specified target:
docker compose up -d on host (via SSH or CI)Verify it's accessible and working
Write README.md in the project root with:
Write DELIVERY.md in the project root. This is the client-facing handoff document. All projects get the same structure — depth scales naturally with the project's complexity.
# Delivery — [Project Name]
## What Was Built
[What it does, who it's for — 1-3 sentences]
## How to Use It
[Run command, URL, or access method]
## Acceptance Criteria — Verified
- [x] [Criterion 1] — Evidence: [how it was verified]
- [x] [Criterion 2] — Evidence: [...]
## Deferred Items
[Items from scope.md Deferred section. If none: "None — full scope delivered."]
## Known Limitations
[What it doesn't do, edge cases, performance bounds]
## Operational Notes
[How to monitor, restart, check logs, common issues. For simple tools: "Run [command]. No persistent state."]
## Architecture Overview
[Brief summary of how the system is structured. Point to scaffolding/design.md for full details.]
## Data & Migrations
[Current schema version, migration instructions, backup strategy. If stateless: "Stateless — no data persistence."]
## Security Posture
[Auth method, data handling, input validation, compliance notes. At minimum: "No secrets in code, HTTPS, parameterized queries."]
## Incident Response
[What to do when things break. Point to RUNBOOK.md if it exists. For simple tools: "Check logs, restart process, report issue."]
## Support Terms
[Bug-fix period, contact method, what's included vs. out of scope]
## Next Steps / Roadmap
[Recommended future work from deferred items, known limitations, and client input. If final: "No further work planned."]
## Version History
[v1 — date — summary of what was delivered]
[v2 — date — summary of iteration changes (if applicable)]
For simpler projects, sections will naturally be shorter (one-liners). The agent should not pad sections with filler — if a section is "N/A" or a single sentence, that's fine. The structure stays consistent so every delivery is navigable the same way.
If any gate condition fails, fix it and recheck. Up to 3 retries.
Log the result to scaffolding/log.md with URL/access method as evidence.
Git checkpoint:
git add -A && git commit -m "chore(deploy): deploy to [target]" -m "[URL or access method]\nGate: post-deploy PASS (attempt N)."
STOP here and report to the user:
✓ FULL PIPELINE COMPLETE.
[URL or access method]
[What was deployed and where]
[Summary of scaffolding/log.md — all phases, all gate results]
DELIVERY.md written with handoff details.
Scaffolding and input docs persist as project provenance.
To iterate: add feedback to docs/input/ and run /iterate.