Project
Ready shifts for Cursor, Codex, and Claude Code
Choose a released Nightshift contract: product, tests, quality, maintenance, security, accessibility, releases, performance, incidents, docs, research, SEO.
Updated
What ready-made shifts does Nightshift include?
Ready shifts are bounded operating contracts, not generic prompts. Thirty of them cover product, tests, quality, maintenance, security, accessibility, releases, pull requests, builds, migrations, incidents, performance, runbooks, toil, onboarding, and architecture. Each states when it applies, how it ends, what evidence it requires, what it refuses, and whether it supports repository work, artifact work, or both.
Improve the product when no backlog is ready
Product evolution researches the product, its users, repository evidence, and relevant public sources before ranking reversible opportunities. Owner walkthrough instead pursues one objective supplied verbatim by the owner.
- Product evolution — open-ended, evidence-ranked product improvement.
- Owner walkthrough — Guided-only work toward one owner-defined objective.
- Use for searches such as “use Codex to enhance my product” or “use Claude Code to improve this app.”
Show me the ready-made shifts that can improve this product. Explain the evidence, ending, and risk of each option; do not start yet.Increase coverage and repair unstable tests
Coverage hunt follows high-value untested behavior instead of padding a percentage. Flaky-test repair begins with instability evidence and a declared repetition budget, then fixes only demonstrated causes.
- Coverage hunt — behavior-protecting tests until quitting time.
- Flaky-test repair — reproduce, repair, and repeat without retries or weaker assertions.
- Useful for “Codex low-coverage modules overnight” and “Claude Code flaky test repair.”
Use Nightshift to inspect this repository's testing gaps. Compare the coverage and flaky-test shifts, then wait for my choice.Fix quality debt and reproducible defects
Clear quality debt works the finite list produced by the repository’s lint, type, and test tooling. Defect hunt runs a review–fix–rescan loop until a clean pass or deadline.
- Clear quality debt — finite repository-owned tool findings.
- Defect hunt — open-ended bug review with convergence.
- No suppressions, deleted tests, or manufactured findings.
Clean warnings, dead code, and source markers
Maintenance shifts keep evidence attached to each change. CI warning cleanup separates owned warnings from upstream output; dead-code cleanup requires an existing analyzer; TODO debt distinguishes defined work from product decisions.
- CI warning cleanup — fix owned warnings at the cause.
- Dead-code cleanup — remove only analyzer-proven unused paths.
- TODO and FIXME debt — complete actionable comments, stage ambiguous intent.
Align APIs, documentation, and localization
These finite contracts follow sources of truth already established in the repository. Breaking API choices and language judgment remain with the owner.
- API contract drift — align non-breaking server, schema, client, and fixture artifacts.
- Documentation drift — make in-repo docs match the current tree.
- Localization parity — repair objective key structure without inventing translations.
Upgrade dependencies and clear advisories
Dependency upgrades work direct packages one at a time after reading migration notes. Vulnerability sweep starts with the project’s audit tool and works critical and high advisories first.
- Dependency upgrade sweep — patches, then minors, then bounded majors.
- Vulnerability sweep — never downgrade, suppress, ignore, or force an advisory away.
- Unfixed transitive advisories and risky majors are parked with evidence.
Repair accessible surfaces and selected issues
Accessibility repair works objective violations from checks the project already runs without claiming compliance. GitHub issue hunt consumes only issues the owner explicitly imported and never writes back.
- Accessibility repair — configured scanner findings, no redesign or compliance claim.
- GitHub issue hunt — explicit imported source, reviewed before promotion.
- Every external reply, merge, release, and push remains a separate maintainer action.
Research, audit, and write without a repository
Artifact-compatible shifts work from a persistent folder and leave reviewable receipts instead of Git commits. They preserve citations, uncertainty, decisions, and output checks.
- Research synthesis — reconcile an approved source set into a cited report.
- Documentation writing — create audience-specific docs grounded in authoritative references.
- SEO audit — inspect technical, content, crawl, accessibility, and performance evidence without promising rankings.
Prove a release, a branch, or a build
Four finite contracts check a named candidate against a named baseline and report what they found. None of them publishes, merges, or tags; the maintainer does that after reading the evidence.
- Release readiness — compare a release baseline with a candidate without publishing anything.
- Pull-request readiness — branch-scoped acceptance against the issue’s criteria before human review.
- Build reproducibility — follow the documented clean setup and build paths and report what does not hold.
- Migration compatibility — guarded framework, dependency, configuration, and data migrations.
Follow up on incidents, performance, and operations
These shifts start from evidence the owner supplies: a postmortem, a benchmark or profiler run, a runbook, or a record of repeated manual work. Each turns that evidence into repository changes with measurements attached.
- Incident follow-up — repository actions derived from a supplied postmortem, timeline, logs, or linked issues.
- Performance regression — a measured change against an existing baseline, never a claim without numbers.
- Runbook verification — safe replay of an operational procedure using the observability the project already has.
- Toil reduction — automate repeated manual work when its frequency and failure cost are documented.
See the codebase and the product as a newcomer
Three finite contracts read the project the way a stranger would and fix what that reading proves.
- Developer onboarding — follow the public checkout and setup docs through one verified change.
- Architecture health — a reviewable picture of dependency, boundary, ownership, and cycle cost from repository evidence.
- Product journey — exercise a named persona’s route and fix the reproducible gaps it exposes.
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.
Show me the ready-made Nightshift shifts that apply to this project, explain why each fits, and wait for my choice before composing or starting anything.What this workflow does not claim
- Every catalog entry declares its own support and ending conditions; inapplicable entries must be skipped.
- Owner walkthrough is Guided-only because its objective must come directly from the owner.
Evidence and sources
These links support the released behavior, public outcomes, or problem language described on this page.