agentsclimarketplace

Os improvement loop

Skill richfrem/agent-plugins-skills/plugins/agent-agentic-os/skills/os-improvement-loop

Pattern 5: Concurrent Event-Driven Multi-Agent Loop. Coordinates multiple Claude sessions as OS threads sharing a common event bus and memory address space. Every loop cycle is a full improvement cycle: execute, eval against benchmark (KEEP/DISCARD), emit friction events, and close with surveys, metrics, memory persistence, and Triple-Loop triggers.From its SKILL.md

Install
npx -y skills add richfrem/agent-plugins-skills --skill os-improvement-loop

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
  • runs commandsInstructs the agent to run 2 commands, including `os-init` and 1 more.

SKILL.md

4.2 KB, 853 tokens by cl100k_base, as published. Nobody here has run it

Concurrent Agent Loop

Treats concurrent sessions as OS threads sharing a common event bus and memory address space. Every cycle includes execution, independent peer evaluation, friction tracking, self-assessment surveys, post-run metrics, and memory persistence.


When to Use This Pattern

Use when:

  • Coordinating continuous improvement across multiple concurrent agent sessions.
  • Evaluating and improving multiple skills, workflows, or templates in parallel.
  • You need every cycle to generate measurable accuracy gains and persistent memory.

Do NOT use for:

  • Single-session procedural tasks (use os-eval-runner directly).
  • Signal-only coordination with no evaluation, survey, or memory steps.

Key Invariants

  • No-Rollback Rule: Never manually roll back changes during a cycle unless evaluate.py registers an explicit accuracy regression.
  • Eval Gate Mandatory: Every modification must pass the independent evaluation gate (evaluate.py exit code 0). No manual bypasses.
  • NEVER STOP Discipline: Do not abort a running loop due to minor/moderate errors. Complete the loop close checklist and log unresolved issues as Map Debt.
  • Outer Loop Ownership: The outer loop owns session lifecycle. Inner loop tasks (os-eval-runner) must not prematurely close a session without running Stage 4 (memory promotion and survey collection).

Stage Pointers & Reference Protocols

The execution details are split across modular references:


Smoke Test

  1. Verify Event Registry: Run os-init or start a test loop. Assert that context/events.jsonl registers start events correctly.
  2. Execute Scorer: Run python3 ./scripts/evaluate.py --skill skills/todo-check/ on a dummy check to verify that exit codes map correctly (0 for KEEP, 1 for DISCARD, 2 for path error).
  3. Friction Event Test: Propose a manual edit, emit a mock friction event, resolve it with friction.resolved, and verify the metrics engine logs the resolution gate pass.

Gotchas

  • Conflation of Loops: Conflating the inner target skill loop with the outer OS-improvement loop. Outer loop changes the OS workflows; inner loop changes target skills.
  • Orphaned Sessions: Completing inner loop tasks but failing to run memory promotion and survey curation. Ephemeral findings are lost.
  • Directory Symlinks: Creating directory-level symlinks from skills to shared roots. This violates ADR-003. Use file-level symlinks.

HANDOFF_BLOCK Template

Every loop execution that completes a cycle must output this block in its handoff:

## HANDOFF_BLOCK
- **Cycle ID**: cycle-YYYYMMDD-HHMMSS
- **Target Skill**: [path/to/target]
- **Verdict**: KEEP / DISCARD
- **Score (Before -> After)**: [0.XX -> 0.YY]
- **Friction Events**: [N encountered / N resolved]
- **Outstanding Map Debt**: [list links or IDs]
- **Recommended Next Step**: [next hypothesis to test]

What ships with it: 24 files

3.0 KB alongside SKILL.md, 5 of them executable

evals/

scripts/

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.