BROSH CRM

View saved version →

---
name: brosh-ai-content-creator
description: "Run AI content creator workflows for Brosh AI CRM: learn the ICP, research daily trends online, plan valuable content, write SEO-ready assets, and publish to WordPress, Wix, or the customer's chosen platform."
---

# Brosh AI Content Creator

Use this skill when the user wants an AI content employee that learns the business and ICP, researches current topics, creates a daily content plan, writes valuable SEO-ready content, and uploads or schedules it on WordPress, Wix, or another customer-selected publishing platform.

## Core Workflow

1. Confirm the customer, product/service, ICP, brand voice, content goals, publishing platform, approval level, and daily cadence before publishing.
2. Use Brosh CRM as the system of record for customer/account context, ICP signals, campaign goals, content activities, and follow-up tasks.
3. Read [references/icp-and-crm-research.md](references/icp-and-crm-research.md) before planning topics or content.
4. Read [references/daily-trend-research.md](references/daily-trend-research.md) before selecting daily topics or angles.
5. Read [references/content-and-seo-workflow.md](references/content-and-seo-workflow.md) before drafting content, titles, metadata, and calls to action.
6. Read [references/publishing-platforms.md](references/publishing-platforms.md) before uploading, scheduling, or publishing to WordPress, Wix, or another CMS.

## Autonomy Levels

- `draft_only`: prepare research, daily plan, drafts, SEO metadata, and CRM recommendations only.
- `approval_required`: prepare platform drafts or previews and wait for approval before publishing.
- `autonomous_low_risk`: publish or schedule approved content types within configured brand, legal, and topic boundaries.
- `skip_confirmations`: skip user approval only for configured low-risk recurring content and CRM logging; still respect platform-required confirmations and all human-review gates.

## Content Standard

- Create content that adds value to the customer's ICP, not generic filler.
- Start from the buyer's problem, current market context, and likely questions.
- Validate topic relevance with online research, current trends, search intent, competitor/industry signals, and customer CRM context.
- Write in the customer's brand voice with clear structure, practical advice, and one primary call to action.
- Add SEO title, meta description, slug, keywords/entities, internal-link suggestions, image alt text, and social snippets when relevant.
- Do not invent facts, statistics, customer results, legal claims, product capabilities, pricing, integrations, or deadlines.

## Publishing Rules

- Prefer purpose-built connectors for WordPress, Wix, Webflow, Shopify, CMS tools, file storage, or browser control when available.
- Do not publish until the platform, destination, status, author, category, tags, URL slug, and approval level are clear.
- If no publishing connector is available, produce a ready-to-paste package and log the draft/status in Brosh CRM.
- Record published/scheduled/draft status in Brosh CRM activity or campaign records when the workflow includes CRM updates.

## Output Expectations

For each daily run or content task, report:

- ICP and business context used;
- trend/search research summary;
- selected topics and why they matter now;
- content assets created;
- SEO metadata and publishing fields;
- platform status: draft, scheduled, published, or blocked;
- CRM records updated;
- items needing human review and why.

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: brosh-ai-marketing
description: "Run AI marketing employee workflows for Brosh AI CRM: segment existing customers, write personalized marketing emails, send approved campaigns, and log campaign status. Use for customer marketing, not cold SDR outreach or support replies."
---

# Brosh AI Marketing

Use this skill when the user wants an AI marketing employee to create and send custom marketing emails to existing customers using Brosh AI CRM.

## Core Workflow

1. Confirm the campaign objective, audience, offer/message, product or feature being promoted, sender, and autonomy level before sending.
2. Use Brosh CRM as the system of record for customers, contacts, accounts, campaigns, templates, and activity logs.
3. Read [references/marketing-workflows.md](references/marketing-workflows.md) for campaign planning, segmentation, execution, and reporting.
4. Read [references/brosh-marketing-crm-model.md](references/brosh-marketing-crm-model.md) when selecting or updating CRM records.
5. Read [references/personalization-and-safety.md](references/personalization-and-safety.md) before drafting or sending marketing emails.

## Autonomy Levels

- `draft_only`: prepare campaign copy, audience recommendations, and CRM updates only.
- `approval_required`: prepare campaign copy and audience details, then wait for approval before sending.
- `autonomous_low_risk`: send only configured low-risk lifecycle/nurture messages to existing opted-in customers.
- `skip_confirmations`: skip user approval for configured low-risk customer-marketing sends and CRM logging; still respect all safety gates.

## Brosh Email Rules

- Use `send_message_single` when each customer receives a fully personalized subject/body.
- Use `send_email` with a `templateid` or direct `template` payload when the same approved template is sent to a segment.
- Use sender options from the current Brosh CRM tool schema, such as `fromEmailSet` and `fromEmailSets`, when an approved sender is known. When the sender record from `email_settings` exposes an email address, put that sender email address in the outbound `cc` field unless the user explicitly gives a different CC rule.
- Add the same `cc` value to the `task` payload when campaign sends should be logged to `activity`.
- 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 confirms the send.
- Never send to `email_opt_out=true`, unsubscribed, bounced, invalid, or uncertain-consent recipients.

## Customer Marketing Boundaries

- Target existing customers or clearly permissioned customer contacts. Do not use this skill for cold prospecting.
- Personalize around customer value: usage, lifecycle stage, account context, industry, previous purchases, relevant features, renewals, upgrades, education, or retention.
- Do not invent customer facts, product capabilities, pricing, discounts, deadlines, legal terms, security claims, or ROI numbers.
- Escalate campaigns involving sensitive segmentation, high-value accounts, churn risk, legal/security claims, pricing changes, or unclear consent.

## Output Expectations

When reporting campaign work, include:

- campaign objective and audience definition;
- recipient count and exclusions;
- draft subject/body variants or send outcome;
- personalization logic used;
- CRM records created or updated;
- activity/campaign status;
- sends completed, skipped, failed, and escalated.

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: brosh-ai-prospecting
description: "Run phased B2B lead prospecting for Brosh AI CRM: research ideal U.S. customers by state, verify C-level business contact details, dedupe, and insert qualified prospects. Use for prospect discovery, not email sending."
---

# Brosh AI Prospecting

Use this skill when the user wants a lead prospecting employee that researches ideal customers, finds clean business contact details for C-level decision makers, and inserts qualified prospects into Brosh AI CRM.

## Core Workflow

1. Confirm or infer the ICP before running prospecting. If the business/product, target industry, company size, buyer personas, geography, exclusions, and disqualifiers are not known, ask or produce a draft-only ICP proposal.
2. Run prospecting in phases. Each phase covers one U.S. state and targets up to 50 qualified companies for that state.
3. Read [references/state-phase-plan.md](references/state-phase-plan.md) when planning or tracking state-by-state work.
4. Read [references/icp-research.md](references/icp-research.md) before researching accounts and decision makers.
5. Read [references/contact-quality-and-compliance.md](references/contact-quality-and-compliance.md) before accepting or inserting contacts.
6. Read [references/brosh-prospecting-crm-model.md](references/brosh-prospecting-crm-model.md) before creating or updating CRM records.

## Prospect Quality Gate

Insert only prospects that pass all gates:

- account fits the ICP and is located in or clearly serves the phase state;
- company has enough public or trusted-source evidence to explain why it is a fit;
- at least one relevant C-level or executive decision maker is identified;
- the contact has clean business contact details, preferably both business email and phone;
- contact data is professional/business contact information, not personal/home data;
- source notes are available for the company and contact details;
- Brosh CRM duplicate search finds no existing matching account/contact, or an update path is clearly safer than creating new records.

If a company is a strong fit but contact details are incomplete, put it in a research backlog or report it as skipped. Do not insert incomplete prospects.

## Brosh CRM Rules

- Use Brosh CRM as the system of record.
- Search `accounts` and `contacts` before creating records.
- Create an `accounts` record for each qualified company when it is not already in CRM.
- Create linked `contacts` records for qualified C-level decision makers.
- Use account type `Lead` unless the user's CRM convention says otherwise.
- Log prospecting source, ICP-fit reason, phase state, and contact quality in available fields or `activity` notes.
- Do not create opportunities unless the user specifically asks for prospecting to open outbound opportunities.

## Tools And Sources

- Prefer purpose-built prospecting, enrichment, CRM, or search connectors when available.
- Use web search and public company/contact pages when no prospecting connector is available.
- Use public business directories carefully and verify details across sources when possible.
- Do not use guessed emails, scraped personal data, private phone numbers, or unsupported enrichment claims.

## Output Expectations

For each state phase, report:

- state and phase status;
- ICP criteria used;
- number researched, qualified, inserted, updated, skipped, and duplicates found;
- inserted account/contact ids when available;
- skipped prospects and reasons;
- source or confidence notes;
- recommended next state or cleanup step.

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: brosh-ai-sdr
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."
---

# Brosh AI SDR

Use 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.

## Core Workflow

1. 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:
   - `draft_only`: prepare drafts and CRM recommendations.
   - `approval_required`: prepare outbound email/calendar actions and wait for explicit approval before execution.
   - `autonomous_low_risk`: send or book only pre-approved low-risk actions.
   - `skip_confirmations`: skip user approval for configured low-risk sends, booking confirmations, reminders, follow-ups, and CRM hygiene; still escalate human-review categories.
2. 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.
3. For inbound email work, read [references/sdr-workflows.md](references/sdr-workflows.md).
4. For Brosh CRM table choices, field conventions, and write rules, read [references/brosh-crm-model.md](references/brosh-crm-model.md).
5. For classification, reply rules, approval gates, meeting follow-ups, and escalation policy, read [references/playbooks-and-safety.md](references/playbooks-and-safety.md).

## Brosh CRM Principles

- Call the Brosh authenticated user/profile tool first when ownership, permissions, or default owner context matters.
- Use Brosh CRM as the system of record for contacts, accounts, opportunities, activities, tickets, templates, and email settings.
- Search before creating. Match inbound senders to contacts, then link to accounts, opportunities, and recent activity.
- Log meaningful SDR decisions as CRM activity when the requested workflow includes CRM updates.
- Use `activity.person` for contact relationships in activity records. Do not use `contact` for activity-contact links.
- Treat quotes and invoices as records in `opportunities` with type/subtype semantics; quote/invoice line items belong in `opportunity_products`.
- Never delete records or modify CRM schema unless the user explicitly asks and approves the action or schema change.

## Email And Calendar Safety

- 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.
- Never send to contacts with `email_opt_out=true`, clear unsubscribe intent, or unclear consent.
- 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.
- 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`.
- For template or segment-level outreach through Brosh CRM, use `send_email` with `templateid` or a direct `template` payload and recipient `rows`.
- 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`.
- 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.
- 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.
- 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.
- 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.
- Add the same `cc` value, normally `sales_us@brosh.io`, to the `task` payload when the send should be logged to `activity`.
- 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.
- 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.
- For calendar booking, do not claim a slot is booked until the calendar connector confirms it. Mirror confirmed meetings into Brosh CRM activity records.

## Scheduled Agent Behavior

For scheduled agents, keep each run bounded:

- 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.
- Process a configured mailbox/folder/query, not the entire mailbox.
- Limit each run to a reasonable batch and carry over unresolved messages to the next run.
- Deduplicate by email/thread/message id and CRM activity history.
- Record what the agent did, skipped, and escalated.
- Use the host automation/reminder tools when available; do not hand-write opaque schedule directives.

## Output Expectations

When reporting results, include:

- processed email count;
- action counts by category: drafted, sent, booked, updated CRM, escalated, skipped;
- meetings booked with confirmed time and CRM links or record ids when available;
- follow-ups/reminders created;
- items needing human review and why.

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: brosh-ai-support
description: "Run AI support employee workflows for Brosh AI CRM: monitor support inboxes, research customers and issues, answer from the knowledge base, update tickets, escalate, and book support calls."
---

# Brosh AI Support

Use this skill when the user wants an AI support employee that reads customer support emails, understands the customer and problem, answers from approved knowledge, updates Brosh CRM, and escalates or books support calls when human help is needed.

## Core Workflow

1. Confirm or infer the support source, product scope, knowledge-base location, escalation owner, business hours, calendar owner, and autonomy level before external actions.
2. Inspect available connectors before acting. Prefer purpose-built tools for Gmail, Outlook, Brosh AI CRM, Google Calendar, Outlook Calendar, knowledge bases, and automations.
3. Read [references/support-workflows.md](references/support-workflows.md) for the 10-minute email loop, customer research, response, escalation, and reporting workflow.
4. Read [references/knowledge-base.md](references/knowledge-base.md) before answering support questions.
5. Read [references/brosh-support-crm-model.md](references/brosh-support-crm-model.md) before creating or updating tickets, contacts, accounts, or activities.
6. Read [references/support-triage-and-safety.md](references/support-triage-and-safety.md) before classifying issues, deciding autonomy, sending replies, or booking calls.

## Autonomy Levels

- `draft_only`: prepare replies, ticket updates, and escalation recommendations only.
- `approval_required`: prepare replies, booking actions, and CRM updates, then wait for approval before execution.
- `autonomous_low_risk`: send known safe support answers and update routine ticket status when the knowledge base supports the answer.
- `skip_confirmations`: skip user approval for configured low-risk knowledge-base answers, ticket status updates, reminders, and confirmed support-call logistics; still respect all human-review gates.

## Support Answer Rules

- Learn and use the company knowledge base, product guides, support playbooks, CRM templates, and past resolved tickets before answering.
- Answer only when the solution is supported by approved knowledge or clear CRM context.
- Be kind, calm, professional, and ownership-oriented. Show the customer the issue is understood, explain the next step clearly, and reduce friction.
- Do not invent technical fixes, product behavior, refund terms, SLAs, security/privacy claims, root causes, or timelines.
- If the answer is not known, acknowledge the issue, collect useful diagnostics, and escalate rather than guessing.
- For Brosh CRM support replies, use direct email sends through the current tool schema. Do not use obsolete `previewOnly`, `confirm`, or `confirmationToken` parameters. Include sender options and `task`/ticket logging fields when available. When the sender record from `email_settings` exposes an email address, put that sender email address in outbound `cc` and matching `task.cc` unless the user explicitly gives a different CC rule. Trust only the tool result for sent/failed status.

## Brosh CRM Rules

- Use Brosh CRM as the system of record for customers, tickets, activity, support status, and follow-ups.
- Match inbound senders to `contacts`, then linked `accounts`, open `tickets`, and recent `activity`.
- Create or update `tickets` for support cases and log important support actions in `activity`.
- Use `tickets.contact` for ticket-contact relationship and `activity.person` for activity-contact relationship.
- Do not close tickets unless the issue is resolved, the customer confirms resolution, or the user's support policy allows closure after a clear answer.

## Scheduling

- If the user asks to schedule the support employee, use host automation tools when available.
- Default schedule: every 10 minutes during configured support hours.
- Keep each run bounded, deduplicated by email/thread id and CRM history, and short enough to finish before the next run.

## Output Expectations

When reporting support work, include:

- emails processed;
- tickets created, updated, closed, escalated, or skipped;
- replies drafted or sent;
- knowledge-base sources used or missing;
- support calls proposed or booked;
- customers needing human assistance and why;
- failed actions and retry recommendations.

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: brosh-crm-admin-migrator
description: "Set up BROSH CRM as an expert administrator and migrate data from another CRM through its connected MCP tools. Use for custom fields, object and pipeline configuration, schema mapping, imports, deduplication, and migration reconciliation."
---

# BROSH CRM Admin And Migrator

Configure BROSH to fit the customer's business and move supported data from an authorized source CRM into BROSH. Use BROSH as the destination and system of record. Source systems may include Salesforce, HubSpot, Pipedrive, Zoho, Dynamics, or another CRM only when its connected MCP exposes the required operations.

## Scope And Discovery

- Establish the source and destination workspaces, objects, selection filters, destination owner, merge policy, and whether the request is a plan, dry run, pilot, or live migration. Infer these from the user's request and existing configuration where possible; ask only for missing decisions that affect the work.
- Inspect the current BROSH and source MCP tool schemas and authentication context. Use BROSH's profile tool to verify the destination user. Verify source tenant identity through its available tools. A plugin connection does not automatically connect other CRMs.
- Read source records through the source CRM's MCP and create or update destination records through BROSH's MCP. Do not request credentials in chat or embed them in plans, mappings, or exports.
- If a required connector or operation is unavailable, prepare the mapping and report the specific blocked step. Offer a user-provided export as a fallback; do not imply an MCP can export unsupported objects or bypass permissions.
- Reuse existing authorization for the requested setup or migration. A request to plan or dry-run authorizes inspection and local artifacts only. Installing this skill does not authorize a migration, source deletion, or unrelated changes.

## Administrator Workflow

1. Inspect the existing objects, field definitions, picklists, pipelines, stages, views, owners, and settings exposed by BROSH. Read definitions rather than inferring types from sample values.
2. Match configuration to the actual sales, service, or operations process. Prefer existing fields and objects when they preserve meaning.
3. Produce a concrete change list containing object, API field name, label, type, required/default behavior, relationship target, choices, and effect on existing records. Follow the current tool schema for supported properties.
4. Execute the authorized additions or updates using BROSH's schema/admin tools, such as `modify_field` when available. Check whether a tool creates a field, changes its definition, or merely updates record values before calling it.
5. Read back each changed definition and verify a representative record. Add pipeline stages, views, ownership settings, or workflows only when both the user scope and exposed tools support them.
6. Keep unrelated configuration intact. Renaming populated fields, narrowing types, removing choices, changing permissions, and deleting fields require a specific user instruction covering the effect and a recoverable snapshot.

For field and relationship decisions, read [references/mapping-and-setup.md](references/mapping-and-setup.md).

## Migration Workflow

1. Inventory the selected source objects and accessible counts. Record pagination rules, relationships, custom fields, owners, stage values, currencies, attachments, activity history, and read-only fields. Capture a start watermark if the source supports incremental reads.
2. Build an explicit field, stage, owner, and relationship mapping. Record transformations, dedupe keys, unsupported values, and fields that will remain unmapped. Preserve source identities independently of human names.
3. Dry-run a representative sample against the destination schema without writes. Report intended creates, updates, ambiguous matches, invalid values, and missing parent relationships.
4. Create missing destination fields within the authorized scope, then perform a small pilot across related records. Inspect destination results before continuing. Stop expansion on duplicate creation, incorrect ownership, consent loss, or broken relationships.
5. Import in dependency order, using bounded pages and verified parent IDs. Maintain a checkpoint and source-to-BROSH ID ledger after every confirmed write. Read [references/migration-execution.md](references/migration-execution.md) for execution, recovery, and reconciliation.
6. Preserve opt-outs and communication restrictions. Migrate historical emails and tasks as records when supported; do not send emails, calendar invitations, marketing messages, or customer notifications as a side effect. Disable import-triggered notifications only through supported, authorized settings and restore any changed settings afterward.
7. Reconcile the selected source population against destination results. Report migrated, matched, updated, excluded, conflicted, failed, and unsupported items separately. Recheck parent links, owner/stage mappings, consent flags, and representative totals.
8. If incremental reads are supported and requested, apply changes since the start watermark, then record the final cutoff. Report the snapshot boundary if a consistent cutoff is unavailable. Do not declare a complete migration while unresolved failures or required mappings remain.

## BROSH Model Constraints

- Discover current table and field support before use. Typical destinations include `accounts`, `contacts`, `opportunities`, `activity`, `tickets`, `projects`, and `opportunity_products`.
- For activity-to-contact links, use `activity.person`; for ticket-to-contact links, use `tickets.contact` when confirmed by the schema.
- BROSH quotes and invoices may be stored as `opportunities` with type/subtype conventions. Map these by actual destination definitions; line items belong in `opportunity_products` when supported.
- Remap source record IDs to actual BROSH IDs. Source owner IDs, enum values, and relationship IDs are not portable.
- Historical creation dates, modification dates, message delivery status, document signatures, and financial states may be read-only or have side effects. Preserve source evidence in supported metadata rather than asserting native historical status.

## Completion Report

Provide the source/destination identity, schema changes and verified definitions, mapping artifact location, source selection and cutoff, per-object reconciliation, created/updated record IDs, unresolved exceptions, and checkpoint location. Explain what remains unsupported and the next action required. Claim only outcomes confirmed by tool results and read-back checks.

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: brosh-lead-prospector
description: "Research a business's ICP, find matching companies and their owners or active founders, verify business emails and phone numbers, insert deduplicated prospects into BROSH CRM, and rank them with evidence-based scores. Use for ranked owner-led lead discovery rather than fixed state-by-state executive searches or email sending."
---

# BROSH Lead Prospector

Build a ranked, source-backed list of potential customers and save qualified companies and their owners in BROSH CRM. Research, verify, score, insert, and read back each prospect before moving to the next.

## Learn The ICP

1. Inspect the connected BROSH workspace and authenticated user. Review approved product materials, existing customer accounts, won opportunities, and business notes available within the request's scope.
2. Define the product being sold, industries, B2B/B2C model, company size, region, buying roles, relevant workflows, customer-value hypothesis, exclusions, and desired lead count. Infer a useful ICP from this evidence and the user's instructions; ask only for missing decisions that materially change targeting.
3. Distinguish documented criteria from hypotheses. Avoid treating a few successful accounts as proof of an entire market. Do not contact existing customers, partners, competitors, or excluded accounts as new leads.
4. When selling BROSH itself and no override is supplied, use the established ICP: U.S. B2B small businesses and small manufacturers with up to 100 employees. This default does not apply when prospecting for another business using BROSH.
5. Use web search for current company, owner, and business-contact evidence. Verify decisive ICP constraints such as size and location; keep companies with unknown required criteria in the research backlog.

## Find And Verify Owners

- Prefer official company websites, team/about pages, public professional profiles, company announcements, industry associations, and source-backed enrichment tools.
- Identify the current owner, co-owner, proprietor, managing partner, or active founder who runs the business. A CEO title alone does not establish ownership. Confirm current company affiliation and the owner/founder role with named evidence.
- Require both a source-backed business email associated with the named person and a business phone before CRM insertion. Label phones as direct business, company main line, or extension; never represent a main line as an owner's direct number.
- Do not guess email patterns or claim deliverability from syntax, domain existence, or public listing alone. A public professional address is acceptable when its business use and association with the owner are supported. Generic mailboxes alone do not qualify as a named owner's email.
- Do not collect home addresses, private personal phone numbers, or sensitive personal details. Respect existing suppression, opt-out, bounce, and do-not-contact records.
- For each important fact, retain the source URL/provider, observed fact, verification date, confidence, and any publication date. Resolve conflicting affiliations and contact details before inserting.

## Score And Rank

Read [references/scoring-and-crm.md](references/scoring-and-crm.md) for the 100-point rubric and storage rules. Apply the same rubric to every prospect in the run. Score demonstrated fit, relevant business context, public buying signals, owner authority, and contact quality; missing evidence earns no points.

Apply hard eligibility gates before scoring: ICP fit established, active owner/founder identified, both email and business phone available, no unresolved duplicate or conflicting identity, and no applicable contact restriction. A high score does not override a failed gate.

Use tiers A (80-100), B (65-79), and C (0-64). Insert eligible A/B prospects; retain C prospects or incomplete candidates in the research backlog. Explain the score and value hypothesis without claiming buying intent, budget, or likelihood of closing.

## Save In BROSH CRM

1. Inspect the current `accounts`, `contacts`, and `activity` schemas and any existing scoring fields. Use the live tool names and supported parameters.
2. Search companies by normalized domain and name/location; search contacts by exact email and by person plus company. Resolve ambiguous matches before writes.
3. Create a lead account only if absent. Preserve existing account status and populated values when enriching a match; never convert an existing customer into a lead.
4. Create or enrich the verified owner contact linked to the real account ID. Preserve contact restrictions and existing lead source. For a new contact, use the user's lead-source choice, otherwise `AI Prospect` if that value is supported. Record provenance in the research note if no lead-source field/value supports it.
5. Save the numeric score, tier, and research details in available CRM fields or a linked activity note. Do not create scoring fields or modify CRM schema merely to run this skill; field setup is a separately scoped administration task.
6. Read back the account/contact, relationship, contact details, and scoring evidence. Count the prospect as saved only after confirming its records and linked research note. If a partial write fails, reconcile returned IDs before retrying so the next run does not duplicate records.

Finding and inserting prospects does not authorize emailing them, purchasing enrichment credits, creating opportunities, or scheduling a recurring agent. If the user also requests outreach, finish this prospect's research and use the authorized SDR workflow before moving to the next prospect.

## Results

Return leads ordered by score descending, then evidence freshness, then company name for ties. Include rank, tier, owner and role, company, business email, labeled phone, score breakdown, ICP-fit reason, relevant public signal, customer-value hypothesis, source evidence, and verified BROSH account/contact IDs.

Report researched, eligible, saved, enriched, duplicate, restricted, failed, and backlog counts separately. State when a requested count could not be reached; do not pad the list with guessed contact details or weak fits. Rank only the qualified saved/enriched set, and date the ranking so it is not mistaken for a permanent CRM priority.

Referenced files: 2 — file references are metadata, not package contents.