Deployment
Use when tested code must be released with versioning, rollout, smoke checks, and a rollback path.From its SKILL.md
npx -y skills add douglance/sdlc-plugin --skill deploymentAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
1.8 KB, as published. Nobody here has run it
Use lifecycle-documentation only when the result needs a durable artifact or handoff.
Ship it safely. Take built-and-tested code to its target environment with a path forward and a path back. Decide the version, run the release, confirm it works in place, and be ready to roll back the instant it doesn't.
A release is only done when a smoke check proves the deployed version is healthy. "It deployed" is not the same as "it works."
</what-to-do> <supporting-info>The release loop
- Confirm the build and tests are green for the exact commit you are shipping.
- Choose the version and tag it; record what changed.
- Roll out — prefer staged/canary over big-bang where the target supports it.
- Run smoke checks against the live target. Healthy → done. Unhealthy → roll back, don't debug in prod.
What to get right
- Rollback first — know the down path (previous version, feature flag, revert) before you push the up path.
- Config and secrets — environment config and secrets are correct for the target; secrets never land in the artifact, logs, or VCS.
- Versioning — tag the release so the deployed version is traceable to a commit.
- Smoke checks — a minimal end-to-end probe of the live system, not just "the process started."
What to produce
The version shipped, the rollout method used, the smoke-check result, and the exact rollback command for this release.
</supporting-info>