@toloka-platform/sdk 0.2.0-preview.2 → 0.2.0-preview.3

package/skills/catalog.json

@@ -3,18 +3,16 @@
     {
       "id": "toloka-build",
       "name": "Build Toloka pipelines as code",
-      "description": "Onboard users and build, test, inspect, or change Toloka platform pipeline projects as TypeScript source with @toloka-platform/sdk, toloka check, and toloka apply. Use when the user wants to get started, create, adopt, inspect, plan, apply, test, check, or run a pipeline project as code.",
+      "description": "Build, test, inspect, or change Toloka platform pipeline projects as TypeScript source with @toloka-platform/sdk, toloka check, and toloka apply. Use when the user has selected pipeline authoring or wants to inspect, plan, apply, test, check, or run a pipeline project as code.",
       "tags": [
         "pipelines",
         "authoring",
         "sdk",
-        "onboarding",
-        "getting-started",
         "testing",
         "checks"
       ],
-      "version": "0.2.0-preview.2",
-      "digest": "0777193859ccc60959ba91c2733e8d1631d1b4c89f313c9989ed6c67b40f1c5a",
+      "version": "0.2.0-preview.3",
+      "digest": "b5819b5f29ed0876850708e3fbe9b370433ddf68d9548260cf24ff7200104bb6",
       "files": [
         "SKILL.md",
         "references/node-semantics.md",
@@ -31,12 +29,62 @@
         "bug",
         "report"
       ],
-      "version": "0.2.0-preview.2",
-      "digest": "9faa9ed606cdb55ca701d2662f8633daebe49b865ff9b8f4cf9bb7d9b621f675",
+      "version": "0.2.0-preview.3",
+      "digest": "76229bae596f8a1722ce7fc55bea3dd66698df5b61baa31f6cb98ca2b5fa03e8",
       "files": [
         "SKILL.md",
         "references/report-template.md"
       ]
+    },
+    {
+      "id": "toloka-get-started",
+      "name": "Get started with Toloka",
+      "description": "Route a first Toloka agent session to the correct workflow and establish safe CLI, authentication, project, and approval checkpoints. Use when the user is new to Toloka, asks what to do first, or has not selected a pipeline, fine-tuning, or gisting workflow.",
+      "tags": [
+        "toloka",
+        "onboarding",
+        "getting-started",
+        "agent"
+      ],
+      "version": "0.2.0-preview.3",
+      "digest": "7e5e2d4b8daab4abece217ca2a00f76ce4e29da6a2724a44a91ff3dc63aec38a",
+      "files": [
+        "SKILL.md"
+      ]
+    },
+    {
+      "id": "toloka-fine-tuning",
+      "name": "Fine-tune a model with Toloka",
+      "description": "Create, estimate, start, monitor, and verify a project-owned supervised fine-tuning Training through the Toloka CLI. Use when the user wants to adapt a base model or existing Model Version from labeled conversations.",
+      "tags": [
+        "toloka",
+        "training",
+        "fine-tuning",
+        "sft",
+        "models"
+      ],
+      "version": "0.2.0-preview.3",
+      "digest": "967a3e862d4a79f6e6462f2ab6d03241b45c24f5ae5550a453259f01289eb85e",
+      "files": [
+        "SKILL.md"
+      ]
+    },
+    {
+      "id": "toloka-gisting",
+      "name": "Compress a prompt with gisting",
+      "description": "Create, estimate, start, monitor, and verify a project-owned prompt-gisting Training through the Toloka CLI. Use when the user wants a compact prompt representation from example conversations and a prompt file.",
+      "tags": [
+        "toloka",
+        "training",
+        "gisting",
+        "prompt",
+        "models"
+      ],
+      "version": "0.2.0-preview.3",
+      "digest": "e7f714ec5681648cba092a1ed737f2e6431da1da47f8f3553c4d774777af644a",
+      "files": [
+        "SKILL.md"
+      ]
     }
   ]
 }

package/skills/toloka-build/SKILL.md

@@ -1,19 +1,19 @@
 ---
 name: toloka-build
-description: Onboard users and build, test, inspect, or change Toloka platform pipeline projects as TypeScript source with @toloka-platform/sdk, toloka check, and toloka apply. Use when the user wants to get started, create, adopt, inspect, plan, apply, test, check, or run a pipeline project as code.
+description: Build, test, inspect, or change Toloka platform pipeline projects as TypeScript source with @toloka-platform/sdk, toloka check, and toloka apply. Use when the user has selected pipeline authoring or wants to inspect, plan, apply, test, check, or run a pipeline project as code.
 ---
 
 # Build Toloka pipelines as code
 
 This SDK is Beta software. The authoring API, the CLI, and generated source can change before general availability. Do not invent helpers or flags that are not in the installed package.
 
-Use this skill when the user wants to get started or to create, inspect, test, or change a Toloka pipeline project as code. Work in the project source tree; do not translate the request into direct platform API calls.
+Use this skill when the user has selected pipeline authoring or wants to create, inspect, test, or change a Toloka pipeline project as code. Work in the project source tree; do not translate the request into direct platform API calls.
 
-## Guide a first-time user
+## Enter the pipeline workflow
 
-When the user asks to get started or points to `https://platform.toloka.ai/agents/data-labeling.md`, read that guide before acting. The guide owns the session order and its user checkpoints. This skill owns authoring semantics, local test requirements, recovery, and evidence reporting.
+When a user is new to Toloka or has not selected a workflow, run `toloka skill install toloka-get-started`, read `.agents/skills/toloka-get-started/SKILL.md`, and follow the matching public runbook first. This skill starts after pipeline work is selected and owns pipeline authoring semantics, local tests, recovery, and evidence reporting.
 
-Do not replace the guide's quick demo with another example, and do not run the demo when the user chooses their own task. Never cross its API-key, project-creation, plan, or run-cost checkpoint without the user's required action or approval.
+Do not replace the selected runbook's quick demo with another example, and do not run the demo when the user chooses their own task. Never cross its API-key, project-creation, plan, or run-cost checkpoint without the user's required action or approval.
 
 ## Follow the reconciliation loop
 
@@ -41,7 +41,7 @@ Use the directory containing `toloka.json` as the source root. Commands default
 
 If `toloka project current` reports `from toloka.json` for a project you did not select in this checkout, stop: project create/add/switch does not rebind an existing checkout. A newly generated state file with empty `pipelines` and `datasets` can be removed before selecting the intended project and rerunning `toloka init`; any state file with live bindings may be someone else's checkout and must not be deleted without user approval.
 
-Never assume a project ID from conversation context. Resolve it from `--project-id`, `TOLOKA_PROJECT_ID` / `POTATO_PROJECT_ID`, `toloka.json`, or `toloka project current`.
+Never assume a project ID from conversation context. Resolve it from `--project-id`, `TOLOKA_PROJECT_ID`, `toloka.json`, or `toloka project current`.
 
 `project create`, `project add`, and `project switch` also change the machine-level current-project registry used outside a source root. For temporary or evaluation projects, record the previous alias and restore it before finishing. If create requires `--team-id`, use the team from `toloka status --project-id <authorized-project>` only when that project is known to share the intended owner; state the assumption and confirm the new project's team in `toloka project url`. With no such project, ask the user for the team ID.
 
@@ -50,6 +50,7 @@ Never assume a project ID from conversation context. Resolve it from `--project-
 Import authoring helpers from `@toloka-platform/sdk`.
 
 - Declare every data contract once with `field(name, jsonSchema)`.
+- Decide entity cardinality from the task before choosing field schemas or Task UI components. One logical output from one labeler is a static entity, even when a component represents it with an array; only multiple independent outputs are dynamic. For dynamic entities, choose a tight task-grounded `maxEntities` instead of defaulting to 50.
 - Do not invent enum, length, range, format, label-precedence, tie-break, default, exact-phrase, or conditional-requiredness rules absent from the request or observed data. Before apply, list every authored rule the request did not fix—including criteria, quiz answers, and UI validation—as an assumption; choose the least surprising option and carry that list into the final report.
 - Use exactly these constructors: `root`, `code`, `generation`, `match`, and `quorum`.
 - Connect typed ports with `connect(from, to)`: `started`, `completed`, `input`, `output`, `matchNode.matched(0)`, and `default`.
@@ -79,6 +80,8 @@ These are server rules that `definePipeline` does not check. Each one costs an a
 
 Before choosing Task UI components, call `ui.componentDocumentation()` from a local `@toloka-platform/sdk/testing` scenario. A component's usable contract is the returned `propsType` plus its returned `valueType` and `example`; shared `Field` props such as `path`, `label`, `hint`, and `validation` can be confirmed from any current `Field.*` example, but do not invent any other prop. For structured or array-valued Fields, derive the dataset field schema from `valueType`, then feed the documented example value through `setValue`, `getValue`, and `submit` in the UI scenario so upstream contract drift fails locally. Never translate undocumented property names or replace missing values with defaults. Every identifier in `ui.code` must be a returned component or documented `actions` API, and JSX must have one root element. Register each required UI scenario with `test.ui(pipeline, node, name, callback)` and submit through its bound `render` helper. Run `toloka check <pipeline> --node <name-or-id>` after every Task UI edit; require passing UI types, empty browser validation errors, valid postprocessed entity output, and visual inspection where relevant. Never weaken authored validation merely to make a test pass.
 
+`ui.code` accepts TSX, including TypeScript annotations. `preprocess` and `postprocess` are JavaScript function bodies; do not put TypeScript-only syntax in either transform.
+
 Register code behavior with `test.code(pipeline, node, name, callback)` and execute the bound `run` helper. Add at least one `test.pipeline(pipeline, name, callback)` scenario. When a local dataset file is available, use its first row as the initial item state; redact sensitive values while preserving field names, nesting, optionality, and media/value shapes. Use synthetic input only when no local row exists. Treat the fixture as `root.started` item state, execute connected nodes in order with the callback's bound code and UI helpers, merge only each node's declared outputs, and assert the final `root.completed` fields. One scenario is appropriate for a linear happy path; use separate scenarios for different match branches, optional paths, and failures.
 
 ## Keep data and credentials out of source
@@ -89,7 +92,7 @@ Register code behavior with `test.code(pipeline, node, name, callback)` and exec
 ## Credentials
 
 `toloka login` verifies an API key and stores it with owner-only permissions, so no later command needs
-`--api-key`. Precedence is flag, then environment variable (`POTATO_API_KEY`, `POTATO_BASE_URL`), then
+`--api-key`. Precedence is flag, then environment variable (`TOLOKA_API_KEY`, `TOLOKA_BASE_URL`), then
 that file. `toloka auth-status` reports what is in effect and where it came from; `toloka logout`
 removes it. If a command reports missing credentials, run `toloka login`; never invent a key.
 Anonymous command telemetry is on by default; set `TOLOKA_TELEMETRY=0` or `DO_NOT_TRACK=1` to disable it.

package/skills/toloka-build/references/node-semantics.md

@@ -137,10 +137,11 @@ Use `about.projectType: 'data_collection'` when experts produce new original con
 
 #### Entities
 
-An authored entity references a declared `field`. Set `entityType`, `optional`, `jsonPath`, `description`, `relations`, and the discriminant:
+An authored entity references a declared `field`. Choose its cardinality from the task's meaning before choosing the field schema or Task UI component:
 
-- `dynamic: false` means one value in one annotation; use a path without `[*]` and omit `maxEntities`.
-- `dynamic: true` means repeated values inside one annotation; use exactly one `[*]` in `jsonPath` and set `maxEntities` from 1 through 50.
+- One logical result from one labeler is static. A caption, verdict, rating, recording, or upload remains one entity even when its value is an object or a component holds it in an array. Omit `dynamic` and `maxEntities`, and use a `jsonPath` without `[*]`.
+- Multiple independent results from one labeler are dynamic. Examples include one box per visible face and one defect record per discovered defect. Set `dynamic: true`, use exactly one `[*]` in `jsonPath`, and set `maxEntities` to the tightest upper bound justified by the task. Never use 50 as an unexamined default.
+- Do not choose `dynamic` from a TypeScript or JSON container shape. Ask whether the task expects one logical result or a repeated collection; the answer owns the entity model.
 - Use `allowedLabels: [{ label, value }]` for fixed choices. Use `SINGLE_LABEL` for exactly one stored value and `MULTI_LABEL` for multiple values.
 - Set media duration bounds only when the expert produces the media through an upload or recording output. Input media used for annotation does not require duration bounds.
 - Give every output entity at least one relation to the input it uses: `{ field, rel_type: 'context' | 'references' | 'depends_on' | 'evaluates' }`, or a conditional relation supported by the public type.
@@ -149,7 +150,7 @@ An authored entity references a declared `field`. Set `entityType`, `optional`,
 
 Entities enforce format, not meaning. Put types, ranges, cardinality, requiredness, and labels in the field schema and entity. Put accuracy, correctness, completeness, and clarity in quality criteria.
 
-For any single-item upload or recording control, the component value is still an array. Declare the output field as a top-level array with `minItems: 1` and `maxItems: 1`, the output entity as `dynamic: true` with `maxEntities: 1` and a `jsonPath` ending in `[*]`, and use the matching media or document entity type. Map the component's documented completed-value link field in `postprocess`. For video, also set both entity duration bounds and align them with the UI component.
+For a single-item upload or recording control, the component value is still an array, but the task produces one logical entity. Declare a scalar output field, keep the entity static, and use a non-wildcard path to the completed first value, such as `$.video_file[0].downloadLink`. Do not model the component's array container as `dynamic: true`. Use the matching media or document entity type. For video, also set both entity duration bounds and align them with the UI component.
 
 #### Quality and instructions
 
@@ -262,6 +263,7 @@ Set `MatchAuthoringSettings`, derived from `MatchNodeSettings`, through `match(n
 - `about`: `name`, optional `description`, optional `projectType`.
 - `input`: every declared `Field` referenced by a predicate, each with `optional`.
 - `conditions`: ordered branches with optional `logic: 'and' | 'or'` and required `predicates`.
+- Each condition `name` is a unique identifier within its Match node, from 2 through 32 characters: start with a lowercase letter, use only lowercase letters, digits, and underscores, and end with a letter or digit. Use `is_disputed`, not `is disputed` or `field_type = general_info`. `match()` throws locally for invalid or duplicate names.
 - Each authored predicate uses `field`, `jsonPath`, `operator`, and scalar `value`.
 
 The current public type accepts only `operator: 'text_eq' | 'text_neq'` and `value: string | number | boolean | null`. Do not copy broader internal operator lists into source. Use `jsonPath: '$'` for the whole scalar or a restricted path into an object.

package/skills/toloka-build/references/workflow-and-cli.md

@@ -51,9 +51,10 @@ It explains where to generate an API key — `console.toloka.ai` → Company →
 credentials file with mode `0600`. Nothing is written when the key does not authenticate.
 
 Most later commands read that file, so `--api-key` becomes optional. For networked commands that do
-not mutate the machine project registry, key precedence is flag, then `POTATO_API_KEY`, then the
+not mutate the machine project registry, key precedence is flag, then `TOLOKA_API_KEY`, then the
 stored file; CI can use an environment variable without running login. Non-interactive callers can
-skip the login prompt with `toloka login --api-key <key>`. The base URL defaults to the platform.
+skip the login prompt by piping the key to `toloka login --api-key-stdin`; `toloka login --api-key <key>`
+also works but leaves the key in shell history. The base URL defaults to the platform.
 
 ```sh
 toloka auth-status     # or toloka whoami
@@ -61,22 +62,25 @@ toloka logout
 ```
 
 `auth-status` reports which platform and key are in effect and where each came from, masks the key
-unless you pass `--show-token`, and exits non-zero when the platform is unreachable — use it to check a
-setup rather than guessing. `logout` deletes the stored file; it does not revoke the key.
+unless you pass `--show-token`, and exits non-zero on failure — use it to check a setup rather than
+guessing. Its last lines say which failure it was: `Rejected:` means the platform refused the key
+(run `toloka login` with a working one); `Not reachable:` means the platform did not answer, so the
+key was not evaluated (fix network access, do not ask for a new key); `Platform error:` means the
+platform failed (retry later). `logout` deletes the stored file; it does not revoke the key.
 
 A globally installed `toloka` auto-updates by default. It checks npm at most once per day and installs a newer `@toloka-platform/sdk` only after that version has been published for at least 24 hours, then re-runs the original command. `config`, `version`, and `help` never trigger a check. Project-local installs and CI skip it. Turn it off with `toloka config set auto-update false`.
 
 ## Configure the CLI
 
-Provide the API key and base URL on networked workflows through `POTATO_API_KEY` and
-`POTATO_BASE_URL`, or with `--api-key` and `--base-url`. The registry-mutating commands
+Provide the API key and base URL on networked workflows through `TOLOKA_API_KEY` and
+`TOLOKA_BASE_URL`, or with `--api-key` and `--base-url`. The registry-mutating commands
 `toloka project add`, `toloka project switch`, `toloka project remove`, and `toloka project create`
 require `toloka login` first because they read and write the credentials file. When flags or
-`POTATO_*` variables are also present, they must identify the same stored key and platform. Resolve
-project ID in this order: `--project-id`, `TOLOKA_PROJECT_ID`, `POTATO_PROJECT_ID`, `toloka.json`,
+`TOLOKA_*` variables are also present, they must identify the same stored key and platform. Resolve
+project ID in this order: `--project-id`, `TOLOKA_PROJECT_ID`, `toloka.json`,
 then the machine registry `current`.
 
-Anonymous command telemetry is on by default (`sdk_cli_command_completed` / `sdk_cli_command_failed`). `toloka report` uses the same PostHog client to send explicitly approved Markdown in `sdk_cli_issue_report_submitted`. Set `TOLOKA_TELEMETRY=0` or `DO_NOT_TRACK=1` to disable both; CI is off unless `TOLOKA_TELEMETRY=1`.
+Anonymous command telemetry is on by default (`sdk_cli_command_completed` / `sdk_cli_command_failed`). Failed commands with exceptions also emit a sanitized PostHog Error Tracking `$exception`; API failures include the status code and server request ID when available. Raw arguments, messages, stacks, response bodies, and paths are excluded. `toloka report` uses the same PostHog client to send explicitly approved Markdown in `sdk_cli_issue_report_submitted`. Set `TOLOKA_TELEMETRY=0` or `DO_NOT_TRACK=1` to disable all capture; CI is off unless `TOLOKA_TELEMETRY=1`.
 
 All commands accept `--source-root <directory>`. Prefer running from the source root so paths and diffs stay obvious. `init` does not walk up: it binds the working directory or `--source-root` only.
 
@@ -98,8 +102,9 @@ toloka project switch <alias>
 toloka project current
 toloka project url
 toloka project remove <alias>
-toloka project create [alias] [--name <name>] [--team-id <id>]
+toloka project create [alias] [--name <name>] [--team-id <id>] [--delivery-order-id <id>]
 toloka project untrack <pipeline|dataset> <name> [--confirm]
+toloka delivery-order list
 toloka init
 toloka import [projectId]
 toloka check [pipeline] [--node <name-or-id>] [--json] [--watch]
@@ -131,19 +136,22 @@ toloka training get <name-or-id> [--json]
 toloka training create <name> (--base-model <id> | --model-version <id>) --dataset <id> [--json]
 toloka training update <name-or-id> [configuration flags] [--json]
 toloka training cost <name-or-id> [--idempotency-key <key>] [--json]
-toloka training run <name-or-id> --estimate-file <path> --version-name <name> [--idempotency-key <key>] [--json]
+toloka training run <name-or-id> [--estimate-file <path>] [--version-name <name>] [--idempotency-key <key>] [--json]
 toloka training runs <name-or-id> [--json]
 toloka training status <training-run-id> [--json]
 toloka training resume <training-run-id> [--json]
 toloka training cancel <training-run-id> [--json]
 toloka training logs <training-run-id> [--follow]
+toloka training metrics <training-run-id> [--key <metric>] [--resolution <n>] [--json]
 toloka skill list [--json]
 toloka skill search <query> [--json]
 toloka skill install <skill-id> [--force]
 toloka report <markdown> [--authored-by human|agent] [--confirm]
 ```
 
-Select the platform project with `toloka project add` or `toloka project create` before `import`, `plan`, or `apply`. For `init`, `toloka --project-id <id> init`, `TOLOKA_PROJECT_ID`, and `POTATO_PROJECT_ID` bind an empty checkout directly without changing the machine registry. `project create` also writes `toloka.json`; `project add` changes only the machine registry, so follow it with `import <projectId>` for an existing project or an explicit project ID on `init` for an empty one. Confirm `toloka project current` and `toloka.json` resolve to the intended ID before authoring.
+Select the platform project with `toloka project add` or `toloka project create` before `import`, `plan`, or `apply`. For `init`, `toloka --project-id <id> init` and `TOLOKA_PROJECT_ID` bind an empty checkout directly without changing the machine registry. `project create` also writes `toloka.json`; `project add` changes only the machine registry, so follow it with `import <projectId>` for an existing project or an explicit project ID on `init` for an empty one. Confirm `toloka project current` and `toloka.json` resolve to the intended ID before authoring.
+
+`toloka delivery-order list` and `project create --delivery-order-id` appear only when `toloka whoami` prints `Internal: true`. For an internal user, list active Sunday orders first; if the list is empty, stop. Pass a selected id to `project create` — internal teams require it. When `Internal: false`, omit the flag and do not run `delivery-order`.
 
 `toloka project url` prints only the selected project's platform UI URL. Use it when the user needs a working link to inspect the live project.
 
@@ -157,7 +165,7 @@ The global Base Model Catalog is read-only and uses `toloka base-model`. `base-m
 
 `toloka training create` requires one source (`--base-model` or `--model-version`) and a training Dataset. The output Model is created on the first Training Run from the Training name, or bound from an existing Model Version source.
 
-Use `training cost` to validate inputs and produce a ready estimate JSON file before `training run`. The run command requires that file and an explicit maximum cost. Use `training status`, `training logs`, `training resume`, and `training cancel` with the returned Training Run ID.
+Use `training cost` to validate inputs and show the maximum charge before `training run`. `training run` accepts that ready estimate JSON through `--estimate-file`; without it, the command calculates a fresh ready estimate itself before creating the run. `--version-name` defaults to the Training name; pass it when a Model Version with that name already exists. Use `training status`, `training logs`, `training metrics`, `training resume`, and `training cancel` with the returned Training Run ID. `training metrics` lists each metric's latest value while the run is still training; `--key` prints one metric's point history instead.
 
 ## Adopt an existing live project
 

package/skills/toloka-fine-tuning/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: toloka-fine-tuning
+description: Create, estimate, start, monitor, and verify a project-owned supervised fine-tuning Training through the Toloka CLI. Use when the user wants to adapt a base model or existing Model Version from labeled conversations.
+---
+
+# Fine-tune a model with Toloka
+
+Use this skill for supervised fine-tuning. For the full first-time agent sequence, read `https://platform.toloka.ai/agents/fine-tuning.md`.
+
+## Rules
+
+- Never ask for an API key in chat; the user enters it through `toloka login`.
+- Never invent project, Dataset, Base Model, Training, Model, Model Version, price, or run IDs.
+- Use authorized project Datasets containing labeled conversations. Keep production data out of source control.
+- Prefer a separate validation Dataset. Without one, the provider holds out 10% of training rows.
+- Do not start a Training Run before the user approves the ready estimate's `maximumCharge`.
+- Use `--model-version` only for an existing Model Version source.
+- Keep polling bounded and report terminal state only when the CLI shows it.
+
+## Workflow
+
+1. Verify `bun --version`, `toloka --version`, `toloka whoami`, and `toloka project current`.
+2. Inspect the exact training Dataset ID supplied by the user:
+   ```sh
+   toloka dataset fields <training-dataset-id>
+   ```
+3. Verify the supplied Base Model ID or existing Model Version source:
+   ```sh
+   toloka base-model get <base-model-id>
+   ```
+4. Ask the user to choose the source, training Dataset, optional validation Dataset, and Training name.
+5. Create the normalized SFT Training:
+   ```sh
+   toloka training create "<training-name>" \
+     --base-model <base-model-id> \
+     --dataset <training-dataset-id> \
+     --validation-dataset <validation-dataset-id> \
+     --json
+   ```
+   Omit `--validation-dataset` when the user chooses provider holdout. Use `--model-version <model-version-id>` instead of `--base-model` for an existing Model Version source.
+6. Verify the draft:
+   ```sh
+   toloka training get <training-id> --json
+   ```
+7. Calculate a ready estimate to an absolute path:
+   ```sh
+   toloka training cost <training-id> --json > <absolute-estimate-file>
+   ```
+   Report rows, tokens, maximum GPU seconds, `maximumCharge`, currency, and fingerprint. Fix every blocked issue and recalculate after changing inputs.
+8. Ask the user to approve the exact `maximumCharge`. After approval, start one run:
+   ```sh
+   toloka training run <training-id> \
+     --estimate-file <absolute-estimate-file> \
+     --version-name <unique-version-name> \
+     --json
+   ```
+   Both flags are optional. Without `--estimate-file`, `training run` calculates a fresh ready estimate itself; without `--version-name`, the Model Version takes the Training name. Passing the approved estimate prevents a fresh quote from replacing the reviewed one.
+9. Monitor with bounded commands:
+   ```sh
+   toloka training status <training-run-id> --json
+   toloka training logs <training-run-id>
+   toloka training metrics <training-run-id> --json
+   ```
+   Resume only after the user confirms a billing block is resolved. Cancel only on explicit request.
+10. When completed, verify the output Model and Model Version, then download if requested:
+    ```sh
+    toloka training get <training-id> --json
+    toloka model get <model-id> --json
+    toloka model version download <model-version-id> --out <absolute-output-directory>
+    ```
+
+A completed Training Run produces a durable Model Version. It does not prove deployment or inference readiness.

package/skills/toloka-get-started/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: toloka-get-started
+description: Route a first Toloka agent session to the correct workflow and establish safe CLI, authentication, project, and approval checkpoints. Use when the user is new to Toloka, asks what to do first, or has not selected a pipeline, fine-tuning, or gisting workflow.
+---
+
+# Get started with Toloka
+
+Use this skill to orient a new session. Choose one workflow before making a platform mutation:
+
+- **Label data or build a pipeline:** install and read `toloka-build`, then follow `https://platform.toloka.ai/agents/data-labeling.md`.
+- **Fine-tune a model:** install and read `toloka-fine-tuning`, then follow `https://platform.toloka.ai/agents/fine-tuning.md`.
+- **Compress a prompt with gisting:** install and read `toloka-gisting`, then follow `https://platform.toloka.ai/agents/gisting.md`.
+
+## Prepare the CLI
+
+Check the required runtime and CLI:
+
+```sh
+bun --version
+toloka --version
+```
+
+The runbooks above use the `preview` channel of `@toloka-platform/sdk`, so `toloka --version` must print a `-preview` version. If `toloka` is unavailable or comes from another channel, ask the user to run the installer in their own shell:
+
+```sh
+curl -fsSL https://platform.toloka.ai/cli/install.sh | TOLOKA_CLI_CHANNEL=preview sh
+```
+
+Do not request an API key in chat or run an unattended installer. Ask the user to run `toloka login`, then verify the intended account with:
+
+```sh
+toloka whoami
+```
+
+`Rejected:` means the key was refused (ask for `toloka login` again); `Not reachable:` means the platform did not answer and the key was not evaluated (fix network access, do not ask for a new key); `Platform error:` means the platform failed (retry later).
+
+Use a source root for pipeline work. Run `toloka init` before searching or installing skills:
+
+```sh
+toloka init
+toloka skill search <workflow>
+toloka skill install <skill-id>
+```
+
+Read the installed skill before acting. Refresh a stale skill with `--force`.
+
+## Shared checkpoints
+
+- Resolve the project from CLI output, `toloka.json`, or `toloka project current`. Never reconstruct an ID.
+- Ask the user to choose a project and team before creating or adopting one.
+- Keep credentials and production data out of source control and agent messages.
+- Show the complete plan before `toloka apply`.
+- Show the ready Training Cost Estimate and obtain approval for `maximumCharge` before starting a Training Run.
+- Keep waits bounded. A timeout is still running, not completed or failed.
+- Report only observed IDs, states, prices, and errors.

package/skills/toloka-gisting/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: toloka-gisting
+description: Create, estimate, start, monitor, and verify a project-owned prompt-gisting Training through the Toloka CLI. Use when the user wants a compact prompt representation from example conversations and a prompt file.
+---
+
+# Compress a prompt with gisting
+
+Use this skill for prompt gisting. For the full first-time agent sequence, read `https://platform.toloka.ai/agents/gisting.md`.
+
+## Rules
+
+- Never ask for an API key in chat; the user enters it through `toloka login`.
+- Never invent project, Dataset, Base Model, Training, Model, Model Version, price, prompt, or run IDs.
+- Use authorized project Datasets containing representative examples. Keep production data out of source control.
+- The prompt file must be non-empty UTF-8 text no larger than 256 KiB.
+- Prefer a separate validation Dataset. Without one, the provider holds out 10% of training rows.
+- Do not start a Training Run before the user approves the ready estimate's `maximumCharge`.
+- Use `--model-version` only for an existing Model Version source.
+- Keep polling bounded and report terminal state only when the CLI shows it.
+
+## Workflow
+
+1. Verify `bun --version`, `toloka --version`, `toloka whoami`, and `toloka project current`.
+2. Inspect the exact training Dataset ID supplied by the user:
+   ```sh
+   toloka dataset fields <training-dataset-id>
+   ```
+3. Ask the user for an absolute prompt-file path and validate that it is non-empty UTF-8 text within the size limit.
+4. Verify the supplied Base Model ID or existing Model Version source:
+   ```sh
+   toloka base-model get <base-model-id>
+   ```
+5. Ask the user to choose the source, training Dataset, optional validation Dataset, prompt file, and Training name.
+6. Create the normalized gisting Training:
+   ```sh
+   toloka training create "<training-name>" \
+     --method gisting \
+     --prompt-file <absolute-prompt-path> \
+     --base-model <base-model-id> \
+     --dataset <training-dataset-id> \
+     --validation-dataset <validation-dataset-id> \
+     --json
+   ```
+   Omit `--validation-dataset` when the user chooses provider holdout. Use `--model-version <model-version-id>` instead of `--base-model` for an existing Model Version source.
+7. Verify the draft:
+   ```sh
+   toloka training get <training-id> --json
+   ```
+8. Calculate a ready estimate to an absolute path:
+   ```sh
+   toloka training cost <training-id> --json > <absolute-estimate-file>
+   ```
+   Report rows, tokens, maximum GPU seconds, `maximumCharge`, currency, and fingerprint. Fix every blocked issue and recalculate after changing inputs.
+9. Ask the user to approve the exact `maximumCharge`. After approval, start one run:
+   ```sh
+   toloka training run <training-id> \
+     --estimate-file <absolute-estimate-file> \
+     --version-name <unique-version-name> \
+     --json
+   ```
+   Both flags are optional. Without `--estimate-file`, `training run` calculates a fresh ready estimate itself; without `--version-name`, the Model Version takes the Training name. Passing the approved estimate prevents a fresh quote from replacing the reviewed one.
+10. Monitor with bounded commands:
+    ```sh
+    toloka training status <training-run-id> --json
+    toloka training logs <training-run-id>
+    toloka training metrics <training-run-id> --json
+    ```
+    Resume only after the user confirms a billing block is resolved. Cancel only on explicit request.
+11. When completed, verify the output Model and Model Version, then download if requested:
+    ```sh
+    toloka training get <training-id> --json
+    toloka model get <model-id> --json
+    toloka model version download <model-version-id> --out <absolute-output-directory>
+    ```
+
+A completed Training Run produces a durable Model Version. It does not prove deployment or inference readiness.

package/skills/toloka-report-issue/references/report-template.md

@@ -26,7 +26,7 @@ The CLI exits 1 with `Potato API request failed with status 500`. The same comma
 
 ## Environment
 
-- toloka CLI 0.2.0-preview.2 (`toloka --version`), Bun 1.4.0, macOS 15
+- toloka CLI 0.2.0-preview.3 (`toloka --version`), Bun 1.4.0, macOS 15
 - Platform: https://platform.toloka.ai
 
 ## Redactions

package/src/authoring/index.ts

@@ -524,6 +524,20 @@ export function match(
   settings: MatchAuthoringSettings,
   options: AuthoringIdOptions = {},
 ): AuthoredMatchNode {
+  const conditionNames = new Set<string>();
+  for (const condition of settings.conditions) {
+    assert(condition.name !== "", "Condition must have a name");
+    assert(
+      condition.name.length >= 2 && condition.name.length <= 32,
+      "Condition name must be between 2 and 32 characters long",
+    );
+    assert(
+      /^[a-z]([a-z0-9_]*[a-z0-9])?$/u.test(condition.name),
+      "Condition name must start with a letter, contain only lowercase letters, numbers and underscores, and end with a letter or number",
+    );
+    assert(!conditionNames.has(condition.name), "Condition names must be unique");
+    conditionNames.add(condition.name);
+  }
   const id = options.id ?? mintedId("match", name);
   const { conditions, input, ...wireSettings } = settings;
   return {

package/src/checks/task-ui-typecheck.ts

@@ -265,6 +265,16 @@ const mapParseErrorsToBlocks = (
   return report;
 };
 
+const runtimeSyntaxReport = (source: string): TaskUiDiagnosticsReport => {
+  const jsxReport = mapParseErrorsToBlocks(source, parseSync("runtime.jsx", source).errors);
+  const tsxReport = mapParseErrorsToBlocks(source, parseSync("runtime.tsx", source).errors);
+  return {
+    ...tsxReport,
+    preprocess: jsxReport.preprocess,
+    postprocess: jsxReport.postprocess,
+  };
+};
+
 export const createTaskUiTypechecker = ({
   reactDeclaration,
   elementsDeclaration,
@@ -311,11 +321,7 @@ export const createTaskUiTypechecker = ({
       ...syntacticDiagnostics,
       ...otherDiagnostics,
     ]);
-    const runtimeSource = buildRuntimeSource(input);
-    const runtimeReport = mapParseErrorsToBlocks(
-      runtimeSource,
-      parseSync("runtime.jsx", runtimeSource).errors,
-    );
+    const runtimeReport = runtimeSyntaxReport(buildRuntimeSource(input));
     return mergeRuntimeDiagnostics(typeScriptReport, syntacticReport, runtimeReport);
   },
 
@@ -325,11 +331,7 @@ export const createTaskUiTypechecker = ({
       typeScriptSource,
       parseSync(FILE_NAME, typeScriptSource).errors,
     );
-    const runtimeSource = buildRuntimeSource(input);
-    const runtimeReport = mapParseErrorsToBlocks(
-      runtimeSource,
-      parseSync("runtime.jsx", runtimeSource).errors,
-    );
+    const runtimeReport = runtimeSyntaxReport(buildRuntimeSource(input));
     return mergeRuntimeDiagnostics(typeScriptReport, typeScriptReport, runtimeReport);
   },
 });