Token导航 LogoToken导航

Agent Skill · 效率

double-check(双重检查)

double-check 用于补充效率相关能力,适合在 OpenClaw 中需要让 Agent 承接效率相关任务时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

double-check 是效率类 Agent Skill,可用宿主为 OpenClaw,通过ClawHub获取,权限为权限未标注;许可证为 MIT-0,第三方扫描已通过,按安装量在效率类的 21,003 个 Skill 里排第 11,761。

总安装 4,440周安装 185GitHub Stars 公开资料未说明下载 1,480核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT-0
版本
0.1.0

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:double-check(双重检查)
来源仓库:https://github.com/belugarex/double-check
安装命令:
openclaw skills install double-check
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

ClawHubOpenClaw
openclaw skills install double-check

这个 Skill 是做什么的

效率类 Skill 把重复的整理、汇总、转换工作交给助手完成,减少手工复制粘贴。

用于所有文件修改后的双重验证质量保证。double-check 属于效率类 Skill,可作为该场景下的辅助能力补充。自动执行两次独立测试或编译以确保变更无误。适用于删除功能或重构代码等高风险操作场景。默认应用于全部任务需人工干预时可临时关闭。建议配置自动化流水线以降低重复检查成本。

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 OpenClaw;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 openclaw skills install double-check;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    权限没有明确标注,第一次使用时只给一个无关紧要的任务,观察它到底读了哪些文件和网络。

常见问题

6 条

double-check 怎么安装?

在终端执行 openclaw skills install double-check。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

double-check 支持哪些 AI 工具?

公开资料标注支持 OpenClaw。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

double-check 需要什么权限?

权限级别没有明确标注。第一次使用时建议只给无关紧要的任务,观察它实际读写了哪些内容。

double-check 是免费的吗?

来源标注的许可证是 MIT-0。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

double-check 用的人多吗?

公开数据是累计安装 4,440 次,近一周安装 185 次,下载 1,480 次。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

double-check 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 专注 OpenClaw 一种宿主,触发方式和使用习惯不用来回切换。
  • 许可证明确为 MIT-0,商用和分发边界好判断。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 OpenClaw,想直接扩展它能力的人。
  • 需要处理效率类任务、又不想每次都手写提示词的人。
  • 需要许可证清楚、并且有第三方扫描结果的团队项目。

不太适合

  • 需要厂商级技术支持和 SLA 的生产系统。

效率类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
github

GitHub 代码协作 · OpenClaw

7,632,918545需要联网MIT-0通过
nano-pdf

Nano PDF 文档 · OpenClaw

4,249,476231需要联网MIT-0通过
auto-updater

自动更新程序 · OpenClaw

2,964,063386操作浏览器MIT-0通过
video-frames

视频帧 · OpenClaw

2,621,304112需要联网MIT-0通过
gemini

Gemini 助手 · OpenClaw

2,547,39648需要联网MIT-0有提醒
double-check

双重检查 · 本页

4,440—权限未标注MIT-0通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

name
double-check
description
在修改任何文件后(包括删除功能),自动进行两次独立验证(测试/编译/运行检查/文档或配置检查),确保无误才结束。本技能应默认应用于所有文件修改任务。 / After any file changes (including feature removal), automatically perform two independent verifications (tests/compilation/runtime checks/docs or config checks) to ensure correctness. This skill should be applied by default to any file modification task.
author
BelugaRex
tags
[coding, testing, verification, quality-assurance, bilingual]

双重验证技能 / Double-Check Skill

本技能适用于任何文件修改场景,包括代码、文档、配置、资源文件的添加、修改、删除、重构与更新等。核心要求:只要用户请求修改任何文件,AI 应自动应用本技能,并在每次修改后执行以下双重验证流程:

激活标识:每次启用本技能的回复以 ✅✅ 开头,便于你确认本技能已被调用。

  • 连续两次验证:修改后立即进行两次验证,两次均无错误才能结束。
  • 同样严谨:两次验证使用相同的方式(如相同的测试命令或运行命令),确保结果可靠。
  • 自动触发:无需用户额外提示,AI 应主动遵循本流程。
  • 验证目标:确保修改后的文件变更能够顺利通过对应检查(无编译/运行/构建/文档校验错误,且原有功能或内容不受影响)。

📌 适用场景 / Applicable Scenarios

本技能应默认应用于所有涉及文件修改的请求,包括但不限于:

  • 修复 Bug 后运行测试用例或运行程序检查。
  • 添加新功能后确保原有功能正常。
  • 删除功能后验证剩余代码是否能顺利运行,无残留错误。
  • 重构代码后检查编译/类型错误或运行程序。
  • 调整代码风格后验证 lint 规则。
  • 更新依赖后检查构建是否正常。
  • 更新文档后验证文档构建或校验规则。
  • 修改配置后验证构建/运行流程是否正常。
  • 任何其他文件变更后需要保证正确性的任务。

🧠 核心原则 / Core Principles

  1. 自动应用:AI 应识别出“修改文件”的意图,并自动激活本技能。
  2. 修改 → 验证 → 修正 → 再验证:任何文件修改都必须经过验证环节。
  3. 两次连续成功:必须连续两次验证均无错误,才能视为最终成功。
  4. 同样严谨:两次验证采用完全相同的方式(例如都运行 npm test 或 python main.py),确保一致性。
  5. 独立验证:尽管命令相同,但两次运行在逻辑上是独立的(例如不使用缓存结果,或使用 --no-cache 等选项),避免偶然因素。
  6. 清晰报告:每次验证后向用户报告结果(成功/失败,错误详情)。

📋 执行步骤 / Execution Steps

1. 理解任务

  • 明确用户希望修改的文件(增、删、改、重构等)。
  • 确认项目类型和可用的验证方式(测试命令、构建命令、运行命令、文档/配置检查等)。

2. 执行修改

  • 按照用户要求修改文件(包括删除功能时,需一并移除相关调用、引用等)。
  • 记录修改内容(便于回溯)。

3. 确定验证方式

根据项目情况选择合适的验证方式:

  • 如果有标准测试/构建/文档校验命令(如 npm test、pytest、cargo check、make test、mkdocs build、markdownlint 等),优先使用这些命令进行验证。
  • 如果没有标准验证命令,则与用户协商一个可执行的检查方式(如运行主程序、执行构建脚本、或使用已存在的校验脚本),通过退出码(0 表示成功)和错误输出来判断是否正常。注意:这种方式只能发现运行时/构建层面的错误,不能保证逻辑或内容正确性,需告知用户。

4. 第一次验证

  • 运行确定的验证命令。
  • 捕获输出,判断是否通过(测试通过/编译成功/运行无报错且退出码为0)。

5. 结果处理

  • 如果验证失败:

- 向用户报告错误详情(错误信息、行号等)。 - 根据错误修正相关文件变更。 - 返回步骤 4(第一次验证)重新开始,计数重置。

  • 如果验证成功:

- 记录“第一次成功”。 - 进入步骤 6。

6. 第二次验证(同样严谨)

  • 立即再次运行相同的验证命令(使用相同的方式,例如同样包含 --no-cache 等选项)。
  • 捕获输出,判断是否通过。

7. 最终判断

  • 如果第二次验证也成功:

- 向用户报告:✅ 双重验证通过!修改已完成且连续两次验证无错误。 - 结束任务。

  • 如果第二次验证失败:

- 向用户报告失败详情(可能是偶发性问题或修改引入的新错误)。 - 根据错误修正相关文件变更。 - 返回步骤 4(第一次验证),计数重置,重新开始双重验证流程。

🔧 验证方式示例

项目类型推荐验证命令说明
Node.js (有测试)npm test运行测试
Node.js (无测试)node index.js运行主程序,检查是否报错
Python (有测试)pytest 或 python -m unittest运行测试
Python (无测试)python main.py运行主程序,检查是否报错
Rustcargo test 或 cargo check运行测试或编译检查
Gogo test ./...运行测试
Go (无测试)go run main.go运行主程序,检查是否报错
Java (Maven)mvn test运行测试
Java (无测试)java -jar target/app.jar运行打包后的程序,检查是否报错
通用 (有 Makefile)make test 或 make check自定义测试
通用 (无测试)与用户协商运行命令例如运行脚本、启动服务等

💬 用户交互示例

示例 1:删除功能(有测试)

用户:请删除用户登录功能,用不到它了。

AI(自动应用本技能):

  1. 定位并删除登录功能的相关代码(文件、函数、调用等)。
  2. 运行 npm test(第一次验证)→ 测试通过(原有测试不受影响)。
  3. 再次运行 npm test(第二次验证)→ 测试通过。
  4. 报告:✅ 双重验证通过!登录功能已删除,剩余代码运行正常,所有测试通过。

示例 2:删除功能(无测试,运行检查)

用户:删掉设置页面的主题切换功能,没用了。

AI(自动应用本技能):

  1. 删除主题切换的相关代码。
  2. 由于没有找到测试命令,与用户协商:“我没有找到标准的测试命令。我可以运行 python main.py 来检查是否有运行时错误,这种方式只能发现程序崩溃,无法验证逻辑正确性。你同意吗?或者你有其他验证方式?”

- 用户回复:“可以,就运行看看。”

  1. 运行 python main.py(第一次验证)→ 程序正常运行,退出码 0。
  2. 再次运行 python main.py(第二次验证)→ 程序正常运行,退出码 0。
  3. 报告:✅ 双重验证通过!主题切换功能已删除,程序运行无报错。请注意,这仅验证了运行时错误,未检查其他功能是否受影响。

示例 3:验证失败并修正(添加功能)

用户:添加一个计算器函数。

AI:

  1. 添加函数及相关代码。
  2. 运行 pytest(第一次验证)→ 失败(新函数测试未通过)。
  3. 报告错误详情,修正代码。
  4. 再次运行 pytest(第一次验证重置)→ 通过。
  5. 再次运行 pytest(第二次验证)→ 通过。
  6. 报告:✅ 双重验证通过!计算器函数添加成功,所有测试通过。

⚠️ 注意事项 / Important Notes

  • 自动应用:本技能旨在默认应用于所有文件修改任务。AI 应主动识别文件修改意图并遵循本流程。
  • 删除功能的特殊考虑:删除功能时,需确保移除了所有相关引用(如调用、导入、配置),避免残留代码导致错误。
  • 验证方式协商:如果项目没有标准的验证命令,AI 必须与用户协商确定验证方式(如简单的运行命令或构建脚本),并告知用户该方式的局限性(只能发现运行时/构建错误,不能保证逻辑或内容正确)。
  • 验证命令可用性:确保验证命令在环境中可用。如果无法执行(例如没有运行环境),应与用户协商替代方案(如人工审查)。
  • 连续两次:强调“连续”意味着两次验证之间没有新的文件修改,只有验证执行。
  • 同样严谨:两次验证应使用完全相同的方式(包括命令、参数、环境等),以确保结果一致且可靠。
  • 验证独立性:如果工具存在缓存机制可能影响结果,建议使用清除缓存的相关选项(如 npm test -- --no-cache、pytest --cache-clear 等)确保两次验证真实独立。
  • 超时处理:如果验证命令运行时间过长(例如超过 5 分钟),可提示用户并建议手动检查,或允许用户中断。
  • 与版本控制结合:建议在修改前创建提交点或暂存更改,以便回滚。

🚀 与现有技能结合

如果你已在用 answer-framework 技能,本技能可与它自然衔接。例如,answer-framework 负责分析问题、组织回答,而 double-check 负责确保修改后的文件质量。AI 在收到文件修改请求时,应同时融合两个技能的指导。


记住:文件质量不是偶然,而是双重验证的结果。本技能应默认应用于每次文件修改。 Remember: File quality is not an accident; it's the result of double-checking. This skill should be applied by default to every file modification.

平台分布

OpenClaw

84.91%
按下载量换算1,257

安全审计

VirusTotal

通过

ClawScan

通过

Static analysis

通过

权限和风险

权限未标注

当前来源未能明确判断权限范围,默认进入异常复核队列。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills