Update to BROSH CRM

{
  "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.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 266
    },
    {
      "relative_path": "references/mapping-and-setup.md",
      "size_in_bytes": 3334
    },
    {
      "relative_path": "references/migration-execution.md",
      "size_in_bytes": 5092
    }
  ],
  "name": "brosh-crm-admin-migrator",
  "skill_md_contents": "---\nname: brosh-crm-admin-migrator\ndescription: \"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.\"\n---\n\n# BROSH CRM Admin And Migrator\n\nConfigure 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.\n\n## Scope And Discovery\n\n- 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.\n- 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.\n- 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.\n- 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.\n- 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.\n\n## Administrator Workflow\n\n1. 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.\n2. Match configuration to the actual sales, service, or operations process. Prefer existing fields and objects when they preserve meaning.\n3. 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.\n4. 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.\n5. 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.\n6. 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.\n\nFor field and relationship decisions, read [references/mapping-and-setup.md](references/mapping-and-setup.md).\n\n## Migration Workflow\n\n1. 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.\n2. 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.\n3. Dry-run a representative sample against the destination schema without writes. Report intended creates, updates, ambiguous matches, invalid values, and missing parent relationships.\n4. 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.\n5. 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.\n6. 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.\n7. 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.\n8. 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.\n\n## BROSH Model Constraints\n\n- Discover current table and field support before use. Typical destinations include `accounts`, `contacts`, `opportunities`, `activity`, `tickets`, `projects`, and `opportunity_products`.\n- For activity-to-contact links, use `activity.person`; for ticket-to-contact links, use `tickets.contact` when confirmed by the schema.\n- 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.\n- Remap source record IDs to actual BROSH IDs. Source owner IDs, enum values, and relationship IDs are not portable.\n- 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.\n\n## Completion Report\n\nProvide 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.\n"
}