Skill: clarkchenkai/loop-stability-check-clarkchenkai (version 1.0.0)

--- name: loop-stability-check description: | Loop Stability Check — Workflow Stability Skill for Detecting Loops, Drift, and Retry Waste. Use it when the user needs a disciplined protocol and fixed output contract for this kind of task rather than a generic answer. license: MIT metadata: author: clarkchenkai version: "1.0.0" language: en --- # Loop Stability Check — Workflow Stability Skill for Detecting Loops, Drift, and Retry Waste Use this skill when the task matches the protocol below. ## Activation Triggers - repeated retries with no improvement - oscillation between multiple outputs or states - planning loops that never cash out into execution - human-bot ping-pong with no stable owner - cases where repetition is happening but convergence is not ## Core Protocol ### Step 1: Define the intended loop objective A loop cannot be judged as stable if nobody states what it is supposed to converge toward. ### Step 2: Observe the repeated behavior Look at retries, state changes, tool calls, or handoff cycles instead of reasoning from theory alone. ### Step 3: Classify the instability Name the pattern: dead retry, oscillation, drift, amplification, or feedback starvation. ### Step 4: Locate the feedback failure Ask which signal is missing, delayed, noisy, or being ignored. ### Step 5: Add guardrails and intervention Recommend retry caps, state locks, escalation triggers, ownership boundaries, or full halts where needed. ## Output Contract Always end with this six-part structure: ```markdown ## Loop Objective [...] ## Observed Behavior [...] ## Stability Risks [...] ## Likely Failure Mode [...] ## Guardrails [...] ## Recommended Intervention [...] ``` ## Response Style - Describe the loop behavior concretely. - Prefer named failure modes over generic ‘this seems buggy.’ - Recommend the smallest guardrail that restores convergence. - Stop the loop when the right action is halt, not another cycle. ## Boundaries - It does not optimize creativity by forcing every open-ended workflow into rigid convergence. - It does not confuse ‘more steps’ with ‘more learning.’ - It does not permit repeated motion to substitute for explicit ownership and escalation.

path: agents/openai.yaml
content: interface:
  display_name: "Loop Stability Check"
  short_description: "Diagnose unstable loops before they waste more cycles."
  default_prompt: "Use $loop-stability-check to inspect this workflow loop, name the instability pattern, and recommend guardrails or a halt condition."

policy:
  allow_implicit_invocation: true


path: references/failure-modes.md
content: # Failure Modes

## Dead retry
The same action repeats despite a non-retriable cause.

## Oscillation
The workflow bounces between two or more states without settling.

## Drift
The loop keeps moving but away from the original objective.

## Amplification
Each cycle makes the error or cost larger.

## Feedback starvation
The loop never receives the signal needed to converge.


path: references/guardrails.md
content: # Guardrails

Useful guardrails include:

- retry caps
- state locks
- explicit ownership boundaries
- escalation triggers
- trace visibility
- pause or halt conditions for non-retriable failures


path: references/wiener.md
content: # Wiener Reference

Loop Stability Check applies Wiener's control insight at the workflow level.

## Core implications

- Stable loops need useful feedback, not just repetition
- Error should shrink over time if the loop is healthy
- Missing or noisy signals can create oscillation or runaway retries
- Humans can serve as stabilizers when automation lacks the right signal


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)