eunomia-social-radar

name

eunomia-social-radar

description

Monitor the continuing public performance and conversation around Eunomia blogs, reports, projects, and platform posts. Use when Codex needs to inspect published-content metrics, verify that pages and previews still work, find reposts or citations, read comments and replies, follow active discussions, identify response or repost opportunities, compare observations over time, and return actionable findings to eunomia-content-patrol. This skill uses normal visible browser interaction for social platforms and does not authorize a final reply, repost, or other engagement action by itself.

Eunomia Social Radar

Follow what happens after publication. Observe each relevant published item over time, understand the surrounding conversation, and return only findings that can improve distribution, responses, or future editorial work.

Use eunomia-community-radar instead when the task starts from external technical communities and seeks recurring questions rather than echoes of a known Eunomia publication.

Required Context

Read these before inspecting platforms:

• CLAUDE.md
• .agents/README.md
• today's media workspace and run log, if present: draft/media/YYYY-MM-DD/ and draft/media/YYYY-MM-DD/run-log.md
• .github/publisher/media/README.md
• .github/publisher/media/published.md
• .github/publisher/media/not-published.md
• .github/publisher/media/community-feedback.md
• relevant .github/publisher/media/platforms/*.json
• matching publisher skill for any platform being inspected

Use those records to identify the canonical article, every known platform post, publication time, account, and earlier observations.

Observation Scope

Prioritize:

• newly published blogs and their platform adaptations
• posts with active or unresolved discussion
• posts whose earlier observation requested a follow-up checkpoint
• older evergreen posts that receive a new citation, repost, or traffic signal

Do not treat the radar as an endless feed-reading exercise. Start from known published items, then follow their visible echoes and adjacent conversations.

Workflow

1. Verify The Published Surface

Confirm that the canonical page and known platform posts remain publicly reachable and that title, media preview, links, and visible formatting are intact. Report a broken or incorrect artifact immediately; do not silently edit or republish it.

2. Observe Performance

Collect only metrics visible to the normal account or public page, such as views, impressions, reactions, comments, replies, reposts, quotes, saves, clicks, or follower changes. Record the observation time and distinguish unavailable metrics from zero activity.

Compare a post with its own earlier checkpoints and, when useful, with similar posts on the same account and platform. Do not compare raw counts across platforms as if they measured the same behavior. Avoid strong conclusions from small or early samples.

3. Find External Echoes

Search for the canonical URL, exact title, distinctive phrases, project name, and author/account mentions. Look for reposts, quote posts, backlinks, citations, forum submissions, newsletters, and discussions that may not link the article directly.

Search engines can discover leads. Inspect the original public page before relying on a mention, quotation, or discussion context.

4. Read The Conversation

Read substantive comments, replies, quote context, objections, questions, and maintainer discussion. Separate:

• factual correction or broken-link reports needing prompt attention
• genuine technical questions worth answering
• disagreement that could improve or challenge the article
• useful practitioner evidence for future research
• praise or low-information reactions that need no response
• spam, abuse, confidential requests, or promotional bait to ignore

Do not optimize for replying to everything. A thoughtful unanswered technical question matters more than response volume.

5. Recommend The Next Action

For each actionable finding, recommend one of: reply, clarify the source, correct the canonical article, quote/repost with context, prepare a follow-up, capture a future research question, or take no action. Include the public URL, why the action matters, and any factual support a response needs.

Use the matching publisher skill to prepare platform-native reply or repost copy. When eunomia-content-patrol routes the action as part of today's tasks, complete the final interaction; the daily task already supplies the required authorization. In a standalone run, act when the user authorizes the action.

Browser Boundary

Use only normal visible browser interaction for LinkedIn, Xiaohongshu, Zhihu, Juejin, X, Reddit, Medium, DEV, Hacker News, Lobsters, and similar platforms. Do not use platform APIs, hidden endpoints, background requests, or scraping datasets. Search indexing can discover a lead but cannot replace reading the original visible post before acting on it.

Do not send DMs, connection requests, follows, likes, votes, or account-setting changes. Do not expose private analytics, customer information, or unpublished strategy in a response draft or log.

Output

Return a compact result to eunomia-content-patrol containing:

• items and platforms inspected, with observation time
• meaningful metric changes, without dumping every visible number
• reposts, citations, discussions, comments, or replies worth attention
• recommended actions and whether they are due in today's patrol
• the next useful checkpoint

After each real monitoring run, append one compact dated checkpoint to .github/publisher/media/community-feedback.md. Record meaningful public feedback, external echoes, actionable defects, the decision taken, and the next checkpoint. When nothing actionable changed, one concise line is enough; do not copy praise-only reactions, private analytics, raw metric dumps, or browsing transcripts.

Use draft/media/YYYY-MM-DD/run-log.md only for real execution exceptions or same-day actions that are not already captured in the feedback ledger. Do not duplicate the checkpoint there, create a monthly daily-log file, or create a standalone daily radar file. Update platform ledgers only after a real action or when the existing ledger schema explicitly stores observation status.

Load references/observation-guide.md when comparing performance or deciding whether a conversation warrants action.