threads-automation

name

threads-automation

description

Unified Threads publishing and reply automation with Playwright. Use when Codex needs to research a Threads angle, choose between a standalone post/thread, an image-led card post, or a conversation-first reply campaign, draft native Threads copy, discover candidate posts to reply to, validate auth and the active account, run dry-runs or capped live publish/reply sessions, and verify the live result. Triggers on requests to automate Threads posting, create Threads content, publish on Threads, plan or execute a Threads reply campaign, find posts to reply to on Threads, or coordinate both posting and replies as one workflow.

Threads Automation

Purpose

Use this skill to run a production-grade Threads workflow from planning through live verification:

brief -> lane choice -> shared auth check -> draft or discovery -> dry-run -> QA -> live run -> verify

This skill combines three lanes:

• publish: write and publish a native Threads post, multi-post thread, long-form attachment, or image-led card post
• reply: discover suitable Threads posts, plan thoughtful replies, and execute a capped reply session
• combined: publish an anchor post, then run a reply campaign around adjacent conversations

Choose the lane first

1. publish Use when the original post should carry the main idea.

2. reply Use when discovery should come from participating in active discussions.

3. combined Use when the strongest move is a flagship post plus a small reply campaign that expands the idea into relevant conversations.

Core guardrails

• Default to dry-run.
• Confirm the active account handle before any live run.
• Use replies to add value, not to funnel or praise.
• Cap live reply sessions at 15 replies unless the user explicitly wants a lower limit.
• If the topic is timely, browse first and include concrete dates in the research packet and copy.
• Use topic tags only when they genuinely fit.
• Treat image-led cards as 1-2 short, phone-readable cards.
• Prefer saved browser state; if auth fails, open a headed browser and let the user log in manually.
• Verify from the live Threads surface, not only from a JSON summary.

Shared auth and account confirmation

Both scripts reuse the same auth state by default:

• output/playwright/threads/threads-auth-state.json

For any live publish or reply run, prefer the reply script's auth check first because it prints the active handle when it can resolve it:

node ./scripts/threads-reply-campaign.mjs check-auth

If auth fails or the handle is wrong:

node ./scripts/threads-reply-campaign.mjs capture-state --headed

References

Read only what the task needs:

• references/feature-and-tactics-matrix.md Read before choosing between a post, thread, reply campaign, attachment, poll, or card post.

• references/writing-system.md Read before drafting publish-lane copy.

• references/media-playbook.md Read when deciding whether the idea should stay text-only, use media, use spoilers, or move into an attachment.

• references/image-led-card-playbook.md Read when the value should live in 1-2 concise cards. Use $imagegen if it is available in the environment for the actual card generation.

• references/publish-playwright-workflow.md Read before probing the composer or composing through Threads.com.

• references/publish-qa-rubric.md Read before any live publish.

• references/reply-strategy-system.md Read before drafting replies.

• references/discovery-playbook.md Read before sourcing candidate posts for reply work.

• references/playwright-reply-workflow.md Read before probing the feed, validating a session, or running a reply session.

• references/qa-and-guardrails.md Read before any live reply run.

• references/publish-source-notes.md and references/reply-source-notes.md Read when you need dates, product notes, or source rationale behind the tactics.

Workflow

1. Define the goal. Choose views, replies, reposts, profile visits, link clicks, follows, or conversation quality.

2. Choose the lane. Use publish, reply, or combined.

3. If the topic is timely, research first. Separate facts from framing and carry concrete dates into the packet.

4. Run the shared auth check. Confirm the active handle before any live action.

5. Branch by lane.

Publish lane

1. Choose the format: single post, multi-post thread, long-form attachment, experimental native feature, or image-led card post.

2. Build a thread packet with thesis, target reader, desired interaction, hooks, outline, media plan, CTA, and follow-up reply plan.

3. If the value belongs in a card, design the card before finalizing the caption.

4. Probe the composer if the UI or feature set may have drifted:

node ./scripts/threads-compose.mjs probe-composer --headed

5. Default to a dry-run compose:

node ./scripts/threads-compose.mjs compose \
  --thread-file ./thread.json \
  --output-dir ./output/playwright/threads/run-01

6. Only publish if the user explicitly wants it:

node ./scripts/threads-compose.mjs compose \
  --thread-file ./thread.json \
  --output-dir ./output/playwright/threads/run-01 \
  --publish true \
  --headed

7. Review screenshots, final URL, and live rendering before claiming success.

Reply lane

1. Define the reply brief: target topic, tone, participation standard, promotional red lines, and skip criteria.

2. Discover more candidate posts than you need.

3. Score and prune for posts where you can add one useful missing layer.

4. Build a session file with postUrl, whyThisPost, replyType, recommendedReply, and optional alternates.

5. Validate the session:

node ./scripts/threads-reply-campaign.mjs validate-session \
  --session-file ./reply-session.json

6. Default to a dry-run:

node ./scripts/threads-reply-campaign.mjs run-session \
  --session-file ./reply-session.json \
  --output-dir ./output/playwright/threads-reply-campaign/run-01

7. If the user explicitly wants live replies, start with a canary when the account or UI changed:

node ./scripts/threads-reply-campaign.mjs run-session \
  --session-file ./reply-session.json \
  --output-dir ./output/playwright/threads-reply-campaign/run-01 \
  --publish true \
  --headed \
  --limit 1

8. Verify on the actual Replies tab after any live run.

Combined lane

1. Draft and dry-run the anchor post first.

2. Publish only after the publish QA pass.

3. Use the live post to sharpen the reply brief.

4. Run a small, high-quality reply session around adjacent discussions.

5. Avoid replies that merely restate the anchor post.

6. If needed, add a fast clarifying self-reply or follow-up comment on the anchor post.

Production defaults

• Default base URL: https://www.threads.com
• Shared auth state: output/playwright/threads/threads-auth-state.json
• Publish artifacts: output/playwright/threads/
• Reply artifacts: output/playwright/threads-reply-campaign/
• Default reply cap: 15
• Default mode: dry-run

Fast notes

• Use probe-composer or probe-feed whenever the web UI looks different.
• Prefer original Threads-native copy over cross-posted copy.
• Use links sparingly; earn the click.
• If three candidate reply targets in a row fail quality gates, stop and reassess the brief.
• If the live account handle is wrong, stop and recapture auth state before continuing.