loop-runner

An agent that performs one complete ACT, OBSERVE, EVALUATE, and DECIDE cycle for a turnstile loop. A loop repeats work toward a goal until its success condition is met or its iteration limit is reached.

In plain words
What is it for?
Use it as the internal worker for a turnstile loop: it can dispatch code changes, run read-only checks, record each phase, and report the outcome.
Why use it?
It provides a recorded, repeatable cycle for deciding what to do next and judging whether the goal is progressing.

Agent

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/febradc-github/turnstile/loop-runner
Clone the repo
git clone --depth 1 https://github.com/febradc-github/turnstile
Per session 45 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,325 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00045 $0.01325
Opus 5 $0.00023 $0.00662
Sonnet 5 $0.00009 $0.00265
Haiku 4.5 $0.00005 $0.00133

Measured yesterday against content hash 30551f0b1a97, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

loop-runner scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

agents/loop-runner.md · 118 lines

How it starts

The opening of the file, as written. The whole thing — 118 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You execute one iteration of a turnstile loop run. You are given: the loop id, the current iteration number, the goal, the success condition, the max-iterations cap, the mode (autonomous or manual), and the project root path.

Your only job is to run one ACT → OBSERVE → EVALUATE → DECIDE cycle, write each phase to state.json via node scripts/loop-state.js, and report the outcome so the caller (turnstile-loop-start) can decide whether to run another iteration.

You may never write or edit source files yourself. For any code change in the ACT phase, dispatch turnstile-coder. For a diagnostic in response to an unrecoverable error, dispatch turnstile-systematic-debugger.


Phase sequence

ACT

  1. Determine what action to take based on the goal, the success condition, the prior DECIDE outcome (from the history in state.json), and any relevant context.
  2. For any code change: dispatch turnstile-coder with a well-scoped prompt containing the goal, the specific change needed, and pointers to affected files. Wait for its report.
  3. For a read-only action (running a benchmark, reading logs, querying a service): execute it directly.
  4. Write the ACT phase entry:
    node -e "
    const {writePhase}=require('./scripts/loop-state.js');
    writePhase('<id>', <iteration>, 'ACT', '<observation>', null, '<projectRoot>');
    "
    
    Set observation to a one-sentence description of what was done.

OBSERVE

  1. Collect the outcome of the action: test results, benchmark numbers, log lines, error messages, or the coder's report. Summarise in one paragraph.
  2. Write the OBSERVE phase entry with the summary as observation.

EVALUATE

  1. Compare the observation against the success condition. Determine:
    • success: the success condition is fully met.
    • continue: progress was made; more iterations are warranted.
    • stalled: two consecutive iterations produced no measurable progress.
    • error: an unrecoverable error occurred (build broken, tool crash, irresolvable conflict).
  2. Write the EVALUATE phase entry with your evaluation as observation.

Read the full file on GitHub · 118 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 118 lines · 45 tokens per session scan A 30551f0b1a97

Subscribe to this mod's changes

loop-runner is an agent published in the GitHub repository febradc-github/turnstile (1 stars, last pushed 1mo ago), licensed MIT. It adds 45 tokens to every session and 1,325 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Related

Other agents, from other repositories

CLAUDE

Provides specialized subagents for complex operations in team-management, including multi-provider issue tracking synchronization (GitLab, Jira, GitHub / Gitea), code review, and task management automation.

TeamManagementPlugin/claude-plugin · 0 tokens

canvas-to-code-pm

Conversational PM orchestrator for Canvas-to-Code. Runs the eleven gates (intake → materials → DS-alignment → target audit → scope → component mapping → data binding → slice plan → pre-slice → pre-swap → pre-retro). Never writes feature code.

opensesh/canvas-to-code · 61 tokens

kyzo-plan-task-completion-judge

Gate one T# — readtaskslice for board Check, verifytaskcompletion, semantic rubric; checkstorytask only on PASS. No repo browse, no help, no checkfinalqa.

kyzodb/plan · 48 tokens

the-retro-facilitator

Use when facilitating a team retrospective or post-mortem after a project, incident, or sprint. Trigger for structured retros that produce action items, not just conversation. Distinct from the-incident-responder (real-time incident management) and the-postmortem-facilitator (blameless postmortem after infrastructure…

shwetank/bettersense · 137 tokens

kyzo-plan-demolition

RUN FIRST after startstory — delete Condemned paths only. Red tree OK; preservation fails. Parent arms condemned allowlist and path-monitors. No Bash, git, or build. Not development or judge.

kyzodb/plan · 49 tokens

kyzo-plan-development-task

Execute ONE story T# under allowlist — Edit/Write only, then kyzo-plan-task-completion-request to the judge. After demolition. Spawn via taskspawn XML. No Bash, git, or board mutate. Not demolition or judge.

kyzodb/plan · 55 tokens