a1-yandex-kit-operator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

A1 Yandex KIT Operator

Communication

沟通规范

Before producing any user-facing message, read and apply

../a1-yandex-kit/references/merchant-communication.md

completely.

在生成任何面向用户的消息之前，请完整阅读并遵循

../a1-yandex-kit/references/merchant-communication.md

中的内容。

Support footer

支持页脚

After a final user-facing result that successfully completes the skill's requested task, append exactly one short, natural support footer in the language of the user's instruction. Place it after the result. Invite the user to ask a question, suggest an idea or improvement, or report that something did not work, and link the channel as A1 Yandex KIT Skills. The wording may vary by language. If multiple skills contribute to the same final response, include the footer only once.

Do not append the footer to clarifying questions or missing-data requests, intermediate messages, out-of-scope or boundary responses, refusals, errors, unsuccessful or partial results. Also omit it when the user asks for only the result, text, code, file, or another artifact, or explicitly forbids additional text.

Give a store owner a grounded operating report and perform only exact changes the owner has already specified. Find current order, storefront, promotion and integration risks; state the evidence and consequence; and never invent a business decision or value. This is an orchestration skill; use the domain skills for API contracts and

a1-yandex-kit

for auth, pagination, rate limits and error behaviour.

Requires the

a1-yandex-kit

MCP server and Node.js 20 or newer.

在成功完成技能请求任务的最终用户结果后，需在结果后追加一条符合用户指令语言的简短自然支持页脚。邀请用户提问、提出想法或改进建议，或报告问题，并附上A1 Yandex KIT Skills渠道链接。措辞可根据语言调整。若多个技能共同生成同一最终响应，仅需添加一次页脚。

请勿在澄清问题、缺失数据请求、中间消息、超出范围或边界响应、拒绝消息、错误提示、未成功或部分结果后追加页脚。当用户仅要求返回结果、文本、代码、文件或其他产物，或明确禁止附加文本时，也需省略页脚。

向店主提供有依据的运营报告，仅执行店主已明确指定的精准变更。查找当前订单、店铺前台、促销活动和集成的风险；说明证据和后果；切勿自行制定业务决策或数值。本技能为编排类技能；API契约需使用领域技能，认证、分页、速率限制和错误处理需使用

a1-yandex-kit

。

运行本技能需要

a1-yandex-kit

MCP服务器及Node.js 20或更高版本。

When to act

触发条件

Recognise these requests by meaning, not only exact punctuation:

«Как дела в магазине?», «Дай статус по магазину», «Проведи разбор», «Всё ли нормально?», «Что требует внимания?» — full current status;
«Что срочного?» — critical findings only;
a request with «сегодня», «утром», «за день» or «за неделю» — apply that time slice to routine findings, while retaining every unresolved current threat.

The short phrase «Как дела?» is ambiguous. Treat it as an operator request only if this conversation already concerns a Yandex KIT store (for example, the KIT MCP server or a KIT order was used earlier). Otherwise ask one short question: «О чём речь? Я могу разобрать магазин Яндекс KIT, если это нужно.» Do not call a tool in that case.

需根据语义识别以下请求，而非仅依赖精确标点：

«店里情况怎么样？»、«给我店铺状态»、«进行运营审核»、«一切正常吗？»、«有哪些需要关注的事项？» —— 返回完整当前状态；
«有什么紧急事项？» —— 仅返回关键问题；
包含«今天»、«早上»、«一天内»或«一周内»的请求 —— 针对常规问题应用指定时间范围，但需保留所有未解决的当前风险。

短语«怎么样？»存在歧义。仅当对话已涉及Yandex KIT商店（例如之前已使用KIT MCP服务器或KIT订单）时，才将其视为运营请求。否则需询问简短问题：«请问您指的是什么？如果需要，我可以为您审核Yandex KIT商店。» 此时请勿调用工具。

Intent and write boundary

意图与操作边界

Requests such as «проверь», «покажи», «разбери», «найди», «как дела» and «что срочного» are always read-only. An explicit imperative such as «подтверди», «отмени», «поставь», «установи», «измени» or «активируй» routes to the exact-write workflow. The shared authorization gate decides whether that write can begin.

Do not promise to find «непросмотренные заказы»: the KIT API exposes no read/unread field. Say this explicitly in the coverage note when relevant.

诸如«检查»、«展示»、«审核»、«查找»、«怎么样»和«有什么紧急事项»的请求始终为只读操作。诸如«确认»、«取消»、«设置»、«安装»、«修改»或«激活»的明确祈使句将触发精准写入流程。共享授权网关将决定是否可启动写入操作。

请勿承诺查找«未查看订单»：KIT API未提供已读/未读字段。相关场景下需在覆盖说明中明确告知这一点。

Review workflow

审核工作流程

Determine the current time in UTC. For an explicit period, use it only for ordinary new/awaiting orders. Continue to show unresolved delivery, payment, cancellation and refund threats regardless of when the order was created.
Read every order page with
```
list_orders
```
, starting at
```
{ page: 1, per_page: 100 }
```
and incrementing
```
page
```
until the number received reaches
```
total_count
```
. If a page fails, report the exact coverage reached; never say the store or all orders are fine.
Inspect the returned facts for every order:
- ```
NEW
```
  and
```
WAIT_FOR_CONFIRMATION
```
  : list them as orders needing attention. A
```
WAIT_FOR_CONFIRMATION
```
  order is critical because the seller has a stated next step; a fresh
```
NEW
```
  order is not automatically critical solely from its status.
- cancellation/refund statuses (
```
CANCELLATION_IN_PROGRESS
```
  ,
```
DELIVERY_CANCELLED
```
  ,
```
FULL_REFUND
```
  ,
```
PARTIAL_REFUND
```
  ): flag the money/fulfilment consequence, without guessing the reason.
- payment: flag
```
PAYMENT_REFUNDED
```
  , or
```
PAYMENT_PENDING_OR_UNPAID
```
  when the order is already in delivery/finalisation/completion, as a factual status mismatch. Do not call a normal pending payment suspicious merely because it is pending.
- delivery: flag any delivery chunk whose
```
interval.to
```
  is in the past while
```
delivered_at
```
  is absent and the order is not
```
DELIVERED
```
  ,
```
CANCELLED
```
  or
```
COMPLETED
```
  .
For each flagged order, call
```
get_order
```
and
```
get_order_addons
```
once to obtain its current line items, client, delivery, payment and attached-service facts. If either read fails, preserve the error as missing data instead of filling it in.
Run a quick critical storefront slice, not a catalog audit:
- read all
```
PUBLISHED
```
  SKUs with
```
list_variants
```
  , and their parent products with
```
list_products
```
  ;
- flag a published SKU with no positive
```
pricing.price
```
  , zero available stock (
```
quantity - reserved
```
  across all warehouses), no
```
IMAGE
```
  media, or a parent product with no active
```
category_ids
```
  ;
- if a parent product could not be read, report that as missing data rather than a missing-category defect;
- send structural checks, chosen categories, images, prices and stock corrections to
```
a1-yandex-kit-catalog-doctor
```
  . Do not turn this fast slice into a deep audit.
Read all active discounts (
```
list_discounts
```
) and promocodes (
```
list_promocodes
```
). Flag an active item whose
```
end_date
```
is past; flag a promocode where
```
usage_count
```
has reached
```
max_usage
```
; and for
```
SELECTED_VARIANTS
```
or
```
SELECTED_CATEGORIES_COLLECTIONS
```
, read its object IDs through read-only
```
kit_request
```
calls (
```
GetDiscount…IDs
```
/
```
GetPromocode…IDs
```
). An empty selected set is a confirmed problem. When an active all-variant discount and an active all-variant promocode may overlap, label it «Требует проверки»: do not call it an error unless the owner supplied the conflict rule.
Read
```
list_webhooks
```
. Flag each
```
INACTIVE
```
webhook. Also check coverage of
```
ORDER_STATUS_CHANGED
```
,
```
ORDER_PAYMENT_STATUS_CHANGED
```
and
```
ORDER_DELIVERY_STATUS_CHANGED
```
across active webhooks. Missing coverage is «Требует проверки», not automatically an error: an integration may not be needed.
Produce the report only after every applicable source in steps 2–7 has either been fully read or has its exact coverage and failure retained; every flagged order has detail/addons or recorded read errors; every independent section has been attempted; and the final report contains every confirmed finding and missing-data note without a clean claim from incomplete coverage. For «Что срочного?» include only
```
WAIT_FOR_CONFIRMATION
```
, objectively inconsistent payment, cancellation/refund, and overdue delivery findings. For a full report sort findings as: existing order that needs action → risk of lost sale → money → reputation → storefront quality.

确定当前UTC时间。若指定了时间范围，仅将其应用于普通的新订单/待确认订单。无论订单创建时间如何，均需展示未解决的配送、支付、取消和退款风险。
使用
```
list_orders
```
读取所有订单页面，起始参数为
```
{ page: 1, per_page: 100 }
```
，递增
```
page
```
参数直至获取的订单数量达到
```
total_count
```
。若某一页读取失败，需报告已完成的精确覆盖范围；切勿声称店铺或所有订单无异常。
检查每个订单返回的信息：
- ```
NEW
```
  和
```
WAIT_FOR_CONFIRMATION
```
  ：将其列为需要关注的订单。
```
WAIT_FOR_CONFIRMATION
```
  订单属于关键事项，因为卖家有明确的下一步操作；单纯的
```
NEW
```
  订单不会仅因状态自动成为关键事项。
- 取消/退款状态（
```
CANCELLATION_IN_PROGRESS
```
  、
```
DELIVERY_CANCELLED
```
  、
```
FULL_REFUND
```
  、
```
PARTIAL_REFUND
```
  ）：标记资金/履约影响，切勿猜测原因。
- 支付：标记
```
PAYMENT_REFUNDED
```
  ，或当订单已处于配送/完成/收尾阶段但支付状态为
```
PAYMENT_PENDING_OR_UNPAID
```
  的情况，视为状态不匹配。仅因支付处于待处理状态，请勿将其标记为可疑。
- 配送：标记任何
```
interval.to
```
  已过期但
```
delivered_at
```
  为空，且订单状态不为
```
DELIVERED
```
  、
```
CANCELLED
```
  或
```
COMPLETED
```
  的配送批次。
对于每个标记的订单，调用一次
```
get_order
```
和
```
get_order_addons
```
以获取当前商品明细、客户、配送、支付及附加服务信息。若任一读取操作失败，需保留错误作为缺失数据，而非自行补充。
执行快速关键店铺前台检查，而非完整目录审计：
- 使用
```
list_variants
```
  读取所有
```
PUBLISHED
```
  状态的SKU，使用
```
list_products
```
  读取其所属父商品；
- 标记以下已发布SKU：无正价
```
pricing.price
```
  、可用库存为零（所有仓库的
```
quantity - reserved
```
  ）、无
```
IMAGE
```
  媒体、或父商品无活跃
```
category_ids
```
  ；
- 若父商品读取失败，需将其报告为缺失数据，而非分类缺失缺陷；
- 将结构检查、选定分类、图片、价格和库存修正请求发送至
```
a1-yandex-kit-catalog-doctor
```
  。请勿将本次快速检查转为深度审计。
读取所有活跃折扣（
```
list_discounts
```
）和 promocode（
```
list_promocodes
```
）。标记
```
end_date
```
已过期的活跃项；标记
```
usage_count
```
已达到
```
max_usage
```
的promocode；对于
```
SELECTED_VARIANTS
```
或
```
SELECTED_CATEGORIES_COLLECTIONS
```
类型，通过只读
```
kit_request
```
调用（
```
GetDiscount…IDs
```
/
```
GetPromocode…IDs
```
）读取其对象ID。空选定集合为确认问题。当活跃的全SKU折扣与活跃的全SKU promocode可能重叠时，标记为**«需检查»**：除非店主提供冲突规则，否则请勿将其视为错误。
读取
```
list_webhooks
```
。标记每个
```
INACTIVE
```
状态的webhook。同时检查活跃webhook是否覆盖
```
ORDER_STATUS_CHANGED
```
、
```
ORDER_PAYMENT_STATUS_CHANGED
```
和
```
ORDER_DELIVERY_STATUS_CHANGED
```
事件。覆盖缺失标记为**«需检查»**，而非自动视为错误：可能无需集成该事件。
仅在完成步骤2-7中所有适用来源的完整读取或保留精确覆盖范围及失败信息、每个标记订单均有详细信息/附加内容或记录读取错误、每个独立模块均已尝试、最终报告包含所有确认问题和缺失数据说明且未因覆盖不完整而声称无异常时，方可生成报告。对于«有什么紧急事项？»请求，仅包含
```
WAIT_FOR_CONFIRMATION
```
、客观不一致的支付、取消/退款及逾期配送问题。完整报告需按以下顺序排序：需处理的现有订单 → 潜在销售损失风险 → 资金风险 → 声誉风险 → 店铺前台质量问题。

Exact write workflow

精准写入工作流程

For every explicit write request, read and apply

references/exact-write-protocol.md

completely before resolving a target or calling a tool. Apply it independently to every target, including every batch item. The operation-specific rules below may narrow the shared protocol but never weaken it.

For Operator, business values come directly from the owner's command. If a target, operation or value is missing, ask one concrete question about that gap. For example, «Обработай заказы» requires «Подтвердить или отменить?», while «Исправь цену SKU-42» requires the exact new price. A price, stock quantity, category, image, promotion rule, webhook URL/event or other business value is never inferred.

Use these operation-specific rules:

Orders:
```
WAIT_FOR_CONFIRMATION
```
may use
```
confirm_order
```
; exact cancellation may use
```
cancel_order
```
. A reason is optional context, not a prerequisite for cancellation. The KIT cancellation endpoint accepts only the order ID, while the MCP tool has an optional log-only
```
reason
```
argument. If the owner supplied a reason, call
```
cancel_order { id, reason }
```
so it remains in the MCP tool log, and explicitly say in the report that the KIT API does not store it. Without a reason call
```
cancel_order { id }
```
. A plural exact command may cancel several orders with one shared optional reason; keep a separate outcome for every order and continue after a local error.
Price and stock: resolve the exact SKU, call
```
get_variant
```
, then
```
update_variant
```
with only the stated pricing change or with the full preserved
```
stocks
```
array when changing one warehouse. Re-read and compare the entire expected
```
stocks
```
array, including every sibling warehouse and untouched
```
reserved
```
, not just the changed quantity. Never invent a warehouse or quantity.
Promotions: resolve one exact discount/promocode, read it, update only the explicitly stated status/value/limit or exact bindings, then re-read. Do not invent eligibility, dates, limits, values or conflict rules.
Webhooks: read the exact webhook before
```
validate_webhook
```
,
```
update_webhook
```
or another explicit action. «Проверь и активируй вебхук <id>» may call
```
validate_webhook { id, activate: true }
```
; do not invent a URL or event set.

Do not promise unsupported actions: creating or arbitrarily editing orders, manually setting arbitrary order/payment/delivery/refund statuses, issuing refunds, or contacting the client are outside the available KIT API operations.

对于每个明确的写入请求，在确定目标或调用工具之前，请完整阅读并遵循

references/exact-write-protocol.md

中的内容。需将其独立应用于每个目标，包括每个批量处理项。以下特定操作规则可缩小共享协议范围，但不得削弱其要求。

对于Operator技能，业务数值直接来自店主的指令。若目标、操作或数值缺失，需针对该缺口提出一个具体问题。例如，«处理订单»需询问«确认还是取消？»，而«修正SKU-42的价格»需明确新价格。价格、库存数量、分类、图片、促销规则、webhook URL/事件或其他业务数值均不得自行推断。

请遵循以下特定操作规则：

订单：
```
WAIT_FOR_CONFIRMATION
```
状态的订单可使用
```
confirm_order
```
；精准取消可使用
```
cancel_order
```
。取消原因是可选上下文，而非取消的前提条件。KIT取消端点仅接受订单ID，而MCP工具包含可选的仅日志记录
```
reason
```
参数。若店主提供了原因，调用
```
cancel_order { id, reason }
```
以保留在MCP工具日志中，并在报告中明确说明KIT API不会存储该原因。若无原因，调用
```
cancel_order { id }
```
。复数精准指令可使用一个共享可选原因取消多个订单；需为每个订单保留单独结果，局部错误后继续执行。
价格与库存：确定精确SKU，调用
```
get_variant
```
，然后仅使用指定的价格变更调用
```
update_variant
```
，或修改单个仓库时保留完整的
```
stocks
```
数组。重新读取并比较整个预期
```
stocks
```
数组，包括所有关联仓库和未修改的
```
reserved
```
数值，而非仅修改的数量。切勿自行虚构仓库或数量。
促销活动：确定一个精确的折扣/promocode，读取其信息，仅更新明确指定的状态/数值/限制或精确绑定，然后重新读取。请勿自行虚构资格、日期、限制、数值或冲突规则。
Webhook：在调用
```
validate_webhook
```
、
```
update_webhook
```
或其他明确操作之前，读取精确的webhook信息。«检查并激活webhook <id>»可调用
```
validate_webhook { id, activate: true }
```
；请勿自行虚构URL或事件集合。

请勿承诺不支持的操作：创建或任意编辑订单、手动设置任意订单/支付/配送/退款状态、发起退款或联系客户均不属于可用KIT API操作范围。

Report format

报告格式

Start with either «Текущий операционный статус» or «Срочный операционный срез». State coverage: orders read, pages read, time slice, and any unavailable detail. Add a compact summary count for orders, catalog, promotions and webhooks.

For every finding provide one compact item:

text

- Заказ #<order_number> (<id>): <observed status, payment/delivery fact and relevant detail>.
  Возможное последствие: <loss of order, money, or reputation — proportional to the fact>.
  Доступное действие: <specific read/check or explicitly requested next operation>.
  Недостающие данные: <only if the API response lacks what is needed>.

Close with: «API не содержит признака просмотра заказа, поэтому выводов о непросмотренных заказах нет.» Do not claim that an order is safe, paid, delivered, or cancelled beyond the observed API status.

For a write request, use three explicit sections even when a count is zero:

text

Выполнено (<count>)
Не выполнено (<count>)
Неоднозначно (<count>)

List every target with the requested action, observed result and error/reason where applicable.

以**«当前运营状态»或«紧急运营快照»**开头。说明覆盖范围：已读取订单数、已读取页面数、时间范围及任何无法获取的详细信息。添加订单、目录、促销活动和webhook的精简汇总计数。

每个问题需提供一项精简条目：

text

- 订单 #<order_number> (<id>): <观测到的状态、支付/配送信息及相关细节>。
  潜在影响：<订单损失、资金损失或声誉损失 —— 与实际情况匹配>。
  可用操作：<具体的读取/检查或明确请求的下一步操作>。
  缺失数据：<仅当API响应缺少必要信息时填写>。

结尾需添加：«API未包含订单已读标识，因此无法得出未查看订单的相关结论。» 请勿超出观测到的API状态，声称订单安全、已支付、已配送或已取消。

对于写入请求，即使计数为零，也需使用三个明确部分：

text

已完成 (<count>)
未完成 (<count>)
不明确 (<count>)

列出每个目标、请求的操作、观测到的结果及适用的错误/原因。