SkillFeed
Automatically match the best skills to unblock a failed or stuck workflow.
Trigger Conditions (auto)
Run this skill when any of these signals appears:
- 1. Command/API failure (non-zero exit, HTTP 4xx/5xx)
- Retry threshold exceeded (default >=2 retries)
- Expected output missing (for example no tweet id after post task)
- Execution timeout exceeded
- User explicitly asks for tool/skill recommendation
- User describes a goal but has no clear implementation path
Do not trigger for normal delay/noise or when the user already has a working solution.
Workflow
- 1. Capture failure context (sanitize before any external use)
- task name
- platform (X/Twitter, Telegram, GitHub, etc.)
- error message/code (generic type only — see sanitization rules below)
- latest action log summary (stripped of secrets)
- 2. Classify failure type
- auth/permission
- rate limit/quota
- network/timeout
- invalid params/payload
- unknown
- 3. Build layered search queries (broad -> scenario -> failure)
- Q1 broad capability query
- Q2 scenario-specific query
- Q3 failure-specific query with error tokens
-
Sanitize all queries before searching — see Data Sanitization section
- 4. Search ClawHub
- Use
https://clawhub.ai/skills?focus=search
- Always perform a live search; use
references/top-skills-*.md only as offline fallback
- Prefer sorting by stars / recently updated when comparing candidates
- 5. Rank candidates
- match to goal (highest weight)
- match to failure type
- setup cost and risk
- maintenance signals
- 6. Return recovery plan
- Top 1 primary skill
- 2 alternatives
- 3-5 concrete next actions
- fallback path if primary fails
- 7. Anti-noise guardrails
- Avoid repeating the same recommendation for the same error within a single conversation
- Avoid auto-running high-risk external actions without user confirmation
Query Construction Rules
Generate queries from context tokens:
- - Goal tokens:
post, schedule, auto reply, INLINECODE5 - Platform tokens:
x, twitter, tweet, telegram, INLINECODE10 - Failure tokens:
401, 403, 429, timeout, invalid token, INLINECODE16
Example for failed tweet post:
- - Q1: INLINECODE17
- Q2: INLINECODE18
- Q3: INLINECODE19
Data Sanitization
All failure context MUST be sanitized before it is included in any external search query or output. This prevents accidental leakage of secrets, credentials, and private data.
Strip before searching
- - API keys, tokens, passwords, secrets (e.g.
sk-..., ghp_..., Bearer ...) - Personally identifiable information (emails, usernames, IPs, hostnames)
- Internal URLs, file paths containing usernames or org names
- Request/response bodies and headers containing auth data
- Environment variable values (keep only the variable name)
Keep in queries (safe tokens)
- - Generic error codes:
401, 403, 429, 500, INLINECODE27 - Generic error types:
invalid token, rate limit, INLINECODE30 - Platform names:
twitter, github, INLINECODE33 - Action verbs:
post, publish, schedule, INLINECODE37
Rules
- 1. Never embed raw log lines in a search query — extract only the error type/code.
- If unsure whether a token is sensitive, omit it.
- Queries should read like generic capability descriptions, not contain project-specific data.
Example — BAD query: twitter post failed Bearer sk-abc123 user@company.com 401
Example — GOOD query: INLINECODE39
Provider Adaptation (Claude Code / ChatGPT / Gemini)
Format the recovery plan for the current provider by default. Only include multi-provider runbooks when the user explicitly requests cross-platform output.
- 1. Keep core logic provider-neutral
- Use the same goal, failure classification, query generation, and ranking flow.
- 2. Detect current provider and use the matching execution style
- Claude Code: terminal-first, exact command sequences, minimal commentary.
- ChatGPT: compact checklist bullets, short "why" before steps.
- Gemini: explicit sections, assumptions, deterministic validation criteria.
- 3. Normalize outputs
- Keep identical recommendation order across providers.
- Only vary phrasing and action formatting.
Output Format
- - Goal:
- Failure signal:
- Primary recommendation:
<skill> (/slug) — - Alternatives:
-
<skill> (
/slug) —
- <skill> (/slug) —
- - Immediate actions (3-5 steps)
- Success check:
- expected output present
- no critical error in latest run
- - Fallback if still failing
- Execution notes:
References
- - Search and ranking recipes: INLINECODE46
- Scenario keyword map: INLINECODE47
- Claude Code / ChatGPT / Gemini adaptation: INLINECODE48
SkillFeed
自动匹配最佳技能以解除失败或卡住的工作流。
触发条件(自动)
当出现以下任一信号时运行此技能:
- 1. 命令/API 失败(非零退出码、HTTP 4xx/5xx)
- 超过重试阈值(默认 >=2 次重试)
- 缺少预期输出(例如发布任务后没有推文 ID)
- 执行超时
- 用户明确请求工具/技能推荐
- 用户描述目标但没有明确的实现路径
正常延迟/噪音或用户已有可行解决方案时不要触发。
工作流程
- 1. 捕获失败上下文(在外部使用前进行脱敏处理)
- 任务名称
- 平台(X/Twitter、Telegram、GitHub 等)
- 错误消息/代码(仅通用类型——见下方脱敏规则)
- 最新操作日志摘要(去除机密信息)
- 2. 分类失败类型
- 认证/权限
- 速率限制/配额
- 网络/超时
- 无效参数/负载
- 未知
- 3. 构建分层搜索查询(广泛 -> 场景 -> 失败)
- Q1 广泛能力查询
- Q2 特定场景查询
- Q3 带错误标记的特定失败查询
-
搜索前对所有查询进行脱敏处理——见数据脱敏部分
- 4. 搜索 ClawHub
- 使用 https://clawhub.ai/skills?focus=search
- 始终进行实时搜索;仅将 references/top-skills-*.md 作为离线备用
- 比较候选时优先按星标/最近更新排序
- 5. 对候选进行排名
- 匹配目标(权重最高)
- 匹配失败类型
- 设置成本和风险
- 维护信号
- 6. 返回恢复计划
- 排名第一的主要技能
- 2 个备选方案
- 3-5 个具体后续操作
- 主要方案失败时的备用路径
- 7. 抗噪音护栏
- 避免在单次对话中针对同一错误重复推荐
- 未经用户确认避免自动运行高风险外部操作
查询构建规则
从上下文标记生成查询:
- - 目标标记:发布、调度、自动回复、日报
- 平台标记:x、twitter、tweet、telegram、github
- 失败标记:401、403、429、timeout、invalid token、permission denied
推文发布失败示例:
- - Q1:tweet automation
- Q2:x twitter schedule post cron
- Q3:twitter post failed 401 invalid token rate limit
数据脱敏
所有失败上下文在包含到任何外部搜索查询或输出之前必须进行脱敏处理。这可以防止意外泄露密钥、凭据和私有数据。
搜索前去除
- - API 密钥、令牌、密码、机密(例如 sk-...、ghp_...、Bearer ...)
- 个人身份信息(电子邮件、用户名、IP、主机名)
- 包含用户名或组织名的内部 URL、文件路径
- 包含认证数据的请求/响应体和头部
- 环境变量值(仅保留变量名)
查询中保留(安全标记)
- - 通用错误码:401、403、429、500、timeout
- 通用错误类型:invalid token、rate limit、permission denied
- 平台名称:twitter、github、telegram
- 动作动词:post、publish、schedule、fetch
规则
- 1. 切勿在搜索查询中嵌入原始日志行——仅提取错误类型/代码。
- 如果不确定标记是否敏感,则省略。
- 查询应像通用能力描述,不包含项目特定数据。
示例——错误查询:twitter post failed Bearer sk-abc123 user@company.com 401
示例——正确查询:twitter post failed 401 invalid token
提供商适配(Claude Code / ChatGPT / Gemini)
默认情况下为当前提供商格式化恢复计划。仅当用户明确请求跨平台输出时才包含多提供商运行手册。
- 1. 保持核心逻辑与提供商无关
- 使用相同的目标、失败分类、查询生成和排名流程。
- 2. 检测当前提供商并使用匹配的执行风格
- Claude Code:终端优先、精确命令序列、最少注释。
- ChatGPT:紧凑清单要点、步骤前简短原因。
- Gemini:明确章节、假设、确定性验证标准。
- 3. 规范化输出
- 跨提供商保持相同的推荐顺序。
- 仅措辞和操作格式有所不同。
输出格式
- - 目标:<用户想要什么>
- 失败信号:<什么失败了>
- 主要推荐:<技能>(/slug)—— <原因>
- 备选方案:
- <技能>(/slug)—— <权衡>
- <技能>(/slug)—— <权衡>
- 预期输出存在
- 最新运行中无严重错误
- - 如果仍然失败的备用方案
- 执行说明:<为当前提供商格式化的步骤>
参考
- - 搜索和排名配方:references/discovery-workflow.md
- 场景关键词映射:references/query-templates.md
- Claude Code / ChatGPT / Gemini 适配:references/provider-adaptation.md