---

name: lidfly-site-commerce description: "Создавать, оформлять и проверять сайты LidFly через MCP v3: визуальная концепция, шаблоны, блоки, изображения, адаптивность и visual QA. Также страницы, базы знаний, SEO/GEO, feeds, файлы, лиды, публикация, товары, остатки, заказы и платежи с точным scope и защитой секретов YooKassa."

LidFly Site Commerce

Use for LidFly sites, landing pages, published pages, SEO and social metadata, Schema.org, RSS/YML feeds, assets/uploads, leads, analytics, stores, offers, variants, inventory, orders, fulfillments, payments, and Commerce setup.

Terminology

• "Тема оформления" means visual tokens: colors, fonts, radius, renderer choices.
• "Шаблон сайта" means persistent site-level design system: header, footer, product page/card layout, checkout, and page blueprints.
• Do not call generated storefront pages "templates" unless they use real design_template_id.

Source Of Truth

• Commerce source of truth is store/provider tools backed by PostgreSQL.
• Published HTML under /sites is only a publish artifact.
• YooKassa seller secrets are never shown, echoed, or saved in user-visible docs.

Workflow

Visual work

For a new page or substantial redesign, complete this cycle in the authorized scope. For a local correction, preserve the direction and check the affected area; an order, inventory or SEO-metadata operation does not require a redesign.

1. Read the current site and references. State one concrete visual direction: audience/task, hierarchy, typography, palette, grid, spacing and image treatment. Read Creative page direction.
2. Map the content to native templates and blocks, with an intentional mobile arrangement. Read Frontend page craft. A blueprint is a starting point, not a section quota. Knowledge pages need readable structure; do not force a sales hero or repeated oversized cards.
3. When media is needed, read Visual assets: plan roles/crops, inspect actual images and verify their asset bindings. Preserve supplied content; do not invent evidence or require paid generation.
4. Read Visual QA. After applying changes, inspect actual desktop/mobile screenshots and interactions against the brief; fix visible defects and recheck the new revision. Technical pass or successful publication alone is not aesthetic approval. If viewing is unavailable, say QA is incomplete.

In MCP/chat, load these relevant references with get_skill_resource using name="lidfly-site-commerce" and the exact path above; installed clients read the local files. Load them by stage, not every operational reference at once.

Native operations

Choose blocks by observable interaction before appearance: whole-card navigation, image zoom, separate CTA, or opening a form. For focused edits read the current section snapshot; use blueprints for page composition. Compare filtered catalog description/purpose/visible_when and read the selected definition. Continue pagination or narrow filters if has_more; explain unsupported behavior without replacing a requested whole-card link with a separate button. After saving, disclose warnings and test clicks, target anchors, unwanted zoom, keyboard and mobile behavior.

For a managed site with design_template_id="knowledge-base", route ingest, query-to-wiki, provenance, relations, findings, changesets, and lint to $lidfly-knowledge-maintainer; do not emulate knowledge updates with sequential page writes.

1. If the site, store, owner, or project is unclear, call the top-level get_provider_context({ provider: "lidfly", query? }) and use only returned scope arguments.
2. Find internal LidFly tools with search_tools.
3. Read each internal tool schema with get_tool_schema before its first call.
4. Use call_tool for reads: sites, pages, assets, leads, analytics, stores, orders, and CRM delivery diagnostics.
5. Use call_write_tool for publishing, uploads, store/order changes, payment setup, CRM profile/policy changes, delivery resolution, and image generation.
6. For paid image generation, show prompt, format, crop, and wait for explicit confirmation.
7. Never run two write calls for the same site in parallel. Before a write to a known URL/site_id/subdomain/name, refresh the targeted get_provider_context({ provider: "lidfly", query: "..." }); use lidfly_list_sites only when the site is unknown. Continue only when publication_write.status="idle" and use its fresh publication_revision. If it is busy, wait for the named operation to finish, reread the same targeted scope, verify the previous write's actual state, and only then make at most one retry.

For a new or substantially revised managed site, use the server-verifiable workflow from MCP v3 compatibility methodology: declare the page and image scope, inspect compact snapshots, choose a blueprint, apply one acceptance-bound changeset, then verify the exact revision on desktop and mobile. A successful write means only that changes were applied. Say that the site is ready only after promised routes/assets and visual QA pass; disclose every visual warning explicitly.

For several desired-state edits on one site, save them sequentially and publish once after all edits. In particular, multiple taxonomy node page overrides use get_catalog_node_page → update_catalog_node_page one node at a time, followed by one preview_catalog_publish → publish_store flow.

Privacy consent on managed sites

• Privacy consent is a site-level managed capability, not CSS, arbitrary HTML, a custom checkbox field, or a Bitrix24-only setting.
• Use lidfly_get_site_privacy_consent to read the current policy and exact revisions. Publish every referenced internal document route first, then call lidfly_update_site_privacy_consent with those exact revisions, and finish with a control read.
• form.required=true adds one required unchecked checkbox to every standard managed lead form. Use distinct consent_url and privacy_policy_url; changing enabled text or links requires a new version.
• analytics.required=true enables the site-wide accept/reject banner and keeps Yandex Metrika and optional tracking inert until acceptance. A new analytics version asks visitors again.
• Verify submitted proof through lidfly_get_leads: consent must include acceptance time, current version, immutable text, both document URLs, and the submitting page URL. Do not claim compliance from visual presence alone.

Progressive References

Read only the reference needed for the current task:

• The four visual guides above — required by stage for page creation/redesign, proportional to a focused correction.
• Managed pages — native widgets, page metadata and video blocks.
• Site chrome — inherited header/footer and design templates.
• Static sites — archive preview and full deployment.
• Commerce — products, imports, add-ons and storefront feeds.
• Shared galleries — albums, category examples, preview/apply, operation status and Bitrix inventory.
• SEO and feeds — GEO readiness, Organization, articles and RSS.
• MCP v3 compatibility methodology — mandatory compact workflow in initial chat activation and the legacy get_methodology projection.

Workspace

If work belongs to a business/client, resolve workspace_project_id before saving decisions, documents, or scheduled follow-ups.