Update to Centralize

{
  "description": "Define buyer functions and personas for a named account in the connected Centralize workspace. Use when the user asks to configure who that account's sales team sells to.",
  "included_files": [],
  "name": "centralize-persona-functions-creation",
  "skill_md_contents": "---\nname: centralize-persona-functions-creation\ndescription: \"Define buyer functions and personas for a named account in the connected Centralize workspace. Use when the user asks to configure who that account's sales team sells to.\"\n---\n\n# Configure buyer functions and personas\n\nRead [workspace and write boundaries](../../references/workspace-safety.md) first.\nModel the external buyers that the named company's sales team serves, not the plugin developer's own buyers.\n\n## Establish scope and existing definitions\n\nResolve the company with `searchCustomers`. Read `getAccountContext`, `listFunctions`, `listPersonas`, and `listSeniorities`.\nIf the account does not exist, stop and ask whether the user wants to add it. Do not create an unrelated default function.\nIf account context does not establish the company's buyers, ask for its target roles and sales motion.\nDo not require external enrichment, private call notes, or another plugin to complete this workflow.\n\nReuse matching functions and persona concepts. Flag duplicates and prospect-specific text on workspace defaults without editing them.\nDo not assume that the connected workspace contains a fixed set of functions or seniority names.\n\n## Present the plan\n\nFor each new function, give its name, responsibilities, four to eight example job titles, and five to eight related keywords.\nUse generic responsibilities so the function does not contain another prospect's sales pitch.\nMark each definition as reuse or create. New account-specific functions require `isDefault: false` and `accountIds` for the selected account.\n\nFor each persona, give its name, function, discovered seniorities, and business context of no more than 1,000 characters.\nExplain the buyer's responsibilities, relevant problem, buying triggers, role in the decision, and common objections.\nState which claims come from account context and which require user confirmation.\n\nPersonas are workspace-wide definitions even when they include `customerOverrides`. Explain this scope before approval.\nReuse an existing persona when it fits. The plugin has no persona-update operation, so do not create duplicates to emulate an update.\nWhen an existing persona needs a new override, report the required edit for the user to make in Centralize.\nObtain confirmation of the exact definitions, account bindings, and workspace-wide effects before creation.\n\n## Create and verify\n\nCreate approved functions with `createFunction` before the personas that depend on them.\nTrim names, keep them within 200 characters, and exclude colons from function names.\nKeep function descriptions within 1,000 characters.\n\nUse `createPersona` with either `customFunctionName` or `function`, following the current schema.\nUse discovered `customSeniorityNames` or supported base `seniorities` without inventing names.\nUse `customerOverrides` only when creating an approved new persona that requires account-specific mappings.\nNever imply that `createPersona` edits an existing persona.\n\nRead `listFunctions` and `listPersonas` again. Report stored names, account bindings, created definitions, and unsupported edits.\nAfter a partial failure, re-read existing definitions before retrying to prevent duplicate creation.\n"
}