use-telegram-serverless 是面向 Telegram Serverless（tgcloud）平台的开发技能，目标是在 Telegram 云端构建、发布和扩展简单的或全栈的 Telegram 机器人与 Mini App，不需要自行管理服务器。该技能基于 Telegram Serverless（tgcloud）提供的能力：即时 V8 JavaScript（ES Module）隔离环境、内置 SQLite 数据库（sdk/db）、原生 Bot API 与 HTTP 客户端（sdk/api、sdk/fetch）、经过认证的 Mini App RPC 端点（Telegram.WebApp.Serverless.call），以及内置静态托管（tgcloud.ai）。
适用场景 该技能适用于任何 Telegram Serverless 项目，包括从快速单处理器机器人、轻量 Mini App 到使用 Telegram Serverless、tgcloud、@tgcloud/cli、@tgcloud/bot、tgcloud/ 或 tgcloud.jsonc 扩展的全栈应用。也适用于编写或更新机器人处理器（tgcloud/handlers/.js）、认证的 Mini App 端点（tgcloud/endpoints/.js）、共享 ES 模块（tgcloud/lib/**/*.js）、SQLite 模式与查询（tgcloud/schema.js）以及 Mini App 静态托管（https://app<app_id>.tgcloud.ai/）。功能范围涵盖简单的 /start 命令、内联键盘、出站 sdk/fetch 调用，到对话状态机、64 字节回调路由、Telegram Stars（XTR）支付、内联查询、渐进式草稿回复（sendMessageDraft）以及 Telegram.WebApp.Serverless.call 前端集成。该技能还用于安全云操作与调试，例如代码审查、安全审计、零停机 SQLite 模式迁移（tgcloud migrate）、远程沙箱测试（tgcloud run）、实时部署（tgcloud push）、webhook 同步以及本地与云端冲突恢复。
不适用场景 当 Telegram 机器人被有意托管在 VPS、Docker 容器、Cloudflare Workers、AWS Lambda、Vercel 或其他非 Telegram 运行时（如使用 grammY、Telegraf 或 aiogram 等框架）时，不应使用该技能；除非用户明确要求，否则不要把外部机器人迁移到 Telegram Serverless。当任务只涉及与 Telegram Mini App SDK 集成或 tgcloud.jsonc 静态托管无关的通用前端样式时同样不适用。如果所需功能依赖 Telegram Serverless V8 隔离运行时不支持的能力（例如原始 TCP 套接字、后台 cron 守护进程、原生 Node.js C++ 插件或 SQLite 之外的文件系统持久化），应先说明平台限制，再提出变通方案或外部架构。
工作流程 技能按用户授权意图选择路线，并只加载最少必要参考：解释、审计或审查；搭建、初始化或链接项目（npm create @tgcloud/bot、tgcloud init、tgcloud add、tgcloud login）；构建或修改机器人；构建或修改 Mini App；设计或演进数据库；验证与测试；部署变更；诊断、同步或升级；以及端到端全栈构建（数据库模式 → 共享 lib/ → 机器人处理器 → Mini App 端点与前端 → 验证）。对于清晰明确的意图，直接宣布所选路线并执行；对于存在真实架构取舍的问题（例如机器人内联键盘流程与完整 Mini App 的选择、无状态处理器与持久化 SQLite 模式设计、安全增量模式演进与破坏性 .deprecated() 删除或手动类型迁移、以及在没有运行时 process.env 的情况下如何处理第三方 API 密钥），应先提出简洁高价值的问题（一次一个，并给出推荐默认值）以对齐设计。
执行与安全 执行时先建立上下文与范围，识别目标目录、机器人或应用标识（不暴露密钥）、已有未提交更改以及被授权的操作（仅离线、远程运行、push 或迁移）。实现时保持后端导入严格位于 tgcloud/ 内，使用相对 .js 路径（../schema.js、../lib/util.js）和内置 SDK 说明符（sdk、sdk/db、sdk/api、sdk/fetch）。在代码同时演进已有线上数据库时，应按仅模式 push → 授权迁移 → 消费方处理器与端点 push 的顺序执行。离线检查优先（git diff、tgcloud diff、Node 语法检查 node --check、静态构建验证），任何具有远程副作用的命令（tgcloud run、tgcloud push、tgcloud migrate、tgcloud webhook sync、tgcloud pull）都需要用户明确确认。 安全约束包括：tgcloud run 属于远程执行而非本地单元测试，会上传本地 tgcloud/ 模块并在云端针对实时数据库、实时 Bot API 和实时外部 HTTP 端点执行；push、migrate、run 和 webhook 同步各自需要独立授权，不带路径参数的全量 tgcloud push 会镜像本地 tgcloud/ 并删除远端不存在的模块；在执行 tgcloud pull、tgcloud reset 或 tgcloud upgrade 前应检查未提交的本地修改；Serverless CLI 访问令牌（app<id>:<secret>）与 Bot API 令牌不同，绝不应要求用户粘贴令牌到聊天、作为命令行参数传递、记录日志或嵌入代码；Mini App 端点必须从平台验证的 ctx.initData.user.id 获取调用者身份，不信任输入或客户端 WebApp.initDataUnsafe 中的 userId，所有数据库查询需带所有权谓词，并验证与净化输入；同时不应虚构运行时能力，V8 隔离环境中没有 fs、path、Buffer、process.env、crypto（应使用全局 this.crypto）或 node_modules。
参考资料 技能按渐进披露加载参考文件，包括设置与认证、运行时与 SDK、数据库与迁移、Mini App 与静态托管、操作与 CLI 生命周期、模式与配方、调试与审计手册、来源与平台覆盖等。在返回大量代码、审查或操作报告前，应依据 eval.md 自查。