Bitrix24 Skill

Integrate AI agents with Bitrix24 REST API to automate CRM, tasks, chats, event processing, auth selection, and API error troubleshooting.

Security Scan

The skill's code, docs, and runtime instructions are coherent with its stated purpose (Bitrix24 REST integration); it requests no unrelated credentials and uses only local files and Bitrix endpoints.

Purpose & Capability

Name/description (Bitrix24 REST integrations) matches the included code, CLI scripts, and many Bitrix-specific reference files. All env vars and files referenced in the README/SKILL.md (webhook code, OAuth tokens, B24_* vars) are directly relevant to Bitrix API integration.

Instruction Scope

SKILL.md limits agent actions to Bitrix references and the included scripts, prescribes allowlists/confirm flags, and explicitly forbids exposing secrets. It does not instruct reading unrelated system files or transmitting data to unrelated external endpoints.

Install Mechanism

There is no install spec (scripts are shipped as files). No network downloads, package installs, or obscure URLs are used by the skill itself. This is lower-risk than an arbitrary remote installer.

Credentials

The registry metadata lists no required env vars, but README and SKILL.md show many effective environment variables (B24_DOMAIN, B24_AUTH_MODE, B24_ACCESS_TOKEN, B24_CLIENT_SECRET, etc.). Those variables are appropriate for Bitrix integration, but the metadata omission is a mild inconsistency — the skill expects secrets/tokens to be present at runtime.

Persistence & Privilege

Scripts legitimately read/write local state (rate limiter, retry state, DLQ, plan files) and may create files when running. always:false and no elevated privileges are requested. Persisted files can contain event payloads and retry metadata; users should be aware of on-disk storage location and access controls.

Assessment

This skill appears to implement what it claims (Bitrix24 REST integration) and uses only Bitrix-relevant environment variables and local files. Before installing: (1) Review and store Bitrix tokens (OAuth/webhook) in a dedicated secrets store or env scoped to the skill; avoid placing other service credentials in the same environment. (2) Run the scripts against a test portal first (use B24_RUN_INTEGRATION or a sandbox) and enable the two-phase/plan-only mode (B24_REQUIRE_PLAN / --plan-only) to avoid accidental writes. (3) Note the scripts write local state (rate limiter, retry state, DLQ); decide where those files will live and who can read them. (4) If you need a policy-level check, ask the publisher to declare required env vars in the registry metadata (current manifest lists none despite many documented env variables). (5) If you are not comfortable granting access to Bitrix tokens, do not enable this skill or provide only least-privilege tokens scoped to the operations you intend to allow.

Bitrix24 Agent (Lean + Reliable)

Use this skill to deliver correct Bitrix24 integrations with minimal token usage.

Default Mode: Lean

Apply these limits unless the user asks for deep detail:

• Load at most 2 reference files before first actionable step.
• Start from references/packs.md.
• Then open only one target file: references/catalog-<pack>.md.
• Open references/chains-<pack>.md only if user asks for workflow/chain.
• Open references/bitrix24.md only for auth architecture, limits, events reliability, or unknown errors.

Response format limits:

• Use concise output (goal + next action + one command).
• Do not retell documentation.
• Do not dump large JSON unless explicitly requested.
• Avoid repeating already provided guidance; return only delta.

Routing Workflow

1. Determine intent:

• method call,
• troubleshooting,
• architecture decision,
• event/reliability setup.

Term normalization (product vocabulary):

• "collabs", "workgroups", "projects", "social network groups" -> collab (and boards for scrum).
• "Copilot", "CoPilot", "BitrixGPT", "AI prompts" -> platform (ai.*).
• "open lines", "contact center connectors", "line connectors" -> comms (imopenlines.*, imconnector.*).
• "feed", "live feed", "news feed" -> collab (log.*).
• "sites", "landing pages", "landing" -> sites (landing.*).
• "booking", "calendar", "work time", "time tracking" -> services (booking.*, calendar.*, timeman.*).
• "orders", "payments", "catalog", "products" -> commerce (sale.*, catalog.*).
• "consents", "consent", "e-signature", "sign" -> compliance (userconsent.*, sign.*).

2. Choose auth quickly:

• one portal/internal: incoming webhook.
• app/multi-portal/lifecycle features: OAuth.

3. Select minimal packs:

• default core.
• add only required packs: comms, automation, collab, content, boards, commerce, services, platform, sites, compliance, diagnostics.

4. Execute with guardrails:

• prefer scripts/bitrix24_client.py and scripts/offline_sync_worker.py,
• enforce allowlist + --confirm-write / --confirm-destructive,
• keep writes idempotent when possible.

5. Escalate to deep reference only on trigger:

• WRONG_AUTH_TYPE, insufficient_scope, QUERY_LIMIT_EXCEEDED, expired_token,
• offline event loss concerns,
• OAuth refresh race or tenant isolation issues.

Quality Guardrails

• Never expose webhook/OAuth secrets.
• Scope and permissions must be least-privilege.
• No nested batch.
• Online events are not guaranteed delivery; use offline flow for no-loss processing.
• Prefer REST 3.0 where compatible; fallback to v2 where needed.

Reference Loading Map

1. references/packs.md for pack and loading strategy.
2. references/catalog-<pack>.md for method shortlist.
3. references/chains-<pack>.md for implementation chains.
4. references/bitrix24.md only when deeper protocol detail is required.

Useful search shortcuts:

rg -n "^# Catalog|^# Chains" references/catalog-*.md references/chains-*.md
rg -n "WRONG_AUTH_TYPE|insufficient_scope|QUERY_LIMIT_EXCEEDED|expired_token" references/bitrix24.md
rg -n "offline|event\\.bind|event\\.offline|application_token" references/bitrix24.md

Scripts

• scripts/bitrix24_client.py: method calls, packs, allowlist, confirmations, audit.
• scripts/offline_sync_worker.py: offline queue processing with retries and DLQ.