Project
Ready-made shifts for Codex and Claude Code
Choose a released Nightshift contract for product improvement, testing, quality, maintenance, contracts, dependencies, security, accessibility, localization, or selected issues.
Answers: ready-made coding-agent shifts · Updated
Ready shifts are not generic prompts. Each released contract states when it applies, how it ends, what evidence it requires, what it refuses to do, and which project gate must stay green. Ask Nightshift what fits the repository, review the proposed work, then choose whether to run it.
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.
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.