Update to Corezoid

{
  "description": "Documents a Corezoid process — produces a human-readable Markdown file AND enriches the process JSON with descriptions on every node and parameter. Output is designed for team wikis, internal portals, and future product integration. Activate whenever a user asks to document a process, write docs for a connector, add descriptions to a process, create documentation for a logic, describe what a process does, or any similar phrasing. Also activate when the user shares a process JSON and asks to explain it or make it self-documenting. Always produce BOTH outputs (Markdown file + enriched JSON) — never just one.\n",
  "included_files": [],
  "name": "corezoid-process-tech-writer",
  "skill_md_contents": "---\nname: corezoid-process-tech-writer\ndescription: >\n  Documents a Corezoid process — produces a human-readable Markdown file AND enriches\n  the process JSON with descriptions on every node and parameter. Output is designed for\n  team wikis, internal portals, and future product integration.\n  Activate whenever a user asks to document a process, write docs for a connector,\n  add descriptions to a process, create documentation for a logic, describe what a\n  process does, or any similar phrasing. Also activate when the user shares a process\n  JSON and asks to explain it or make it self-documenting. Always produce BOTH outputs\n  (Markdown file + enriched JSON) — never just one.\n---\n\n# Corezoid Process Tech Writer\n\nAlways produce **two outputs** for every process:\n1. Markdown documentation file at `.processes/<name>-docs.md`\n2. Enriched process JSON (same file, `description` fields filled in) at `.processes/<name>-enriched.json`\n\n---\n\n## Step 0 — Load the process\n\nIf the user provides a file path, read it directly. If they provide a process name or ID, use\n`pull-process` to fetch it first.\n\n---\n\n## How to extract information from the process JSON\n\n### Inputs\nRead the `params` array. Each entry has:\n- `name` — parameter name\n- `type` — data type\n- `descr` — description (may be empty — infer from context)\n- `flags` — `\"required\"` flag means mandatory; `\"input\"` = input param, `\"output\"` = output param\n- `regex` — validation pattern (document if non-empty)\n\n### Outputs\nFind all nodes with `api_rpc_reply` logic in `condition.logics`:\n- `throw_exception: false` → success response — document `res_data` keys and types\n- `throw_exception: true` → error response — document what triggers it (node title, `exception_reason` if present)\n\n### Process flow\nWalk `scheme.nodes` following `go` entries from the Start node (`obj_type: 1`):\n- Start → node with `id` matching the `to_node_id` in Start's `go` logic\n- Continue following `go` entries to map the happy path\n- Note branches at Condition nodes or `go_if_const` entries\n- Note error paths via `err_node_id` references\n\n### External dependencies\n- API Call nodes (`api` logic): extract `url`, `method`, `extra_headers`\n- `{{env_var[@name]}}` references: list all unique variable names used\n- Code nodes (`api_code`): look for referenced services or data transformations\n- Call Process nodes (`api_rpc`): extract `conv_id` values (called process IDs)\n\n---\n\n## Output 1: Markdown documentation\n\nSave to `.processes/<process-name-in-snake-case>-docs.md`.\n\nUse this exact structure:\n\n```markdown\n# <Process Title>\n\n## Overview\n<1-2 sentences: what this process does and when to call it. Be specific about the business purpose.>\n\n## Input Parameters\n\n| Name | Type | Required | Description |\n|------|------|----------|-------------|\n| field_name | string | Yes | Description from params.descr |\n| optional_field | number | No | Description |\n\n<If any field has regex validation, add a \"Validation\" subsection listing the rules.>\n\n## Output\n\n### Success response\n| Field | Type | Description |\n|-------|------|-------------|\n| response | object | The API response body |\n\n### Error cases\n| Error | Trigger condition |\n|-------|------------------|\n| \"Code node error\" | JavaScript execution failed in the preparation step |\n| \"API call error\" | External API returned an error or was unreachable |\n\n## How to Call\n\nExample `task_data` with realistic values:\n​```json\n{\n  \"field_name\": \"example_value\",\n  \"optional_field\": 42\n}\n​```\n\n## Process Flow\n\n1. **Start** — Entry point, receives the task\n2. **<Code Node title>** — <plain English: what this step does>\n3. **<API Call / Call Process title>** — <plain English: what is called and why>\n4. **<Reply node title>** — <what is returned on success>\n5. **Final** — Task stored, process complete\n\n<For error paths, describe them after the happy path:>\n\n**Error path (Code Node failure):** If the preparation step fails, an error reply is returned\nwith the exception description, and the task ends at the Error node.\n\n## External Dependencies\n\n| Dependency | Type | Variable / URL |\n|-----------|------|----------------|\n| <service name> | HTTP API | `{{env_var[@variable-name]}}` |\n| <process name> | Corezoid process | ID: `<conv_id>` |\n\n## Notes\n\n- <Any timeouts configured via semaphors — e.g. \"API call has a 30-second timeout\">\n- <Rate limiting (max_threads setting)>\n- <Any other relevant technical notes>\n```\n\n---\n\n## Output 2: Enriched process JSON\n\nRead the original process JSON, add `description` fields to every node, and write the result\nto `.processes/<name>-enriched.json`.\n\n### Rules for node enrichment\n\n**What to fill:**\n- `description` field on every node — one plain English sentence: what this node does in the context of this process\n- `params[].descr` — if empty, infer from the field name and process context\n\n**What NOT to change:**\n- `id`, `obj_type`, `condition`, `logics`, `semaphors` — never touch these\n- `x`, `y`, `extra`, `options` — leave as-is\n- `title` — only fill if the field is completely empty (`\"\"`)\n\n**Description style:**\n- One sentence, active voice, present tense\n- Specific to this process — not generic (\"Handles errors\" is bad; \"Returns an error reply if the actor creation API call fails\" is good)\n- Reference actual data fields and external services where relevant\n\n**Examples:**\n\n| Node type | Bad description | Good description |\n|-----------|----------------|-----------------|\n| Code node | \"Prepares data\" | \"Builds the request body with actor_name, form_id, and authorization_header for the Simulator API call\" |\n| API Call | \"Makes API call\" | \"Sends POST request to Simulator API to create a new actor with the prepared parameters\" |\n| Reply Success | \"Returns response\" | \"Returns the created actor data from the Simulator API back to the calling process\" |\n| Reply Error | \"Returns error\" | \"Returns error reply with throw_exception:true when the actor creation API call fails\" |\n| Final | \"Final\" | \"Stores the completed task with actor creation result and marks the process as successful\" |\n\n---\n\n## Both files must be produced in the same response\n\nDo not produce one without the other. If the process JSON is very large, produce the Markdown\nfirst, then the enriched JSON.\n"
}