From lo-swe
Deploy phase. Push to the deployment target, verify it's live, write README and DELIVERY.md.
How this skill is triggered — by the user, by Claude, or both
Slash command
/lo-swe:deployThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Deploy the verified software to its target.
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.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub rcsnyder/lights-out-swe-plugin --plugin lo-swe