Update to BROSH CRM

{
  "description": "Run AI SDR workflows for Brosh AI CRM: monitor sales inboxes, research prospects, answer emails, book meetings, and manage follow-ups. Use for sales email automation, not for support-only ticket handling.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 256
    },
    {
      "relative_path": "references/brosh-crm-model.md",
      "size_in_bytes": 5190
    },
    {
      "relative_path": "references/playbooks-and-safety.md",
      "size_in_bytes": 5654
    },
    {
      "relative_path": "references/sdr-workflows.md",
      "size_in_bytes": 6665
    }
  ],
  "name": "brosh-ai-sdr",
  "skill_md_contents": "---\nname: brosh-ai-sdr\ndescription: \"Run AI SDR workflows for Brosh AI CRM: monitor sales inboxes, research prospects, answer emails, book meetings, and manage follow-ups. Use for sales email automation, not for support-only ticket handling.\"\n---\n\n# Brosh AI SDR\n\nUse this skill when the user wants an AI SDR agent or scheduled sales assistant connected to Brosh AI CRM, email, web research, and calendar systems.\n\n## Core Workflow\n\n1. Resolve the user's desired autonomy level from their request and saved configuration before any recurring or external-send behavior. Reuse explicit authorization already given for the run; ask only if the action scope remains unclear:\n   - `draft_only`: prepare drafts and CRM recommendations.\n   - `approval_required`: prepare outbound email/calendar actions and wait for explicit approval before execution.\n   - `autonomous_low_risk`: send or book only pre-approved low-risk actions.\n   - `skip_confirmations`: skip user approval for configured low-risk sends, booking confirmations, reminders, follow-ups, and CRM hygiene; still escalate human-review categories.\n2. Inspect the available connectors before acting. Prefer purpose-built tools for Gmail, Outlook, Google Calendar, Outlook Calendar, Brosh AI CRM, and automations. If a required connector is unavailable, say what is missing and continue with drafts or a local plan.\n3. For inbound email work, read [references/sdr-workflows.md](references/sdr-workflows.md).\n4. For Brosh CRM table choices, field conventions, and write rules, read [references/brosh-crm-model.md](references/brosh-crm-model.md).\n5. For classification, reply rules, approval gates, meeting follow-ups, and escalation policy, read [references/playbooks-and-safety.md](references/playbooks-and-safety.md).\n\n## Brosh CRM Principles\n\n- Call the Brosh authenticated user/profile tool first when ownership, permissions, or default owner context matters.\n- Use Brosh CRM as the system of record for contacts, accounts, opportunities, activities, tickets, templates, and email settings.\n- Search before creating. Match inbound senders to contacts, then link to accounts, opportunities, and recent activity.\n- Log meaningful SDR decisions as CRM activity when the requested workflow includes CRM updates.\n- Use `activity.person` for contact relationships in activity records. Do not use `contact` for activity-contact links.\n- Treat quotes and invoices as records in `opportunities` with type/subtype semantics; quote/invoice line items belong in `opportunity_products`.\n- Never delete records or modify CRM schema unless the user explicitly asks and approves the action or schema change.\n\n## Email And Calendar Safety\n\n- Sender id `14`, alternate id `13`, and CC `sales_us@brosh.io` below are saved defaults for the BROSH sales workspace. Apply them only when that workspace and outreach context are verified. For other customer workspaces, use their own approved sender and CC configuration; numeric sender IDs are tenant-specific.\n- Never send to contacts with `email_opt_out=true`, clear unsubscribe intent, or unclear consent.\n- For outbound lead/contact sequences, process exactly one contact at a time. Complete matching, CRM/context review, web research, message generation, send or skip decision, Brosh email send, activity logging, and result verification for the current contact before moving to the next contact. Do not prepare a multi-contact send and then execute it later as a batch.\n- For one-to-one personalized sales outreach through Brosh CRM, use `send_message_single` with one row per recipient. Each row must include a contact id or email plus the final `subject` and `message`/`body`.\n- For template or segment-level outreach through Brosh CRM, use `send_email` with `templateid` or a direct `template` payload and recipient `rows`.\n- For AI SDR outbound email, use `email_settings` id `14` as the default sender: `BROSH main email SEND GRID - RONROY`. If the user specifies another `email_settings` id, use the user's specified sender id for that run. Resolve and pass the full sender row as `fromEmailSets` when the CRM tool allows it; otherwise pass the chosen id as `fromEmailSet`.\n- Before generating each outbound email body, resolve the selected sender id to its `email_settings.email_label`. The signature at the bottom of the email must match the selected sender id's `email_label` exactly. If sender id `14` resolves to Ron Roy, sign as Ron Roy; if sender id `13` resolves to Ben Ford, sign as Ben Ford. Never reuse a label from a different sender id.\n- When writing the email signature, use `email_settings.email_label`, not `email_settings.name`. If `email_settings.email_label` cannot be read, only use a fallback label that the user explicitly provided for that exact sender id. If the exact sender-id-to-label mapping is unknown, do not send; stop and ask for the correct label or a readable sender record.\n- Immediately before sending, check that the final body signature equals the label resolved for the sender id passed in that same tool call. When alternating senders, resolve each selected row independently and rebuild the signature for that email.\n- For AI SDR outbound email, always put `sales_us@brosh.io` in the outbound `cc` field unless the user explicitly gives a different CC rule.\n- Add the same `cc` value, normally `sales_us@brosh.io`, to the `task` payload when the send should be logged to `activity`.\n- Brosh CRM email sends are direct execution calls in the current MCP flow. Do not use obsolete `previewOnly`, `confirm`, or `confirmationToken` parameters, and do not claim an email was sent until the tool result confirms success.\n- Never invent pricing, contractual terms, integrations, security claims, roadmap dates, discounts, or availability. Use approved product materials, CRM templates, or clearly state that human review is needed.\n- For calendar booking, do not claim a slot is booked until the calendar connector confirms it. Mirror confirmed meetings into Brosh CRM activity records.\n\n## Scheduled Agent Behavior\n\nFor scheduled agents, keep each run bounded:\n\n- If the user asks to schedule the skill, use the host automation tools when available. A default high-frequency SDR schedule is every 5 minutes during configured business hours in the user's/team's timezone.\n- Process a configured mailbox/folder/query, not the entire mailbox.\n- Limit each run to a reasonable batch and carry over unresolved messages to the next run.\n- Deduplicate by email/thread/message id and CRM activity history.\n- Record what the agent did, skipped, and escalated.\n- Use the host automation/reminder tools when available; do not hand-write opaque schedule directives.\n\n## Output Expectations\n\nWhen reporting results, include:\n\n- processed email count;\n- action counts by category: drafted, sent, booked, updated CRM, escalated, skipped;\n- meetings booked with confirmed time and CRM links or record ids when available;\n- follow-ups/reminders created;\n- items needing human review and why.\n"
}