Update to Corezoid

{
  "description": "Universal Corezoid assistant. Use when the user asks anything about Corezoid processes, wants to work with process JSON files, mentions process nodes, MCP tools, process validation, or any Corezoid-specific task. Also use when the user mentions \"Corezoid\", \"BPM process\", \"conv.json\", \"push process\", \"run task\", or asks for general platform knowledge. This skill provides deep knowledge of the platform model and guides you to use the Corezoid MCP tools correctly.\n",
  "included_files": [],
  "name": "corezoid",
  "skill_md_contents": "---\nname: corezoid\ndescription: >\n  Universal Corezoid assistant. Use when the user asks anything about\n  Corezoid processes, wants to work with process JSON files, mentions process\n  nodes, MCP tools, process validation, or any Corezoid-specific task. Also\n  use when the user mentions \"Corezoid\", \"BPM process\", \"conv.json\",\n  \"push process\", \"run task\", or asks for general platform knowledge.\n  This skill provides deep knowledge of the platform model and guides you to\n  use the Corezoid MCP tools correctly.\n---\n\n## Hosted connector (read this first)\n\nThis plugin talks to the hosted Corezoid MCP server. Differences from the local plugin:\n\n- **No login tool.** The connection itself is authenticated (OAuth, account.corezoid.com).\n- **Scope per call.** Tools that act inside a workspace take `scope: {company_id, stage_id}`. Find the values with `list-workspaces`, `list-projects`, `list-stages`.\n- **One tool per action.** The `cz-*` router tools are not listed here: their actions (`list-stages`, `share-object`, `modify-task`, …) are separate tools, called directly with their own arguments. Where a skill below says \"`cz-structure` → `list-stages`\", call `list-stages`.\n- **No local files.** `pull-process` returns the process JSON and a `base` token in the tool result. Edit that JSON and deploy it with `push-process` (`content` + `base`). The result contains the deployed scheme and a new `base` for the next edit. `lint-process` takes `content`. `create-process` takes `folder_id` and returns the new process JSON.\n- **Concurrent changes.** If the process changed on the server since your `base`, the push is blocked with a report. Pull again and re-apply your edits; merging is not available here.\n- **Not available:** the Communications Orchestrator builder (`create-communications-orchestrator`: it needs messenger bot tokens), git mirror, local layout, snapshot management, and anything below that mentions files, `.conv.json` paths, `login`, `pull-folder` or `run.sh`. Use the hosted equivalents above.\n\n\n# Corezoid Platform Assistant\n\nYou are an expert on the Corezoid platform.\nYou have access to the Corezoid API via the `corezoid` MCP server.\n\n## MCP Tools Reference\n\nTools come in two shapes. These are called directly, one tool per operation:\n\n| Tool | Purpose |\n|------|---------|\n| `login` | Authenticate via OAuth2 (opens browser) |\n| `logout` | Remove saved credentials |\n| `pull-folder` | Export entire stage/folder to local directory |\n| `pull-process` | Export a single process to a file |\n| `push-process` | Validate and deploy a `.conv.json` file |\n| `lint-process` | Validate process structure locally (no API needed) |\n| `layout-process` | Auto-arrange node coordinates into a clean layout (local; only x/y and collapse flags change) |\n| `clean-process` | Remove nodes with no traffic in the last N days (default 90) and save the result as a reviewable `<ID>_<title>.cleaned.json` proposal — never deploys. Review the diff, then pass that path explicitly to `lint-process`/`push-process` |\n| `run-task` | Run a task on an already-deployed process, by `process_path` or `process_id` — `process_id` needs no local file, so it also works in hosts with no local process repository (no `pull-process` required) |\n| `create-process` | Create a new empty process (`conv_type: \"process\"`) in a folder |\n| `create-state-diagram` | Create a new empty state diagram (`conv_type: \"state\"`) in a folder |\n| `pause-process` / `resume-process` | Explicitly pause or reactivate one process; dry-run + exact confirmation required |\n| `create-alias` | Create a short alias for a process |\n| `create-communications-orchestrator` | Build a multi-platform messenger robot (Telegram / Facebook Messenger / Viber / Apple Messages for Business). Needs one channel token per messenger; returns the `folder_url` of the generated folder once the async build finishes. Two calls: `apply=false` previews and prints a confirm token, `apply=true` + that token builds |\n\n### Router tools\n\nThe CRUD-shaped domains are grouped behind one tool each, so `tools/list` costs 35 KB instead of 65 KB of every session. Call a router with the action name and the action's own arguments:\n\n```\ncz-access {\"action\": \"share-object\", \"args\": {\"obj\": \"conv\", \"obj_id\": 1234567, \"obj_to\": \"user\", \"obj_to_id\": 890, \"privs\": \"view,modify\"}}\n```\n\nArguments go **inside `args`**, never at the top level. Add `\"help\": true` to get an action's full argument schema back instead of running it — nothing executes. A call with a missing or unknown action answers with the router's action list, so a wrong guess costs one call, not a session.\n\n#### `cz-access` — sharing, groups, API keys, invites\n\n| Action | Purpose |\n|--------|---------|\n| `share-object` | Grant or revoke access on a process / folder / stage / project (use privs=\"none\" to revoke — same wire op as share with empty privs) |\n| `list-shares` | Audit who currently has access to an object |\n| `create-group` / `modify-group` / `delete-group` | Manage workspace user groups (delete refuses if group has active shares unless force=true) |\n| `list-group-objects` | List processes currently shared with a group (used to audit impact before delete) |\n| `add-to-group` / `remove-from-group` | Manage group membership |\n| `list-groups` | List groups in the workspace |\n| `create-api-key` | Create an API key. Secret is written to ~/.corezoid/api-keys/<file>.json (chmod 600) — never printed in chat |\n| `modify-api-key` | Rename or re-describe an API key |\n| `delete-api-key` | Delete an API key (invalidates the secret immediately) |\n| `list-api-keys` | List API keys in the workspace |\n| `find-principal` | Resolve user / group / API-key name → obj_id (call before share-object) |\n| `invite-user` | Invite an external email AND share an object in one call |\n\n#### `cz-structure` — workspaces, projects, stages, folders, moves\n\n| Action | Purpose |\n|--------|---------|\n| `create-folder` | Create a new subfolder |\n| `move-process` / `move-folder` | Explicitly reparent an existing object without copying/deploying; dry-run + exact confirmation required |\n| `list-workspaces` | Workspaces (companies) available to the authenticated user |\n| `list-projects` | Projects in a workspace |\n| `show-project` | One project's metadata and the stages visible to the caller |\n| `create-project` | Create a project, optionally with stages |\n| `modify-project` | Rename a project / change short_name or description |\n| `delete-project` | Move a project to Trash (destructive) |\n| `list-stages` | Stages (environments) of a project |\n| `set-stage-immutable` | Set/clear a stage's immutable flag (needs confirm) |\n| `list-folders` | Immediate children of a folder: subfolders, processes, state diagrams |\n| `show-folder` | One folder's metadata: title, obj_type, parent |\n| `modify-folder` | Rename a folder / change its description |\n| `delete-folder` | Move a folder to Trash (destructive) |\n\n#### `cz-tasks` — tasks inside a deployed process\n\n| Action | Purpose |\n|--------|---------|\n| `show-task` | Look up one task by `ref` and/or `task_id` — returns its current `data`, `node_id` and status. Read-only; use it instead of paging `list-node-tasks` |\n| `modify-task` | Change a task's data; deep_merge=true merges instead of replacing |\n| `delete-task` | Delete a task from a process (destructive) |\n| `list-node-tasks` | Tasks currently parked in a node |\n| `list-task-history` | The node path a task has taken |\n| `get-node-stat` | In/out counts for a node over a time range |\n\n#### `cz-dashboards` — dashboards and charts\n\n| Action | Purpose |\n|--------|---------|\n| `create-dashboard` | Create a new dashboard for process metrics |\n| `get-dashboard` | Get dashboard details with charts and series |\n| `add-chart` | Add a chart (column/pie/funnel/table) to a dashboard |\n| `get-chart` | Get a single chart with its series data |\n| `modify-chart` | Modify an existing chart (full series required) |\n| `set-dashboard-layout` | Save chart positions on the grid (required to make charts visible) |\n\n#### `cz-variables` — stage environment variables\n\n| Action | Purpose |\n|--------|---------|\n| `create-variable` | Create a Corezoid environment variable |\n| `list-variables` | All variables of the stage: short_name, obj_id, type, title, value |\n| `modify-variable` | Change value/title/data_type or rename; apply=false dry-run first, then apply=true + confirm |\n| `delete-variable` | Permanently delete a variable; apply=false dry-run first, then apply=true + confirm (destructive) |\n\n#### `cz-snapshots` — manual process checkpoints\n\n| Action | Purpose |\n|--------|---------|\n| `create-snapshot` | Create a snapshot of a process (auto-created before every push-process on existing processes; skipped where the environment has no snapshot support) |\n| `list-snapshots` | List all snapshots for a process |\n| `delete-snapshot` | Delete a snapshot by snapshot_id |\n| `get-snapshot` | Get snapshot node list for diff comparison against current process |\n\n#### `cz-git-context` — the git mirror in .git-context/\n\n| Action | Purpose |\n|--------|---------|\n| `git-pull-context` | Clone or pull the Corezoid git mirror into `.git-context/` |\n| `git-push-context` | Commit and push `_ext/` changes to the git mirror |\n| `read-context-file` | Read a file from `.git-context/` |\n| `update-context-file` | Write or append to a file inside `_ext/` |\n\n## Platform Architecture\n\nCorezoid is an event-driven Actor Engine where processes are defined as directed graphs of nodes:\n\n```\nWorkspace\n  └── Projects\n        └── Stages (Root Folder)\n              └── Folders (optional)\n                    └── Processes (.conv.json)\n                          └── Nodes (Start → Logic → End)\n                                └── Tasks (data flowing through nodes)\n```\n\n**Key concepts:**\n- **Processes** — stored as `.conv.json` files, named `<ID>_<name>.conv.json`\n- **Nodes** — processing units connected via `go` transitions\n- **Tasks** — data objects that flow through process nodes\n- **Variables** — workspace-scoped constants referenced as `{{env_var[@name]}}`\n- **State Diagrams** — a special object (`conv_type: \"state\"`) that stores long-lived tasks keyed by `ref`. Other processes read with `{{conv[<id>].ref[<ref>].<field>}}` and write with `api_copy mode: \"create\"/\"modify\"`. Allowed node set is restricted to 10 logics (Start, Condition, Code, Set Parameters, Copy Task, Modify Task, Set State, Delay, Queue, End). Use `/corezoid-state-diagram-create` and `/corezoid-state-diagram-edit`.\n\n## Node Types\n\n| Node | obj_type | Logic type | Purpose |\n|------|----------|------------|---------|\n| Start | 1 | `go` | Entry point |\n| Code Node | 0 | `api_code` | JS/Erlang code execution |\n| API Call | 0 | `api` | External HTTP request |\n| Call a Process | 0 (`4` when Stub Mode is active) | `api_rpc` | Invoke another process; Stub Mode returns configured mock replies instead |\n| Set Parameters | 0 | `set_param` | Variable assignment |\n| Condition | 0 | `go_if_const` | Branching logic (business flow; `3` when it is an `err_node_id` target) |\n| Reply to Process | 0 | `api_rpc_reply` | Return result to caller (`3` when it is an `err_node_id` target) |\n| End / Error | 2 | _(none)_ | Terminal node |\n\n## Key Validation Rules\n\n- Node IDs must be 24-character hex strings: `^[0-9a-f]{24}$`\n- Every node that can fail must have `err_node_id`\n- All constants (URLs, tokens, IDs) must use `{{env_var[@variable-name]}}` — never hardcoded\n- `extra` and `extra_type` keys must match exactly\n- Object values in `extra` must be stringified JSON strings\n- Active Call Process Stub Mode is `obj_type: 4` plus `condition.stub`; `obj_type: 0` with the same `condition.stub` is inactive and calls the real target process.\n- Use Stub Mode only as a temporary placeholder while the called process is not ready, or as a controlled integration-test fixture. It bypasses the real called process and can hide side effects or fake success in production.\n- `push-process` treats active Stub Mode as warning-only on a resolved mutable non-production-like stage, but blocks immutable, production-like, or unknown stages unless `allow_active_stub_mode=true` is passed after explicit confirmation.\n\n## Common Operations\n\n### Deploy a process\n```\npush-process(process_path=\"./folder/12345_MyProcess.conv.json\")\n```\n\n### Run a test task\n```\nrun-task(process_path=\"./folder/12345_MyProcess.conv.json\", data={\"key\": \"value\"})\n```\n\n### Run a task with no local process file (e.g. a host with no local process repository)\n```\nrun-task(process_id=12345, data={\"key\": \"value\"})\n```\n`process_id` needs no `pull-process` first — it identifies the process the same way `process_path`'s filename does, just without a file (same argument name `pull-process` and the `cz-tasks` actions already use). The `cz-snapshots` actions accept `process_id` the same way. Pass exactly one of the two — both together is rejected as ambiguous, and `process_id` must be greater than zero. These tools still need `stage_id`/`project_id` resolved from Corezoid credentials (`login`, or `COREZOID_*` env vars — see `corezoid-init`), even when no local file is used.\n\n### Inspect a task by its external reference\n```\ncz-tasks {\"action\": \"show-task\", \"args\": {\"process_id\": 12345678, \"ref\": \"ORDER-4711\"}}\n```\nRead-only — never scan a node with the `list-node-tasks` action to find a known `ref`.\n\n### Validate locally without deploying\n```\nlint-process(process_path=\"./folder/12345_MyProcess.conv.json\")\n```\n\n### Pull a process by ID\n```\npull-process(process_id=12345678)\n```\n\n## Specialized Skills\n\nFor domain-specific workflows use the specialized skills:\n- `/corezoid-init` — setting up environment and pulling from Corezoid\n- `/corezoid-logout` — remove saved Corezoid credentials for the current workspace\n- `/corezoid-create` — creating a new process from scratch\n- `/corezoid-connector-create` — connector to an API endpoint (one endpoint = one process): any HTTP API — external, internal, or Corezoid itself\n- `/corezoid-edit` — modifying an existing process\n- `/corezoid-lifecycle` — explicitly pause/resume a process or move a process/folder; never inferred from review/refactoring\n- `/corezoid-state-diagram-create` — creating a new state diagram (`conv_type: \"state\"`) from scratch\n- `/corezoid-state-diagram-edit` — modifying an existing state diagram\n- `/corezoid-review` — auditing and analyzing a single process\n- `/corezoid-project-review` — auditing an entire project or folder (cross-process analysis)\n- `/corezoid-dashboard-manager` — creating dashboards and charts for process metrics\n- `/corezoid-process-tech-writer` — documenting a process (Markdown + enriched JSON)\n- `/corezoid-alias-manager` — creating, listing, modifying, deleting, and using aliases\n- `/corezoid-variable-manager` — creating, listing, modifying, deleting variables (visible/secret, raw/json)\n- `/corezoid-process-optimizer` — reduce tacts (merge nodes), clean data flow, fill names, add semaphors\n- `/corezoid-api-connector` — build processes that call the Corezoid public API (`/api/2/json/`) using `api_secret_outer`\n- `/corezoid-retro` — end-of-session retrospective: extract learnings (failed→fixed push deltas, data-shape surprises, corrections) and route them to workspace CLAUDE.md, team feedback, settings, or personal memory with user confirmation\n- `/corezoid-describe` — update or create the description of a process, folder, or project without editing its logic\n- `/corezoid-git-context` — after a substantial session: analyse changes and update `_ext/docs/*.md` in the git mirror\n- `/corezoid-gen-bot` — turn a set of existing processes into a multi-platform messenger bot (Telegram / Viber / Facebook Messenger / Apple Messages for Business): derives each process's real contract, designs the command map, creates the Communications Orchestrator and one bot process per command\n- `/corezoid-edit-bot` — change a bot that already exists: add/rename/drop a command, wire another process, edit copy or keyboards, promote a stage\n\n## Reference Documents\n\nUse the `Read` tool to load these files when you need deeper detail:\n\n| Path | When to read |\n|---|---|\n| `${CLAUDE_PLUGIN_ROOT}/docs/node-structures.md` | JSON schemas for all node types + full Logics fields reference (canonical) |\n| `${CLAUDE_PLUGIN_ROOT}/docs/nodes/set-parameters-built-in-functions.md` | Built-in functions: `$.math`, `$.date`, `$.random`, `$.sha1_hex`, `$.md5_hex`, `$.base64_encode`, `$.unixtime`, `$.map`, `$.filter` |\n| `${CLAUDE_PLUGIN_ROOT}/docs/nodes/set-parameters-dynamic-values.md` | Dynamic values: `{{var}}`, `{{node[id].count}}`, `{{node[id].SumID}}`, `{{conv[@alias].ref[...]}}`, `{{env_var[@name].key[1]}}` |\n| `${CLAUDE_PLUGIN_ROOT}/docs/tasks/task-metadata.md` | Global `root.*` fields: `root.task_id`, `root.ref`, `root.conv_id`, `root.node_id`, `root.prev_node_id`, `root.user_id`, `root.change_time`, `root.create_time` |\n| `${CLAUDE_PLUGIN_ROOT}/docs/nodes/code-node.md` | Code node details and available JS libraries |\n| `${CLAUDE_PLUGIN_ROOT}/docs/nodes/call-process-node.md` | Call a Process node, semaphores, cross-folder calls |\n| `${CLAUDE_PLUGIN_ROOT}/docs/nodes/api-call-node.md` | HTTP API call configuration |\n| `${CLAUDE_PLUGIN_ROOT}/docs/nodes/condition-node.md` | Condition node (branching logic) |\n| `${CLAUDE_PLUGIN_ROOT}/docs/nodes/reply-to-process-node.md` | Reply formats, object stringification |\n| `${CLAUDE_PLUGIN_ROOT}/docs/nodes/end-node.md` | End node success/error configuration |\n| `${CLAUDE_PLUGIN_ROOT}/docs/process/process-json-validation.md` | Validation rules and common errors |\n| `${CLAUDE_PLUGIN_ROOT}/docs/process/error-handling.md` | Error handling patterns |\n| `${CLAUDE_PLUGIN_ROOT}/docs/process/process-lifecycle-and-move.md` | Verified pause/resume semantics, move wire contract, confirmation and cross-stage safety rules |\n| `${CLAUDE_PLUGIN_ROOT}/docs/state-diagrams/state-diagram-overview.md` | State diagram concepts and allowed nodes |\n| `${CLAUDE_PLUGIN_ROOT}/docs/state-diagrams/state-diagram-node-structures.md` | JSON schemas for nodes inside a state diagram |\n| `${CLAUDE_PLUGIN_ROOT}/docs/state-diagrams/state-diagram-process-interaction.md` | How driver processes read / create / modify state tasks |\n| `${CLAUDE_PLUGIN_ROOT}/docs/variables-guide.md` | Variable naming rules, creation workflow, usage examples |\n\n## Description Update Rule\n\nAfter any successful change to a process, folder, or project, always set or refresh its description. Full authoring rules are in `/corezoid-describe`.\n\nSummary:\n- **Process** — update `description` in `.conv.json` root **before** `push-process` (no second push needed). 1–2 sentences, start with a verb (*Calls*, *Creates*, *Validates*…), under 200 characters, no *\"This process…\"*\n- **Folder** — call `cz-structure` action `modify-folder` with `description` if the folder was structurally changed. Resolve `folder_id` from the process's parent or by name via the `list-folders` action; if unresolvable, skip.\n- **Project** — call `cz-structure` action `modify-project` with `description` if project scope changed.\n\n---\n\n## Tips\n\n- Always `lint-process` before `push-process` to catch errors early\n- Use `pull-folder` to sync the full stage to disk before editing\n- Node IDs are 24-char hex — generate with `crypto.randomBytes(12).toString('hex')`\n- Variables are workspace-scoped — check `_ENV_VARS_.json` before creating new ones\n- `push-process` is mandatory after any edit — changes exist only in memory until pushed\n\n## Proactive improvement/bug reporting\n\nWhen responding to a user message that reveals a **platform-level mistake** — wrong node type, wrong API choice (Corezoid vs Simulator), wrong process structure, wrong MCP tool, missing required platform field — add one line to your response, adapted to the situation:\n\n- Bug / broken behavior → \"Хотите сообщить о баге команде Corezoid?\"\n- Unexpected plugin choice → \"Хотите сообщить об этом команде Corezoid?\"\n- User hints something could be better → \"Хотите отправить пожелание команде Corezoid?\"\n\nThis is one extra line in the same response, not a separate action. Offer once per problem; do not repeat if the user declines.\n\n**Do not add this line** for business-logic iterations: changing a value, adding a field, renaming, adjusting a condition — these are normal user changes, not platform issues.\n"
}