
Run the recurring maintenance pass that keeps an automated social queue healthy — audit scheduled drafts for stale content, check staged media, fill the queue to its depth target, verify recent publishes against known API inconsistencies, and report every manual action needed. Use when someone says "run the social queue check", "fill the queue", "is next week's social covered", or wants a recurring/scheduled social posting agent. Do NOT use for first-time setup — use social-stack-bootstrap; for changing slot times or depth targets, use posting-cadence-designer; for producing the images themselves, use social-asset-pipeline.
---
name: Scheduling Agent Loop
description: Run the recurring maintenance pass that keeps an automated social queue healthy — audit scheduled drafts for stale content, check staged media, fill the queue to its depth target, verify recent publishes against known API inconsistencies, and report every manual action needed. Use when someone says "run the social queue check", "fill the queue", "is next week's social covered", or wants a recurring/scheduled social posting agent. Do NOT use for first-time setup — use social-stack-bootstrap; for changing slot times or depth targets, use posting-cadence-designer; for producing the images themselves, use social-asset-pipeline.
---
# Scheduling Agent Loop
This is the run that makes the operation "automated." It executes against STACK.md, CADENCE.md, and ASSETS.md as ground truth and never re-litigates them. Designed to run on a schedule (e.g. every 2–3 days) or on demand. Order matters — audits run before anything new is created.
## The loop, in order
**1. Audit scheduled drafts for staleness.** List everything currently scheduled (remember the tooling blind spots recorded in STACK.md and CADENCE.md — manually scheduled slots may not appear in queue endpoints; check drafts by status too). Read each draft against current reality — and name your reality source in the report: the product's site, changelog, release notes, README, or the user directly. Check product names, client names, prices, dates, feature claims, links. If no reality source is available this run, do not report the queue as clean — report it as **unaudited** and ask the user for a reality check. Content written two weeks ago and scheduled forward is the most common silent failure in automated social — it ships confidently wrong. Flag every stale draft with its scheduled send date and what is wrong. If editing scheduled drafts is a manual boundary in STACK.md, do not delete-and-recreate without explicit authorization — report for human correction, ranked by soonest send date.
**2. Check staged media.** Inventory uploaded-but-unattached media before generating anything. Match staged files to upcoming slots first. Consult ASSETS.md if social-asset-pipeline is in use; if it is absent, the scheduler's own media library is the only media ground truth — do not invent one.
**3. Measure queue depth.** Days of coverage per channel against CADENCE.md's target. Count manually scheduled slots the queue tools cannot see. Report per-channel: covered through <date>, target <date>.
**4. Fill the gap.** For each unfilled slot inside the target window: draft content appropriate to the slot's weight (as defined in CADENCE.md), attach staged media (or invoke social-asset-pipeline if none fits), schedule via the scheduler's working tools. Respect STACK.md's manual boundaries — anything requiring a UI step goes on the handoff list, never silently skipped. **If CADENCE.md is missing or lacks slot definitions, fill nothing.** Do not invent a slot pattern from a bare depth target — report the gap and route to posting-cadence-designer. An unfilled queue is recoverable; posts scheduled to invented slots are live mistakes.
**5. Verify recent publishes.** For posts past their send time: confirm actually-published state. Do not trust a single field — check for the known inconsistency classes recorded in STACK.md (e.g. a published URL present while the published-at timestamp is missing). If the stack cannot enumerate past posts, verify against the post IDs recorded in previous runs' reports — this is why step 6's report lists every scheduled ID; each run's report is the next run's verification input. If neither enumeration nor prior-run IDs exist, state the limitation in the report rather than claiming verification. Anything ambiguous gets flagged for one-time manual verification rather than assumed published or re-posted — re-posting on a false negative is worse than a missed slot.
**6. Report.** End every run with a structured summary:
```
## Queue report — <date>