一键导入
add-telegram
Add Telegram channel integration via Chat SDK.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Add Telegram channel integration via Chat SDK.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
单后端闭环测试执行器(stack-agnostic / project-agnostic)。当一个后端 feature 收尾、需要补 superpowers/spec-kit 开发期 TDD 与契约测试覆盖不了的后端结构性测试缺口时使用:先读项目栈 (package.json / pyproject.toml / go.mod / pom.xml 等)按栈实例化对应工具,再针对实际命中的缺口 RED→GREEN 补测并固化为回归。覆盖四类后端结构性缺口——真库数据层/迁移/事务/约束、鉴权与越权 (BOLA/BFLA)、并发/竞态/限频原子性、韧性/故障注入(重试/超时/降级)。触发词:单后端测试 / 后端缺口补测 / backend testing / 真库测试 / 越权测试 / 并发测试 / 韧性测试 / 后端集成测试 / 后端回归补测。遵循 testing-system-blueprint 蓝本(风险分级 / 可追溯 / 发布门 / 三层节奏),受自愈护栏约束(只写 tests/、断言 不可弱化、禁伪造修复、有界重试、产 PR 人审)。被 test-routing-advisor 在判定"单后端"时调用,也可直接触发。
单前端闭环测试执行器(stack-agnostic / project-agnostic)。当一个前端 feature 收尾、需要补 superpowers/spec-kit 开发期覆盖不了的前端结构性测试缺口时使用:先读项目栈(package.json 或 等价清单)按栈实例化对应成熟工具,再针对实际命中的层 RED→GREEN 补测并固化为回归。与 backend-testing 的根本区别——后端缺口无现成工具需自建("施工队"),前端成熟工具齐全,本 skill 不重新发明工具,只做 三件事:装 + 配 + 把项目的视觉/交互契约翻译成这些工具能跑的断言/规则("装配工 + 监理")。覆盖五层 前端结构性缺口——编译期 lint 门、L0/L1 单测(含 getComputedStyle 断言 token/深色/涨跌色)、a11y + 跨浏览器/响应式、前后端契约 mock、视觉回归。触发词:单前端测试 / 前端缺口补测 / frontend testing / 视觉回归 / a11y 测试 / 跨浏览器测试 / 响应式测试 / token 断言 / 前后端契约 mock / 前端回归补测。 常见地基为零:很多前端 [FE] 任务出参验证只写"手测"、测试运行器/RTL/Playwright 可能完全没装—— 本 skill 第一动作是"识栈→若无测试运行器先立地基",不假设 L0/L1 已就绪。遵循 testing-system-blueprint 蓝本(风险分级 / 可追溯 / 发布门 / 三层节奏),受自愈护栏约束(只写测试不改产品码、断言不可弱化、禁伪造 修复、有界重试、产 PR 人审)。被 test-routing-advisor 在判定"单前端"时调用,也可直接触发。
完整功能链路测试执行器(stack-agnostic / project-agnostic)。当多个 feature 已陆续收尾、 某条**跨多 feature 的端到端旅程(A→B→C)首次贯通**、需要为这条关键旅程织一张端到端安全网时使用: 与前三格根本不同——本格的被测对象**不是给定的,要先从系统结构里【挖掘】出来**。先从三源 (静态代码图 + 运行时 trace + spec 契约)挖出一份**跨多 feature 的通路清单(path inventory)**, 挑 P0 关键旅程,再端到端验证、固化成安全网。覆盖跨多 feature 且含非 UI 跳步(定时任务 / 异步 / 跨通道)的 完整链路;单 feature 内单切片归"局部前后端"第三格,不在这里。两个最独特点:① 被测对象要先被挖掘出来; ② 它是**安全网层**——少而精只盖 P0;**若 bug 首次在这层被发现,说明下层(单后端/单前端/局部前后端)漏测了, 应回补下层**。六步闭环:挖通路+选 P0 → 全系统编排+只 stub 外部边界 → 条件命中 → 两层落地 → RED→GREEN(禁 sleep, fake clock/手动触发定时任务/poll-retry 等最终态)→ 归档+拆栈+PR 人审。触发词:完整功能链路 / 端到端旅程 / 跨 feature 测试 / 通路挖掘 / path inventory / 关键旅程 / 安全网 / journey 测试 / full chain testing / e2e journey / 链路贯通测试。天然要最多代码才能跑、是最后才能执行的一格;代码未落地时只能"挖候选通路 + 写 RED E2E"不能跑。遵循 testing-system-blueprint 蓝本(风险分级 / 可追溯 / 发布门 / 三层节奏),受自愈护栏约束 (只写测试不改产品码、断言不可弱化、禁伪造修复、有界重试、产 PR 人审,发现真 bug 回交 superpowers TDD)。 被 test-routing-advisor 判定"完整功能链路"时调用,也可直接触发。兄弟:backend-testing(单后端)/ frontend-testing(单前端)/ fullstack-slice-testing(局部前后端)。
局部前后端接缝测试执行器(stack-agnostic / project-agnostic)。当一个 feature 的前后端两侧都收尾、 需要把"单前端阶段拿来 mock 的那份假设"与"单后端的真实行为"做一次对账时使用:在**单 feature 内**, 让消费者侧(前端/调用方)↔ 提供者侧(后端/被调方)的**单条切片**以真实形态对接、停止 mock,验证接缝。 它是 backend-testing / frontend-testing 的对账——单前端 mock 撒的谎(字段/类型/状态码/错误体/鉴权/时序) 在这里穿帮。**仅限单 feature 内单切片,不跨 feature**(跨多 feature 旅程属"完整功能链路"第四格)。覆盖四个 能力缺口——环境编排(让两侧+依赖以真实形态可复现一键起来)、契约真实性(消费者 mock↔提供者规格比对)、 接缝粘合(凭证透传/序列化往返/错误映射/头部跨域)、真实时序(条件命中:仅切片含流式/实时/异步才测)。 与前两格的根本区别——新难点是"起真栈(环境编排)"而非写断言:前两格能把另一侧 mock 掉,这格不能, 必须真把两侧拉活。先读两侧栈清单按栈实例化编排/契约工具,再 RED→GREEN 补接缝断言并固化为回归。 触发词:局部前后端测试 / 前后端接缝测试 / 切片对账 / 真前后端对接 / 起真栈集成 / 契约漂移验证 / 消费者契约对账 / fullstack slice testing / seam testing / contract drift / 前后端集成补测。 遵循 testing-system-blueprint 蓝本(风险分级 / 可追溯 / 发布门 / 三层节奏),受自愈护栏约束(只写测试不改 产品码、断言不可弱化、禁伪造修复、有界重试、产 PR 人审)。被 test-routing-advisor 判定"局部前后端"时调用, 也可直接触发。兄弟:backend-testing(单后端)/ frontend-testing(单前端)。
测试路由顾问:在某个 feature 的所有 task 完成(全绿)、进入收尾阶段时,先通篇扫描该 feature 的所有 task/文件,把它们归入一个「开放可增减」的场景类别集合(单后端 / 单前端 / 局部前后端 / 完整功能链路 / 可增类…),判定本 feature 整体属于哪一类,再把每个测试缺口 「路由到对应类别的执行器 skill」去闭环补测。它是 stack-agnostic 的检测器 / 路由器: 本 skill 只做「判类 + 标缺口 + 路由」,不写死任何单栈工具为答案——具体工具由被路由到的 类别 skill 按栈(读 package.json / pyproject / go.mod 等判栈后)实例化。当前路由去向: 单后端 → `backend-testing` skill;单前端 → `frontend-testing` skill;局部前后端 → `fullstack-slice-testing` skill;完整功能链路 → `full-chain-testing` skill(gstack `/qa` 折叠进它的 UI 可走段,非依赖)。判类、缺口标注、 三层节奏、可追溯、发布门等方法标准统一遵循 `testing-system-blueprint` skill。判类信号来自 任务范围标签、依赖图、跨模块契约声明、验收标准 AC,因此与具体项目无关。它的杀手锏:从依赖图 推导出「完成本 feature 后某条完整功能链路(A→B→C)首次贯通」并主动提示「这条链路现在可以 端到端测了」——这是人最容易忘的事。 当某个 feature 正在收尾、用户说出类似「这个 feature 该测什么 / 收尾测试 / 测试路由 / feature 完成后测什么 / 该用什么测试 / run test routing / what should I test now / which testing tool should I use / what tests does this feature need」时务必使用。 它只做建议与路由——绝不编写、运行或强制任何测试;测试是否真的写了、过了、断言有没有被弱化, 靠确定性的 CI 闸和护栏化自愈 agent 来保证。
测试体系蓝本(testing blueprint / test strategy)——一份 stack-agnostic、project-agnostic 的"测试作为体系"方法骨架。当需要确定测试策略、做风险分级(P0–P3)、建立需求↔测试可追溯、 规划三层测试节奏、设计闭环补测、定义发布 go/no-go 门(release gate)时遵循本蓝本。 触发词:测试体系蓝本、测试策略、测试策略蓝本、风险分级、可追溯、需求追溯、发布门、 闭环补测、testing blueprint、test strategy、test pyramid、release gate。 它被 test-routing-advisor(路由器)和各类别测试 skill(如 backend-testing)共同遵循。 本蓝本只给"方法与标准",不写死任何语言/框架/工具,不执行测试也不强制门禁—— 能力是通用原语,工具由调用方读项目栈后实例化;门禁的强制由 CI/hook/pre-commit 承担。
| name | add-telegram |
| description | Add Telegram channel integration via Chat SDK. |
Adds Telegram bot support via the Chat SDK bridge.
NanoClaw doesn't ship channels in trunk. This skill copies the Telegram adapter, its formatting/pairing helpers, their tests, and the pair-telegram setup step in from the channels branch.
Skip to Credentials if all of these are already in place:
src/channels/telegram.ts, telegram-pairing.ts, telegram-markdown-sanitize.ts (and their .test.ts siblings) all existsrc/channels/index.ts contains import './telegram.js';setup/pair-telegram.ts exists and setup/index.ts's STEPS map contains 'pair-telegram':@chat-adapter/telegram is listed in package.json dependenciesOtherwise continue. Every step below is safe to re-run.
git fetch origin channels
git show origin/channels:src/channels/telegram.ts > src/channels/telegram.ts
git show origin/channels:src/channels/telegram-pairing.ts > src/channels/telegram-pairing.ts
git show origin/channels:src/channels/telegram-pairing.test.ts > src/channels/telegram-pairing.test.ts
git show origin/channels:src/channels/telegram-markdown-sanitize.ts > src/channels/telegram-markdown-sanitize.ts
git show origin/channels:src/channels/telegram-markdown-sanitize.test.ts > src/channels/telegram-markdown-sanitize.test.ts
git show origin/channels:setup/pair-telegram.ts > setup/pair-telegram.ts
Append to src/channels/index.ts (skip if already present):
import './telegram.js';
In setup/index.ts, add this entry to the STEPS map (right after the register line is fine; skip if already present):
'pair-telegram': () => import('./pair-telegram.js'),
pnpm install @chat-adapter/telegram@4.27.0
pnpm run build
@BotFather/newbot and follow the prompts:
123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11)Important for group chats: By default, Telegram bots only see @mentions and commands in groups. To let the bot see all messages:
@BotFather > /mybots > select your botAdd to .env:
TELEGRAM_BOT_TOKEN=your-bot-token
Sync to container: mkdir -p data/env && cp .env data/env/env
If you're in the middle of /setup, return to the setup flow now.
Otherwise, run /manage-channels to wire this channel to an agent group.
telegrampnpm exec tsx setup/index.ts --step pair-telegram -- --intent <main|wire-to:folder|new-agent:folder>, show the user the 4-digit CODE from the PAIR_TELEGRAM_ISSUED block (follow the REMINDER_TO_ASSISTANT line in that block), and tell them to send just the 4 digits as a message from the chat they want to register (DM the bot for main, post in the group otherwise). In groups with Group Privacy ON, prefix with the bot handle: @<botname> CODE. Wrong guesses invalidate the code — if a PAIR_TELEGRAM_ATTEMPT block arrives with a mismatched RECEIVED_CODE, a PAIR_TELEGRAM_NEW_CODE block will follow automatically (up to 5 regenerations); show the new code. On PAIR_TELEGRAM STATUS=failed ERROR=max-regenerations-exceeded, ask the user if they want to try again and re-invoke the step — each invocation starts a fresh 5-attempt batch. Success emits PAIR_TELEGRAM STATUS=success with PLATFORM_ID, IS_GROUP, and ADMIN_USER_ID. The service must be running for this to work (the polling adapter is what observes the code).