Date: <start> to <end> Attendees: <First Last> (<email>), … Calendar event: <calendar event ID> <CRM> meeting <id>, on <record name> ``` `entities`: every attendee with `attendee: true`, an email ref and, for external people, the CRM ref; and the record by its `id`. 4. **Its people**: each distinct external person met in those meetings, once per run. One `capture` with `kind: "external_record"`, `title`: their full name, `external_id: "person:<id>"`, `url`: their page, `scope: "firm"`, and `text`: ```text <CRM> person: <First Last> Emails: <primary email>[, other emails on the record's domains] Met in <CRM> meetings on: <record name> ``` `entities`: the person with the CRM ref and an email ref for each email listed, and the record by its `id`. Leave out emails on other domains: CRMs' merged email lists can hold old employers and personal addresses. 5. **Progress.** After each record, one line: `3/10 <name>: record, 4 notes, 6 meetings, 3 people (2 already there, 1 updated, 1 duplicate)`. After every 5 records, add the captures used so far against the limit. Stop when the limit is reached. 6. **Finish** with one short table: records, people, notes, meetings; each with captured, updated (a new version of a changed record), already there, skipped (too long, duplicate, no ID, private to someone else) and failed (with any ID collisions named). Then the captures used against the limit, where it stopped, and that running it again picks up from there: unchanged records come back as "Already captured", and records changed in the CRM since are updated. ## One company (a backfill) When `brief`, `prepare-meeting` or `seen-before` found a company with `coverage` "crm_only" (CRM record only) and the user said yes to filling it in, import that one company. Never do this for a list, and never unless the user said yes. - **The record is already chosen**: the entity's `crm_record` gives the CRM `system`, the record's ID (`company:<id>`: the CRM ID is the part after the colon) and its page. - **Firm scope**, as for any import: these are the firm's CRM notes and meetings (a note the CRM marks private stays private, as above). - **Dry run, in one line.** Count its notes, its meetings and their external people, as in step 4, over its whole history. Say "<name>: N notes, N meetings, N people: import them?" and wait for a yes. If that is more than 60 captures, offer the newest 60 (notes and meetings in the last 12 months first) and say what would be left. - **Import** as in step 5: the record again (unchanged comes back "Already captured") with `crm_backfill` when the server can fetch the rest, else its notes, meetings and people here. Finish with one progress line, not the table. - Then hand back to the skill that asked, which answers from the brain. If a `capture` fails, count it, carry on with the next item and name the failures at the end. If the CRM connector says the user's seat lacks a permission or a scope, say which and stop.

--- name: import-from-crm description: Fill the firm's Alludium Brain from its CRM (Affinity, Attio or HubSpot) - the companies, people and deals on a chosen list, saved view, pipeline or set of named companies, with their notes and recent meetings - through the CRM's hosted connector. Always dry-runs first, works in batches with progress, is safe to re-run (changed records are updated) and stops at a size limit. Also backfills one company the brain knows only from its CRM record, when brief, prepare-meeting or seen-before offer it. Use when the user says "import our Affinity pipeline", "import from Affinity", "load our deal list from the CRM into the brain", "backfill the brain from HubSpot", "import our Attio deals" or "dry-run a CRM import". Not for checking a sourcing list against the brain (use seen-before) or filing one meeting (use capture-meeting). --- # Import from a CRM You copy CRM records from the user's CRM connector into Alludium Brain with the connector's `capture` tool. Each CRM record becomes one source with its CRM ID, so a re-run finds it already stored: an unchanged record comes back "Already captured", and a record or note whose text changed in the CRM comes back "Updated" and is stored as a new version, whose stage, status, fields and facts replace the old ones. Alludium Brain links and resolves entities; your job is a faithful, bounded copy. This file is the workflow. How to call a particular CRM's connector (tool names, IDs, links, fields, known traps) is in a reference file you read once you know which CRM it is. ## Which CRM Look at the tools you have and match them to a reference: | CRM | Its connector's tools include | Read | `system` | |---|---|---|---| | Affinity | `get_current_user`, `get_lists`, `get_saved_views`, `get_notes_for_entity`, `get_meetings_for_entity` | `references/affinity.md` | `affinity` | | Attio (untested) | `whoami`, `list-lists`, `list-records-in-list`, `search-notes-by-metadata`, `search-meetings` | `references/attio.md` | `attio` | | HubSpot (untested) | `get_user_details`, `search_crm_objects`, `get_crm_objects`, `search_owners` | `references/hubspot.md` | `hubspot` | Tool names carry a connector prefix that varies by host (`mcp____get_lists`); match on the name after it. Read only the reference for the CRM in use, before any CRM call. If the user named a CRM, use that one. If more than one CRM is connected and the user named none, ask which. If none is connected, say which connectors this skill supports and stop. For any other CRM, say it is not supported yet and stop; do not improvise an import. For Attio and HubSpot, say once at the start that this skill has not been tested against that CRM yet, and treat any tool name or field that does not match the reference as a reason to stop and report it rather than guess. ## Server backfill or this conversation Alludium Brain can fetch a record's notes, meetings and people itself, on the server, when the user has connected the CRM to the brain (the viewer's Settings, Connections). That keeps the notes out of this conversation, keeps each note's real author and date, and has no size limit here. Affinity only for now. - Capture each chosen record as in step 5.1 and add `crm_backfill: {}` (or `{"meeting_days": N}` for a meeting window other than the last 365 days). The reply names a job; do not fetch that record's notes, meetings or people yourself. - If the reply says the user has not connected the CRM, ask once whether they want to connect it in the viewer (Settings, Connections) and ask again afterwards, or carry on here with steps 5.2 to 5.4 under the size limit. - Follow the jobs with `job_status` (up to 50 at a time). Each job reports notes, meetings and people fetched, and says when it has paused for the firm's daily model limit; it carries on by itself. - The dry run, the stage mapping and the "check" answers stay here, as below. A server backfill never sets a stage. ## Rules - **Dry run first.** Unless the user has just approved a dry run's plan in this conversation, run the dry run (below) and stop. A dry run reads the CRM only and never calls `capture`. Never call a CRM tool that writes (create, update, delete, merge, add note). - **A size limit.** Ask for the most captures this run may make if the user gave none, and stop before starting the next record once it is reached. Count every `capture` call, including ones that return "Already captured". - **Word for word.** Pass the CRM's text exactly as the connector returned it, HTML or markdown included. No summarising, shortening, reformatting or fixing. Never compute or round a figure. - **Nothing in bulk through the conversation.** Fetch small pages (notes 5 at a time, meetings 10 at a time), capture each item as soon as you have it, and keep only IDs and counts. Never repeat, quote or describe note or record text in your messages, including a note a counting call returned in full; progress lines carry counts only. Skip a note longer than 20,000 characters and list it as too long, rather than risk a truncated copy. Ask the connector only for the fields you need. - **The same text for the same record.** Write a record's text from the template below with the same fields, in the same order, on every run, so a record that did not change in the CRM is recognised as unchanged. A changed value is what makes a new version. - **An ID collision is an error, not a skip.** If `capture` refuses a record because its ID is already stored under another company's title, do not change the ID or retry. Count it as failed, carry on, and list it at the end with both names so the user can check the CRM. If the company was renamed in the CRM, capture it again with the old name in the entity's `aliases`. - **Source IDs on every capture.** `system`: the CRM's value from the table above. `external_id` as `