sumsub/agent-skills

sumsub-check-skills-version

Verify that the locally installed Sumsub agent-skills package is compatible with the published version before doing any Sumsub work.

Ver código-fonte

Como usar

  1. Copie o comando e verifique o pacote antes de instalar no seu ambiente de agente.
  2. Consulte no original as ferramentas, credenciais e ambientes necessários.
  3. Descreva os dados de entrada e a entrega esperada; confira a saída com as fontes.
npx skills add https://github.com/sumsub/agent-skills --skill sumsub-check-skills-version

Antes de começar

  • A instalação não inclui assinatura de modelo, franquia API ou acesso aos seus arquivos.
  • Estrelas e instalações indicam atividade, não um teste independente de qualidade ou segurança.
Documento original do Skill

Renderizado do repositório de origem, preservando títulos, exemplos, código, tabelas, links e imagens.

Sumsub: Check Skills Version

Detects version drift between the locally installed @sumsub/agent-skills package and the canonical version published at https://api.sumsub.com/llms.txt, so that out-of-date skills don't silently produce stale or incorrect Sumsub behavior.

This skill's one user-visible deliverable is the `headsup` line. Running check_version.sh only computes it; the skill has not done its job until that line appears in your reply to the user. Treat emitting it exactly like emitting the result of any other tool call — not as an optional courtesy.

Two-phase protocol (this is how the heads-up actually lands)

Only your FINAL reply reaches the user, and you surface what is freshest in your context when you compose it. If you compute the heads-up first and then do a task, the task result becomes the freshest thing and the heads-up gets dropped. To prevent that, split the work into two phases:

Phase 1 — compute the verdict (before the task). Run check_version.sh. It computes the verdict and caches the rendered heads-up. Note whether a headsup= line was printed; do not write anything to the user yet.

Phase 2 — render LAST, then compose. Carry out the user's actual Sumsub task. Then, as your final action before writing the reply — after the task, after every other tool call — run:

bash
bash ${CLAUDE_SKILL_DIR}/scripts/render_headsup.sh

Treat its stdout exactly like the result of any tool you must surface: if it prints a blockquote, that blockquote is the first line of your reply, verbatim, rendered as markdown; then the task answer follows. If it prints nothing, say nothing about the version. The render step is deliberately your last tool call so the heads-up is the freshest thing in context when you compose — that is what makes it survive into the final reply.

For an explicit "are my skills up to date?" question there is no other task, so Phase 1 already leaves the heads-up as the freshest output — just lead your reply with it; the Phase-2 render is a no-op you can skip.

When NOT to run the check

Do not invoke this skill, run check_version.sh, or mention Sumsub-skills version drift when:

  • The user asks about non-Sumsub tools or vendors (Onfido, Persona, Stripe, etc.) — even if the topic is KYC.
  • The user asks about generic package freshness (npm outdated, pip list --outdated, etc.) for their own project — that is unrelated to the @sumsub/agent-skills npm bundle.
  • The user explicitly says they are not asking about Sumsub.

Never append a "by the way, want me to check your Sumsub skills?" sidenote on unrelated answers.

Anti-pattern (npm outdated): ❌ "Want me to run sumsub-check-skills-version instead?" or mentioning agent-skills-version / llms.txt — the user's npm question is complete once you've summarized npm outdated. Stop there.

Anti-pattern (vendor comparison): ❌ Mentioning Sumsub skills version while comparing Onfido vs Persona. Answer only what was asked.

When to run the check

Run it once per session, before the first Sumsub-related action. Concretely:

  • Before calling any mcp__Sumsub_Dev__* tool for the first time in this session.
  • Before walking the user through any Sumsub workflow (creating an applicant, requesting a check, reading a transaction, building a verification link, etc.).
  • When the user explicitly asks whether their Sumsub skills are up to date.

Do not re-run the network check (check_version.sh) within the same session — repeated curls add latency without value. The Phase-2 render_headsup.sh step does not re-check; it only re-emits the cached verdict, and it is mandatory every time you produce a Sumsub answer in a session that found drift.

The check is non-blocking only in the sense that you do not pause or wait for the user before continuing — it does not mean the heads-up is optional or skippable. Follow the two-phase protocol above, then proceed with the user's task in the same reply.

How to run the check

bash
bash ${CLAUDE_SKILL_DIR}/scripts/check_version.sh

It prints up to four key=value lines on stdout:

local=1.0.1
remote=1.0.2
status=PATCH_BEHIND
headsup=> ⚠️ **Sumsub skills update available** — you're on **1.0.1**, latest is **1.0.2** (patch). Run `npx skills add sumsub/agent-skills --all` to update.
  • local — installed version (baked into references/version.txt at publish time).
  • remote — canonical version parsed from the agent-skills-version: line of the canonical llms.txt.
  • status — the verdict (see below).
  • headsup — present only for non-silent verdicts; the exact markdown line to surface. Don't emit it from here — Phase 1 just caches it; the Phase-2 render_headsup.sh step re-prints it (as a clean blockquote) when you're ready to compose. Never echo the local=/remote=/status=/headsup= keys themselves.

The remote URL is https://api.sumsub.com/llms.txt. No credentials needed — it's a public static file. Override with the SUMSUB_VERSION_URL environment variable for testing.

How to handle each verdict

The headsup text is produced once, by Phase 1, and re-emitted by Phase 2's render_headsup.sh; you never hand-write it. Whatever the render step prints becomes the first line of your reply, verbatim. If it prints nothing (silent verdict), say nothing about the version. The heads-up is shown once per session.

For reference, what each verdict means:

statusheadsup present?Meaning
UP_TO_DATEnoInstalled version matches the published one — stay silent.
PATCH_BEHINDyesA patch release is available — surface the line, then proceed.
MINOR_BEHINDyesA minor release is available — surface the line, then proceed.
MAJOR_BEHINDyesSignificantly behind; behavior may have changed — surface the line, then proceed.
AHEADyesLocal is newer than published (likely a dev build) — surface the line, then proceed.
UNKNOWNnoRemote unreachable or unparseable — stay silent, never block the user.

Important: never block the user's request because of the verdict, and never show the heads-up more than once in the same session — if you've already shown it in this conversation, don't repeat it.

Worked example — implicit trigger

The most common case: the check runs as a background step before some other Sumsub task, verdict is non-UP_TO_DATE. Order of operations:

  1. Phase 1 — run check_version.sh (verdict PATCH_BEHIND, local 1.0.0, remote 1.0.1; heads-up cached). Write nothing yet.
  2. Do the task — look up the transaction.
  3. Phase 2 — run render_headsup.sh as your last action; it prints the blockquote.
  4. Compose the reply: blockquote first, task answer after.

User: "look up sumsub transaction 65a3… — what risk score and which rules fired?"

Your reply:

⚠️ Sumsub skills update available — you're on 1.0.0, latest is 1.0.1 (patch). Run npx skills add sumsub/agent-skills --all to update.

Transaction 65a3…: risk score 78 (RED), 2 rules fired — …answer the actual request here…

Notes

  • The check needs no API credentials — the canonical llms.txt is a public static file.
  • The local version lives in references/version.txt and is bumped together with public/package.json and public/skills.json on every release.
  • If the canonical source moves (host change, or migration to a different file shape), set SUMSUB_VERSION_URL to the new location; the script accepts an agent-skills-version: line (preferred), a JSON "version" field, or a bare version: line.
do mesmo repositório

Mais Skills

Todos os Skills
sumsub
Comunidade

sumsub-analyze-regulation

Analyze a regulation document (PDF or text) and produce a Sumsub configuration plan — mapping regulatory requirements to Sumsub entities (levels, questionnaires, PoA presets, TM rules, workflows, AML resolution rules). TRIGGER when the user provides a regulation PDF, legal act, or compliance requirement document and wants to know what to configure in Sumsub. Acts as the entry point before invoking sumsub-create-level, sumsub-create-questionnaire, sumsub-create-poa-preset, sumsub-create-workflow,

Instalações / 1h
3
GitHub Stars
7
Atualizado
30 de out.
sumsub
Comunidade

sumsub-api-auth

Authenticate to the Sumsub API with an App Token + secret key (HMAC-SHA256 request signing). TRIGGER when the user asks to "call / sign / authenticate Sumsub API requests", debugs 401 Unauthorized / signature errors against api.sumsub.com, or needs a working request example with X-App-Token / X-App-Access-Sig / X-App-Access-Ts headers. SKIP only when a more specific skill in this repo (questionnaire/level/workflow/POA-preset/generic) already covers the user's actual task — those skills sign requ

Instalações / 1h
3
GitHub Stars
7
Atualizado
30 de out.
sumsub
Comunidade

sumsub-api-generic

Catch-all fallback for any Sumsub API task that does NOT match a more specific skill (e.g. create-sumsub-level, sumsub-create-questionnaire, sumsub-api-auth). TRIGGER when the user wants to call, inspect, or debug a Sumsub API endpoint not otherwise covered — fetching applicants, listing levels, reviewing AML hits, exporting data, generating SDK tokens, anything against api.sumsub.com. The procedure — locate the right endpoint in the OpenAPI schema, read its request/response shape, build the pay

Instalações / 1h
3
GitHub Stars
7
Atualizado
30 de out.
sumsub
Comunidade

sumsub-check-databases

Discover the Databases (check-sources) Sumsub offers for a country, whether each is enabled for the tenant, and how database / non-document (eKYC) verification fits into a verification level. Use WHEN a user asks which database / non-document check-sources are available for a country, whether they're enabled, or how to add database validation / non-doc identity / non-doc address verification to a level. Also called by sumsub-create-level before placing those sources. Do NOT use for document-only

Instalações / 1h
3
GitHub Stars
7
Atualizado
30 de out.