engagement-act

type	Skill
name	Engagement Act
category	productivity
description	Turn flagged engagement opportunities into ready-to-post replies - read recent logs, draft specific responses, send as copy-paste-ready output
schedule	30 9 * * *
commits	false
permissions	[]
tags	["social","meta"]

Read memory/MEMORY.md for context on active projects and open engagement follow-ups. Read the last 7 days of memory/logs/ - look for engagement opportunities flagged by other skills (e.g. project-pulse, refresh-x, reply-maker, channel-recap) or noted in MEMORY.md Known Follow-ups.

Projects-of-interest list: if memory/topics/projects-of-interest.md exists, treat the project names listed there as the things to watch for mentions, cosigns, attributions, and fork moments. If the file is missing or empty, fall back to any project names that appear in recent logs or in MEMORY.md.

This skill's output follows the shared docs/output-contract.md (canonical @handle key, deterministic dedup state, visible leverage number, an expiry per opp, self-consistency gate). Rules referenced below by number are from that file.

Steps

0. Bootstrap dedup state. Prose-scanning logs for "replied to @X" is fragile; deterministic state is what keeps an already-actioned handle from resurfacing (contract rule 1).

   mkdir -p memory/topics
   [ -f memory/topics/engagement-acted.json ] || echo '{"acted":[]}' > memory/topics/engagement-acted.json
   

   acted is an LRU (cap 200) of {handle, acted_on} - the canonical @handle and the date a draft was sent for it.

1. Collect unactioned engagement opportunities. Read memory/logs/ for the last 7 days. Look for:

   • Log entries flagging engagement opps (e.g. "Engagement opps: N flagged" with N > 0) - extract the named handles/accounts
   • Any person who cosigned, mentioned, or attributed one of the operator's projects-of-interest
   • GitHub attribution or fork moments not yet acknowledged
   • Entries in MEMORY.md "Known Follow-ups" explicitly flagging engagement opps
   • Cosigns or mentions surfaced in refresh-x, reply-maker, or channel-recap runs

   Build a list: { person/account, context, what_they_did, link_if_known, days_ago }

2. Filter and prioritize. Apply these rules:

   • Drop any opp older than 14 days - window is likely closed
   • De-dupe deterministically: drop any opp whose @handle is in memory/topics/engagement-acted.json (acted). This replaces the old log-prose scan; still cross-check recent logs for a manual "replied to @X" as a backstop.
   • Score leverage so it can be shown, not just used for ranking: high (~10k+ followers or a named project/fund account), mid (~1k-10k), low (under ~1k). Record the follower estimate.
   • Rank by: recency (fresher first) then leverage (high first). Cap at 5 opportunities.

3. Draft ready-to-post responses. For each opportunity:

   • Type (the type tag, contract rule 8): X reply / X DM / GitHub comment / X post
   • Target: @handle or URL
   • Draft text: exact text, ready to copy-paste
   • Keep under 280 chars for X replies; longer is fine for DMs or GitHub comments

Sandbox Note

Reads only local memory files. No outbound network calls needed - no curl, no API. ./notify -f handles delivery reliably even when sandbox blocks curl (writes to .pending-notify/ as fallback).

No Environment Variables Required

Uses only built-in memory files and ./notify.