--- name: "x-twitter-browser-ops" description: "X/Twitter browser operations. Use for X browsing, analysis, bookmark management, content and profile operations, or browser-driven troubleshooting. Require explicit confirmation for outbound posts, DMs, engagement, follows, blocks, mutes, and list edits." argument-hint: "対象のX画面、実行したい操作、対象アカウントまたは投稿" user-invocable: true license: CC BY-NC-SA 4.0 metadata: author: yamapan (https://github.com/aktsmm) --- # X/Twitter Browser Ops Use this skill for all X/Twitter browser operations: browsing and analysis, follower/following collection, bookmark-folder management, content/profile management, and browser-driven troubleshooting. ## When to Use - User asks for X/Twitter follower, following, mutual follower, or verified follower analysis. - User asks to rank X/Twitter accounts by followers, export CSV/Markdown/HTML, or build a dashboard from collected X data. - User asks to organize bookmarks, create/rename/delete bookmark folders, or move bookmarks between folders. - User asks to operate X/Twitter in the browser. ## Do Not Use - Do not use to evade X rate limits, bans, access controls, paywalls, or privacy settings. - Do not save or expose login cookies, auth headers, HAR files, tokens, or browser profile data. ## Safety and Session Rules 1. Confirm the user is logged in before collecting private/session-dependent lists. 2. Treat the browser session as sensitive. Never persist cookies, CSRF tokens, Authorization headers, or HAR captures. 3. Prefer read-only page navigation and response observation over replaying internal API calls. 4. If screenshots or HTML outputs include notification badges, DMs, private handles, or unrelated personal data, mask or omit them. 5. For any outward-facing or relationship-changing action—post, reply, like, repost, DM, follow/unfollow, block, mute, or list edit—show the exact action and obtain explicit confirmation immediately before execution. 6. Bookmark folder creation, renaming, deletion, and assignment are permitted after the user explicitly approves the organization plan. ## Bookmark Management 1. Inspect existing folders plus representative unfoldered and folder-specific posts before proposing a minimal taxonomy. 2. Show the proposed folder names, merges, renames, and classification priority before mutating bookmarks. 3. Confirm each assignment from the UI before removing a post from its prior folder. 4. In virtualized infinite-scroll feeds, operate in bounded batches using a post's canonical `/status/` URL; re-resolve the post immediately before each mutation and never retain an element ref across scrolls or mutations. 5. Process one visible post at a time and re-scan canonical URLs after each folder-picker mutation; do not pre-capture a whole visible candidate batch because X can recycle the sibling articles immediately. 6. On a shared logged-in browser, create a dedicated work tab, pin its CDP target ID, and assert `/i/bookmarks` plus the active search query before every write batch; close only that work tab afterward. 7. Folder membership hydrates after the picker shell. Wait for checkmark/icon state before deciding assigned vs unassigned; an immediately missing checkmark is unknown, not safe to click. 8. X can render duplicate `[role=dialog]` shells. Treat a dialog as actionable only when its bounding rect has both positive width and height, and close it only while the route is `/i/bookmarks/add` to avoid an extra history-back navigation. 9. Treat missing folder-picker options, modals, or navigations as unverified—not as success. Keep the source assignment until the destination is visibly confirmed. 10. Scroll through several batches with no new canonical post URLs before declaring the feed complete; deduplicate and report counts by canonical post ID, and report skipped or unverified items separately. ## X Page Semantics Use URL path, not translated UI tab labels, to avoid tab mix-ups: - `/followers` = all followers. - `/following` = accounts the target follows. - `/followers_you_follow` = followers known to the logged-in user; for the target user's own account this is the useful mutual-follower view. - `/verified_followers` = verified followers only; this is not the same as all mutual followers. For mutual analysis, collect from `/followers_you_follow` when available, or use `relationship_perspectives.following === true` and `relationship_perspectives.followed_by === true` from follower responses. ## Collection Workflow 1. Open the profile and confirm the target handle and visible counts. 2. Navigate to the correct path explicitly. 3. Attach browser response observers for GraphQL list responses; parse user objects from responses rather than relying only on visible text. 4. Scroll slowly in small batches. Suggested baseline: 4-5 scrolls per batch, 4-9 seconds between scrolls, and pause 30-60 seconds after large batches. 5. If HTTP 429, repeated 403, forced redirects, login prompts, or unusual challenge pages appear, stop collection and report partial results instead of pushing harder. 6. Deduplicate by `rest_id` / user ID. Keep `screen_name`, `name`, `followers_count`, `url`, and relationship flags. ## Verified / Non-Verified Split 1. Collect mutual follower IDs from the mutual source. 2. Collect verified follower IDs from `/verified_followers`; filter those where the logged-in account also follows them when relationship flags are available. 3. Verified mutual = mutual IDs present in verified mutual collection. 4. Non-verified mutual = mutual IDs minus verified mutual IDs. 5. Do not assume a visible blue badge in the DOM is enough; prefer response fields such as `is_blue_verified` or verified list membership. ## Ranking and Output - Sort descending by `legacy.followers_count` / `followers_count`. - Output rank, display name, handle, follower count, and profile URL. - For Top 100, verify there are at least 100 rows; if fewer, say how many were collected. - For HTML dashboards, delegate visual artifact styling to `web-artifacts-builder` when appropriate. - For PowerShell-generated HTML, embed JSON safely: use `ConvertTo-Json -Compress`, place it in `