跳到正文
cccskills
免费在 GitHub 公开

error-recovery

Guide agents through failures with timed retries, alternative methods, targeted fixes, and clear handoffs. It also explains when to continue with partial results, helping teams choose a recovery approach that fits the problem.

中文简介正在准备中。当前显示英语简介。

原文查看原文说明

Standard recovery patterns for all squad agents. When something fails, adapt — don't just report the failure.

查看安装方法

适用场景

  • Retrying temporary API and network failures
  • Switching methods when a tool fails
  • Diagnosing build and test errors
  • Handing off unresolved failures with context
  • Delivering partial results when optional data is missing

包含的文件(1)

  • SKILL.md3.4 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Error Recovery Patterns

Standard recovery patterns for all squad agents. When something fails, adapt — don't just report the failure.


1. Retry with Backoff

When: Transient failures — API timeouts, rate limits, network errors, temporary service unavailability.

Pattern:

  1. Wait briefly, then retry (start at 2s, double each attempt)
  2. Maximum 3 retries before escalating
  3. Log each attempt with the error received

Example: API call returns 429 Too Many Requests → wait 2s → retry → wait 4s → retry → wait 8s → retry → escalate if still failing.


2. Fallback Alternatives

When: Primary tool or approach fails and an alternative exists.

Pattern:

  1. Attempt primary approach
  2. On failure, identify alternative tool/method
  3. Try the alternative with the same intent
  4. Document which alternative was used and why

Example: Primary CLI tool fails → fall back to direct API call for the same operation.


3. Diagnose-and-Fix

When: Build failures, test failures, linting errors — structured errors with actionable output.

Pattern:

  1. Read the full error output carefully
  2. Identify the root cause from error messages
  3. Attempt a targeted fix
  4. Re-run to verify the fix
  5. Maximum 3 fix-retry cycles before escalating

Example: Build fails with a type error → check for missing import → add it → rebuild.


4. Escalate with Context

When: Recovery attempts have been exhausted, or the failure requires human judgment.

Pattern:

  1. Summarize what was attempted and what failed
  2. Include the exact error messages
  3. State what you believe the root cause is
  4. Suggest next steps or who might be able to help
  5. Hand off to the coordinator or the appropriate specialist

Example: After 3 failed build attempts → "Build fails on line 42 with null reference. Tried X, Y, Z. Likely a design issue in the Foo module. Recommend the code owner review."


5. Graceful Degradation

When: A non-critical step fails but the overall task can still deliver value.

Pattern:

  1. Determine if the failed step is critical to the task outcome
  2. If non-critical, log the failure and continue
  3. Deliver partial results with a clear note of what was skipped
  4. Offer to retry the skipped step separately

Example: Generating a report with 5 sections — section 3 data source is unavailable → produce the report with 4 sections, note that section 3 was skipped and why.


Applying These Patterns

Each agent should reference these patterns in their charter's ## Error Recovery section, tailored to their domain. The charter should list the agent's most common failure modes and map each to the appropriate pattern above.

Selection guide:

Failure TypePrimary PatternFallback Pattern
Network/API transientRetry with BackoffEscalate with Context
Tool/dependency missingFallback AlternativesEscalate with Context
Build/test errorDiagnose-and-FixEscalate with Context
Auth/permissionsRetry with BackoffEscalate with Context
Non-critical data missingGraceful Degradation—
Unknown/novel errorEscalate with Context—

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Coordinate work across AI agents with shared rules for locating team files, recording decisions and their reasons, and requesting help. It also defines who owns revisions after a reviewer rejects an artifact.

中文简介正在准备中。当前显示英语简介。

  • Locate team files across separate working directories
  • Record decisions that affect other agents
  • Request input from another specialist
github/gh-aw54212026年10月19日 更新

Set shared development rules for an agent team: keep specific agent names out of product code, tests, and CI configuration, verify affected tests before finishing, and record lessons learned from mistakes.

中文简介正在准备中。当前显示英语简介。

  • Share development rules across multiple agents
  • Keep team-specific agent names out of code and tests
  • Check affected tests before declaring work complete
github/gh-aw54212026年10月19日 更新

Routes requests to design, create, update, debug, or upgrade GitHub Agentic Workflows to the appropriate instructions. It helps the agent select a workflow-specific procedure and apply any additional rules defined for the repository.

中文简介正在准备中。当前显示英语简介。

  • Designing a new workflow through questions
  • Investigating failed runs and recurring errors
  • Upgrading workflows and addressing deprecations
github/gh-aw54212026年10月19日 更新

Prepare architecture proposals before implementation so the team can agree on a direction. Organize evidence, technical choices, effects on existing work, risks, and the first release’s scope into a document with clear recommendations and decision owners.

中文简介正在准备中。当前显示英语简介。

  • Proposing a major architecture change
  • Replanning milestones after a foundation change
  • Comparing technical options before seeking approval
github/gh-aw54212026年10月19日 更新

Update the gh-aw-firewall version used by gh-aw, rebuild generated files, and review release notes and configuration schemas, which define valid settings. It guides related code and test updates while identifying follow-up work that remains.

中文简介正在准备中。当前显示英语简介。

  • Updating the firewall version used by gh-aw
  • Reviewing release notes for integration changes
  • Checking configuration schema differences
github/gh-aw54212026年10月19日 更新

Review git and gh operations in gh-aw workflows to check credential availability for each repository. Identify missing token handoffs, risky expansions of limited checkouts, and error handling needed where credentials are intentionally unavailable.

中文简介正在准备中。当前显示英语简介。

  • Reviewing git operations after repository checkout
  • Checking tokens for private cross-repository access
  • Reviewing sparse and shallow checkout changes
github/gh-aw54212026年10月19日 更新

查看 github 的全部技能

报告此技能的问题