Skill flagged — suspicious patterns detected

ClawHub Security flagged this skill as suspicious. Review the scan results before using.

Error Recovery

v1.0.0

系统化错误恢复 — 当工具失败时提供结构化的诊断、重试和汇报流程。防止静默失败、无限重试、错误升级。

0· 115·0 current·0 all-time
byErwin@aptratcn

Install

OpenClaw Prompt Flow

Install with OpenClaw

Best for remote or guided setup. Copy the exact prompt, then paste it into OpenClaw for aptratcn/error-recovery-xiaobai.

Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill "Error Recovery" (aptratcn/error-recovery-xiaobai) from ClawHub.
Skill page: https://clawhub.ai/aptratcn/error-recovery-xiaobai
Keep the work scoped to this skill only.
After install, inspect the skill metadata and help me finish setup.
Use only the metadata you can verify from ClawHub; do not invent missing requirements.
Ask before making any broader environment changes.

Command Line

CLI Commands

Use the direct CLI path if you want to install manually and keep every step visible.

OpenClaw CLI

Bare skill slug

openclaw skills install error-recovery-xiaobai

ClawHub CLI

Package manager switcher

npx clawhub@latest install error-recovery-xiaobai
Security Scan
Capability signals
Requires sensitive credentials
These labels describe what authority the skill may exercise. They are separate from suspicious or malicious moderation verdicts.
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Suspicious
medium confidence
Purpose & Capability
Name/description, SKILL.md, README and the included error-diagnose.mjs align with an 'error recovery' helper: a knowledge base and guidance for diagnosing common errors. Minor incoherences: SKILL.md and README refer to additional helper scripts (e.g., scripts/error-log.mjs) and a GitHub repo clone URL that are not present in the file manifest; source/homepage are 'unknown'. These missing artifacts reduce transparency but do not by themselves imply malicious intent.
!
Instruction Scope
Instructions explicitly tell an agent to run system commands (ls, chmod), try sudo, check environment variables and tokens, and use alternate tools/APIs (gh api, GitHub API). While these actions are reasonable for diagnosing errors, the SKILL.md grants broad discretion to read system state and credentials even though the skill's manifest does not declare any required environment variables. That mismatch elevates risk: the agent may access secrets or perform privileged actions without a declared need.
Install Mechanism
Instruction-only skill with one small local Node script; there is no install spec, no network downloads, and the included script is a local diagnostic printout with no network calls. This is low-risk from an installation perspective.
Credentials
The manifest declares no required environment variables or credentials, yet the guidance discusses checking API keys/tokens and setting env vars (e.g., GIT_CURL_VERBOSE, API keys) and using authenticated APIs. The skill should explicitly declare any credentials it expects; the absence is a transparency gap that could lead to the agent reading secrets without the skill declaring them.
Persistence & Privilege
Skill is not always:true, does not include an install hook, and does not request persistent system-wide privileges. It references integration with other skills (memory-guard, evr) but does not modify other skills or agent configs in the package. No elevated persistence requested.
What to consider before installing
This skill appears to implement a reasonable 4R error-recovery workflow and includes a harmless local diagnostic script. However: (1) SKILL.md and README reference additional helper scripts (e.g., scripts/error-log.mjs) that are not included — ask the author or check the upstream repo for the missing files. (2) The documentation tells the agent to check environment variables, tokens, and to use sudo/alternate APIs; the skill manifest does not declare any credentials. Before installing, review any referenced but missing scripts and confirm they do not read or transmit secrets. If you enable the skill, grant it minimal permissions and test in a sandboxed environment. If the agent will be allowed to run commands on your system, ensure you trust the author/source (registry owner id only is present) and that any recommended tokens/keys are limited-scope and rotatable. If you need help auditing the missing scripts or the GitHub repo referenced in README, provide the repo URL or missing files and I can review them.

Like a lobster shell, security has layers — review code before you run it.

latestvk974bt3abjkmdyxa8kak2d7yzs8572g2
115downloads
0stars
1versions
Updated 1w ago
v1.0.0
MIT-0

Error Recovery - 系统化错误恢复 🩹

失败不可怕,可怕的是假装成功

Skill职责

当AI Agent遇到工具失败、网络超时、权限错误等问题时,提供结构化的恢复流程,防止:

  • ❌ 静默失败 — 命令返回错误但假装成功
  • ❌ 无限重试 — 同一错误反复尝试不停止
  • ❌ 错误升级 — 用错误的方法修复错误
  • ❌ 丢失上下文 — 忘记错误发生在什么场景下

触发场景

任何工具调用返回以下情况时激活:

  • 返回码非0
  • HTTP状态码非200
  • 超时(timeout)
  • 权限拒绝(permission denied)
  • 文件不存在(file not found)
  • API错误(rate limit, auth failure等)

核心流程:4R法则

1️⃣ Record — 记录错误

**错误记录:**
- 时间: [精确时间]
- 工具: [哪个工具/命令]
- 错误类型: [timeout/auth/file-not-found/...]
- 错误信息: [原始错误]
- 上下文: [在做什么时出错]

2️⃣ Reason — 分析原因

不要跳过这一步! 常见错误类型和原因:

错误类型常见原因快速诊断
timeout网络慢/服务器忙换个时段/换API
401/403Token过期/权限不足检查认证
404路径错误/资源不存在检查URL/路径
429Rate limit等待后重试
500服务器错误等待或换方式
ENOENT文件不存在ls确认路径
EACCES权限不足检查chmod
SIGKILL进程被杀超时/内存不足

3️⃣ Recover — 尝试恢复(最多3次)

恢复策略树:

工具失败
├── 能否换工具?
│   ├── curl失败 → 尝试fetch/gh api
│   ├── git push失败 → 尝试API上传
│   └── 搜索失败 → 尝试不同关键词
├── 能否换方式?
│   ├── 网络超时 → 增加timeout/减少数据量
│   ├── 权限错误 → 用sudo或修改权限
│   └── 文件路径错误 → 用绝对路径
└── 能否换思路?
    ├── 本地安装失败 → 用远程API
    ├── push失败 → 用GitHub API直接上传
    └── CLI报错 → 改用SDK

重试规则:

  • 同一方法最多重试 3次
  • 每次重试必须改变参数/方法(不能原样重试)
  • 3次失败后停止,向上汇报

4️⃣ Report — 汇报结果

成功恢复:

✅ 错误已恢复

**原始错误**: [错误信息]
**原因分析**: [分析]
**恢复方法**: [用了什么方法]
**重试次数**: [N/3]

**教训**: [下次如何避免]

恢复失败(3次后):

❌ 错误未解决 — 需要人工干预

**错误**: [错误信息]
**已尝试**:
1. [方法1] → [失败原因]
2. [方法2] → [失败原因]
3. [方法3] → [失败原因]

**建议**: [人工应该做什么]
**影响**: [对当前任务的影响]

使用方法

方式1:手动执行

遇到错误时按4R流程处理。

方式2:脚本辅助

# 诊断错误
node scripts/error-diagnose.mjs --error "ENOENT" --context "读取配置文件"

# 记录错误到日志
node scripts/error-log.mjs --tool git --error "timeout" --message "push超时"

# 查看错误历史
node scripts/error-log.mjs --history

方式3:集成到EVR

## EVR扩展(含错误恢复)

🔧 **Execute**
[执行命令]

❌ **失败** → 激活 error-recovery

1️⃣ Record: [记录错误]
2️⃣ Reason: [分析原因]
3️⃣ Recover: [尝试恢复]
4️⃣ Report: [汇报结果]

回到 EVR:
✅ **Verify**: 验证恢复成功
📋 **Report**: 完整汇报

经典案例

案例1:Git Push超时

错误: git push 在腾讯云到GitHub之间超时

恢复过程:

尝试1: git push --verbose (增加verbose看详情)
       → 仍然超时 (20s)
尝试2: GIT_CURL_VERBOSE=1 git push (调试)
       → 确认是网络问题
尝试3: 用gh api直接上传文件
       → ✅ 成功!

教训: 网络不稳定时,避免git操作,用GitHub API替代

案例2:进程被SIGKILL

错误: 后台进程被系统杀死

恢复过程:

尝试1: 重新执行相同命令
       → 又被杀死 (OOM?)
尝试2: 减少内存使用(分批处理)
       → ✅ 成功
       
教训: 大数据量操作要分批

案例3:文件路径不存在

错误: 读取memory/YYYY-MM-DD.md返回ENOENT

恢复过程:

尝试1: 用ls检查目录
       → 发现文件名是YYYY-MM-DD-addendum.md
尝试2: 读取addendum文件
       → ✅ 找到了遗漏的信息!

教训: 永远不要假设文件名,用ls确认

与其他Skill的配合

Skill配合方式
evr错误恢复是EVR的扩展
time-anchor错误恢复后重新检查时间
memory-guard将错误教训写入记忆
session-handoff错误记录纳入交接文档

License

MIT


Created by 小白 🤍 "失败不可怕,可怕的是假装成功"

Comments

Loading comments...