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.
npx agentmods add skills/choiyounggi/loop-orchestrator/loop-implementnpx skills add choiyounggi/loop-orchestrator --skill loop-implementgit clone --depth 1 https://github.com/choiyounggi/loop-orchestratorWhat 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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00088 | $0.02021 |
| Opus 5 | $0.00044 | $0.01010 |
| Sonnet 5 | $0.00018 | $0.00404 |
| Haiku 4.5 | $0.00009 | $0.00202 |
Grade A, and why
loop-implement 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.
How it starts
The opening of the file, as written. The whole thing — 143 lines — stays where its author put it; the contents beside it link to each section on GitHub.
loop-implement — verification loop for a single task
Take one task and drive it to "done" through a closed loop whose steps are grounded in established methodology (sources at the bottom). This is the worker half of loop-orchestrator: an orchestrator session hands you one task; you complete it here. It also works standalone for a single task.
When to use
- Use: logic changes, new features, bug fixes, behavior-changing refactors.
- Skip: typos, config values, simple rename/import cleanup, one-line edits.
Tool profile (pluggable)
A few steps can use environment-specific tools through named capability roles:
knowledge (domain facts / policy / code values), tacit (past incidents, edge
cases, danger zones), plan (a planning skill), verify (the project's test /
build / QA command), explore (code/symbol search), and design (visual/UI spec
for a UI task, e.g. a Figma link). Resolve them once at the start:
sh ${CLAUDE_PLUGIN_ROOT}/scripts/resolve-tools.sh --summary
For each role: if a tool is configured, use it where the loop references that role
below; if it resolves to default, use the generic built-in behavior (your own
analysis / the step-2 planning). Configuration is optional and layered (per-user
then per-repo) — with nothing set, the loop runs fully generic and depends on no
external tool. Schema, precedence, and examples: references/tool-profile.md.
A role is a tool injected into one step — never a loop. Do NOT map a role (esp.
verify) to a tool that runs its own implement/verify/retry loop or another
orchestrator; that nests loops and muddies the retry/DoD/auditor ownership. There
is no implement role — step 4 below is the single owner of the implement cycle.
The loop
0. Define done — write the acceptance criteria + done checklist FIRST,
so the loop has an explicit pass/fail target. [DoD/XP]
1. Analyze — understand the change; list the test scenarios it needs.
Consult `knowledge` + `tacit` if configured; use `explore`
to locate code/symbols. For a UI-facing task, read the
visual spec — the brief's `<design_spec>` if present, else
consult `design` (e.g. a Figma link) — and implement to it. [TDD step 1 / PDCA Plan]
2. Plan / design — for larger tasks only; fold into step 1 if small.
Use the `plan` role if configured, else plan inline. [PDCA Plan]
3. Write tests (Red) — write the failing test(s) BEFORE the code. The test is
the spec and the verification oracle. If test-first is
impractical (e.g. exploratory UI), fix the acceptance
criteria / verification command before implementing. [TDD test-first]
4. Implement (Green) — minimal code to make the tests pass. [TDD Green / PDCA Do]
5. Run tests (Check) — run new + existing tests; preserve failure output. Use the
`verify` role's command if configured (run only). [PDCA Check / self-testing code]
6. Self-review + refactor — clean up; check bugs, edge cases, resource leaks,
input validation, unused code. Re-check against the
`tacit` role's danger zones if configured. [TDD Refactor / self-review / Self-Refine]
6.5 Independent audit — REQUIRED: call the test-quality-auditor subagent with the
task brief, the diff, and the test paths. Do NOT grade
your own tests. (self-grading guard)
7. Judge against done — pass only if the done checklist is met AND the auditor
returns VERDICT: PASS. [DoD / evaluator]
- PASS -> done.
- FAIL -> 7b.
7b. Reflect + retry — state in words why it failed (what the auditor/tests
showed), then retry from step 3 with that reflection.
Bounded: at most 3 attempts. On the 3rd failure, STOP
and escalate with the last failure reason. [Reflexion / bounded retry]
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.
- yesterday First seen · 143 lines · 88 tokens per session scan A 11cc17c37a86
loop-implement is a skill published in the GitHub repository choiyounggi/loop-orchestrator (2 stars, last pushed 1mo ago), licensed MIT. It adds 88 tokens to every session and 2,021 once invoked, about $0.0004 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.
Other skills, from other repositories
release
Cut a versioned release of the DOS kernel — bump the version, draft release notes, commit, tag, push to master, and create a GitHub release. The tag push triggers the gated PyPI publish pipeline (publish.yml); the skill surfaces the run and its approval gate.
stable-release
Promote an already-shipped rolling release (vX.Y.Z) of the DOS kernel to a named stable channel — gated on a green kernel suite + a green third-party CI run on the candidate + a clean truth syscall + a soak window. Writes an evidence file and adds a stable/ git tag on the same commit. Does NOT bump versions or build…
dos-goal-fleet
Launch multiple goal-scoped workers in waves, each with a witness-gated stop condition and dos arbitrate file-tree safety. Use when an operator asks to run several independent goals in parallel and fold only verified ships.
dos-dispatch-loop
Run recurring dos-dispatch cycles, switching to dos-replan when the backlog drains and stopping on the kernel's loop verdict. Use for unattended dispatch->replan->dispatch work across disjoint lanes.
dos-goal-gate
Ground a keep-working goal in evidence the worker did not author by wiring dos hook stop to refuse false done claims. Use for one self-stopping agent or loop worker; use dos-witness-claim for fold barriers.
dos-witness-claim
Route subagent claims through independent read-back before another agent relies on them. Use at parallel, pipeline, or synthesis barriers where shipped phases, files, rows, messages, or other effects must be witnessed.