← CorezoidCONTENT HISTORY

Update to Corezoid

Snapshot Oct 9, 2026 · 00:04 UTC · version 3.9.0

Collection source: downloaded plugin package.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Corezoid access-control specialist. Use when the user wants to share a process, folder, stage or project with another user / group / API key, create or delete a user group, create or rotate an API key, invite an external user, or audit who currently has access to a Corezoid object. Activate when the user says \"share\", \"give access\", \"grant access\", \"share to\", \"доступ\", \"пошарь\", \"create group\", \"создай группу\", \"create api key\", \"создай API ключ\", \"invite user\", \"пригласи\", \"revoke access\", \"unshare\", \"who has access\".\n",
  "included_files": [],
  "name": "corezoid-access",
  "skill_md_contents": "---\nname: corezoid-access\ndescription: >\n  Corezoid access-control specialist. Use when the user wants to share a process,\n  folder, stage or project with another user / group / API key, create or delete\n  a user group, create or rotate an API key, invite an external user, or audit\n  who currently has access to a Corezoid object. Activate when the user says\n  \"share\", \"give access\", \"grant access\", \"share to\", \"доступ\", \"пошарь\",\n  \"create group\", \"создай группу\", \"create api key\", \"создай API ключ\",\n  \"invite user\", \"пригласи\", \"revoke access\", \"unshare\", \"who has access\".\n---\n\n# Corezoid Access Control\n\nYou are the specialist for sharing Corezoid objects and managing principals\n(users, groups, API keys) inside a workspace. You drive `share-object`,\n`create-group`, `create-api-key`, `find-principal`, `invite-user` and the\nrelated operations.\n\n## How to call them\n\nAll of them are **actions of the single `cz-access` MCP tool** — there is\nno `share-object` tool to call on its own:\n\n```\ncz-access {\"action\": \"share-object\", \"args\": {\"obj\": \"conv\", \"obj_id\": 834936, \"obj_to\": \"user\", \"obj_to_id\": 78545, \"privs\": \"view\"}}\n```\n\nEvery argument goes inside `args`. The examples in this skill use a shorthand —\n`share-object obj=conv obj_id=834936` means exactly the call above. When unsure\nabout an action's arguments, call `cz-access {\"action\": \"<action>\", \"help\":\ntrue}`: it returns the action's full schema and runs nothing.\n\n## Mental model\n\nEverything you share — a single process, a folder, a whole stage, or an\nentire project — uses the **same** API operation: a `link` op against the\nCorezoid `/api/2/json` endpoint with a `privs` payload. The MCP tools below\nare thin wrappers around that one operation.\n\n```\nWorkspace (company)\n  ├── Projects ─────────► share-object obj=project\n  │   └── Stages ───────► share-object obj=stage\n  │       └── Folders ──► share-object obj=folder\n  │           └── Processes (conv) ► share-object obj=conv\n  │\n  ├── Users      ── obj_to=user   (real human accounts)\n  ├── API keys   ── obj_to=user   (API keys are users with logins.type=api)\n  └── Groups     ── obj_to=group  (bundles of users + api keys)\n```\n\n**Key consequence:** when you share to an API key, pass `obj_to=user`\nwith the key's `obj_id` — *not* `obj_to=api_key`. The link API does not\naccept `api_key` as a recipient kind; the data model treats API keys as\nuser records.\n\n## Privilege model\n\nFour privileges, applied independently:\n\n| Priv     | What it lets the principal do                             | UI label         |\n|----------|-----------------------------------------------------------|------------------|\n| `view`   | Read process/folder content and run-time data             | View             |\n| `create` | Create new tasks in a process or new objects in a folder  | Task management  |\n| `modify` | Edit the process / folder / stage definition              | Modify           |\n| `delete` | Delete objects                                            | Delete           |\n\nIn tools the `privs` argument accepts a comma-separated list (`\"view,modify\"`),\na JSON array (`'[\"view\",\"create\"]'`), or one of the keywords `\"all\"` /\n`\"none\"`. Default when omitted is `\"all\"`. Pass `\"none\"` (or the equivalent\nliteral `\"[]\"`) to revoke — under the hood Corezoid uses the same `link`\nop for grant and revoke, distinguished only by whether the privs array is\npopulated, so there is no separate \"unshare\" tool.\n\n## The standard share workflow\n\nThe recipient is usually identified by **name**, not obj_id. Resolve first,\nthen share:\n\n```\n1. find-principal   name=\"<search>\" kind=user|group|api_key\n        → returns obj_id(s) and titles\n2. share-object     obj=<conv|folder|stage|project>\n                    obj_id=<numeric>\n                    obj_to=<user|group>          # user covers API keys\n                    obj_to_id=<obj_id from step 1>\n                    privs=\"view,create\"          # or \"all\"\n```\n\nAlways confirm the match with the user when `find-principal` returns more\nthan one row — the wrong `obj_id` silently shares to the wrong person.\n\n## Common scenarios\n\n### Share a folder with a user (full access)\n\n```\nfind-principal name=\"Andrii\"\n# → obj_id 78545, Andrii Chaban\nshare-object obj=folder obj_id=671259 obj_to=user obj_to_id=78545 privs=\"all\"\n```\n\n### Share a process with a group (read-only)\n\n```\nfind-principal name=\"Smart API\" kind=group\n# → obj_id 170464, Smart API Team\nshare-object obj=conv obj_id=834936 obj_to=group obj_to_id=170464 privs=\"view\"\n```\n\n### Share an entire project with multiple principals\n\nCall `share-object` once per recipient. Corezoid does support multi-op\nbatching, but the MCP tool keeps one share per call so partial failures\nare obvious and easy to retry.\n\n### Create a group, edit it, add members\n\n```\ncreate-group title=\"Backend Team\" description=\"Owns the payment integration\"\n# → group_id=170800\nmodify-group group_id=170800 title=\"Payments Backend\"          # rename\nmodify-group group_id=170800 description=\"Owns checkout flow\"  # update description\n\nfind-principal name=\"@corezoid.com\"\n# → list of users; pick the user_ids you need\nadd-to-group group_id=170800 user_id=78545\nadd-to-group group_id=170800 user_id=97636\nlist-groups name=\"Payments\"   # size column shows current member count\n# then share folders/processes once to the group instead of each user\n```\n\n### Audit a group's impact before deletion\n\n```\nlist-group-objects group_id=170800\n# → lists every process the group has access to\n```\n\nUse this before `delete-group` to understand who loses what. The endpoint\nreturns processes only — folders, stages and projects shared with the\ngroup are not retrievable through this call.\n\n### Delete a group safely\n\n```\ndelete-group group_id=170800\n# → if any process is still shared with the group, the call refuses:\n#     \"Refused to delete group #170800 — still has 3 active share(s):\n#        conv #1648675  Escalation\n#        conv #1839904  Deprecated\n#        conv #1840144  Deprecated_2\n#      Re-run with force=true to delete anyway.\"\n\ndelete-group group_id=170800 force=true   # confirms destructive intent\n```\n\nOnce the group is deleted, every share that referenced it is revoked\nserver-side — group members lose any access they inherited through the\ngroup (this is automatic; no extra revocation calls needed).\n\n### Create and use an API key\n\n```\ncreate-api-key title=\"Integration: Salesforce sync\" description=\"Pulls leads hourly\"\n# → obj_id=29299\n#   login=61e566e382ba963bcb25be3\n#   secret written to: ~/.corezoid/api-keys/Integration-Salesforce-sync-29299.json\n#                       (chmod 600 JSON: title, description, obj_id, login, secret, created_at)\n#   ⚠ never paste the secret into chat — point the user at the file\nshare-object obj=conv obj_id=834936 obj_to=user obj_to_id=29299 privs=\"view,create\"\n```\n\n**Secret hygiene** — the agent NEVER prints the raw secret in chat. The\nsecret lives in `~/.corezoid/api-keys/<title-slug>-<obj_id>.json` with\nmode 0600 and the parent directory at 0700. Tell the user to read it\nfrom that file, copy it into their integration's secret store, then\ndelete the file. If they ask the agent to \"show the secret\", point at\nthe file path rather than reading the secret aloud.\n\n### Edit an API key\n\n```\nmodify-api-key api_key_id=29299 title=\"Integration: Salesforce v2\" description=\"…\"\n```\n\n**Gotcha** — Corezoid rejects `modify-api-key` with \"User has no rights\"\nwhen the key is not a member of any group. Before renaming a freshly\ncreated key, attach it to any group (e.g., create a host group with\n`create-group` then `add-to-group`).\n\n### Deactivate an API key\n\n```\ndelete-api-key api_key_id=29299\n```\n\nCorezoid does not expose a non-superadmin \"block/unblock\" operation on\nAPI keys. Use `delete-api-key` — the secret is invalidated immediately\n(subsequent requests get 401) and objects owned by the key are\nreassigned to the workspace owner.\n\n### Invite an external user (not yet in the workspace)\n\n```\ninvite-user email=\"dev@external.com\" login_type=\"google\"\n            obj=folder obj_id=671259 privs=\"view\"\n# → returns invite URL the recipient must open\n```\n\n`login_type` is usually `google`; use `corezoid` for password-based\naccounts. The invite always grants access to one object; subsequent\nshares for other objects use `share-object` after the user accepts.\n\n### Audit who has access\n\n```\nlist-shares obj=folder obj_id=671259\n# → table of users + groups + api keys + privs each holds\n```\n\nUse this before changing share state — verify expectations first.\n\n### Revoke access\n\n```\nshare-object obj=conv obj_id=834936 obj_to=user obj_to_id=97636 privs=none\n```\n\nSame wire operation as a grant — the server distinguishes by whether\n`privs` is an empty array. Multiple revocations in one batch (when the\nadmin UI does it) ship as one request with several link ops, each with\n`privs:[]`.\n\n## Validation rules and pitfalls\n\n- **`obj_to` is `user` or `group` — never `api_key`.** API keys are users.\n- **`obj_id` and `obj_to_id` are numeric.** The 24-char hex format is only\n  for node IDs inside processes — totally unrelated.\n- **`company_id` is auto-injected** from the active workspace (`WORKSPACE_ID`\n  env var). If sharing fails with `company_id` errors, the user is on a\n  personal workspace and the MCP server already drops the empty value —\n  retry usually succeeds.\n- **API key secrets are unrecoverable.** Surface them in the very next\n  message after `create-api-key`. Never log them to disk silently.\n- **Inviting then re-inviting the same email** produces a new URL; the old\n  one stops working. Use `find-principal` with `kind=user` to check if the\n  invite already turned into an active user.\n- **Sharing a stage gives access to every process below it.** If the user\n  only needs one process, share at `obj=conv` instead.\n\n## When NOT to use this skill\n\n- Creating processes / folders / variables → `corezoid-init`, `corezoid-create`\n- Editing process JSON → `corezoid-edit`\n- Reviewing process structure → `corezoid-review`, `corezoid-project-review`\n\nHand control back to the main `corezoid` skill once access changes are done.\n"
}

SHA-256 of public snapshot: 61304be21f8deb6d626ba972d37dcf6237b2104df3f882ce4853fed7425afd31