Workflows: audits, suggestions, the content-to-learning loop, regional planning, timing and durable delivery

Moved out of SKILL.md so the always-loaded file stays small. Read the section the request needs, not the whole file.

Independent profile and post audits (no external writes)

When the user asks to optimize actual social profiles or gain more legitimate views/impressions/likes, do not reuse one generic score across all networks. Read references/profile-post-audit.md, then choose each specific platform’s field checks and source from scripts/reachweaver/profile_audit_registry.json. profile-audit --file OWNER_SNAPSHOT.json --platform linkedin --json checks owner-confirmed profile facts and known/unknown coverage; post-audit --file OWNER_SNAPSHOT.json --platform youtube --age-hours 168 --json compares source-labelled native outcomes at comparable ages. The commands read only an existing JSON snapshot and never connect accounts, draft, approve, schedule or publish.

Separate source-backed official rules from creative hypotheses. Missing fields and analytics are unknown, not a zero score. Encourage original helpful content, accurate proof, legitimate replies, accessible media, meaningful destination links and opt-in community conduct, not manufactured engagement. Without a real user-supplied or permissioned observed profile and metrics, label the deliverable a playbook rather than an actual user-specific audit. The full repo documents all 26 networks in docs/PROFILE-AND-POST-AUDITS.md; a copied skill uses its portable reference.

Native analytics CSV intake without external access

post-audit --file OWNER_PROFILE.json --metrics-csv OWNER_METRICS.csv --owner-authorized --json and suggest --snapshot OWNER_PROFILE.json --metrics-csv OWNER_METRICS.csv --owner-authorized --json accept only owner-acknowledged normalized exports. The metrics must match an account already declared in the profile JSON; duplicate post IDs, unknown columns, blank/zero confusion and unsafe timestamps are rejected. This is an in-memory read of local files, not a social profile connector, identity verification, published data or permission to contact users. Use references/profile-post-audit.md and references/next-actions.md. The portable skill bundles a synthetic assets/profile-post-metrics.example.csv. Never claim it authenticated to a network.

Evidence-ranked improvement suggestions (Issue #6)

Use suggest --snapshot state/owned-profiles.json --json for a single deterministic ranking of known profile fixes, manually reviewed creative problems and available performance evidence. Optional --engagement-export, --seo-briefs, --experiments inputs are existing owner-controlled JSON files; --include-db reads an already existing local SQLite DB through mode=ro, without migrations or writes. Read references/next-actions.md to interpret the P0–P3 human-only priority, sample coverage and private-text redaction rules. Missing data does not prove low engagement. suggest never contacts platforms, publishes or edits profiles; verified local statistics are not proof of real online account authorization.

The repeatable content-to-learning loop

1. Evidence inventory. Extract real deliverable, problem, source URI, exact claim, verification status and verification date. Separate direct measurement from speculation, marketing claim and personally held opinion.
2. Position + voice. Describe one reader/job, one audience pain, public identity and permitted account. Load a brand profile; do not interrogate again if it already exists.
3. Channel and creative system. For GitHub contributor goals under Reddit/HN constraints, read references/open-source-growth.md first; otherwise load references/channel-selection.md to choose two high-fit channels plus one bounded experiment: do not use global MAU as a predicted personal reach. Load references/platform-playbooks.md to check documented platform practices and community restrictions. Choose 1–2 useful ideas, test truthful hook candidates and produce distinct native angles, one relevant CTA and an accessible media/shotlist brief when needed. Rank on reader utility and evidence rather than viral formula folklore.
4. Quality gate. Check facts, source rights, company affiliation, privacy, disclosure, alt text/captions, account permissions, up-to-date format policies, platform moderation risks and previous content duplicates. No fabricated benchmarks or citations.
5. Offline campaign. Build a versioned campaign JSON (examples/campaign.reachweaver.json), validate it with a brand card (examples/brand.reachweaver.json), and present each exact destination/account/body. If only manual delivery is permitted, export a draft bundle.
6. Authorize. Record explicit human approval of the final exact text and destination account. Do not treat a campaign plan or prior generic automation request as consent to all future posts. Staging only creates drafts.
7. Publish safely. Use only configured authorized platform connectors and documented CLI gates; dry-run by default. Observe real remote receipt; never auto-retry ambiguous send. needs_review requires external account inspection. Never fabricate published URLs.
8. Measure and learn. At comparable post ages, collect native statistics with definitions and coverage; design a predeclared hypothesis/guardrail, run experiment-evaluate only on actual locally recorded metrics, and adjust one variable. Organic sequential comparisons are not randomized trials.

Worldwide region and channel planning (read-only)

For country-targeted visibility, contributor growth, Chinese/Indian/African outreach, or scheduling requests, first load references/global-distribution.md, references/platform-algorithms.md and references/timing-intelligence.md only as relevant. The versioned source registry is bundled at scripts/reachweaver/distribution_registry.json and is intended to give a reproducible starting hypothesis, not replace up-to-date platform research or first-party analytics.

Run (RW is the command prefix from SKILL.md, in a checkout or a copied skill):

RW distribution-plan --region india --goal adoption --limit 5
RW distribution-plan --region china --goal contributors --json
RW distribution-plan --region nigeria --goal collaboration --date 2026-10-14 --json

This is an offline research command, even with --date: it cannot approve, schedule, connect, send, create a remote draft or measure views. For --region global --date ..., supply --timezone IANA/Name representing a specific target audience; never pretend the world has one timezone.

Always surface native_schedule (provider UI/role), reachweaver_delivery (current implemented adapter), account_connected=unknown_not_verified, human review, localization/feature disclaimers, and the actual untested status of the two timing slots. Hacker News is exceptional: no LLM-generated or LLM-edited HN-facing text; only a factual background checklist for the owner to write and submit manually. The human_only attribute overrides all content-generation, calendar and distribution workflows. For Reddit and independent communities, consult individual venue rules before even proposing a post.

Timing intelligence: propose first, publish only when confirmed

1. For any best time, algorithm, content calendar, schedule or batch publishing request, consult references/platform-algorithms.md and references/timing-intelligence.md. Use an owned account’s native audience and comparable post-age analytics first, then treat 2026 industry timing windows as low-confidence starting hypotheses. No universal guaranteed best hour. Separate user timezone from target audience timezone, record IANA zone, local offset and UTC, and account for DST, source date, format and brand constraints.
2. Produce a per-platform scheduling table: account, approved content/variant, recommended local date/time + UTC, signal/evidence and confidence, native-scheduler vs local worker vs reminder-only path, and whether an actual platform queue receipt exists. Candidate slots are proposals, not scheduled posts. Preserve draft state when permission, media, credentials, available native queue or worker are missing.
3. Recognize critical differences: LinkedIn, Threads, YouTube Studio, TikTok and Pinterest may provide native scheduling under account/format limits; Bluesky relies on permitted third-party or local execution; Reddit’s native scheduling is moderator-only; Product Hunt schedules a launch day; Hacker News forbids automated submissions and generated HN post text. Official scheduling UIs do not imply API permission for ReachWeaver.
4. Never label a post scheduled on a remote platform unless a real provider-side receipt or user-confirmed scheduled queue is observed. A ReachWeaver schedule command records local due time only; its dry-run does not publish. No persistent worker is installed automatically by this skill. Publishing still requires exact human item approval, authorized adapter, credential checks, live opt-in, delivery confirmation, emergency stop and ambiguous-send reconciliation.
5. Re-evaluate using matched-age platform-native metrics (+24h/+7d), audience/format cohorts, real clicks or adoption, and visible missingness. Avoid inventing ranking weights, claiming algorithm reverse-engineering or equating observational slot correlations with causality. Refresh upstream policies when acting.

Executable planner when local account/posts are available

• Use RW calendar-plan --account ACCOUNT --timezone Europe/Rome --start YYYY-MM-DD --days 14 to inspect proposals in JSON; repeat --slot 'Wed@16:00' for user-provided audience windows, or pass --audience-activity FILE (owner-exported hour-of-week CSV; see references/timing-intelligence.md) instead, and --post-id ID to select exact posts. --explore-share F --explore-slot 'Sat@11:00' (F at most 0.5, default 0 = off) labels a capped, non-random share of proposals role: explore. With --include-drafts, preview only. Consult the full repo quickstart when installed as a full repository.
• Use RW calendar-gaps --account ACCOUNT --timezone Europe/Rome --days 14 (read-only, opened with mode=ro) to list empty slots, overloaded days and posts queued too close together in the local queue. Optional --timing-source/--timing-metric/--timing-denominator annotate empty slots with the owner’s own matched-age history (association only). It cannot approve, schedule or publish; posts in a platform’s native scheduler are invisible to it, so say so when reporting.
• Never run --apply unless the human has individually approved each exact post, reviewed the dates/accounts and explicitly authorized local queueing. --apply is only for existing Bluesky/Mastodon/Telegram/LinkedIn-member local text adapters, does not publish, and fails atomically for mixed/unapproved/colliding posts. Use the provider’s native UI/manual handoff for all other networks; do not claim a remote schedule without a receipt.
• No automatic performance-learning model, native media scheduler, analytics connectors, account connection or background worker exists solely because this CLI is installed. Keep evidence tier and timezone in any proposed timetable.

Durable delivery safety for scheduled work

When asked to automatically publish already approved posts, read references/publishing.md. For unattended use, a trusted owner-operated host must run publish --live --scheduled-only --max-lateness-minutes 180, with existing exact-item authorization, validated destination, protected SQLite state, secure credentials and explicit live opt-in. Default per-account guardrails are two claimed attempts per rolling 24 hours and 60 minutes between claims; configurable limits are not proof of provider quotas. Do not use the ordinary unscheduled bulk live command as a background worker, or publish stale timed content late. No worker is installed, enabled or granted credentials by the skill.

Use RW health for one offline per-account readiness view (ok | attention | blocked, exit 1 when blocked; credential variable names only) and dead-letter for needs_review posts grouped by sanitized error code with reconcile steps; it never retries. ops-metrics [--format json|prometheus] gives read-only monitoring counts (account ids, platform and fixed codes as labels only) for a node_exporter textfile; an alert is a prompt for the owner, never a reason to resend. Approvals are bound to a hash of the exact payload: a post changed after approval, or approved before that binding existed, is BLOCKED and listed as approval_rebind_required; only the owner re-approves it (unapprove, show, approve). Honour the local opt-out list (config/optout.json): never draft a reply to, mention or tag a listed handle or domain; draft, check, approve and publish (pre-claim, post stays approved) re-check it. Use RW queue-health for an offline summary of overdue local schedules, sending age, needs_review, pause status and account attempts, and human review each uncertain remote outcome before reconciliation. A scheduled record is not remote success. See docs/WORKER-OPERATIONS.md only in the full repository; that path is not necessarily present in a copied standalone skill.

Claude Code helpers: ideas inbox, fact-check agent, status line

Capture ideas instead of drafting them. When the owner says “post about this later”, “remind me to write about X” or shares a link worth a post someday, run RW idea add "ONE SENTENCE" [--source https://...] [--tag T] and say it was saved. Do not draft, stage or schedule it. An idea is not a draft: the inbox is a private ideas.json next to the database (text up to 2000 characters, https sources only, text that looks like a credential is refused), and it can never be approved or sent. RW idea list [--status open] [--tag T] [--json] shows the inbox; offer it when the owner asks what to post next. RW idea drop ID retires one. When the owner picks an idea, RW idea promote ID --campaign SLUG --out NEW_DIR [--brand B --accounts A] writes a NEW campaign scaffold (campaign.reachweaver.json + brief.md) in the campaign contract format with the idea as the brief and {{write: ...}} placeholders. campaign-check reports it BLOCKED until real text and verified evidence replace every placeholder; then continue with the normal campaign flow. Promotion never creates a post, approval or send.

Fact-check before you show a draft. With the plugin installed, delegate to the read-only fact-check subagent (reachweaver:fact-check) before presenting any draft that states a number, date, version, release, feature, comparison, quote, partnership or customer count. Give it the exact draft text and the campaign file path. It labels each claim verified, unverified or contradicted with the source URL and a short quote, and it never edits, approves or publishes. Show its table next to the draft. Fix or remove every contradicted claim and every unverified number, release or feature claim before asking for approval, and confirm any quote you rely on in the page itself (WebFetch returns a processed view). Its labels are evidence for the owner’s review, never consent to publish. Without the plugin, do the same check yourself.

Status line. RW statusline prints one read-only line such as RW 0.10.0 | drafts 3 | queued 1 | needs review 0 | ideas 2 | PAUSED (no database: RW: no workspace). It never creates a database, never reads stdin and prints counts only. If the owner wants it in Claude Code’s status bar, show the statusLine snippet from docs/CLAUDE-CODE.md and let the owner add it to their own settings; never edit their settings yourself.