Production use + intent to contribute domain-skills for Mastodon, Bluesky, and LinkedIn engagement workflows

[drmweyers]

Before submitting

• I searched existing issues and discussions.
• This is a feature request, not a bug.

Problem

SmartSocial (https://smartsocial-ai.com) is a live multi-tenant SaaS for autonomous social media engagement. Our agent "Bob" runs 6-platform engagement loops
via official APIs today (Bluesky, X, Reddit, Mastodon, LinkedIn-via-UI, multi-account inbox).

Two concrete limitations are pushing us toward browser-harness:

1. Three platforms we engage on have no domain-skills/ coverage yet — Mastodon, Bluesky, and the proactive (vs reactive) side of LinkedIn. Without skills
   here we either roll our own per-platform browser logic in isolation (carrying selector-rotation maintenance alone) or stay API-only and lose access to
   surfaces the API doesn't expose (TikTok comments, LinkedIn proactive engagement, etc.).

2. Selector rotation is unsustainable for any single team to absorb solo. browser-harness's self-healing helpers + community-contributed playbooks are the
   unique value the framework offers over rolling our own Playwright stack. To benefit from that loop we need to be in it — both consuming and contributing.

We're a real production user with working code across these platforms and want to contribute the platform-generic parts upstream rather than carry the
maintenance privately.

Proposal

Three concrete domain-skills/ contributions plus one generic helper:

1. domain-skills/mastodon/ — read home timeline, post reply, boost. No folder exists today. Federated DOM diversity (mastodon.social, fosstodon.org,
   hachyderm.io) makes this a natural showcase for the self-healing pattern. I have working API-based Mastodon code I can port.
2. domain-skills/bluesky/ — AT Protocol thread engagement (reply, like, follow-back). No folder exists today.
3. Additions to domain-skills/linkedin/ — connection-request follow-up flows and DM-after-acceptance. I noticed PR linkedin: domain skills for send-connection-request + connection-search-scrape #348 is in flight on the
   connection-request side; happy to coordinate with that contributor rather than overlap.

Generic helper for agent_helpers.py: safe_click_after_modal_settle() — waits for aria-busy="false" before clicking inside a freshly-opened dialog.
Recurring need across compose-modal flows on multiple platforms.

Happy to follow your preferred scoping. Should I open the Mastodon PR first as the smallest blast radius?

— Mark Weyers, BCI Innovation Labs (https://bcinnovationlabs.com)

Alternatives considered

A few approaches I evaluated before posting:

1. Keep these skills proprietary in our own codebase. Means carrying selector-rotation alone, missing the community self-healing pattern, no connection
   with downstream users hitting the same platforms. Net negative once we'd already decided to adopt browser-harness as the actuator.

2. Fork browser-harness with these skills internally added. Rejected. With ~30 PRs/week upstream, fork-divergence would mean weekly re-merge effort, silent
   breakage on helper APIs, and losing community-contributed skills landing into the canonical version. Vercel-on-Next.js model fits us better: upstream the
   primitives, keep our product layer (audit trail, brand config, approval gates) separate.

3. Open three separate smaller issues instead of one omnibus. Happy to split if you prefer. Bundled because the three platforms share a design question
   around federated/heterogeneous instances (Mastodon/Bluesky), and I wanted to flag the LinkedIn PR linkedin: domain skills for send-connection-request + connection-search-scrape #348 overlap upfront rather than open a parallel issue.

4. Open PRs directly without this intro issue. Would land cold without coordination on PR linkedin: domain skills for send-connection-request + connection-search-scrape #348 or your scoping preferences. Intro felt like cheaper
   coordination cost than three half-aligned PRs.

5. Wait until we have more production engagement-log data before contributing. Not blocked on this — we have working API-based code for all three platforms
   in TypeScript that I can port. Browser-harness adoption is a parallel actuator surface, not a data-gated decision.

[Alezander9]

Go ahead and submit domain skills as PRs here, we welcome them

[drmweyers]

Thanks @Alezander9 — will do. Plan: Mastodon skill first, then a small modal-settle helper, then Bluesky. Holding off on LinkedIn until #348 lands.