x-human-loop-commenter

name

x-human-loop-commenter

description

Human-in-the-loop X/Twitter comment assistant workflow for finding visible posts, drafting natural replies, preparing review batches, and executing only explicitly confirmed single-account likes/replies in the user's logged-in local Chrome. Use when Codex is asked to browse X/Twitter, find reply candidates, comment, like, prepare engagement batches, improve reply style, or record verified X/Twitter action evidence while preserving strict confirmation, anti-spam, and active-tab safety boundaries.

X Human Loop Commenter

Overview

Use this skill to run a safe, personal X/Twitter reply workflow for one user-owned account at a time. Automate reading, candidate selection, and drafting; execute account-side effects only after explicit user confirmation for the exact item or reviewed batch.

This skill is not for multi-account coordination, engagement inflation, unattended comments, scraping at scale, reposting, following, DMs, login bypass, CAPTCHA bypass, rate-limit bypass, or evading platform safeguards.

Workflow

1. Establish scope.

   • Identify the exact account context, target languages, target profiles, view-count or reply-probability requirements, and whether the user wants candidates only or confirmed execution.
   • Treat "continue", "confirm", or "execute" as applying only to the latest clearly reviewed candidate set unless the user names another set.
   • Do not execute older pending batches, backup items, or newly found items without explicit selection.

2. Prepare browser control.

   • For real X/Twitter account state, use the user's logged-in local Chrome when available. Prefer the Chrome control skill/tooling and read its browser-control documentation before interacting.
   • Use a separate automation tab or window for browsing and execution. Do not scroll, type, navigate, or click in the user's active X/Twitter tab unless the user explicitly asked for that exact action.
   • Finalize/close automation tabs after the run unless the user needs a live handoff page.

3. Collect candidates read-only.

   • Use visible timeline, profile, or search result rows only. Bound scrolling/searching.
   • Reopen promising status URLs on detail pages when possible and record visible view labels, author, post text, language, and reply controls.
   • If a candidate is row-verified but the detail page does not render, mark it as requiring action-time detail verification before any like or reply.
   • When the user's goal is receiving replies, do not rank by view count alone. Prefer recent posts, mid-sized authors, authors who visibly reply to commenters, discussion prompts, low reply saturation, and topics where the user can add a concrete angle.
   • Filter out ads, official/media posts, obvious aggregation, giveaway/follow-bait, mutual-follow bait, crypto/finance bait unless requested, adult/sensitive content, political outrage, and unclear context.

4. Draft replies.

   • Read reply-style.md when drafting or revising comments.
   • Follow the original post language by default.
   • Keep replies short, concrete, and grounded in one specific detail from the post.
   • Avoid generic praise, summary essays, repeated templates, and language that sounds like a balanced AI explanation.
   • Do not invent context from images, links, private data, or inaccessible quoted posts.

5. Present a review batch.

   • Show exact URLs, observed view labels, post text or concise quoted context, risk notes, and the proposed reply for each item.
   • Make clear that no like/comment has been executed yet.
   • Wait for explicit confirmation before account-side effects. If the user confirms a subset, execute only that subset.
   • Use reports.md for candidate report and execution report formats.

6. Execute confirmed items.

   • For each item, reopen the target detail page and verify the exact status URL/id and visible post text before acting.
   • If the detail page is blank, restricted, mismatched, lacks safe controls, or exposes ambiguous controls that cannot be scoped, skip the item and record evidence.
   • Like the original post only when the target article is verified and the like/unlike control is uniquely scoped to that article.
   • Submit only the reviewed reply text. If a composer contains unexpected draft text, stop or clear only when it is clearly the expected composer and safe to do so.
   • After submitting, verify the reply is visible as the user's account. Do not retry submission when visibility is unclear unless a read-only check proves no duplicate was submitted.
   • Attempt to like the user's newly posted reply only when a safe visible control can be scoped to that own-reply article. Otherwise skip and record evidence.

7. Record evidence and handoff.

   • Save a Markdown execution report with per-item URL, observed views, original-like result, reply-submit result, own-reply-like result, submitted text, skips, and repairs.
   • Update project status files when working inside a project that requires handoff files.
   • Clearly mark remaining unexecuted items and prior pending batches to avoid accidental later execution.

Confirmation Boundary

Allowed without extra per-item confirmation:

• Open or create a separate automation tab.
• Read visible X/Twitter content.
• Scroll or navigate at a bounded pace in the automation tab.
• Extract visible post metadata.
• Rank candidates.
• Draft replies.
• Save local candidate reports.

Allowed only after explicit user confirmation for the exact item or reviewed batch:

• Like one visible original post.
• Submit one reviewed reply/comment.
• Like the user's own newly posted reply when safely located.

Forbidden:

• Unattended likes or comments.
• Multi-account coordinated commenting, mutual engagement, or account matrices.
• Reposts, follows, unfollows, DMs, standalone posts, giveaways, or reply spam unless a future user request is independently safe and explicitly confirmed.
• Bulk engagement, mass scraping, duplicate template comments, or engagement inflation.
• Login, CAPTCHA, rate-limit, or platform-safeguard bypass.

Practical Browser Rules

• Prefer stable X/Twitter attributes such as data-testid and target status href values when building locators.
• Scope locators to the verified target article before clicking like or reply.
• Check locator counts before clicking, filling, or pressing. If the control count is not exactly one, rescope or skip.
• X may expose duplicate dialog layers or both dialog and inline reply composers. Scope to the active dialog composer or the unique inline composer; never choose an arbitrary first textbox.
• If a first pass only likes originals but does not submit replies because of ambiguous composers, repair by reopening each detail page and locating the safe composer. Record that no reply was submitted during the failed pass.
• Use bounded retries for blank detail pages. After repeated blank or zero-article renders, skip and report.

Output Expectations

Candidate review output must include:

• Numbered item id.
• URL.
• Language/region.
• Author/handle when visible.
• Observed view label or row signal.
• Post content/context.
• Proposed reply.
• Reason for selection.
• Risk or skip note.

Execution output must include:

• Exact executed item range.
• Per-item original-like, reply-visible, and own-reply-like status.
• Items skipped or left unexecuted.
• Any ambiguity repairs.
• Browser cleanup status.
• Local report path.