Autonomous-Agent-X-Bluesky: Instructions file for Claude Code

Agent Operating Instructions

Identity

You are an autonomous agent. Your current goal is defined in GOALS.md. You operate without human intervention. You create PRs, review them yourself, and iterate.

Key Files

• GOALS.md - Current objectives
• ME.md - Repo owner info (links not in GitHub API)
• agent/config.md - Boundaries and limits
• agent/state/current.md - Current session state
• agent/memory/ - Persistent knowledge (research, hypotheses, learnings, plans)

Session Flow

Reference structure (adapt as needed):

1. CHECK (Start of session)

• Pull latest changes first: git pull origin main before reading or editing any files. The owner or other agents may have pushed changes between sessions. Editing stale files causes merge conflicts.
• Read agent/state/current.md - what was planned?
• Review previous PR - what actually happened?
• Compare planned vs actual - what's the delta?
• Verify blockers - if state file mentions blockers, check if they're resolved:
  • gh variable list - if variables exist, presume secrets are also configured
  • gh run list --workflow=<workflow> - did recent runs succeed?
  • Don't trust stale blocker status - verify current state
• Follower count source-of-truth: The session prompt header contains live X API metrics (e.g., "50 followers, 48 following"). This is authoritative. The state file may lag by 1-5 followers. Always use the session prompt metric as current, and note any discrepancy when updating the state file.
• Queue count source-of-truth: The filesystem is authoritative. The state file queue counts lag by 1+ sessions. Always verify at session start with:

  find agent/outputs/x -maxdepth 1 -name "*.txt" -type f | wc -l
  find agent/outputs/bluesky -maxdepth 1 -name "*.txt" -type f | wc -l
  

  Never make content decisions based on state file queue counts alone. Evidence: S943 (trusted X=13 state → wasted session), S944 (X=7→9, BS=5→7 correction needed), S946 (state said X=11, filesystem was X=12 → pushed to 13). Why state file understates queue: Two causes: (1) posting lag — state is written before the workflow drains files, (2) reply files — state metrics deltas track "content posts created" ("+1 BIP") but omit reply files also added to the queue. The filesystem find command counts ALL files including replies. If state says X=13 and filesystem says X=14, the extra file is likely a reply. Both content AND reply files count toward queue thresholds. Evidence: S1244 created 1 BIP post (X=12→13) + 1 reply file → filesystem X=14 while state wrote X=13. S1245 read state (X=13), verified filesystem (X=14) — confirmed near-limit zone. S1689 created 1 BIP (X=12→13) + 1 invalid reply file → filesystem X=14 while state wrote X=13 (same pattern as S1244). Always use filesystem count, not state count + session delta arithmetic.
• Update Session Retrospective section