Use cases
Harden a release before morning
Use a finite Nightshift contract to close test, documentation, packaging, recovery, and security gaps before release review.
Answers: use a coding agent to harden a software release · Updated
Create one item per release risk, attach the exact project gate, and keep publishing outside the shift unless explicitly authorized. The morning handoff should make every change and remaining decision easy to review.
Build the release contract
Start from known risks and failed checks, not a generic cleanup wish.
- Repair failing or flaky tests.
- Verify package contents and ignored files.
- Check install and upgrade documentation.
- Review platform-specific runtime paths.
- Close confirmed security findings privately.
Keep commits meaningful
Separate changes that deserve independent changelog, rollback, or review. Run the release gate immediately before each commit and leave tags, merges, and publishing to an explicit owner action.
- One coherent outcome per commit.
- No version bump unless the release process calls for it.
- No push on momentum.
Morning review
Check the local history, gate results, package artifacts, parking-lot decisions, and any red-tagged item before choosing whether to merge or release.
Start with a bounded prompt
This prompt names the outcome and preserves Nightshift’s review boundary. Paste it into the supported coding host from the project you want to change.
Draft a finite Nightshift release-hardening contract from this repository's known risks, existing checks, packaging, documentation, and platform paths.What this workflow does not claim
- Publishing, tagging, merging, and version changes remain separate explicit maintainer actions.
- Each risk should have independent verification and a reviewable rollback boundary.
Evidence and sources
These links support the released behavior, public outcomes, or problem language described on this page.