/schedule should be reserved for tasks with genuine time-dependent triggers — work that becomes meaningful only after some external condition elapses. Offering to schedule well-scoped follow-up work for “next week” when the context is loaded right now is a category error: it pays the cache-miss + context-reload cost twice (once now to write the schedule, once next week to execute) for zero benefit.

Why: Rich’s call-out 2026-04-28T17:25 after I offered to /schedule a CLAUDE.md cross-pollination follow-up in 1 week: “why would we wait a week to do that?” The work was well-scoped (mirror the 4 sister CLAUDE.mds; lock test-pyramid-specific concerns), the pattern was established (5-rep cross-pollination sweep), the context was fully loaded. Doing it immediately took 15 minutes; deferring to a scheduled background agent would have meant context-reload + re-establishing pattern conventions + re-verifying cross-references — easily 30+ minutes of incremental cost for the same output, with the added risk that the pattern might drift in the intervening week. Recorded as v3.4 methodological observation #1.

How to apply:

When offering /schedule for follow-up work, apply this filter:

LEGITIMATE schedule targets (genuine time-dependent triggers):

  • Cleanup-after-soak (e.g., “remove the feature flag in 2 weeks once metrics confirm rollout success”)
  • Ramp-after-metrics (e.g., “advance from 10% → 50% rollout in 7 days if error rate stays under threshold”)
  • Recurring sweeps (e.g., “weekly partner-pipeline triage”)
  • Long-soak verification (e.g., “check 30-day uptime + summarise” — only meaningful after 30 days)
  • One-time gates that fire on calendar (e.g., “1 week before launch, confirm comms cadence”)

ILLEGITIMATE schedule targets (do it now):

  • “The same well-scoped thing, but later” — context-reload cost is real
  • Follow-up work with no time-dependent trigger
  • Polish / hardening passes that have no waiting cost
  • Work where the reason to defer is “I’m not sure if it’s needed” — that’s a clarification question, not a schedule item

Default: do it now. Reach for /schedule only when you can articulate the specific time-dependent trigger that makes deferring strictly better than immediate execution.