---
name: crm-smm-n8n-publisher
description: Use this skill whenever discussing, designing, or scoping automated Telegram posting for Swipix SMM via n8n. Triggers include any mention of "автоматизируй постинг", "automate posting", "n8n для Telegram", "постинг-бот", "Telegram Bot API", "sendMessage/sendPhoto workflow", "автопостинг в канал", "n8n сценарий для SMM", "как запостить автоматически", "chat_id для канала", "bot token для постинга". Make sure to use this skill any time someone wants to move from manual Telegram posting to an automated n8n flow — it describes what needs to be built (nodes, credentials, scenario shape) WITHOUT touching n8n itself; actual creation and any activation is a separate, explicitly-approved step.
---

# Swipix SMM n8n Publisher — automation design (not execution)

Describes the n8n automation that WOULD post approved Swipix SMM content to
Telegram — what nodes and credentials are needed, and the scenario shape — based
on the existing CRM-reporting pattern already proven in n8n. **This skill is a
design/scoping document. It does not create, edit, or activate anything in n8n.**

## Hard boundary — read this first

- This skill never calls `n8n_query.py` in a write mode, never creates a
  workflow, never sets a credential, never activates/deactivates anything.
- Building the actual workflow is a separate task, gated the same way any
  external-send capability is gated in this project (`CLAUDE.md` go-live rule):
  **draft/design/local build → no ask needed; the moment the workflow could send
  a real message to the live Telegram channel (test send, activation, first
  scheduled run) → explicit operator confirmation required**, same as any other
  external-send gate.
- Per `reference/connectors.md` §9 / `crm-n8n-reporting` policy: existing n8n workflows
  are analyze-only, never touched. A NEW workflow for this specific posting
  scenario is allowed, but only with its own explicit authorization at build
  time — this skill existing does not itself authorize creating it.

## Current state (as of the 2026-08-25 recon)

Per `artifacts/smm/n8n-existing-assets.md` — nothing reusable exists yet:

- **No Telegram node** (`n8n-nodes-base.telegram`) anywhere in the 18-workflow
  workspace.
- **No `httpRequest` node hitting `api.telegram.org`** (raw Bot API).
- **No Telegram-shaped credential** among the 7 that exist (all Redis/Chatwoot/
  admin/Bearer — none for Telegram or any social channel).
- The only "telegram" mention in the workspace is an EXCLUSION filter inside the
  Chatwoot support-bot workflow (`tFwAj3d6edFY4kYQ`) that skips Telegram-typed
  Chatwoot *support* inbox conversations — unrelated to outbound SMM posting.
- **Conclusion**: this has to be built from scratch — token, credential, target
  chat_id, and the scenario itself all need to be created; there is nothing to
  repoint or extend.

## What needs to exist before this can go live

| Piece | What it is | Source |
|---|---|---|
| Bot token | A Telegram bot created via @BotFather, added as admin/poster to the target channel | Operator action — Claude cannot create a Telegram bot or accept its terms |
| n8n credential | The bot token stored as an n8n credential (httpHeaderAuth/httpBearerAuth, or the built-in Telegram credential type if used) | New credential in n8n, scoped to this workflow only |
| Target chat_id | The numeric/`@channelusername` id of the Swipix Telegram channel | Confirm with the operator which channel/bot this targets — do not assume the Chatwoot "Swipix Telegram" support inbox is the same channel; that's an inbound support surface, not the outbound SMM channel |
| The workflow itself | Trigger → build message → `sendMessage`/`sendPhoto`/`sendMediaGroup` | Built new, per the scenario shape below |

## Proposed scenario shape (design only)

Reuses the pattern already proven by the 4 CRM Slack reports
(`crm-n8n-reporting`: Daily Digest / Weekly Report / Pipeline Watchdog) —
"code node assembles the payload → `this.helpers.httpRequest` POST" — swapped
from a Slack Incoming Webhook to the Telegram Bot API.

1. **Trigger**: manual trigger for now (operator clicks "run" per approved
   post), or a `scheduleTrigger` reading a queue of approved posts once the
   content-plan → approval flow is stable. Start manual — don't design straight
   to full autonomy.
2. **Source of the post**: the approved post record (text + image URL/asset +
   target date) — coming from the content-plan artifact
   (`crm-smm-content-planner` output) once an operator has approved it. This
   workflow should read APPROVED content only, never draft content directly.
3. **Build message (Code node)**: assemble the final text (already through
   `crm-smm-voice-and-style` review) and resolve the image asset URL if the post
   has one.
4. **Send (httpRequest node or Telegram node)**:
   - Text-only: `POST https://api.telegram.org/bot<TOKEN>/sendMessage` with
     `chat_id` + `text` (+ `parse_mode` if formatting is used).
   - With one image: `sendPhoto` with `chat_id` + `photo` (URL) + `caption`.
   - Multi-image: `sendMediaGroup`.
5. **Confirmation/logging**: log the Telegram message_id returned, so re-runs
   don't silently double-post — mirrors the CRM reports' own dedup lessons
   (`crm-n8n-reporting`: message_id-based dedup, static-data patterns).

## Gotchas to carry over from the reporting workflows

From `crm-n8n-reporting` (same underlying n8n instance, same gotchas apply):

- Workflow `settings.timezone` must be `'UTC'` explicitly, or any scheduled
  trigger fires 4h late (instance default is `America/New_York`).
- Updating an ALREADY-ACTIVE workflow does not reload the running instance —
  must deactivate → activate to pick up changes. Not relevant while manual-only,
  becomes relevant the moment this gets a schedule trigger.
- Verify any test fire by checking the node's actual OUTPUT data (not just
  `status=success`) — a swallowed API error (e.g. bad chat_id, revoked token)
  can still report "success" at the workflow level.
- Never embed unrelated infra credentials (App-CH, etc.) into this workflow —
  keep it scoped to exactly the Telegram token it needs.

## Anti-patterns

- Creating the n8n workflow, credential, or a test send without a separate,
  explicit operator go-ahead for THIS specific automation.
- Reusing/repurposing an existing workflow or credential instead of building a
  new, narrowly-scoped one.
- Assuming the Chatwoot "Swipix Telegram" inbox's chat context is the same
  destination as the outbound SMM channel — confirm with the operator.
- Designing straight to a fully autonomous scheduled auto-post with no manual
  approval step in the loop.
- Posting draft (unapproved) content — the workflow should only ever read
  content that has already cleared `crm-smm-voice-and-style` review and operator
  sign-off.

## Definition of done for THIS skill's output

A design note (nodes, credentials, scenario steps, open questions like "which
chat_id") that a future, separately-authorized build step can execute — not a
working n8n workflow. If asked to "just build it," restate this boundary and ask
for the specific go-live authorization (bot token source, target chat_id
confirmation, manual-vs-scheduled decision) before touching n8n.

## Pair with

- `artifacts/smm/n8n-existing-assets.md` — the recon this skill is built on.
- `crm-n8n-reporting` — the proven code-node + httpRequest POST pattern and its
  gotchas, reused here for a different destination.
- `crm-smm-content-planner` / `crm-smm-voice-and-style` — the approval pipeline
  this workflow would read from; it must only ever post reviewed, approved
  content.
- `reference/connectors.md` §9 — n8n access/policy.
