@m13v/s4l 1.6.197-rc.7

package/setup/SKILL.md

@@ -0,0 +1,277 @@
+---
+name: social-autoposter-setup
+description: "Set up social-autoposter for a new user end to end. Installs/repairs the runtime, discovers product and voice context, connects X/Twitter, seeds search topics, schedules the draft autopilot, and verifies it produces a draft. Use when: 'set up social autoposter', 'install social autoposter', 'configure social posting'."
+---
+
+# Social Autoposter Setup
+
+Set up social-autoposter end to end. Treat the user's setup request as a terminal
+goal, not as the beginning of an interview.
+
+## Operating contract
+
+- Keep taking the next safe setup action until the system is working end to end.
+- Do not ask whether to run setup, install a dependency, inspect status, connect
+  X, scan the profile, research the website, save inferred fields, seed topics,
+  or retry a recoverable failure. Do them.
+- An explicit request to set up social-autoposter authorizes its owned local
+  runtime installation and importing only x.com/twitter.com session cookies
+  into its managed browser. Briefly warn that macOS keychain prompts may appear,
+  then proceed; do not wait for another yes/no reply.
+- Use existing configuration, the user's message/context, their connected X
+  profile, public website pages, and reasonable factual inference before asking
+  for information.
+- Ask at most one bundled blocking question, and only when required information
+  cannot be discovered or safely inferred. The usual legitimate blocker is:
+  there is no configured project, no clear product URL in context or the X
+  profile, and no way to identify what product to market.
+- Never post a draft during setup unless the user explicitly asked for that.
+- Never hand-run the X cycle. Do not run `run-twitter-cycle.sh`,
+  `claude_job.py`, or any cycle script directly, and never offer to "trigger a
+  cycle" or "run one now" so a draft appears faster. Only the launchd kicker may
+  fire the cycle, with its required environment. A manual kick produces an
+  empty-plan artifact and blocks the autopilot. Verification means scheduling
+  the autopilot and letting the kicker drive it; you wait and poll, you never
+  trigger.
+- Do not edit the MCP server, plugin source, or an unrelated user workspace to
+  work around setup failures. Use the product's setup/install tools.
+
+## Definition of done
+
+Do not report setup complete until all of these are true:
+
+1. The owned runtime is installed and ready.
+2. At least one project is ready with name, website, description, ICP, voice,
+   and search topics. For the personal-brand persona, the search topics and the
+   grounding corpus come from the user's dictation interview (below), not from
+   the profile scan alone.
+3. Search topics have been seeded into the backend. Seeding is POSTPONED until
+   after the dictation interview so the topics reflect what the user wants to be
+   in conversations about, not only what they already posted.
+4. X is connected and the real handle has been auto-detected.
+5. The draft autopilot is scheduled and has produced a draft card without
+   posting. A returned/pending review batch is the strongest success signal. If X
+   simply has no matching supply, report that precise result only after
+   configuration/auth/runtime checks pass.
+
+## Architecture
+
+- **Config**: `~/social-autoposter/config.json` — `projects[]` (what to post
+  about) and `accounts` (where to post).
+- **Data + stats**: backend HTTP API at `https://s4l.ai`, scoped by a stable
+  per-install identity in `identity.json`. There is no local Postgres or
+  `DATABASE_URL`.
+- **Search topics**: the X cycle reads `project_search_topics`, seeded
+  automatically from each project's `search_topics`. No topics means nothing
+  to scan. `search_topics` is the ONLY field that changes what gets scanned;
+  every other persona field only shapes the draft after a thread is found. For
+  the persona, the profile scan is backward-looking (only what the user already
+  posted), so topics are sourced primarily from the dictation interview.
+
+## Choose the path
+
+- If the social-autoposter MCP tools are connected (`project_config`, `runtime`,
+  `queue_setup`, `post_drafts`, `get_stats`, `dashboard`), use the MCP path.
+  Do not hand-edit `config.json`.
+- If only the CLI/skill is installed, use the CLI fallback.
+
+## MCP path
+
+### 1. Inspect and repair the environment
+
+Call `project_config` in status mode and `runtime` (action:'status') immediately.
+
+If the runtime is not ready:
+
+1. Call `runtime` with action:'install'.
+2. Poll `runtime` (action:'status') until it succeeds or returns a concrete failure.
+3. For a recoverable/partial failure, call `runtime` action:'install' again and continue.
+   Do not send the user away to install Chrome, Python, uv, Chromium, or
+   browser-harness manually; the owned installer handles them.
+
+Preserve any already-ready project or X connection. Resume from the first
+incomplete milestone instead of restarting the interview.
+
+### 2. Connect X and learn the user's voice
+
+If X is not connected:
+
+1. Call `project_config` with `action:'detect_x_sources'`.
+2. Choose `recommended`, preferring a source whose `x_session` is present.
+   Do not ask the user to choose a browser profile when the tool can choose.
+3. Tell the user in one short progress update that macOS may show browser Safe
+   Storage prompts and they should enter their Mac password and click **Allow**
+   or **Always Allow**.
+4. Immediately call `project_config` with `action:'connect_x', confirm:true` and the
+   selected `x_source`. The setup request itself is authorization; do not add a
+   separate consent round-trip.
+5. If the result is transient, retry. If it opens managed Chrome in
+   `needs_login`, tell the user to finish signing in to x.com in that window.
+   This is an unavoidable user action, not a product-choice question. Re-run
+   `connect_x` after sign-in and continue.
+
+Once connected, call `project_config` with `action:'profile_scan'`. Treat the returned
+bio, links, recent posts, and replies as grounding truth for the VOICE, not as the
+primary source of topics (the scan only shows what they already posted):
+
+- profession/identity;
+- voice, casing, phrasing, and tone;
+- ICP;
+- wording or claims the user avoids;
+- recurring themes (reinforcement for topics, not the origin).
+
+Do not ask the user to approve the inferred voice during initial setup. Save a
+specific, conservative best draft and mention afterward that it can be edited.
+
+Then run the DICTATION INTERVIEW before extracting topics or seeding. This is
+where the persona's `search_topics` and grounding corpus come from. Tell the user
+to answer all of the following in ONE spoken dictation (the Claude input box
+already supports dictation, so they talk once and you split the answers into
+fields). Ask verbatim as a single numbered list:
+
+1. Who are you, and what do you want to be known for? (→ description)
+2. What subjects could you talk about for an hour, work and non-work? (→
+   `search_topics`; this is the load-bearing answer, it is the only thing that
+   decides what gets scanned on X)
+3. Your most contrarian takes — what does everyone in your field get wrong, and
+   what did you used to believe that you have reversed on? (→ content_angle +
+   corpus)
+4. What can you explain in 5 minutes that took you years, and what mistake do you
+   watch beginners make over and over? (→ content_angle + corpus)
+5. Best or worst thing that happened to you recently, and a failure you learned
+   the most from? (→ corpus, keeps drafts current)
+6. Who do you love or hate reading online, and any lines or phrases you say a
+   lot? (→ voice calibration)
+7. Anything off-limits (topics, companies, people), and how spicy can we get —
+   safe, opinionated, or provocative? (→ content_guardrails + voice.never)
+
+From the dictation, synthesize the fields: `search_topics` primarily from answer
+2 (fold in recurring scan themes only as reinforcement), the rest from the other
+answers. Keep the RAW transcript VERBATIM as the persona corpus (do not
+paraphrase; the actual numbers, opinions, and phrasing are what make drafts sound
+like them). Pass it as `content_corpus` when you call `engagement_mode` (or
+`project_config`); it is stored in the `persona_corpus.txt` sidecar, not
+config.json. If the user declines or gives nothing usable, fall back to
+scan-derived topics.
+
+Only after the dictation is captured do you set the engagement mode / save the
+persona, which seeds the topics. Do not seed topics from the scan before the
+dictation.
+
+### 3. Discover and research the product
+
+Find the product URL in this order:
+
+1. an existing project/config;
+2. the user's setup request and conversation context;
+3. the connected X profile URL/bio/recent posts;
+4. a clearly associated public product discovered with web research.
+
+When one product is clearly supported by the evidence, use it without asking.
+If several are plausible and no primary product is evident, choose the one most
+prominent in the current context/profile. Ask one bundled blocking question
+only if no defensible product can be identified.
+
+Visit the product site with your own browser/fetch tools and read at least five
+pages when available: homepage, pricing, features/product, about, docs,
+changelog/blog, FAQ, and customer/case-study pages. From what you actually read,
+derive:
+
+- `name`: short lowercase machine slug;
+- `website`;
+- `description`;
+- `differentiator`;
+- `icp`;
+- `get_started_link`;
+- `content_guardrails`;
+- `voice` and `search_topics`, grounded in the profile scan.
+
+Do not invent features, metrics, customers, or guarantees. If the site is thin,
+save a conservative factual description rather than stopping for optional
+details.
+
+### 4. Save and seed
+
+Call `project_config` once with the complete inferred project whenever possible. It
+merges fields, reports missing required fields, seeds `search_topics` into
+`project_search_topics`, and expands them into search queries.
+
+If required fields remain, first attempt to derive them from the sources already
+collected. Ask the user only if a genuinely unknowable required field blocks
+readiness. Optional/recommended fields never justify stopping setup.
+
+### 5. Schedule the autopilot + verify end to end
+
+Schedule the draft autopilot: call `queue_setup`, then for EACH returned task
+call the host tool `create_scheduled_task` (taskId, cronExpression, prompt
+verbatim; "already exists" is fine). The autopilot then drafts on its own — the
+launchd kicker fires a draft-only cycle and the queue worker drafts the replies;
+nothing posts. Then wait: poll the `dashboard` tool until the pending-draft
+count rises; a returned review batch is the strongest success signal.
+
+Do not hand-run a cycle to make this happen faster, and do not offer the user to
+trigger one. Scheduling the autopilot is the only sanctioned way to produce the
+verification draft; the kicker drives it on its own minute-by-minute schedule.
+
+If no card appears, diagnose the fixable reason, fix it, and let the autopilot
+retry on its next scheduled cycle:
+
+- missing topics: derive/add topics through `project_config`, then retry;
+- runtime/browser-harness/Chrome issue: run/repair the owned runtime, then retry;
+- stale X session: reconnect X, then retry;
+- transient backend/network issue: retry once;
+- Claude CLI login/usage limit or an interactive X login: report the exact
+  blocker and the single user action required.
+
+Do not enable autopilot automatically. Offer it only after setup is verified,
+or enable it when the user's original request explicitly included hands-free
+posting.
+
+Once verification passes (or you reach a precise blocker), call the `dashboard`
+tool so the user sees the finished setup rendered visually, then give the
+completion summary below.
+
+## CLI fallback
+
+Use only when MCP tools are unavailable. Execute the flow yourself rather than
+turning it into instructions for the user.
+
+1. Install/repair: `npx -y social-autoposter@latest init`
+2. Inspect `~/social-autoposter/config.json` and preserve existing projects.
+3. Discover the product and voice using the same evidence order above. For a
+   personal-brand persona, run the dictation interview (the 7 questions above)
+   and take `search_topics` + the raw corpus from it, scan themes as backup.
+4. Write a complete project with name, website, description, ICP, voice, and
+   `search_topics`.
+5. Seed topics:
+   `python3 ~/social-autoposter/scripts/seed_search_topics.py --project <name>`
+6. Connect X:
+   `python3 ~/social-autoposter/scripts/setup_twitter_auth.py connect`
+   The user may need to approve a macOS keychain prompt or sign in once in the
+   managed browser; continue automatically afterward.
+7. Do not load launchd/autopilot jobs unless explicitly requested, and never
+   hand-run `run-twitter-cycle.sh` or any cycle script to "verify." A manual
+   kick produces an empty-plan artifact and blocks the autopilot. The cycle runs
+   only when the launchd autopilot is scheduled and the kicker fires it. In CLI
+   fallback, setup is configured once the project is saved, topics are seeded,
+   and X is connected; the first draft appears after the autopilot is scheduled.
+
+## Completion summary
+
+Render the `dashboard` tool once setup is verified, then report outcomes (not a
+recap of every prompt):
+
+```text
+Social Autoposter Setup Complete
+
+Runtime:       ready
+Project:       NAME — ready
+Topics seeded: N
+X/Twitter:     @HANDLE
+Verification:  autopilot produced a draft (not posted)
+Autopilot:     off
+Stats:         https://s4l.ai/stats/HANDLE
+```
+
+If setup is blocked, do not call it complete. State the exact completed
+milestones, the blocker, and the one user action needed to resume.

package/skill/amplitude-24h-signups.sh

@@ -0,0 +1,38 @@
+#!/usr/bin/env bash
+# amplitude-24h-signups.sh — launchd wrapper for scripts/amplitude_24h_signups.py.
+#
+# Fires every 5 min from com.m13v.social-amplitude-24h.plist.
+# Writes ~/social-autoposter/skill/cache/amplitude_24h_signups.json.
+#
+# The script itself uses a real-time PostHog count for the headline number
+# (cheap, ~1s) and refreshes the eventually-consistent Amplitude export
+# only every ~25 min (heavy, ~30s + ~150 MB).
+#
+# Read by project_stats_json.py:_amplitude_signups when days==1.
+
+set -uo pipefail
+
+REPO_DIR="$HOME/social-autoposter"
+
+# shellcheck source=/dev/null
+[ -f "$REPO_DIR/.env" ] && source "$REPO_DIR/.env"
+
+# Inject Amplitude + PostHog creds from keychain so the export half can run
+# without env vars being baked into the launchd plist.
+export AMPLITUDE_STUDYLY_API_KEY="${AMPLITUDE_STUDYLY_API_KEY:-$(security find-generic-password -s amplitude-studyly-api-key -w 2>/dev/null)}"
+export AMPLITUDE_STUDYLY_SECRET_KEY="${AMPLITUDE_STUDYLY_SECRET_KEY:-$(security find-generic-password -s amplitude-studyly-secret-key -w 2>/dev/null)}"
+export POSTHOG_PERSONAL_API_KEY="${POSTHOG_PERSONAL_API_KEY:-$(security find-generic-password -s PostHog-Personal-API-Key-m13v -w 2>/dev/null)}"
+
+cd "$REPO_DIR" || exit 2
+
+# shellcheck source=lock.sh
+source "$REPO_DIR/skill/lock.sh"
+acquire_lock amplitude-24h-signups 5
+
+RUN_START=$(date +%s)
+/opt/homebrew/bin/python3.11 "$REPO_DIR/scripts/amplitude_24h_signups.py"
+EXIT_CODE=$?
+RUN_ELAPSED=$(( $(date +%s) - RUN_START ))
+
+echo "[$(date +%H:%M:%S)] === done in ${RUN_ELAPSED}s (exit=${EXIT_CODE}) ==="
+exit "$EXIT_CODE"

package/skill/archive-old-logs.sh

@@ -0,0 +1,40 @@
+#!/bin/bash
+# Archive log files older than 7 days from skill/logs/ to skill/logs-archive/.
+# The dashboard (bin/server.js) does many fs.readdirSync(LOG_DIR) calls per
+# pulse. Letting that directory grow to 17k+ files starves the event loop
+# and the dashboard stops responding. Pruning to a sibling dir keeps the
+# files around for forensics without including them in the dashboard scan.
+#
+# Scheduled daily by ~/Library/LaunchAgents/com.m13v.social-archive-logs.plist
+
+set -uo pipefail
+
+LOG_DIR="/Users/matthewdi/social-autoposter/skill/logs"
+ARCHIVE_DIR="/Users/matthewdi/social-autoposter/skill/logs-archive"
+DAYS="${ARCHIVE_DAYS:-7}"
+
+mkdir -p "$ARCHIVE_DIR" "$LOG_DIR"
+
+# Per-run summary log so the dashboard's "Other" section can find this job.
+# Filename matches the JOBS[].logPrefix value in bin/server.js.
+RUN_LOG="$LOG_DIR/archive-logs-$(date +%Y-%m-%d_%H%M%S).log"
+log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$RUN_LOG"; }
+
+if [ ! -d "$LOG_DIR" ]; then
+  log "ERROR: LOG_DIR not found: $LOG_DIR"
+  exit 0
+fi
+
+log "=== archive-old-logs starting (DAYS=$DAYS) ==="
+
+# Only top-level files; do not touch claude-sessions/ or other subdirs.
+# Also exclude the per-run summary we just created so we don't archive
+# ourselves on long-tail edge cases.
+find "$LOG_DIR" -maxdepth 1 -type f -mtime +"$DAYS" ! -name "$(basename "$RUN_LOG")" -print0 \
+  | xargs -0 -I{} mv {} "$ARCHIVE_DIR/" 2>&1 | tee -a "$RUN_LOG" >/dev/null || true
+
+remaining=$(find "$LOG_DIR" -maxdepth 1 -type f | wc -l | tr -d ' ')
+archived=$(find "$ARCHIVE_DIR" -maxdepth 1 -type f | wc -l | tr -d ' ')
+
+log "kept=$remaining archived_total=$archived"
+log "=== done ==="

package/skill/audit-dm-staleness.sh

@@ -0,0 +1,42 @@
+#!/usr/bin/env bash
+# audit-dm-staleness.sh — Age out no_response DMs after 14 days of silence
+# and downgrade stale not_our_prospect escalations.
+#
+# Runs daily via launchd com.m13v.social-audit-dm-staleness.plist.
+
+set -uo pipefail
+
+# shellcheck source=/dev/null
+[ -f "$HOME/social-autoposter/.env" ] && source "$HOME/social-autoposter/.env"
+
+REPO_DIR="$HOME/social-autoposter"
+LOG_DIR="$REPO_DIR/skill/logs"
+mkdir -p "$LOG_DIR"
+LOG_FILE="$LOG_DIR/audit-dm-staleness-$(date +%Y-%m-%d_%H%M%S).log"
+
+log() { echo "[$(date +%H:%M:%S)] $*" | tee -a "$LOG_FILE"; }
+
+# HTTP-only lane (2026-06-01): both staleness UPDATEs run server-side via the
+# s4l.ai API (POST /api/v1/dms/staleness-sweep). No DATABASE_URL, no psql.
+AUDIT_HELPER="$REPO_DIR/scripts/audit_helper.py"
+
+RUN_START=$(date +%s)
+log "=== DM staleness audit: $(date) ==="
+
+# Both sweeps run in one POST and return {aged, downgraded}:
+#   1. Ghosted outreach: no_response + active + older than 14 days -> stale.
+#   2. Reverse-pitchers the reply bot escalated (needs_human + not_our_prospect)
+#      -> active; next inbound re-evaluates via classifier and re-escalates if needed.
+SWEEP_JSON=$(python3 "$AUDIT_HELPER" dm-staleness-sweep 2>/dev/null || echo '{"aged":0,"downgraded":0}')
+AGED=$(echo "$SWEEP_JSON" | python3 -c "import json,sys; print(int(json.load(sys.stdin).get('aged') or 0))" 2>/dev/null || echo "0")
+DOWNGRADED=$(echo "$SWEEP_JSON" | python3 -c "import json,sys; print(int(json.load(sys.stdin).get('downgraded') or 0))" 2>/dev/null || echo "0")
+log "Aged ghosted outreach to stale: $AGED"
+log "Downgraded not_our_prospect escalations: $DOWNGRADED"
+
+RUN_ELAPSED=$(( $(date +%s) - RUN_START ))
+python3 "$REPO_DIR/scripts/log_run.py" --script "audit-dm-staleness" \
+    --posted "$AGED" --skipped "$DOWNGRADED" --failed 0 --cost 0 --elapsed "$RUN_ELAPSED" 2>/dev/null || true
+
+log "=== Done in ${RUN_ELAPSED}s ==="
+
+find "$LOG_DIR" -name "audit-dm-staleness-*.log" -mtime +30 -delete 2>/dev/null || true

package/skill/audit-linkedin.sh

@@ -0,0 +1,14 @@
+#!/usr/bin/env bash
+# audit-linkedin.sh — LinkedIn-only audit (Python CDP + summary)
+
+# LinkedIn killswitch (2026-05-27): refuse to run if a prior fire detected
+# session compromise (http_999, authwall, throttle, li_at cleared).
+# State: ~/.claude/social-autoposter/linkedin.killswitch
+# Clear: python3 ~/social-autoposter/scripts/linkedin_killswitch.py clear
+if [ -f "$HOME/.claude/social-autoposter/linkedin.killswitch" ]; then
+    echo "[$(date +%H:%M:%S)] LINKEDIN_KILLSWITCH active. Aborting LinkedIn pipeline."
+    echo "  Re-auth LinkedIn in harness Chrome, then: python3 ~/social-autoposter/scripts/linkedin_killswitch.py clear"
+    exit 0
+fi
+
+exec "$(dirname "$0")/audit.sh" --platform linkedin

package/skill/audit-moltbook.sh

@@ -0,0 +1,4 @@
+#!/usr/bin/env bash
+# audit-moltbook.sh — Moltbook-only audit (Moltbook API + summary)
+
+exec "$(dirname "$0")/audit.sh" --platform moltbook

package/skill/audit-reddit-resurrect.sh

@@ -0,0 +1,67 @@
+#!/usr/bin/env bash
+# audit-reddit-resurrect.sh — Weekly check of Reddit posts marked deleted/removed
+# in the last 60 days. If a post is now visible again, flips status back to active.
+
+set -uo pipefail
+
+source "$(dirname "$0")/lock.sh"
+# reddit-harness backend (2026-05-29): exports REDDIT_CDP_URL=:9557 so the
+# resurrect fetch (stats.py --reddit-resurrect -> reddit_tools.batch_fetch_info
+# -> reddit_browser_fetch) attaches to the harness Chrome instead of 403ing on
+# *.json from this residential IP. Source after lock.sh, before pre-flight.
+source "$(dirname "$0")/lib/reddit-backend.sh"
+# Unified reddit lock (2026-05-10): TTL-aware Python lease. The MCP proxy
+# heartbeats expires_at on every reddit-agent call, so the lease stays held
+# during real browser activity but auto-decays within 90s of idleness.
+REPO_DIR_FOR_LOCK="$HOME/social-autoposter"
+_release_reddit_lease() {
+    timeout 3 python3 "$REPO_DIR_FOR_LOCK/scripts/reddit_browser_lock.py" release 2>/dev/null || true
+}
+python3 "$REPO_DIR_FOR_LOCK/scripts/reddit_browser_lock.py" acquire --timeout 3600 --ttl 90 2>&1 || \
+    echo "WARNING: reddit_browser_lock.py acquire failed; proceeding without lease."
+trap '_release_reddit_lease; _sa_release_locks' EXIT INT TERM HUP
+if ! ensure_reddit_browser_for_backend 2>&1; then
+    echo "[audit-reddit-resurrect] WARNING: reddit-harness bootstrap failed; falling back to ensure_browser_healthy reddit"
+    ensure_browser_healthy "reddit"
+fi
+acquire_lock "audit-reddit-resurrect" 3600
+
+# shellcheck source=/dev/null
+[ -f "$HOME/social-autoposter/.env" ] && source "$HOME/social-autoposter/.env"
+
+REPO_DIR="$HOME/social-autoposter"
+LOG_DIR="$REPO_DIR/skill/logs"
+# HTTP-only lane (2026-06-01): the candidate-count read goes through the s4l.ai
+# API via scripts/audit_helper.py. No DATABASE_URL, no psql, no fallback.
+AUDIT_HELPER="$REPO_DIR/scripts/audit_helper.py"
+
+mkdir -p "$LOG_DIR"
+LOG_FILE="$LOG_DIR/audit-reddit-resurrect-$(date +%Y-%m-%d_%H%M%S).log"
+
+log() { echo "[$(date +%H:%M:%S)] $*" >> "$LOG_FILE"; echo "[$(date +%H:%M:%S)] $*"; }
+
+RUN_START=$(date +%s)
+log "=== Reddit resurrect audit: $(date) ==="
+
+CANDIDATES=$(python3 "$AUDIT_HELPER" resurrect-candidates 2>/dev/null || echo "0")
+
+log "Candidates: $CANDIDATES posts marked deleted/removed in last 60 days"
+
+python3 "$REPO_DIR/scripts/stats.py" --reddit-resurrect --resurrect-days 60 >> "$LOG_FILE" 2>&1
+EXIT_CODE=$?
+
+if [ "$EXIT_CODE" -ne 0 ]; then
+    log "FAILED (exit $EXIT_CODE)"
+else
+    log "Done"
+fi
+
+RESURRECTED=$(grep -c "^RESURRECTED " "$LOG_FILE" 2>/dev/null || echo "0")
+log "Resurrected this run: $RESURRECTED"
+
+RUN_ELAPSED=$(( $(date +%s) - RUN_START ))
+python3 "$REPO_DIR/scripts/log_run.py" --script "audit-reddit-resurrect" --posted "$RESURRECTED" --skipped 0 --failed "$EXIT_CODE" --cost 0 --elapsed "$RUN_ELAPSED"
+
+log "=== Reddit resurrect audit complete: $(date) ==="
+
+find "$LOG_DIR" -name "audit-reddit-resurrect-*.log" -mtime +30 -delete 2>/dev/null || true

package/skill/audit-reddit.sh

@@ -0,0 +1,4 @@
+#!/usr/bin/env bash
+# audit-reddit.sh — Reddit-only audit (API deleted/removed check + summary)
+
+exec "$(dirname "$0")/audit.sh" --platform reddit

package/skill/audit-twitter.sh

@@ -0,0 +1,4 @@
+#!/usr/bin/env bash
+# audit-twitter.sh — Twitter-only audit (fxtwitter API check + summary)
+
+exec "$(dirname "$0")/audit.sh" --platform twitter