/goalmaintenancehigh riskintermediatesafety C · 65Forward Futurepre-dates current gate · under review

Propagate a value everywhere it lives

Update every copy of a changed value across the project, hunt down leftovers, and prove only intentional old references remain.

prompt
→ Claude
After changing a version, count, rule, name, or configuration, list where the new value belongs and update it. Search the project for the old value and related forms. Review each match: fix real stale values, but keep intentional history, examples, migrations, or compatibility rules. Repeat until zero stale values remain. If one returns for two rounds, stop and identify what may be regenerating it. Return changes, intentional matches, and search output.
claude-code · codex

Use this when

Use this after changing something that appears in several files—such as a version number, feature name, count, rule, setting, or identifier—and every copy must stay consistent.

How it runs

  1. List the files, documentation, settings, generated outputs, or operational notes that are expected to copy the changed value.
  2. Update the known copies, then search the whole project for the old value, old spelling, and other likely leftover forms.
  3. Decide whether each match is truly stale or intentionally preserved history, an example, a migration, or a compatibility rule; fix only the stale matches.
  4. Repeat the same searches until no stale match remains; if one comes back for two rounds, stop and identify the generator or process restoring it.

Done when

No unintended copy of the old value remains. The final searches find only references that are intentionally historical or required for examples, migrations, or compatibility, with a reason recorded for each one.

Why it works

The repeat search is the important part: it catches copies missed by the first update. Reviewing each match also prevents a broad replacement from corrupting historical notes, migration code, or examples that intentionally show the old value.

Implementation note

The exact files depend on the change. The original submission used several operational notes and procedure files; another project might need code, tests, documentation, deployment settings, generated files, or all of them.

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