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

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.
claude-code · codex

Use this when

Use this when someone owes you a refund and getting it may take more than one support conversation or follow-up.

How it runs

  1. Gather the charge, reason for the refund, useful evidence, current status, and any earlier conversation or promise.
  2. Start or continue the claim through a support channel the user has approved, then note what happened and what should happen next.
  3. Follow up whenever a reply, promise, or deadline creates a useful next step; keep the case moving instead of treating a pending status as done.
  4. Stop when the refund arrives, or explain the genuine blocker when the next useful step needs the user.

Done when

The refund is received, or a genuine blocker requires the user. An open claim, promise, or pending refund is progress, not success; keep following up until the money arrives or no approved next step remains.

Why it works

Refunds often stall because a promise or pending status gets treated as completion. This loop keeps ownership through delays and handoffs until the money actually arrives.

Implementation note

Use truthful information and the permissions already granted. If the next step needs a new permission or decision, bring that blocker to the user instead of stopping silently.

Source: Forward Future

More maintenance loops

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.
maintenancehigh riskclaude-codecodex

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

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