safe-facebook-messenger

# Safe Facebook Messenger ## Purpose Use this skill to send or draft Facebook Messenger messages through a **local, signed-in Chrome browser** controlled via **Chrome DevTools MCP**. This skill is for **Messenger only**. Its purpose is to prevent the most common browser-driven messaging failures: - typing into the wrong thread - sending from the wrong composer - selecting the wrong person from search - confusing group chats with 1:1 threads - sending high-risk content without review ## Required environment Use this skill only when all of the following are true: - Chrome is signed in to the intended Messenger account - Chrome DevTools MCP is connected to that live browser session - the operator understands that this skill controls a signed-in browser directly Recommended posture: - use an intentionally chosen browser profile/account - prefer operator-supervised/manual invocation by default - validate behavior before enabling any broader autonomy ## Privacy and access model This skill relies on browser-side inspection of Messenger UI state needed to operate safely, including: - active conversation header - compose placeholder - visible thread history snippets - search results - outbound message state Because it operates through Facebook Messenger in a live browser session, conversation content necessarily passes through the browser and Facebook's own service as part of normal use. Any additional logging, storage, or forwarding performed by the surrounding runtime or operator should be disclosed separately. ## Core operating principles 1. **Verify the thread before acting.** 2. **Verify the composer before typing.** 3. **Re-verify after every meaningful UI change.** 4. **Stop on ambiguity instead of guessing.** 5. **Treat search as high-risk until handoff is confirmed.** 6. **Treat group chats as higher risk than 1:1 threads.** 7. **Screen message risk before sending.** 8. **Verify the result after send.** ## Safety rules ### Never trust a single signal Do not rely on only one of these: - URL - visible thread row - search result name - stale element ref - composer presence alone Use multiple signals together. ### Never trust stale refs After any meaningful UI change, re-snapshot and re-resolve the relevant target. ### Never continue after human interference If the human clicks, changes focus, or otherwise interacts with the page mid-run, discard the old plan and re-verify from scratch before continuing. ### Never auto-commit on behalf of the user Do not auto-send commitments involving: - money - deadlines - deliverables - legal exposure - availability promises ### Never include irrelevant backstage chatter Do not mention testing, browser mechanics, thread switching, or UI instability unless explicitly relevant to the conversation or requested by the user. ## Social-risk screening Before sending, classify the message. ### Usually acceptable for direct send - low-stakes friendly conversation - casual follow-ups in known threads - acknowledgements - simple supportive or social replies - obvious continuation of an active exchange ### Draft first or escalate instead of auto-send - money, pricing, refunds, debts, purchases - contracts, legal issues, threats, liability - deadlines, promises, deliverables, availability - investor, employer, client-escalation, press, or lawyer threads - severe conflict, grief, breakup-style, or highly sensitive interpersonal messages - first outreach to an important new person - anything likely to be regretted if phrased badly If uncertain, draft first. ## Tone and identity rules ### Match the user’s style Inspect recent thread history and match: - message length - punctuation style - emoji use - warmth vs bluntness - formality vs playfulness Avoid generic assistant tone the user would never use. ### Identity disclosure Mention Identity/Name only when: - the user explicitly wants that disclosed, or - it is genuinely relevant to the conversation ## Thread targeting workflow ### 1. Collect target evidence Before acting, collect as many of these as practical: - recipient name or group title - thread URL/id - active conversation header - compose placeholder - recognizable recent thread history - prior-conversation evidence - relationship/friendship evidence when relevant - for group chats: participant or conversation-info evidence ### 2. Choose targeting mode #### Existing verified thread Use when the thread is already known and clearly active. #### Search reacquisition Use when: - the thread is not visible - the thread list is reordered - the current thread state feels contaminated - multiple similar recent chats exist - a previous draft/send misrouted in the current session #### Thread-list caution Thread-list clicks are weaker evidence than verified active-conversation state. Do not assume a visible row means the active composer belongs to that thread. ### 3. Verify the active conversation Before clicking the composer, confirm: - the conversation header matches the intended target - the compose placeholder matches the intended target - visible thread history looks correct - if search was used, the result is supported by prior-thread or relationship evidence If the active conversation is not clearly correct, stop. ## Composer workflow ### 1. Click composer, then re-verify After clicking the composer: - take a fresh snapshot - confirm the active conversation is still the intended one - confirm the focused composer belongs to that same thread If the conversation changed, stop before typing. ### 2. Type, then re-verify After typing: - re-snapshot - confirm the draft text is visible in the intended composer - confirm the active conversation is still correct If the draft appears in another thread, do not send. ### 3. Send, then verify result After sending: - confirm the same thread is still active - confirm the new outbound bubble appears there - confirm visible send state such as `Sent`, `Seen`, or obvious outbound placement Do not report success until the actual result is visible in the intended thread. ## Search-based reacquisition Use this when direct thread state is not trustworthy. ### Preferred implementation When possible, prefer: - DOM/evaluate-based focus acquisition for **Search Messenger** - DOM/evaluate-based result selection This is generally more reliable than aging snapshot refs for Messenger search. ### Search sequence 1. Take a fresh snapshot. 2. Focus **Search Messenger**. 3. Confirm Search Messenger is actually the focused field. 4. Confirm the current thread composer is not focused. 5. Type the exact target name into search. 6. Inspect results carefully. 7. Choose only a result supported by thread/history/relationship evidence. 8. Select the result. 9. If result selection fails, stop immediately and clear search state. 10. Wait for the active conversation header to change. 11. Confirm the conversation header now matches the intended target. 12. Confirm the composer placeholder now matches the intended target. 13. Confirm the search box is no longer the active field. 14. Confirm the previous thread no longer owns the visible draft box. 15. Dismiss or normalize any lingering search-results overlay. 16. Only then proceed to draft or send. ### Search failure rules Do not proceed if: - Search Messenger never actually becomes focused - search results are ambiguous - result selection fails - the conversation header never changes to the target - the search box remains focused after selection - the previous thread still owns the visible draft box - the search overlay cannot be dismissed or normalized ## Group chat targeting Treat Messenger group chats as higher-risk targets. Do not trust the group title alone. Also verify at least one of: - participant evidence - recognizable group-thread history - known thread URL/id - conversation info confirming the intended group For group chats: - prefer draft-first - prefer explicit approval for sensitive content - stop if participant context is unclear ## Cleanup mode Use cleanup mode after a mistaken draft or send. ### Cleanup sequence 1. Open the accidental recipient thread directly. 2. Verify the mistaken recipient and exact content. 3. Unsend, delete, or clear draft only after exact content match. 4. If the failure came from search contamination, clear the contaminated draft before retrying search. 5. Verify removal state. ## Stop conditions Stop before typing or sending if any of these are true: - active conversation header changes unexpectedly - focused composer no longer belongs to intended thread - draft appears in another thread - search results are ambiguous - Search Messenger never actually gains focus - search result selection fails - search box remains focused after result selection - conversation header never changes after search-result selection - previous thread still owns the visible draft box after search selection - lingering search overlay cannot be normalized - group title matches but participant/context evidence does not - multiple composer surfaces are visible and ownership is unclear - only stale refs are available and no fresh snapshot has been taken - human interaction changed focus and no re-verification has been performed ## Examples ### Example: verified known-thread send - open a known Messenger thread - verify conversation header - verify compose placeholder - type message - re-verify draft placement - send - verify outbound bubble in same thread ### Example: search-based reacquisition - focus Search Messenger - verify focus - type target name - select an existing-thread result supported by prior-thread evidence - verify conversation header - verify compose placeholder - normalize lingering search UI - draft without sending ### Example: refusal on ambiguity - search returns multiple similar names or unclear group threads - participant or prior-thread evidence does not resolve ambiguity - stop before typing any draft content - report the ambiguity instead of guessing ## Minimal checklist Before clicking composer: - target identified - active conversation verified - fresh snapshot checked - if search used, relationship/group evidence confirmed After clicking composer: - fresh snapshot taken - same conversation still active - composer still belongs to target After typing: - fresh snapshot taken - draft visible in intended composer - same conversation still active Before send: - social-risk screen passed - tone matches thread - no accidental overcommitment - no unnecessary operational chatter After send: - outbound message visible - same thread still active - status confirmed