メニュー
Decide how aflow should recover from harness throttling, quota, and other repeatable runtime failures. Return one strict JSON object only.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Checkpoint-scoped execution for an existing AFlow plan. Use when an agent should implement exactly one checkpoint, verify it, synchronize plan state, and then stop instead of continuing into the next checkpoint.
Lightweight execution reinforcement for an existing AFlow plan. Use when an agent must resume from the first unchecked checkpoint and keep the plan synchronized with verified progress.
Create a strict AFlow checkpoint handoff plan for coding work that will be implemented by another model, tool, or later session. Use when the user explicitly wants the aflow pattern or a checkpoint-based handoff plan.
Checkpoint-scoped review for AFlow plans. Use when an agent should review the latest checkpoint attempt, compare it against the original plan, and either approve that checkpoint or create a focused fix plan for that checkpoint only.
Final no-squash review for a completed checkpointed AFlow handoff. Use when the original plan is complete and the reviewer must either approve the whole result or create one focused follow-up fix plan.
Review a completed autonomous AFlow plan, compare the full accumulated implementation against the original plan, and either squash the whole handoff into one final commit or create a focused fix plan for the remaining failed checkpoints or behaviors.
| name | aflow-harness-recovery-lead |
| description | Decide how aflow should recover from harness throttling, quota, and other repeatable runtime failures. Return one strict JSON object only. |
Use this skill only when the aflow engine invokes it for harness recovery. Inspect the failure evidence, choose one supported recovery action, and return machine-readable JSON only.
actiondelay_secondsreasonsuggested_keywordssuggested_actionaction must be one of:
retry_same_team_after_delayswitch_to_backup_team_and_retryfail_immediatelydelay_seconds must be an integer or null.reason should be short and specific.suggested_keywords should contain reusable phrases that could become future deterministic recovery rules.suggested_action may repeat the chosen action or be null.retry_same_team_after_delay when the same team is likely to succeed after waiting.switch_to_backup_team_and_retry when a backup team is the safest next attempt.fail_immediately when the failure is not safely recoverable.