/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

Weekly tech debt report

/scheduleloopreponew

Every Friday, compile a trend report of debt signals — TODO count, lint suppressions, type coverage, largest files — so the team sees drift before it compounds.

prompt
→ Claude
/schedule every Friday at 4pm, measure TODO/FIXME count, eslint-disable and ts-ignore counts, type coverage, and the five largest source files; append the numbers with week-over-week deltas to reports/tech-debt.md and call out the single worst trend in one paragraph
maintenancelow risk

Keep memory pins under control

/schedulenew

Audit and prune pinned memory contexts to stay under 7, replacing competing invariants atomically and checking load count before each pin.

prompt
→ Claude
/goal that must load every session (it is then surfaced deterministically by load pinned ). Pin sparingly — keep a context at ≤7 pinned (prune at 10; the pinned load cap of 100 is a safety net, not the budget). Decisions/patterns/status are NOT pin material. Before pinning, call load pinned to check the count; when an invariant supersedes an old one, unpin the old in the same step ( update memory(memory id=<old , delivery mode="on recall") ) so two competing invariants are never both pinned
maintenancemedium risk

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 risk