@floomhq/signaldash 0.13.0 → 0.22.0

package/skills/signaldash-safe-usage/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: signaldash-safe-usage
-description: Safely read and send LinkedIn, WhatsApp, or email messages through the SignalDash MCP without triggering account restrictions or contacting the wrong person. Use whenever an agent uses li_list_chats, li_read_messages, li_send_message, wa_list_chats, wa_read_messages, wa_send_message, email_list, email_read, or email_send.
+description: Safely search stored LinkedIn connections, inspect exact contact state and action budgets, read and send LinkedIn, WhatsApp, or email messages, and operate exact LinkedIn invitations or human-approved invitation batches through the SignalDash MCP without triggering account restrictions or contacting the wrong person. Use whenever an agent uses li_search_connections, sd_contact_state, sd_budget_status, li_list_chats, li_read_messages, li_send_message, li_send_invitation, li_invitations_received, li_accept_invitation, li_invitations_sent, li_withdraw_invitation, li_create_invitation_batch, li_get_invitation_batch, li_cancel_invitation_batch, wa_list_chats, wa_read_messages, wa_send_message, email_list, email_read, or email_send.
 ---
 
 # Use SignalDash safely
@@ -23,6 +23,21 @@ Treat LinkedIn, WhatsApp, and email as human accounts, not bulk messaging APIs.
 Never infer a recipient from a partial name. Never send blind. Never retry a
 send after an ambiguous timeout without first reading the thread.
 
+## Contact-state limits
+
+- `sd_contact_state` uses exact user-and-channel identifiers only. It does not
+  infer that a LinkedIn profile, WhatsApp number, and email address belong to
+  one person.
+- Inspect state with `action:"get"` before outreach planning. Stop when
+  `campaign_eligible` is false.
+- Add a suppression only after explicit human approval of the exact channel,
+  identifier kind, and reason. Use `action:"suppress"` with an allowed reason
+  and `confirm:true`.
+- Never switch identifiers or channels to evade `contact_suppressed`,
+  `recipient_replied`, `already_contacted`, or `already_connected`.
+- MCP cannot clear a suppression. Escalate mistaken suppressions to the
+  SignalDash operator.
+
 ## Email limits
 
 - `email_send` accepts one recipient per call. Never loop to simulate a bulk
@@ -37,12 +52,62 @@ send after an ambiguous timeout without first reading the thread.
 
 ## LinkedIn limits
 
-- Keep normal messaging at 15 to 20 sends per day. SignalDash hard-caps at 18
-  send attempts per account per UTC day.
-- Let SignalDash enforce 45 to 90 seconds between sends. Do not parallelize
-  send calls or bypass the guard.
+- Prefer `li_search_connections` for list building inside the user's existing
+  network. It searches the account-scoped stored snapshot and exact local
+  contact state only; it makes no LinkedIn, Unipile, HarvestAPI, or other paid
+  discovery request. A missing snapshot requires the paced `signaldash
+  connections` sync, never an improvised profile-fetch loop.
+- Treat connection-search results as planning evidence, not action approval.
+  Inspect `already_in_contact`, `contact_state`, and `blocking_reasons`.
+  Resolve, review, and approve every later action through its one-object flow.
+- Read `sd_budget_status` before planning multiple LinkedIn actions. Treat its
+  campaign-excluded portion as capacity campaigns cannot consume, never as a
+  reserved or guaranteed manual allowance. Its counts cover SignalDash
+  attempts, not all native LinkedIn activity.
+- Keep normal messaging at human volume. Use the cap reported in each hosted
+  response; LinkedIn messages, invitations, invitation maintenance, and post
+  publishing share the stable sender's daily action budget.
+- Let SignalDash serialize LinkedIn writes and apply action-specific jitter. Do
+  not parallelize write calls or bypass the guard. Invitation jitter completes
+  before the server's final provider preflight and action reservation.
+- Campaign invitations use a sender-local Monday-Friday 09:00-17:00 work
+  window and a durable 90-180 second per-sender pacing interval. Timing is
+  checked before final preflight and atomically during action reservation.
+  Downtime does not authorize a catch-up burst.
+- `li_create_invitation_batch` accepts only 1-10 immutable canonical LinkedIn
+  `/in/` URLs with an exact inclusion reason and optional exact note for each
+  target. It starts a durable preview, never a provider write. Use
+  `li_get_invitation_batch` until the preview is complete, then give the exact
+  `approval_url` to the human.
+- MCP cannot approve a batch. Never enter the human credential, automate the
+  approval page, preselect targets, or claim approval from an MCP confirmation.
+  The human authenticates separately, reviews every stored row, and selects
+  each exact invitation.
+- To cancel, first call `li_get_invitation_batch`, show the exact state and
+  approval hash, obtain explicit approval, then call
+  `li_cancel_invitation_batch` once with that exact hash and `confirm:true`.
+  Cancel affects only unstarted targets and cannot recall an executing write.
+- Do not emulate pause, resume, priority, future scheduling, recurring runs,
+  dynamic target generation, or automatic follow-ups. A changed target, note,
+  reason, sender binding, or source label requires a new batch and new human
+  approval.
+- SignalDash does not expose future start dates, recurring schedules,
+  automatic follow-ups, acceptance-triggered messages, or multi-message
+  sequences. Treat every later message as new context that needs a fresh
+  thread read, exact draft, and human approval.
 - LinkedIn invitation ceilings vary and often surface around 100 invitations
-  per week. SignalDash exposes no invitation tool. Do not automate invites.
+  per week. SignalDash enforces a separate default policy cap of 100 outbound
+  invitation attempts per stable sender each UTC week. This is not a claim
+  about a LinkedIn-safe threshold.
+- Preview `li_send_invitation` once without `confirm`, show the exact target and
+  note, obtain approval, then repeat the identical payload once with
+  `confirm:true`.
+- Before `li_accept_invitation` or `li_withdraw_invitation`, list the exact
+  current received or sent invitation, show the exact action, and obtain
+  approval. Never loop over an invitation page.
+- Relationship uncertainty, an existing connection, an existing one-to-one
+  chat, a pending invitation in either direction, an incomplete bounded page,
+  a sender lock, or `outcome_unknown` blocks the action.
 - Never bulk-fetch profiles, run enrichment sweeps, or repeatedly open
   individual profiles. Prefer chat lists, exported connection data, and
   cached records.
@@ -71,13 +136,13 @@ sessions, and repeated checkpoint retries trigger restrictions.
 Do not work around daily caps, jitter, duplicate detection, account scoping,
 or the persistent warning lock.
 
-On a warning:
+On a warning or `outcome_unknown`:
 
 1. Stop all sends on that account.
 2. Inspect LinkedIn or WhatsApp manually for a restriction or checkpoint.
 3. Wait until the account is clearly back in good standing.
-4. Let a human clear only that account's entry in
-   `~/.signaldash/safety/send-state.json`.
+4. Let the hosted SignalDash operator reconcile and clear the durable sender
+   lock. A local session change cannot clear it.
 5. Resume at a lower volume.
 
 Let the agent act slowly and human-like. Account health outranks throughput.