Loop/loopMaintenancehigh riskintermediatesafety C · 55Forward Futurepre-dates current gate · under review

Define done before Codex starts

Set the completion contract up front, track proof for every requirement, and block partial work from being called done.

prompt
→ Claude
Run $goal-planner-codex [task] for long-running Codex work where partial work could be mistaken for done. Landing a PR and verifying production is one example. Before acting, define every required outcome and its evidence. After each bounded action, mark requirements proved, weak, missing, or contradicted. Complete the Goal only when all are proved; otherwise stop as blocked, stalled, or exhausted. Ask before creating Goal state. Finish with the requirement-to-evidence table, status, owner, and next action.
claude-code · codex

Use this when

Use this for long-running Codex work, pull requests, runtime checks, or user-visible artifacts where a plausible partial result could be mistaken for completion.

How it runs

  1. Recover a measurable definition of done for every ambiguous requirement.
  2. Record the requirements, scope, non-goals, evidence plan, and current status without expanding the requested work.
  3. Execute one bounded action at a time and attach current evidence to each affected requirement.
  4. Audit every requirement before closure and preserve honest blocked, exhausted, stalled, or contradicted states.

Done when

Every Codex Goal requirement has current, adequate proof. The final audit contains no weak, missing, or contradicted required item; otherwise the work remains open, blocked, or exhausted.

Why it works

A durable completion contract keeps the definition of done visible across long sessions. Mapping every requirement to evidence makes false completion easy to detect.

Implementation note

Use $goal-planner-codex only when the user explicitly asks for a Codex Goal or completion audit. Create native Goal state only with approval; ordinary task planning does not need it, and budget exhaustion never counts as success.

Source: Forward Future

More maintenance loops

Upgrade to current Node LTS

Loop/goallooprepo

Move the project to the current Node LTS across .nvmrc, CI config, Dockerfiles, and engines, fixing deprecations until everything is green on the new runtime.

prompt
→ Claude
/goal the project runs on the current Node LTS — update .nvmrc, the engines field, CI workflow files, and any Dockerfile base images to the LTS version, then run install, build, lint, and the full test suite on it, fixing deprecation warnings and breakages one at a time; stop when all are green or after 15 turns
maintenancemedium riskclaude-codecodexcursor

Prove your backups actually restore

Restore random real recovery points, verify integrity and RPO/RTO, and keep every failure as a regression drill.

prompt
→ Claude
For each required recovery scenario, randomly select an eligible real backup or recovery point and restore from zero in a disposable, isolated clean-room using only documented materials. Verify integrity, dependencies, representative reads and writes, and actual RPO and RTO. Repair one blocker, destroy the environment, and retry fresh. Stop when every scenario reaches its predefined consecutive-success streak or an exception is explicitly accepted. Never overwrite production, expose restored data, or initiate failover without approval.
maintenancehigh riskclaude-codecodex

Chase a refund until it lands

Open the claim, watch replies and deadlines, and keep the case moving until the money actually arrives.

prompt
→ Claude
Get my refund for [company and charge info]. Start the claim now through an approved support channel, then keep following up on replies, promises, and deadlines until the refund arrives. Keep a short case note so each follow-up has context. Stop only when the refund is received or you are genuinely blocked and need me.
maintenancemedium riskclaude-codecodex