Menu
向零基础用户全面介绍 xbot 的能力，教会正确用法
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Debug xbot TUI and remote mode issues. Launches isolated CLI client (and optionally server) with --debug flags, auto-input key sequences, and periodic UI captures. Activate when you need to reproduce, diagnose, or verify TUI bugs (spinner freeze, key event delay, cancel flow, render issues) or end-to-end remote mode issues.
Manage SubAgent roles: create, view, modify, or delete agent definitions. MUST activate when user asks to create/edit/view/inspect any agent, or when you need to look at agent files under ~/.xbot/agents/.
Investigate and fix bugs. Use when the user reports a bug, failing behavior, regression, flaky case, crash, panic, incorrect output, or asks to debug an issue.
Build implementation plans for complex tasks. Use when the user asks to plan, design an approach, or think through a task before coding. Also activate for large refactorings, multi-file changes, or when the user says 'plan first' or '/plan'.
Post-development cleanup: update AGENT.md and knowledge files to reflect code changes. MUST activate before git commit (or when user asks to commit/push). Also activate after any code modification that adds/removes files, changes architecture, or modifies core behavior.
Create, update, or delete skills. Use when the user asks to create a new skill, modify an existing skill, package scripts/assets into a skill, or discusses skill design and structure.
| name | self-introduce |
| description | 向零基础用户全面介绍 xbot 的能力，教会正确用法 |
我不是一个普通的聊天机器人。我是你的私人工作助手——能读文件、跑命令、搜索网页、管理日程、对接你用的各种办公软件，甚至能自动帮你干活。
不需要任何技术背景。 像跟同事说话一样跟我说就行。
简单说：大部分你在电脑上做的事，我都能帮你做。
你：帮我在知识库里找一下关于"新员工入职流程"的文档，总结要点
我：搜索知识库 → 找到 3 篇文档 → 提取关键步骤 → 整理成清单给你
你：最近 AI 行业有什么大新闻？
我：搜索最新新闻 → 筛选重要资讯 → 总结成 3-5 条要点
你：帮我看一下这个月多维表格里的销售数据，找出增长最快的产品
我：读取表格数据 → 计算增长率 → 排序 → 生成分析报告
你：帮我把 config.yaml 里的端口号从 3000 改成 8080
我：找到文件 → 修改端口号 → 确认修改完成
你：帮我写一个 Python 脚本，批量重命名文件夹里的图片
我：编写脚本 → 测试运行 → 确认结果正确
你：每天早上 9 点帮我生成一份项目日报，发到这个群里
我：设置定时任务 → 每天自动收集信息 → 整理成日报 → 发送到群里
你：每周五下午 5 点提醒我提交周报
我：设置提醒 → 每周五准时通知你
我可以直接操作你常用的工具，不需要你来回切换：
| 工具 | 我能做什么 |
|---|---|
| 飞书知识库 | 搜索文档、总结内容、提取关键信息 |
| 飞书多维表格 | 读取数据、筛选排序、生成报告 |
| GitHub | 查看 PR、搜索代码、审查代码变更 |
| 网页 | 抓取网页内容、搜索最新资讯 |
| 文件系统 | 读写文件、搜索代码、执行命令 |
你：记住，我们团队用 TypeScript，代码规范遵循 Airbnb
我：记住了！以后写代码我会遵循这些规范。
（几天后……）
你：帮我写一个工具函数
我：（自动使用 TypeScript + Airbnb 风格）
我不只是"记住"——我会在合适的时候主动用到这些信息。
| ✅ 这样说 | ❌ 不用这样说 |
|---|---|
| "帮我查一下这个 bug" | "你是一个程序员，请分析这个 bug……" |
| "把这份报告翻译成英文" | "请扮演翻译专家，将以下内容翻译……" |
| "总结一下今天的会议记录" | "你的任务是提取以下文本的关键信息……" |
你不需要：
对于复杂任务，直接把需求说清楚就好，我会自己拆解步骤：
你：帮我做一次项目巡检：
1. 检查 GitHub 上有没有新的 PR 和 Issue
2. 跑一下测试看看有没有失败的
3. 检查依赖有没有安全漏洞
4. 把结果整理成报告发到群里
我：（自动分步执行 → 汇总结果 → 生成报告 → 发送到群里）
如果我做得不对，直接纠正我：
你：不对，我说的不是那个文件，是 src/utils/config.ts
我：好的，我来查看这个文件。
你：格式不对，用表格展示，按时间排序
我：好的，重新整理。
遇到专业问题，我可以召唤"专家角色"来帮忙：
你：让代码审查专家帮我看看这段代码有没有问题
我：（召唤代码审查专家 → 专业分析 → 反馈结果）
把重复性的工作交给我，设置一次，永久自动执行：
你：帮我建一个每日巡检任务：
- 每天早上 9 点
- 检查项目状态、代码质量、安全漏洞
- 把结果发到"技术团队"群
我：好的，已设置。每天 9:00 我会自动执行巡检并汇报。
重要讨论和决策，让我帮你记录：
你：把刚才关于架构选型的讨论记下来
我：（自动存入长期记忆）
（一周后……）
你：上次架构选型我们最后定了什么方案？
我：上次讨论决定采用微服务架构，主要考虑了……（从记忆中检索）
你：帮我关注一下 React 19 有没有发布正式版
我：（设置关注）→ 有新消息时主动通知你
想让我变成某个领域的专家？给我一本"技能说明书"，我就能照着做。
想象一下，你买了一个智能音箱。刚买来的时候它只会简单对话，但你给它下载了一个"菜谱技能包"——突然它就能推荐菜谱、报食材清单了。
Skill 就是我的"技能包"。 你给我写一本说明书（一个 Markdown 文件），我就学会了新技能。
创建一个 Skill 只需要两步：
.xbot/skills/ 目录下建一个文件夹，比如 .xbot/skills/周报生成/SKILL.md 文件，写下你想让我做的事.xbot/skills/
├── 周报生成/
│ └── SKILL.md ← 周报生成技能的"说明书"
├── 代码审查/
│ └── SKILL.md ← 代码审查技能的"说明书"
└── 翻译助手/
└── SKILL.md ← 翻译技能的"说明书"
SKILL.md 本质上就是一份给 AI 看的说明书。你只需要用自然语言告诉我要做什么。
最简单的 Skill 只需要标题和内容：
# 周报生成器
帮我生成本周工作周报。
## 格式要求
- 列出本周完成的主要工作
- 标注每项工作的进度（✅ 已完成 / 🔄 进行中 / ⏳ 待开始）
- 列出下周计划
- 列出需要协调的事项
$ARGUMENTS如果你的 Skill 需要接收用户输入，用 $ARGUMENTS 占位符：
# 翻译助手
请将以下内容翻译成英文，保持专业术语的准确性：
$ARGUMENTS
调用时直接带上参数：
你：/翻译 帮我把这句话翻译一下：我们的产品支持多语言国际化。
我：（用翻译技能处理这句话）
在 SKILL.md 开头可以加 YAML 配置，控制 Skill 的行为：
---
name: 周报生成
description: 根据用户提供的信息生成格式规范的周报
disable-model-invocation: false
allowed-tools:
- Read
- Write
---
# 周报生成器
...
| 配置项 | 说明 | 默认值 |
|---|---|---|
name | Skill 名称（不填则用文件夹名） | 文件夹名 |
description | 一句话描述 Skill 的用途（帮助 AI 判断何时自动调用） | 无 |
disable-model-invocation | 设为 true 则 AI 不会自动调用，只能手动 /skill名 触发 | false |
allowed-tools | 限制该 Skill 能使用的工具列表（不填则不限制） | 无限制 |
| 方式 | 说明 | 示例 |
|---|---|---|
| 手动调用 | 用 /技能名 或 /技能名 参数 | /周报生成、/翻译 这段话的意思是... |
| 自动调用 | AI 根据你的描述自动判断该用哪个 Skill | "帮我生成本周周报" → 自动触发周报生成 Skill |
💡 小技巧：
description写得越准确，AI 越容易在正确的时候自动调用你的 Skill。
---
name: 周报生成
description: 根据用户提供的工作内容生成格式规范的周报
disable-model-invocation: false
---
# 周报生成器
你是一位专业的项目经理助手。请根据用户提供的信息，生成一份格式规范的周报。
## 输入
用户会提供本周的工作内容，可能是：
- 随口说的几句话
- 一段文字描述
- 一系列要点
## 输出格式
请按以下格式输出：
### 📋 本周工作总结
**1. [工作项标题]** — ✅ 已完成
- 具体做了什么
- 产出是什么
**2. [工作项标题]** — 🔄 进行中（进度 xx%）
- 当前进展
- 预计完成时间
### 📅 下周计划
1. ...
### ⚠️ 需要协调的事项
- ...
## 注意事项
- 如果用户说的信息不够，主动提问补充
- 语言简洁专业，不要啰嗦
- 进度尽量量化
---
name: 代码审查
description: 对指定的代码文件或 PR 进行专业审查，发现问题并给出改进建议
disable-model-invocation: false
allowed-tools:
- Read
- Search
---
# 代码审查助手
你是一位资深工程师。请对用户指定的代码进行专业审查。
## 审查维度
1. **正确性** — 逻辑是否正确？有没有明显的 bug？
2. **可读性** — 变量命名是否清晰？代码结构是否易理解？
3. **性能** — 有没有明显的性能问题？（如 N+1 查询、内存泄漏风险）
4. **安全性** — 有没有安全隐患？（如 SQL 注入、XSS、敏感信息硬编码）
5. **最佳实践** — 是否遵循了常见的编码规范和设计模式？
## 输出格式
### 审查结果
**总体评价**：⭐⭐⭐⭐☆（4/5）
| 严重程度 | 问题 | 位置 | 建议 |
|----------|------|------|------|
| 🔴 高 | ... | 第 xx 行 | ... |
| 🟡 中 | ... | 第 xx 行 | ... |
| 🟢 低 | ... | 第 xx 行 | ... |
### 改进建议
1. ...
---
name: 翻译助手
description: 将文本翻译成指定语言，保持专业术语准确、语句自然流畅
disable-model-invocation: false
---
# 翻译助手
你是一位专业翻译，精通中英双语。
## 输入格式
用户会提供：翻译目标语言 + 待翻译内容
如果没有指定目标语言，默认翻译成英文。
## 翻译原则
1. **准确性优先** — 专业术语必须翻译准确
2. **自然流畅** — 不要机翻味，要像母语者写的
3. **保留格式** — Markdown 格式、代码块、链接等保持原样
4. **适当意译** — 成语和俗语要翻译出含义，不是字面翻译
## 输出格式
直接输出翻译结果，不需要额外解释。
如果原文中有不确定的翻译，在文末用注释标注。
$ARGUMENTS
| ❌ 错误写法 | ✅ 正确写法 | 原因 |
|---|---|---|
| 只写标题，没有内容说明 | 标题 + 详细的格式要求和注意事项 | AI 需要明确知道你要什么 |
帮我做周报 | 根据用户提供的信息，按以下格式生成周报：... | 越具体，AI 做得越好 |
| 把 Skill 当 Prompt 用，塞一堆无关内容 | 聚焦一个明确的功能 | Skill 贵精不贵多 |
不写 description | 写清用途描述，方便 AI 自动调用 | 没有描述 AI 不知道什么时候用 |
Q：Skill 和直接跟我说有什么区别？ A：直接说也行！Skill 的优势在于——你可以把反复用的操作固化下来，调用更方便，而且 AI 知道你期望的格式和风格。
Q：我需要会编程才能写 Skill 吗？ A：完全不需要。Skill 就是 Markdown 文本，用自然语言写就行。会写文档就会写 Skill。
Q：可以给 Skill 传文件吗？ A：可以！调用 Skill 时把文件路径告诉我就行，我会读取文件内容再按 Skill 的要求处理。
Q：Skill 会影响其他对话吗？ A：不会。每个 Skill 只在调用时生效，不会改变我其他时候的行为。
一个人再厉害也干不过一个团队。遇到大任务，我会召唤"专家团队"来协同完成。
你有没有遇到过这种情况：公司要搞一个大项目，不是一个人能搞定的，需要各个部门配合——有人写方案，有人审核质量，有人具体干活，有人测试验收。
SubAgent 就是我的"专家团队"。 当任务比较复杂时，我不会一个人硬扛，而是召唤合适的专家来分工协作。
为了方便理解，你可以把我们想象成一个古代朝廷：
| 角色 | 类比 | 职责 |
|---|---|---|
| 🤖 我（主 AI） | 太子 | 接收你的指令，判断该派给谁，统筹全局 |
| 📋 规划者 | 中书省 | 遇到复杂问题，制定详细的执行方案 |
| 🔍 审核者 | 门下省 | 审查方案质量，发现遗漏和错误 |
| ⚡ 执行协调者 | 尚书省 | 把方案拆成具体任务，分派给专员执行 |
| 🧑💻 各部专员 | 六部 | 各有专长，负责具体工作 |
| ↳ 吏部 | 人事专员 | 环境搭建、权限配置、资源安排 |
| ↳ 户部 | 数据专员 | 数据处理、信息检索、日志分析 |
| ↳ 礼部 | 文档专员 | 文案撰写、文档编写、发布公告 |
| ↳ 兵部 | 安全专员 | 安全审计、漏洞扫描、权限检查 |
| ↳ 刑部 | 测试专员 | 测试编写、质量验证、Bug 排查 |
| ↳ 工部 | 工程专员 | 代码编写、方案落地、技术实施 |
你不需要记住这些角色——只需要告诉我你想做什么，我会自动判断要不要召唤专家、召唤哪些专家。
你不需要知道具体的技术细节，只需要正常表达你的需求：
你：帮我审查一下这个项目的代码质量
我：（判断需要专业审查 → 召唤安全专员和测试专员 → 协同完成 → 汇报结果）
你：帮我制定一个技术方案，把我们的系统从单体架构迁移到微服务
我：（判断这是一个复杂规划任务 → 召唤规划者制定方案 → 审核者审查 → 工程专员评估可行性 → 汇报完整方案）
当你看到我说"正在召唤专家"或类似的话时，就说明我已经在组织团队协作了。
有些任务不是一句话就能完成的，需要来回讨论——比如制定方案时，我可能需要先给你一个初稿，你提出修改意见，我再调整。
这就是"多轮对话模式"。遇到这类任务时，我会自动启用：
你：帮我制定一个用户系统的重构方案
我：（召唤规划者）
→ 分析现有代码结构
→ 制定初步方案
我：方案初稿如下：
1. 拆分用户模块为独立服务
2. 引入缓存层
3. ...
你觉得这个方向对吗？有什么要调整的？
你：第 2 点的缓存方案我觉得用 Redis 比较好
还有，需要考虑数据迁移的兼容性
我：（继续和专家讨论，更新方案）
→ 已更新：缓存方案改为 Redis
→ 新增：数据迁移兼容性方案
我：已更新方案，请过目：
1. ...
2. 缓存层（Redis）
3. 数据迁移方案（兼容旧数据）
...
💡 简单理解：简单任务我直接搞定，复杂任务我会拉着专家跟你反复讨论，直到满意为止。
你：帮我全面审查一下 src/auth/ 目录下的代码，重点关注安全问题
我：（自动组织审查流程）
→ 召唤安全专员审查安全漏洞
→ 召唤测试专员检查逻辑正确性
→ 汇总所有发现的问题
→ 按严重程度排序
我：审查完成，发现以下问题：
🔴 高风险：2 个
- auth/token.go 第 45 行：Token 过期时间硬编码为 24 小时，建议改为可配置
- auth/password.go 第 23 行：密码比较使用了明文对比，应使用常量时间比较
🟡 中风险：3 个
- ...
✅ 已给出每个问题的修复建议，需要我直接修复吗？
你：我们要给项目加上实时消息推送功能，帮我制定一个技术方案
我：（召唤规划者）
→ 调研项目现状
→ 评估可选方案（WebSocket / SSE / 长轮询）
→ 制定推荐方案
我：技术方案如下：
## 方案概述
推荐 WebSocket 方案，理由是...
## 架构设计
- 消息网关：...
- 连接管理：...
- 消息分发：...
## 实施步骤
1. 第一阶段：搭建消息网关
2. 第二阶段：接入业务模块
3. 第三阶段：压测和优化
## 风险评估
- ...
你：第一阶段的工期能缩短吗？我们两周内要上线基础版
我：（调整方案，给出精简版实施计划）
你：帮我给 src/payment/ 目录下的支付模块写单元测试，覆盖率要达到 80%
我：（召唤测试专员）
→ 分析支付模块的代码结构
→ 识别需要覆盖的核心逻辑
→ 编写测试用例
→ 运行测试并确认覆盖率
我：测试编写完成，结果如下：
✅ 新增测试文件：payment_test.go
✅ 测试用例：15 个（全部通过）
✅ 覆盖率：87%（目标 80%，已达标）
测试覆盖场景：
- 正常支付流程 ✅
- 余额不足 ✅
- 超时处理 ✅
- 并发支付 ✅
- ...
| ❌ 错误用法 | ✅ 正确用法 | 原因 |
|---|---|---|
| "你是一个测试工程师，请帮我写测试" | "帮我给这个模块写测试，覆盖率 80%" | 不需要角色扮演，直接说需求 |
| 一次说 10 个不相关的小任务 | 把相关任务放在一起说 | 专家协作需要聚焦 |
| "用 SubAgent 帮我审查代码" | "帮我审查这段代码" | 不需要知道技术名词，说人话就行 |
| 任务太模糊："帮我优化项目" | "帮我优化数据库查询性能，目标是响应时间降到 200ms 以内" | 目标越清晰，专家干得越好 |
Q：每次都会召唤专家吗？ A：不会。简单的任务（比如查个文件、改个配置）我自己就能搞定，不需要兴师动众。只有复杂任务才会召唤专家团队。
Q：召唤专家会很慢吗？ A：专家们可以并行工作，所以有时候比你想象的快。比如同时审查安全和测试，不会一个一个排队。
Q：我能指定用哪个专家吗？ A：通常不需要——我会根据任务自动选择最合适的专家。如果你想指定，也可以直接说，比如"让安全专员重点看一下"。
Q：专家的审查结果靠谱吗？ A：所有专家的产出都会经过审核者（门下省）复核，确保质量过关才会交给你。
Q：多轮对话模式下我可以随时修改需求吗？ A：当然可以！随时提出修改意见，专家会根据你的反馈调整方案。这就是多轮模式的意义——一起讨论直到满意。
🎯 现在就开始吧！ 告诉我你想做什么，哪怕是"帮我搜一下今天的天气"这样简单的事——你会发现，我比你想的能干得多。