Nexusplus

View saved version →

---
name: capture-with-reason
description: Use when the user has just met someone and wants to save them to their Nexusplus contacts, or wants to add a new person or company to their contacts, and says why ("met at the conference", "a candidate for the sales role", "a competitor"), or asks you to add someone to their contacts and check that they are not already saved. Not for looking people up elsewhere.
---

Adds a brand-new contact together with the reason the user is adding it, so the record still explains how they know this person later.

Input to expect: a name or company, ideally an email address or phone number, and the reason in the user's own words.

Steps:

1. Collect what `create_contact` needs: at least one identifying signal. Any one of a first or last name, a company name (with `entityType: company` for a company), an email or a phone number is accepted, but a name alone cannot be checked reliably against the user's saved contacts. Ask for an email or phone when the user has one; if they have neither, say the check for an existing copy is weaker and continue only if they still want it. Never guess a missing email, phone, company or title.
2. If the user may already know this person, call `search_contacts` on the email or name first. If they are there, go to step 7 instead of creating.
3. Publishing rule (the same in every Nexusplus skill). `create_contact` publishes the new contact to the user's connected Outlook and iCloud accounts unless the contact list is set to hold changes for review or you pass `disposition: stage_for_review` (which holds it for the user's review instead). Before the call, say in one sentence what will leave Nexusplus and to which connected accounts (`list_integrations` names them). Wait for a yes only if the user has not already asked for it to go to their accounts: "add her and sync it to my phone" is such a request, a plain "add her" is not.
4. Call `create_contact` with the name or `companyName`, the `email` or `phone`, and `title` only together with `companyName`. For the why, pass `intent.kind` as the closest of lead, competitor, partner, vendor, candidate, investor, press or other (use other when none fits; never invent a kind), `intent.source` for where it happened ("conference"), and `intent.note` and `reason` as one short sentence each, at most 200 characters, never the conversation. Pass `destinations` only if the user named where it should go (see the publish-and-destinations skill).
5. A successful call returns `outcome: created` and `pending: true`. The contact appears within a few seconds and `masterId` is still empty. Read `disposition`: `accept_now` will publish to the connected accounts, `stage_for_review` waits as an unpublished change for the user's review, and `degradedFromAcceptNow` means the user's access does not allow publishing, so it was held for review. Find the contact with `search_contacts` and confirm with `get_contact_dossier`: `intents` shows the kind and note, `destinations` shows where it goes. Do not say it is done until the dossier shows it.
6. A weaker match with a saved contact is not visible in the create result: it comes back as `outcome: created` like any other. After a create, call `list_duplicate_candidates` to learn whether the new contact was filed as a possible duplicate. If it was, its publishing is held until the pair is resolved: say so and follow the duplicate-review skill.
7. If the result says `outcome: matched_existing`, no contact was created and nothing was recorded. Tell the user who already matches (`match` has the name, match type and confidence) and that you did not make a second copy. To add the new email, phone or company to that person, use the edit-contact skill (`submit_contact_revision` with the `masterId` and `addAttribute`, one attribute per call); it follows the same publishing rule. This capture's reason cannot be attached to an existing contact; tell the user, and do not put it in `fields.notes`, which replaces the existing notes.

Output: a plain confirmation naming the contact, the reason recorded, and whether it was sent to the connected accounts or is waiting for review.

Stop and ask when neither a name nor an email or phone is available, when several saved contacts could be the match, or when the user has more than one contact list and has not said which.

View saved version →

---
name: duplicate-review
description: Use when the user asks whether their Nexusplus contacts contain duplicates, whether two of their contacts are the same person, wants to clean up or merge their saved contacts, wants to dismiss a suggested duplicate, or says a merge of their contacts was wrong and wants it undone or two people separated. Not for deciding whether two public figures or companies are the same.
---

Finds contacts that may be the same person and resolves them, without ever merging on a guess.

Input to expect: "do I have duplicates", "are these two the same person", "merge them", "that merge was wrong".

Steps:

1. To review the queue, call `list_duplicate_candidates` (proposals awaiting review by default). For one named person, find them with `search_contacts`, then call `find_duplicate_candidates` with their `masterId`. Each pair has a match type (email, phone or name) and a confidence. Describe pairs in plain words ("these two share an email address") and show a few at a time.
2. Confidence is never a decision, and merging is always the user's explicit choice. A pair whose reasons include `name_disagreement` shares an identifier but the names plainly differ; treat it as probably two people.
3. If two contacts have in common only a shared address, an office or main phone line, or a surname, say they may well be different people and do not propose a merge. A father and son who share a name and an address (one with a Jr. suffix), and a married couple who share a surname and an address, are different people.
4. For a pair worth considering, call `merge_preview` with both `masterIds` and show what would be combined: the names, company, emails, phones and sources of each, which contact would be kept and which retired into it. Let the user choose which to keep. If `mergeToken` comes back empty, do not merge; relay the note.
5. Merge only after the user says yes to that preview. Call `merge_contacts` with `primaryMasterId` (kept), `secondaryMasterIds`, the preview's `mergeToken` and a one-sentence `reason`. The token lasts about ten minutes and goes stale if either contact changes; if it is refused, preview and confirm again. Merging needs admin access to the contact list; if refused for access, say so.
6. The merge is applied within a few seconds, so re-read with `get_contact_dossier` before saying it is done. A merge changes nothing in the user's connected Outlook or iCloud accounts until the merged contact is published (see the publish-and-destinations skill). Offer to publish; do not publish unasked. Before publishing a merged contact, say this plainly: if a connected account holds a card for each of the two contacts, the absorbed contact's card will be deleted from that account when the surviving contact is sent there (Nexusplus marks it as superseded first), and a later scheduled sync can do the same. The same publishing rule as everywhere applies: say what will leave Nexusplus and to which accounts, and wait for the user's yes.
7. If they are different people, call `dismiss_duplicate_candidate` with both ids and a short `reason` ("father and son, same address") so the pair does not come back. There is no call to undo a dismissal; the pair can still be merged later if the user changes their mind.
8. To undo a merge, call `unmerge_contact` with the survivor's `masterId`. It works only for a clean, recent merge of two contacts with no edits to the survivor since, and refuses anything else with the reasons. If the merge was already published and the absorbed contact's card was deleted from a connected account, say so first: the contact comes back in Nexusplus, but its old card and any edits made to that card are not restored, and it gets a new card the next time it is published (the unmerge is refused if that account does not accept new contacts of that type).
9. For a contact that holds two people's records, call `get_contact_sources`, show which records belong to whom, then call `split_contact` to move one person's records onto an existing, separate contact (every record must be assigned). A split needs that second contact to exist already as the target. If none exists, do not try to create one with `create_contact`: it may refuse because the new person's details match the conflated contact. Say so, and ask the user to create the separate contact in the Nexusplus app first, then continue. Merge, unmerge and split need admin access to the contact list.

Output: what was compared, what you did or did not change, and what the user can do next.

Stop and ask when the user has not confirmed the preview, when the preview shows conflicting identities, or when a pair has only a shared address, line or surname in common.

View saved version →

---
name: edit-contact
description: Use when the user wants to change something about a person or company already saved in their Nexusplus contacts: a new phone number or email, a new job or employer, a spelling or name correction, a birthday, notes, or tags ("Sheila's new number is...", "she moved to Acme", "fix the spelling of his name"). Not for adding a brand-new contact.
---

Changes a saved contact with `submit_contact_revision`, which either replaces a field's value or adds one new item beside the existing ones, and says plainly what stays, what changes, and what goes out to the user's accounts.

Input to expect: "Sheila's new number is...", "she moved to Acme", "fix the spelling of his name", "add a work email for him", "tag her as a client".

Steps:

1. Find the contact with `search_contacts`, then read `get_contact_dossier` for its `masterId` and current values. If several people fit, show them with something that tells them apart (company, email) and ask which; never pick one silently. If the person is not saved, use the capture-with-reason skill instead.
2. Choose the input that matches what the user said:
   - `fields` REPLACES the value of each field you pass: the name parts (`firstName`, `lastName`, `middleName`, `prefix`, `suffix`, `nickname`), `companyName`, `primaryCompany` (the employer shown on a person), `primaryTitle`, `birthday`, `anniversary` and `notes`. Use it for a spelling fix, a changed employer or title, or a birthday. Passing `null` for a field clears it. `fields.notes` replaces ALL existing notes, so read the current notes first and send the full new text, only what the user asked to record, never conversation text.
   - `addAttribute` only ever ADDS one new email, phone, address, role (`orgRole`) or web address per call; a social profile is a `url` with the matching `urlType`. It never replaces or removes anything: a new phone number or email sits beside the old one, and an item that is already there is skipped silently. If the user means "replace the old number", say that the new number will be added next to the old one and that the old one cannot be removed through the assistant; it has to be removed in the Nexusplus app.
   - `tags` adds and removes tags: `add` and `remove` are case-insensitive, adding a tag that is already there or removing one that is not changes nothing, and a tag named in both is removed.
   For "she moved to Acme", set `fields.primaryCompany` to Acme (and `primaryTitle` if the user gave a title). Tell the user exactly that: the employer shown on the contact changed; the assistant cannot end or remove other recorded roles, so if they want an old role removed or ended, that is done in the Nexusplus app.
3. Publishing rule (the same in every Nexusplus skill). By default the revision is published: it is sent to the user's connected Outlook and iCloud accounts and overwrites the matching fields of the record there, unless the contact list is set to hold changes for review or you pass `disposition: stage_for_review` (which holds the change for the user's review instead). Before the call, say in one sentence what will leave Nexusplus and to which connected accounts (`list_integrations` names them; `get_contact_dossier` shows where this contact goes). Wait for a yes only if the user has not already asked for this edit to go to their accounts: "fix his name and sync it to my phone" is such a request, a plain "fix his name" is not. A send can also delete extra cards for the same contact in an account (see the publish-and-destinations skill).
4. Call `submit_contact_revision` with the `masterId`, the change (`fields`, `addAttribute` and/or `tags`) and a one-sentence `reason` in the user's own words ("new job at Acme"). One call carries at most one `addAttribute`; make a separate call for each further email or phone.
5. A successful call returns `accepted: true`. The change is applied within a few seconds, so re-read `get_contact_dossier` and report what it shows; do not say it is done until the dossier shows it. Read `disposition`: `accept_now` is published to the connected accounts, `stage_for_review` waits as an unpublished change for the user's review, and `degradedFromAcceptNow` means the user's access does not allow publishing, so it was held for review.
6. Undo: earlier values stay in version history (`get_contact_versions`), so a wrong replaced field or tag change is corrected by revising again. An item added by mistake with `addAttribute` cannot yet be removed through the assistant; say so and send the user to the Nexusplus app.

Output: a plain confirmation naming the contact, what was changed or added, what stayed as it was, and whether it was sent to the connected accounts or is waiting for review.

Stop and ask when the contact is not clearly one person, when the user has more than one contact list and has not said which, when the new value would replace several existing values, or before replacing notes the user did not ask to overwrite.

View saved version →

---
name: get-started
description: Use when the user has just connected Nexusplus, asks what Nexusplus can do with their contacts, or asks about a person or company in their own Nexusplus contacts, a possible duplicate among those contacts, or a change to one of those contacts, for the first time in a conversation. Do not use for general questions about people or companies that are not about the user's own contacts.
---

Nexusplus holds the user's own contact lists, built from their connected Outlook, iCloud and CSV sources, with one record per person and a full history of every change.

Input to expect: a question about a person or company in the user's own contacts ("who do I know at Acme", "what is Sheila's current number"), a request to add a new contact with a reason, to fix a duplicate, to change a saved contact, or to add an email or phone to someone already saved.

Steps:

1. Call `list_my_lists` once to learn the user's contact lists. If there is exactly one, every other tool may omit `listId`.
2. To answer a question, use `search_contacts` or `list_contacts`, then `get_contact_dossier` for the full record. Report only what the tools return; never infer a phone number, email or employer that is not in the record.
3. Before any change, find the contact and read its dossier. A write records the change and Nexusplus applies it within a few seconds; re-read the dossier to confirm the result instead of assuming it. Only `set_contact_destinations` takes effect immediately.
4. Pick the skill for the job: `capture-with-reason` to add a new contact, `edit-contact` to change a saved one, `duplicate-review` for duplicates, merges and splits, `publish-and-destinations` for what goes to the user's Outlook and iCloud accounts, and `lookup` for questions.
5. Publishing rule (the same in every Nexusplus skill). `publish_contact` sends changes to the user's connected Outlook and iCloud accounts, and so do `create_contact` and `submit_contact_revision` unless the contact list is set to hold changes for review or you pass `disposition: stage_for_review` (which holds the change for the user's review instead). Before any call that will publish, say in one sentence what will leave Nexusplus and to which connected accounts (`list_integrations` names them). Wait for a yes only if the user has not already asked for this add or edit to go to their accounts: "add her and sync it to my phone" is such a request, a plain "add her" is not. Ask before publishing more than a few contacts at once.
6. When a tool accepts `reason`, pass one short sentence in the user's own words about this action ("met at the conference"), never the conversation.

Output: a plain answer grounded in the tool results, naming the contact list and the contact, and for a change, what was recorded and whether it will be sent to the user's accounts.

Stop and ask when a search returns several plausible people, when a merge preview shows conflicting identities, or when the user's request would publish to accounts they have not named.

View saved version →

---
name: lookup
description: Use when the user asks, about their own Nexusplus contacts, who they know at a company, what a saved contact's phone number, email, address or employer is, how two of their contacts are connected, when one of their contacts last changed or where its details came from, or which accounts are connected to Nexusplus. Do not use for general questions about public figures or companies (for example who someone works for) that are not about the user's own contacts.
---

Answers questions about the user's own saved contacts from tool results only.

Input to expect: "who do I know at Acme", "what's Sheila's number", "when did we last change this contact", "where did this email come from", "what accounts are connected".

Steps:

1. Call `list_my_lists` once. If there is more than one contact list, ask which one, or search each, and pass `listId`.
2. To find a person or company, call `search_contacts` with a name or email fragment; `entityType` (person or company) narrows it. To browse or filter, call `list_contacts` with `search`, `entityType`, or `needsReview` for contacts the system flagged for review. Only active contacts are listed unless `statuses` says otherwise. When `hasMore` is true, say there are more than you showed.
3. If more than one person fits, show them with something that tells them apart (company, email) and ask which. Never pick one silently.
4. For details, call `get_contact_dossier` and answer only from it: emails, phones, addresses, roles and links as labeled, and `intents` for why the user added the person. If a field is not there, say it is not recorded. Never infer or fill in a number, email or employer from memory or from a similar contact.
5. "Who do I know at a company": find the company with `search_contacts` (`entityType: company`), then call `get_relationship_network` with its `masterId` as `entityId`. The people connected to it by an employment relationship are the answer. For how two people are connected, run it on one of them and look for the other. Former links are left out unless `includeRetired` is true; say which you used. Say the answer reflects the relationships recorded in Nexusplus, not everyone who may work there.
6. "When did this change": call `get_contact_versions`, which gives published and earlier versions with a state, `publishedAt` and `createdAt`; add `includeAllRevisions` to include unpublished changes. "Where did this come from": call `get_contact_sources`, which shows the Outlook, iCloud or CSV records behind the contact and their sync status.
7. "What is connected": call `list_integrations` for each connected account's name, type, status and last sync. Credentials are never shown.
8. If the dossier reports a mixed-identity diagnostic, tell the user the record may combine two people and offer the duplicate-review skill.

Output: a short plain answer naming the contact list and the contact, quoting values exactly as recorded, and saying when something is not recorded.

Stop and ask when a search returns several plausible people, when the user has several contact lists, or when the question needs data the tools do not return.

View saved version →

---
name: publish-and-destinations
description: Use when the user asks to sync, send or push their Nexusplus contacts to their phone, Outlook or iCloud, wants one of their contacts to go only to certain accounts ("only to work", "just iCloud"), asks where one of their contacts will go or why it is not showing up in a connected account, wants to publish several contacts at once, or asks whether a publish can be undone.
---

Controls what leaves Nexusplus for the user's connected accounts, and which accounts it reaches.

Input to expect: "sync this to my phone", "only send her to my work account", "publish all of these", "why isn't he in Outlook".

Steps:

1. `publish_contact` takes a contact's unpublished change live and sends it to the user's connected Outlook and iCloud accounts, overwriting the matching fields of the record already there. Edits and merges that are still unpublished stay inside Nexusplus until published. A contact with nothing pending is skipped (`nothing_to_publish`), which is not an error. Publishing needs admin access to the contact list.
2. A send can also delete cards, and the user must hear that before it happens. When Nexusplus successfully sends a contact to a connected Outlook or iCloud account that holds more than one card linked to that contact (typically the absorbed contact's card after a merge), it then deletes the extra cards from that account after marking each as superseded, keeping any extra card it cannot read or that changed after it read it. This happens on any successful send, so a later scheduled sync can do it too, not only a publish. It never touches accounts the contact is not sent to, and excluding an account (step 6) does not delete anything there.
3. By default a contact goes to every connected account that accepts new contacts, plus any account that already holds a record of it; with a destination setting, only to the accounts it allows. To answer "where will it go", read `destinations` (`designated`, `allowed`, `denied`) in `get_contact_dossier`. Call `list_integrations` for the connected accounts and their status.
4. To route a contact, call `set_contact_destinations` with its `masterId` and the complete set. Each entry is a connected account's name as `list_integrations` shows it (not case-sensitive) or an alias: `work` (every Outlook work account), `personal` (Outlook Personal and iCloud), `all`, or `default` on its own to clear the destination setting. Every connected account you do not name is excluded. `create_contact` takes the same set of names as `destinations`.
5. Never guess a name. An unknown name, a name that matches more than one account, or an alias that matches no connected account is refused, even when other names in the same call do match, and the refusal names the valid choices. Show them and ask. If no accounts are connected, say that.
6. Setting destinations sends nothing; it takes effect at the next publish or scheduled sync. Read the allowed and excluded accounts back to the user. Excluding an account stops future updates to it and does not delete a record already sent there. Say so.
7. Publishing rule (the same in every Nexusplus skill). Before any call that will publish, say what will be sent and to which accounts (`list_integrations` names them), and wait for a yes unless the user has already asked for this exact send ("sync it to my phone" is such a request). For more than a few contacts, say how many first. Above 25 in one call the tool requires `confirmCount` equal to the number of contacts; set it only to the number the user just approved, never to get past an error. `create_contact` and `submit_contact_revision` also publish by default unless the contact list is set to hold changes for review or you pass `disposition: stage_for_review`, so the same rule applies to them.
8. Pass `reason` as one short sentence in the user's own words to either write tool. The publish is applied within a few seconds, so re-read `get_contact_dossier` and report what it shows.
9. If a contact did not publish on its own, the usual reasons are that the contact list is set to hold changes for review, that the user's access does not allow publishing, or that an unresolved possible duplicate holds automatic publishing (`list_duplicate_candidates`). Say which apply, and suggest resolving a duplicate first with the duplicate-review skill.
10. Undo: every earlier version stays in version history (`get_contact_versions`), so a wrong field or tag change is corrected by revising the contact again with `submit_contact_revision` and publishing again. An email, phone, address, role or web address that was added by mistake cannot be removed this way, because adding only ever appends: say that it cannot yet be removed through the assistant and has to be fixed in the Nexusplus app. There is no unpublish: a record already sent to an account stays there until it is changed, and a card Nexusplus deleted from an account (step 2) is not restored by version history.

Output: what was published or routed, to which accounts, and what has not yet left Nexusplus.

Stop and ask when the user has not said which accounts, when a destination name is refused, or before publishing more than a few contacts.