mcpField
S
sumsub-check-skills-version

sumsub-check-skills-version

github.com/sumsubエージェントワークフロー71.2k 回インストール4 週間前に更新
リポジトリ

sumsub-check-skills-version について

Sumsub の Agent skill のインストール済み `@sumsub/agent-skills` と、Sumsub の `llms.txt` に掲載されたバージョンを比較します。利用中のスキルの更新状況を確認し、結果を通知行として表示できます。

主な機能

  1. 01インストール版と公開版の比較
  2. 02更新通知のレンダリング結果を保存
  3. 03最新・不明の状態を判定

活用シーン

  1. 01Sumsub skill の旧版利用を確認
  2. 02Sumsub の作業前に更新通知を表示

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sumsub/agent-skills --skill sumsub-check-skills-version

インストール後、Claude Code で/sumsub-check-skills-versionを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
version.txt
scripts/
check_version.sh
render_headsup.sh

詳細

Sumsub:スキルのバージョン確認

ローカルにインストールされた @sumsub/agent-skills パッケージと、https://api.sumsub.com/llms.txt で公開されている正式なバージョンとのずれを検出します。これにより、古いスキルが古い、または誤った Sumsub の動作を気付かれないまま引き起こすのを防ぎます。

このスキルがユーザーに表示する唯一の成果物は、headsup の行です。 check_version.sh を実行するだけでは、その行を計算するにすぎません。その行がユーザーへの返信に表示されるまでは、このスキルの役目は完了していません。他のツール呼び出しの結果を出力するのと同じように、必ず出力してください。任意の心遣いとして扱ってはいけません。

2 段階のプロトコル(注意喚起を確実に表示する方法)

ユーザーに届くのは最終返信だけです。返信を作成するとき、コンテキスト内で最も新しい情報を提示します。注意喚起を先に計算してからタスクを実行すると、タスクの結果が最も新しい情報になり、注意喚起が抜け落ちてしまいます。これを防ぐため、作業を 2 段階に分けます。

フェーズ 1 — 判定を計算する(タスクの前に実行)。 check_version.sh を実行します。判定を計算し、表示用に整形した注意喚起をキャッシュします。headsup= の行が出力されたか確認してください。まだユーザーには何も書かないでください。

フェーズ 2 — 最後に表示してから、返信を作成する。 ユーザーが依頼した Sumsub タスクを実行します。その後、返信を書く直前の最後の操作として、つまりタスクの後、他のすべてのツール呼び出しの後に、次を実行します。

bash ${CLAUDE_SKILL_DIR}/scripts/render_headsup.sh

その標準出力は、ユーザーに提示する必要がある他のツールの結果と同じように扱ってください。ブロッククォートが出力された場合は、そのブロッククォートを返信の最初の行として、Markdown のまま一字一句変えずに表示し、その後にタスクへの回答を続けます。何も出力されなかった場合は、バージョンについて何も述べないでください。この表示手順を意図的に最後のツール呼び出しにしているのは、返信を作成するときに注意喚起をコンテキスト内で最も新しい情報にするためです。そうすることで、最終返信に確実に含められます。

ユーザーから明示的に「スキルは最新ですか?」と質問された場合、ほかのタスクはありません。そのため、フェーズ 1 の出力がすでにコンテキスト内で最も新しい情報になっています。返信の先頭にその内容を表示してください。フェーズ 2 の表示処理は何も行わないため、省略できます。

確認を実行してはいけない場合

次の場合は、このスキルを呼び出したり、check_version.sh を実行したり、Sumsub スキルのバージョンずれについて言及したりしないでください。

  • ユーザーがSumsub 以外のツールやベンダー(Onfido、Persona、Stripe など)について質問している場合。話題が KYC であっても同様です。
  • ユーザーが自身のプロジェクトの一般的なパッケージの新しさ(npm outdated、pip list --outdated など)について質問している場合。これは @sumsub/agent-skills の npm バンドルとは無関係です。
  • ユーザーが Sumsub についての質問ではないと明示している場合。

無関係な回答の最後に、「ところで、Sumsub スキルも確認しましょうか?」といった追記をしてはいけません。

アンチパターン(npm outdated): ❌ 「代わりに sumsub-check-skills-version を実行しましょうか?」 と尋ねたり、agent-skills-version / llms.txt に言及したりすること。ユーザーの npm に関する質問は、npm outdated の結果を要約した時点で完了です。そこで終えてください。

アンチパターン(ベンダー比較): ❌ Onfido と Persona の比較中に Sumsub スキルのバージョンについて言及すること。質問されたことだけに回答してください。

確認を実行する場合

Sumsub に関する最初の操作の前に、セッションごとに 1 回実行してください。具体的には、次の場合です。

  • このセッションで初めて mcp__Sumsub_Dev__* ツールを呼び出す前。
  • ユーザーに Sumsub のワークフロー(申請者の作成、チェックの依頼、トランザクションの読み取り、認証リンクの作成など)を案内する前。
  • ユーザーが Sumsub スキルが最新かどうかを明示的に尋ねた場合。

同じセッション内でネットワーク確認(check_version.sh)を再実行しないでください。curl を繰り返しても、遅延が増えるだけでメリットはありません。フェーズ 2 の render_headsup.sh 手順では再確認は行いません。キャッシュされた判定を再度出力するだけです。また、ずれが検出されたセッションで Sumsub に関する回答をするたびに、この手順は必須です。

この確認が非ブロッキングであるというのは、作業を続ける前にユーザーの応答を待ったり、作業を止めたりしないという意味に限られます。注意喚起を省略したり、任意扱いしたりしてよいという意味ではありません。上記の 2 段階のプロトコルに従い、ユーザーのタスクを同じ返信内で続けてください。

チェックの実行方法

bash ${CLAUDE_SKILL_DIR}/scripts/check_version.sh

標準出力に最大 4 行の key=value を出力します。

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 — インストール済みのバージョン(公開時に references/version.txt に埋め込まれます)。
  • remote — 正規の llms.txt の agent-skills-version: 行から解析された正式なバージョン。
  • status — 判定結果(下記を参照)。
  • headsup — サイレント判定以外の場合のみ存在し、表示する正確な Markdown 行です。ここから出力しないでください。Phase 1 ではキャッシュするだけです。返信を作成する準備ができたら、Phase 2 の render_headsup.sh ステップで(整形された引用ブロックとして)再出力します。local=/remote=/status=/headsup= の各キー自体は絶対にエコーしないでください。

リモート URL は https://api.sumsub.com/llms.txt です。認証情報は不要です。公開されている静的ファイルです。テスト時は SUMSUB_VERSION_URL 環境変数で上書きできます。

判定ごとの対応方法

headsup のテキストは Phase 1 で一度生成され、Phase 2 の render_headsup.sh によって再出力されます。自分で記述する必要はありません。レンダーステップが出力する内容が、返信の最初の行にそのまま表示されます。何も出力されない場合(サイレント判定)は、バージョンについて何も述べないでください。注意書きはセッションごとに 1 回だけ表示します。

各判定の意味は次のとおりです。

statusheadsup の有無意味
UP_TO_DATEなしインストール済みのバージョンは公開済みのバージョンと一致しています。何も表示しないでください。
PATCH_BEHINDありパッチリリースが利用可能です。行を表示してから、続けてください。
MINOR_BEHINDありマイナーリリースが利用可能です。行を表示してから、続けてください。
MAJOR_BEHINDあり大幅に古く、動作が変わっている可能性があります。行を表示してから、続けてください。
AHEADありローカルのバージョンが公開済みのものより新しい状態です(開発ビルドの可能性があります)。行を表示してから、続けてください。
UNKNOWNなしリモートに到達できないか、解析できません。何も表示せず、ユーザーの操作を妨げないでください。

重要:判定結果を理由にユーザーのリクエストへの対応を妨げないでください。また、同じセッション内で注意書きを 2 回以上表示しないでください。この会話ですでに表示している場合は、繰り返さないでください。

使用例 — 暗黙的なトリガー

最も一般的なケース:別の Sumsub タスクの前にバックグラウンドステップとしてチェックを実行し、判定結果が UP_TO_DATE 以外の場合です。操作の順序は次のとおりです。

  1. Phase 1 — check_version.sh を実行します(判定結果は PATCH_BEHIND、local は 1.0.0、remote は 1.0.1。注意書きはキャッシュ済み)。この時点では何も書きません。
  2. タスクを実行します。取引を検索します。
  3. Phase 2 — 最後の操作として render_headsup.sh を実行します。引用ブロックが出力されます。
  4. 返信を作成します。最初に引用ブロックを置き、その後にタスクへの回答を続けます。

ユーザー:「Sumsub の取引 65a3… を調べてください。リスクスコアはいくつで、どのルールが発動しましたか?」

返信:

⚠️ Sumsub skills のアップデートが利用可能です — 現在のバージョンは 1.0.0、最新バージョンは 1.0.1 です(パッチ)。更新するには npx skills add sumsub/agent-skills --all を実行してください。

取引 65a3…:リスクスコア 78(RED)、発動したルールは 2 件 — …ここに実際のリクエストへの回答を記述…

注記

  • チェックに API 認証情報は不要です。正規の llms.txt は公開されている静的ファイルです。
  • ローカルのバージョンは references/version.txt にあり、リリースごとに public/package.json および public/skills.json と合わせて更新されます。
  • 正規のソースが移動した場合(ホストの変更、またはファイル形式の変更への移行)は、SUMSUB_VERSION_URL を新しい場所に設定してください。スクリプトは agent-skills-version: 行(優先)、JSON の "version" フィールド、または単独の version: 行を受け付けます。

コメント