Eunomia Content Patrol

Eunomia Content Patrol

Run the content operation as a thin orchestrator. Delegate substantive work to the owning skill, then confirm the public result without creating filler.

Required Context

Read these before routing work:

• CLAUDE.md
• .agents/README.md
• draft/plan/README.zh.md
• draft/plan/publishing-queue.zh.md
• today's draft/media/YYYY-MM-DD/ workspace and recent run log, when present
• .github/publisher/media/README.md
• .github/publisher/media/community-feedback.md
• .github/publisher/media/published.md
• .github/publisher/media/not-published.md
• relevant .github/publisher/media/platforms/*.json

Role Boundary

This skill:

• reads operational state;
• finds the first eligible authorized task;
• invokes the correct child skill;
• checks that preparation, publication, and public-page verification completed;
• updates the queue, ledger, and compact run record when useful.

It does not:

• search news or choose a thesis;
• write a Blog article, platform post, or reply;
• pretend a draft or open PR is a completed publication;
• perform a child publisher's platform work directly.

Daily Report, Weekly Analysis, and research-report production belong to a separate workflow. Do not invoke, schedule, draft, or publish them from this patrol.

Routing Map

• Invoke eunomia-social-radar for public performance, citations, comments, discussions, and response opportunities.
• Invoke blog-writer and blog-writing-style for project articles, tutorials, releases, engineering explanations, and explicitly human-editorial Blog work.
• Invoke the matching platform publisher for authorized LinkedIn, Xiaohongshu, Zhihu, Juejin, X, Reddit, Medium, DEV, Hacker News, or Lobsters actions.
• Invoke content-launch-planner only when a new multi-platform launch needs a plan not already represented in the queue.

Do not duplicate a child skill's workflow inside this orchestrator.

Daily Orchestration

1. Read the rolling queue, prepared artifacts, platform ledgers, and the previous run's next action. A global pause overrides every item it covers. Scan from the top for the first eligible unfinished task explicitly marked 排队; bypass 待确认 and 阻塞 items without letting them stall unrelated platforms, while 跳过 records a permanently rejected item.
2. Invoke eunomia-social-radar to refresh the observable results and active conversations around published content.
3. Collect the child results and identify the publication actions authorized for the current window. The normal target is one publication per local calendar day. If recent days with eligible queue work ended without a confirmed publication because of an operational blocker, carry one catch-up slot per missed day. Use those slots on the next eligible tasks, never more than one publication per platform in the same day. Intentional pauses and days with no eligible task do not create catch-up slots.
4. Invoke the matching publisher skill for each authorized action. Let that skill own copy adaptation, its documented API or visible-browser submission path, preview, final public-page QA, the action itself, and platform-ledger updates. If one action reaches a real platform blocker, mark it 阻塞 with the exact recovery condition and continue to the next eligible task; do not consume a publication or catch-up slot until a public result is confirmed.
5. Confirm the observable result returned by each child skill. Update the rolling queue and platform ledger first. If a separate run record is useful, write completed actions, real URLs, artifact paths, blockers, and next actions to draft/media/YYYY-MM-DD/run-log.md.
6. Confirm that eunomia-social-radar appended today's compact checkpoint to .github/publisher/media/community-feedback.md. Do not copy that checkpoint into the run log.

The platforms/*.json files are the canonical record; published.md and not-published.md are readable snapshots that drift if a run edits only the JSON. When a run changes a confirmed publication, update the matching snapshot in the same commit: add the new row to published.md, remove or update the not-published.md row, and refresh both Last checked: dates. Treat a snapshot row that contradicts the live public page as a defect to reconcile (the 2026-09-23 run found published.md lagging the JSON by 25 confirmed Juejin entries and still marking Agent Sandbox Needs repair after its duplicate body had been repaired and confirmed). Keep each snapshot's existing line endings: published.md uses LF while not-published.md uses CRLF.

check_media_ledger.py now enforces this: beyond source coverage it fails with exit 2 when any confirmed ledger entry's url or evidence_url is absent from published.md, so run it after any ledger change instead of eyeballing the two files. The same 2026-09-23 run found the drift class was not Juejin-specific: Zhihu was short 40 confirmed rows and LinkedIn was short every entry whose only evidence was a search URL, while the checker still exited 0.

It also fails when a summary date lags the ledgers: sources.json last_checked and the snapshot's Last checked: line must each be at least as recent as the newest per-platform last_checked. The same 2026-09-23 run found both stale — the checker had been printing a 2026-08-02 headline date that was seven weeks behind the platforms/*.json files it summarizes — so refresh those two summary dates whenever the run touches the ledger.

Do not create a standalone orchestration report.