AddThisFeature

Scheduled Publishing

Publish or unpublish content automatically at a chosen future time.

involved Data & Content

What it adds

Durable, idempotent scheduled transitions that survive worker downtime and stay correct when the content or the author's permissions change.

What your agent is told to do

5
  1. 1

    Persist the schedule on the record itself, not only in a job queue. A queue that is drained, migrated, or lost must be recoverable by re-reading the pending schedules from the database.

  2. 2

    Make the transition job idempotent and keyed to the intended run. Running it twice, or late, must produce the same result as running it once on time.

  3. 3

    On worker recovery, process overdue schedules rather than skipping them — but cap how far back you will reach, and report anything published significantly late instead of doing it silently.

  4. 4

    Define what happens when the content is edited after being scheduled: publish whatever is current at the moment of firing, or publish the version that was scheduled. Say which, and show the user that rule in the scheduling UI.

  5. 5

    Do not build your own status model or your own time-zone picker. The draft/published states and their access rules are owned by Draft and Publish States; time-zone selection and DST handling are owned by Time Zone-Aware Scheduling. Extend both rather than adding a second one.

Edge cases it handles

6
  • A schedule must be cancellable, and cancelling must remove the pending job as well as the field on the record.
  • If the author loses permission to publish before the fire time, the schedule must not run on their behalf — fail it and notify someone.
  • Manually publishing before the scheduled time must clear the schedule, not leave a job that republishes later.
  • Deleting or archiving the record must cancel every schedule attached to it.
  • A scheduled unpublish and a scheduled publish on the same record must resolve in a defined order, not by whichever job wins.
  • Show the pending time in the user's own zone alongside the stored intent, and warn when a scheduled time has already passed.

Definition of done

8
  • Pending schedules are stored on the record and can be rebuilt after a queue loss.
  • Running the transition job twice produces the same result as running it once.
  • Overdue schedules are processed on recovery within a defined window and reported when late.
  • The changed-content rule is documented and visible where users schedule.
  • Cancellation, manual publish, permission loss, and deletion all invalidate the schedule.
  • Status model and time-zone handling reuse the existing features rather than duplicating them.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.