agentleFS
markoblogomarkoblogo/abvx-agent-skills/skills/loopops-protocol/SKILL.md

loopops-protocol

Skill16 starsChanged 5 months agoMITView on GitHub

Design and evolve agent skills into cost-bounded loops, workflows, scripts, and memory updates. Use when creating or auditing reusable agent methods, converting prompts or skills into workflows, designing open or closed agent loops, defining supervisor/evaluator contracts, or deciding whether repeated agent work should become a skill, checklist, script, workflow, or autonomous loop.

The file

Show its rules and text

We split this skill into the rules it gives an agent

17 rules. About 0 are common, 17 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈17

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when reusable agent behavior should become more than a better prompt.

    line 12
  2. Distinctive:

    Do not promote work upward unless the extra machinery buys reliability, reuse, or cheaper future execution.

    line 20
  3. Distinctive:

    Prefer the lowest artifact that handles the task reliably.

    line 33
  4. Distinctive:

    If any condition is missing, keep it as a supervised workflow or checklist.

    line 45
  5. Distinctive:

    Use an open loop when:

    line 49
  6. Distinctive:

    Use a closed loop when:

    line 56
  7. Distinctive:

    Every loop must define:

    line 67
  8. Distinctive:

    After each iteration, save only durable signal:

    line 87
  9. Distinctive:

    Do not append raw logs, long transcripts, secrets, private data, or one-off observations to durable memory.

    line 96
  10. Distinctive:

    After a loop completes, update skills only with lessons that are:

    line 100
  11. Distinctive:

    not already covered by higher-priority instructions,

    line 105
  12. Distinctive:

    Every loop must have at least two:

    line 126
  13. Distinctive:

    stop after repeated identical blocker,

    line 133
  14. Distinctive:

    If cost cannot be bounded, do not run autonomously.

    line 136
  15. Distinctive:

    When the same step is repeated three times, decide whether to compile it:

    line 140
  16. Distinctive:

    Prefer scripts and deterministic checks over longer instructions.

    line 148
  17. Distinctive:

    When designing or updating a loop-capable method, report:

    line 152

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

LoopOps Protocol

Use this skill when reusable agent behavior should become more than a better prompt.

The goal is to choose the smallest durable artifact that improves future runs:

prompt -> skill -> checklist -> script -> workflow -> loop

Do not promote work upward unless the extra machinery buys reliability, reuse, or cheaper future execution.

Artifact Ladder

Classify the candidate method first:

  • Prompt: one-off instruction for this run.
  • Skill: compact reusable context, procedure, or tool adapter loaded on demand.
  • Checklist: ordered human/agent validation sequence.
  • Script: deterministic repeatable action with parameters.
  • Workflow: ordered tool/process execution with gates and evidence.
  • Loop: workflow plus evaluator, memory write, retry policy, and stop rule.

Prefer the lowest artifact that handles the task reliably.

Loop Suitability Gate

Promote a workflow into a loop only when all are true:

  • The goal has an observable completion condition.
  • Progress can be evaluated without trusting the worker agent blindly.
  • A retry is likely to improve the result.
  • Cost can be bounded by iteration, time, token, or tool budget.
  • Failure has a clear stop, rollback, or human-escalation path.

If any condition is missing, keep it as a supervised workflow or checklist.

Open vs Closed Loop

Use an open loop when:

  • the solution space is unknown,
  • discovery or exploration matters,
  • multiple valid approaches may exist,
  • the output is research, architecture, strategy, or design direction.

Use a closed loop when:

  • acceptance criteria are known,
  • tests, checks, or review criteria exist,
  • regression risk matters,
  • the task can be decomposed into verifiable steps.

Open loops need tighter budget limits. Closed loops need stronger evaluators.

Supervisor Contract

Every loop must define:

Goal:
Completion condition:
Loop type: open | closed
Worker action:
Evaluator:
Evidence:
Memory write:
Retry policy:
Budget:
Stop rule:
Rollback or escalation:

The evaluator can be a test command, lint/typecheck/build, browser check, static analysis, script, human review, or a separate model. Prefer deterministic evaluators when available.

Memory Policy

After each iteration, save only durable signal:

  • current hypothesis,
  • changed files or artifacts,
  • verification result,
  • blocker or failure mode,
  • next intended action,
  • reusable lesson if it generalizes.

Do not append raw logs, long transcripts, secrets, private data, or one-off observations to durable memory.

Skill Evolution

After a loop completes, update skills only with lessons that are:

  • procedural,
  • reusable,
  • testable,
  • not already covered by higher-priority instructions,
  • worth their token cost.

Good updates:

  • missing repo-specific command,
  • repeated failure mode,
  • verification step that caught a real issue,
  • script or workflow that replaced repeated manual work,
  • rejected path that should not be retried.

Bad updates:

  • generic coding advice,
  • motivational wording,
  • model-behavior hacks,
  • single-incident preferences,
  • rules that increase context without reducing errors.

Cost Controls

Every loop must have at least two:

  • max iterations,
  • max wall-clock time,
  • max token/tool budget if measurable,
  • narrowest useful verification first,
  • summarized memory instead of raw logs,
  • stop after repeated identical blocker,
  • human approval before external, destructive, expensive, or privacy-sensitive actions.

If cost cannot be bounded, do not run autonomously.

Compiler Rule

When the same step is repeated three times, decide whether to compile it:

  • repeated prose instruction -> skill rule,
  • repeated checklist -> workflow,
  • repeated shell/Python/JS snippet -> script,
  • repeated verification pattern -> evaluator,
  • repeated failure recovery -> stop hook or escalation rule.

Prefer scripts and deterministic checks over longer instructions.

Final Report

When designing or updating a loop-capable method, report:

  • chosen artifact level,
  • why higher levels were rejected or accepted,
  • supervisor contract if a loop is used,
  • cost controls,
  • memory writes,
  • validation performed,
  • skill/workflow/script files changed.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.