Token导航 LogoToken导航TokenDH.com
研究检索执行命令github未标认证来源可访问许可证需确认审计通过

resilient-execution弹性执行

Agent Skill

resilient-execution 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

717

周安装

29

GitHub Stars

1

下载量

225
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

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

请帮我安装这个 Agent Skill:resilient-execution(弹性执行)
来源仓库:https://github.com/pixel-process-ug/superkit-agents
仓库路径:skills/resilient-execution
安装命令:
npx skills add https://github.com/pixel-process-ug/superkit-agents --skill resilient-execution
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

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

skills.shnpx skills
npx skills add https://github.com/pixel-process-ug/superkit-agents --skill resilient-execution

简介

用于查找、检索和筛选相关信息。

  • 适合在 Codex、Claude、Cursor、Gemini CLI 中根据关键词或任务场景快速定位候选结果。
  • 通过 npx skills add 命令从指定 GitHub 仓库安装,需确认权限与联网能力。
  • 建议结合原始 README 核验具体用法,注意维护状态和功能边界。
  • 使用前请检查是否会触发文件读写或命令执行,确保环境安全。

SKILL.md

Overview

The resilient-execution skill prevents premature failure by enforcing a minimum of 3 genuinely different approaches before escalating to the user. It provides a structured error classification system, an approach cascade methodology, and transparent logging of each attempt. Without this skill, agents give up too early — with it, they systematically exhaust alternatives and only escalate with full evidence.

Announce at start: "I'm using the resilient-execution skill — I will try multiple approaches before escalating."


Phase 1: Error Classification

When an approach fails, immediately classify the error before retrying:

Error TypeDefinitionIndicatorsCorrect Response
TransientTemporary infrastructure failureNetwork timeout, rate limit, 503 error, lock contentionWait briefly, retry the same approach
EnvironmentalMissing or misconfigured dependencyModule not found, wrong version, missing env var, permission deniedFix the environment, then retry same approach
LogicalWrong approach or incorrect assumptionWrong output, unexpected behavior, type mismatch, wrong API usageRethink the approach entirely
FundamentalGenuinely impossible with available toolsAPI does not exist, hardware limitation, missing capabilityEscalate to user with evidence
STOP: Classify the error before choosing your next approach. Wrong classification leads to wasted retries.

Phase 2: Approach Cascade

Execute the cascade systematically. Each attempt must be a genuinely different strategy.

Attempt 1: Primary approach (most direct solution)
    | fails
    v
Classify error -> Can same approach work with a fix?
    | YES -> Fix and retry (does NOT count as a new attempt)
    | NO  -> Proceed to Attempt 2
    v
Attempt 2: Alternative approach 1 (different technique)
    | fails
    v
Classify error -> Is this fundamentally blocked?
    | YES -> Proceed directly to escalation
    | NO  -> Proceed to Attempt 3
    v
Attempt 3: Alternative approach 2 (different path entirely)
    | fails
    v
Circuit breaker -> Present findings to user with full evidence

For Each Attempt, Log:

### Attempt N: [Approach Name]
**Strategy:** [what makes this different from previous attempts]
**What I tried:** [specific description with commands/code]
**What happened:** [exact error or unexpected result]
**Why it failed:** [root cause analysis]
**Classification:** [Transient / Environmental / Logical / Fundamental]
**What to try next:** [reasoning for next approach]
STOP: Log every attempt before moving to the next. Do NOT skip logging — it is evidence for the escalation report.

Phase 3: Alternative Approach Selection

When the primary approach fails, select the next approach using this decision table:

Failure TypeStrategy 1Strategy 2Strategy 3
Library/API does not workDifferent libraryDirect implementation (no library)Shell command / external tool
Algorithm produces wrong resultDifferent algorithmDecompose into smaller stepsSimplify constraints, solve easier version
Permission/access deniedDifferent access methodEscalate with manual stepsWork around via alternative path
Tool limitationDifferent toolCombine multiple toolsProvide manual instructions
Integration failureMock the dependencyUse alternative interfaceIsolate and test components separately
Performance issueDifferent data structureBatch/stream processingApproximate solution

Alternative Strategy Hierarchy

Try these in order of preference:

  1. Different tool — use a different library, API, or command
  2. Different algorithm — solve the same problem a different way
  3. Decompose — break the problem into smaller, solvable parts
  4. Simplify — remove constraints and solve a simpler version first
  5. Work around — achieve the goal through a different path entirely
  6. Manual steps — provide clear instructions the user can follow themselves

Phase 4: Escalation Report

After 3 genuine attempts with different approaches, produce this report:

## Execution Report

I tried 3 different approaches to [goal]:

### Attempt 1: [Approach Name]
**Strategy:** [description]
**Result:** Failed because [specific reason]
**Error:** [exact error message or unexpected output]

### Attempt 2: [Approach Name]
**Strategy:** [description]
**Result:** Failed because [specific reason]
**Error:** [exact error message or unexpected output]

### Attempt 3: [Approach Name]
**Strategy:** [description]
**Result:** Failed because [specific reason]
**Error:** [exact error message or unexpected output]

### Root Cause Analysis
[Why all three approaches failed — identify the common blocker]

### Recommended Next Steps
- **Option A:** [what the user could try]
- **Option B:** [alternative path]
- **Option C:** [if applicable]

### What I Need From You to Proceed
[Specific ask — access, information, permission, or decision]
STOP: Do NOT escalate without this report. The user needs evidence that 3 genuine attempts were made.

Decision Table: When Retries Count as "Genuine"

Counts as Genuine AttemptDoes NOT Count
Different library or toolSame library with different import
Different algorithm or data structureSame algorithm with tweaked parameters
Different architectural approachSame approach with minor code changes
Manual workaround vs automatedSame automation with retry loop
Breaking problem into sub-problemsSame monolithic approach with logging added
Using an entirely different APISame API with different authentication method (unless auth was the error)

Anti-Patterns / Common Mistakes

What NOT to DoWhy It FailsWhat to Do Instead
Retry the same approach 3 times and call it "3 attempts"Same approach = same failure. Not genuine alternatives.Each attempt must use a meaningfully different strategy
Give up after 1 failureMisses 2+ viable approachesAlways try at least 3 genuinely different approaches
Skip error classificationWithout classification, you retry wrong thingsClassify BEFORE choosing next approach
Hide failed attempts from the userUser cannot help without contextLog and report every attempt transparently
Escalate without trying manual workaroundMany things that fail in automation work manuallyAlways consider manual steps as Approach 3
Blame the platform without investigation"Platform limitation" is often wrongSearch for workarounds before declaring impossible
Fix environment issues and count as new attemptFixing env + retrying same approach is 1 attemptOnly count genuinely different strategies
Skip logging intermediate attemptsLoses evidence trail, cannot produce escalation reportLog every attempt immediately

Anti-Rationalization Guards

ThoughtReality
"This genuinely cannot be done"Have you tried 3 different approaches? Probably not.
"The error is clear, I know what is wrong"Clear errors can have hidden root causes. Investigate.
"I have already tried everything"List what you tried. There are always more options.
"The user should fix this themselves"Provide a manual path, but try 3 approaches first.
"This is a platform limitation"Limitations often have workarounds. Search for them.
"The same error keeps happening"Same error with different approaches = different root cause. Classify.
"This is taking too long"Giving up takes longer when the user has to start over.
"A simpler version would not be useful"A working simple version beats a broken complex one.
Do NOT escalate without 3 genuine attempts. Period.

Integration Points

SkillRelationship
circuit-breakerActivated after resilient-execution exhausts retries at the loop level
task-managementInvokes resilient-execution when a task step fails
self-learningRecords failure patterns to avoid repeating them in future sessions
planningUses failure history to choose more robust approaches
auto-improvementTracks retry success rates and approach effectiveness
verification-before-completionInvokes resilient-execution if verification fails

Concrete Examples

Example: File Parsing Failure

Attempt 1: JSON.parse() on the file
  Result: SyntaxError — file contains comments (JSONC format)
  Classification: Logical — wrong parser for this format

Attempt 2: Strip comments with regex, then JSON.parse()
  Result: Failed — nested block comments not handled
  Classification: Logical — regex too simple for comment stripping

Attempt 3: Use `jsonc-parser` library (handles JSONC natively)
  Result: Success — file parsed correctly

Example: API Integration Failure

Attempt 1: Direct HTTP request to API endpoint
  Result: 403 Forbidden — authentication required
  Classification: Environmental — missing auth config

  Fix: Add API key from .env
  Result: 429 Too Many Requests — rate limited
  Classification: Transient — wait and retry
  Result: 200 OK but response format changed from docs
  Classification: Logical — API version mismatch

Attempt 2: Use official SDK instead of raw HTTP
  Result: SDK throws "unsupported region" error
  Classification: Environmental — region config needed

Attempt 3: Use GraphQL endpoint instead of REST
  Result: Success — GraphQL endpoint supports all regions

Key Principles

  • Never give up silently — always show what was tried
  • Genuine alternatives — each attempt must be a meaningfully different approach, not the same thing with minor tweaks
  • Root cause analysis — understand WHY before trying the next approach
  • Learn from failure — update memory with what did not work and why
  • Transparent — show the user your reasoning at each step
  • Classify first — error type determines whether to retry same approach or try a new one

Skill Type

RIGID — The 3-attempt minimum is a HARD-GATE. Error classification is mandatory before each retry. The escalation report format must be followed exactly. Do not relax these requirements regardless of perceived simplicity.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

37.65%
按下载量换算85

Claude

30.73%
按下载量换算69

Cursor

18.93%
按下载量换算43

Gemini CLI

10.06%
按下载量换算23

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

执行命令

安装流程涉及命令执行,可能通过 npx skills add https://github.com/pixel-process-ug/superkit-agents --skill resilient-execution 联网下载 Skill 或依赖。用户安装前应确认命令来源、仓库内容和执行环境。

安装前确认

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

来源信息

继续浏览同类 Skills