--- name: eunomia-content-patrol description: Orchestrate the scheduled or manual eunomia.dev content operation. Use when an agent needs to read the rolling publication queue, invoke eunomia-social-radar for public performance and conversations, route explicitly authorized platform actions to publisher skills, and confirm end-to-end completion. This skill coordinates monitoring and publishing but does not own Daily Report, research-report, or Weekly Analysis workflows. --- # 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. ## Scheduled Execution Authority CLAUDE.md's Precedence Rule and Publishing section apply; this section only adds patrol-specific scope. A queue item marked `排队` within today's normal or catch-up slots is standing authorization for that action end to end (preparation, preview, publication, public-page QA, ledger updates) — resolve routine details from the queue, artifacts, ledgers, publisher conventions, and visible account state instead of re-confirming. No other queue status grants that authority, and manual patrol runs do not inherit it unless the user explicitly asks to execute the tasks. Mark a task blocked only after practical recovery paths have been attempted and a real external condition remains; record the attempted action and the exact condition. Medium and DEV publishers use their documented APIs by default; all other platform actions use normal visible-browser workflows. Never use hidden platform APIs, background endpoints, or scraping datasets. ## Visible Browser Recovery Before routing any browser-based platform action, confirm the persistent visible Chrome answers on CDP 9222. Every browser publisher depends on it, so a dead browser blocks the whole run, not one platform. - Probe with `curl -s --max-time 12 http://127.0.0.1:9222/json/version`. - Check the supervisor log `/var/log/gem/browser-supervisor.log`. Repeated `Chromium exited before CDP became ready: rc=-5` means Chrome is crash-looping, not merely restarting; a healthy restart logs `Chromium ready on 127.0.0.1:9222, pid=...`. - `rc=-5` is SIGTRAP from crashpad aborting when it cannot create `$HOME/.config/chromium/Crash Reports/new`. That directory being owned by root in the user's own `$HOME` causes the abort, and the profile directory can carry the same root ownership. Confirm with `stat -c '%A %U:%G %n' ~/.config/chromium` and `find ~/.config/browser -user root | head`. - Repair ownership only; never delete or recreate the profile, which holds the mounted login state: `sudo chown -R gem:gem ~/.config/chromium` and `sudo find ~/.config/browser -user root -exec chown gem:gem {} +`. Then wait for the supervisor to relaunch and re-probe 9222. - Verify the fix from the user's own `HOME` before concluding, because a clean `HOME` can mask the fault: launching with `HOME=/tmp/...` succeeds while `HOME=/home/gem` still fails. - After recovery, confirm the platform is still signed in before acting. Sessions survive the repair because only ownership changed. ## No-Filler Rule Do not manufacture a visible artifact to satisfy the scheduler. Match the outcome to the task: a publishing task requires a published item, while a monitoring task may produce an observation or response candidate. A draft or prepared artifact does not substitute for a scheduled publication. A run log is an audit record, not the substantive output, and should not be created only to satisfy cadence. Do not create per-article figure inventories, platform-hook notes, publish-QA notes, or other disposable workflow evidence. Keep necessary checks in working context and put only final platform artifacts, durable skill lessons, or real exceptions in the repository. ## Run Summary When a separate summary is useful, record one compact entry in `draft/media/YYYY-MM-DD/run-log.md` containing: - date and run mode - child skills invoked - published, reposted, or replied URLs - prepared artifact paths - social-performance or conversation findings worth acting on - blocked actions and their exact missing condition - next concrete action Do not copy full child reports, browsing transcripts, or raw metric inventories into the run log. Do not create a monthly daily-log file.