LoopCraft – AI SKOP

—
name: loopcraft
description: Designs self-running agent loops that reason deeply (Chain-of-Thought), explore alternatives (Tree-of-Thought), and verify their own work with an INDEPENDENT checker — turning a recurring manual chore into an unattended, guard-railed loop where the human becomes the guard-rail designer, not the outer loop. Use WHENEVER the user wants to automate a recurring or decomposable task, build an agent loop / „self-running“ or agentic workflow, set up a scheduled / heartbeat / goal-until-condition agent, add CoT or ToT reasoning to a loop, design a verifier or stop condition, or mentions loop engineering, autonomous agents, self-verification, or orchestration. Also trigger on Czech phrasings like „udělej smyčku / loop“, „automatizuj tenhle úkol“, „ať to běží samo“, „navrhni agentní loop“, „sebeověřující agent“, or when the user types /loopcraft. Even when the user only describes a boring repeated chore they want off their plate, consider whether a Loopcraft loop fits and offer it.
—

# Loopcraft

> A skill for designing self-running agent loops that reason deeply (Chain-of-Thought),
> explore alternatives (Tree-of-Thought), and verify their own work independently —
> so the human stops being the „outer loop“ and becomes the guard-rail designer instead.

## Interaction

Communicate with the user in **Czech**; keep technical terms in **English** (loop, trigger, verifier, CoT, ToT, guard, state, hard cap). Match the user’s house style: this SKILL.md stays in English, the conversation is Czech. Don’t lecture the framework at the user — diagnose their actual chore, then walk them through the five stages and hand back a concrete loop design.

## Purpose

Loopcraft combines three layers into one repeatable skill:

1. **Prompt engineering** — crafting the single instruction the agent receives each iteration.
2. **Chain-of-Thought (CoT) / Tree-of-Thought (ToT)** — the reasoning strategy the agent uses *inside* one run to solve the framed task.
3. **Loop engineering** — the outer system that decides when the agent runs, what it’s handed, how the result is checked, and when to stop.

The goal is not to write a better one-off prompt. It’s to design a machine that keeps writing good prompts for itself, checks its own output with something other than itself, and remembers what it already did.

## When to use this skill

Use Loopcraft when a task is:

– **Recurring** — a chore you’d otherwise repeat by hand every day/week.
– **Decomposable into verifiable steps** — tests pass, diff is zero, file is migrated.
– **Too large or ambiguous for a single prompt**, but reasonable when broken into a sequence of framed sub-tasks.

Do **not** use it for one-shot creative or judgment calls with no measurable success condition — those still belong to plain prompt engineering. If the user’s task has no machine-checkable „done,“ say so and steer them back to a single good prompt instead of forcing a loop.

## The five stages of a Loopcraft cycle

Walk the user through these in order. Each stage has a concrete decision to make — don’t leave any implicit.

## Reasoning strategy: CoT vs. ToT inside the Frame/Reason stage

– **Use CoT** when the task is a single well-understood path: migrate this file, fix this failing test, summarize this log. Ask the agent to think step-by-step and show intermediate reasoning before the final answer.
– **Use ToT** when the task has several plausible strategies and picking wrong is costly: refactor approach, architecture decision, debugging a non-obvious failure. Have the agent branch into 2–3 candidate approaches, briefly evaluate each against the success condition, then commit to one before acting.
– A loop can mix both: **ToT to choose *what* to attempt this iteration, CoT to *execute* the chosen branch.**

When helping the user pick, ask one question: *“Is there one obvious way to do this step, or several worth comparing?“* One obvious way → CoT. Several worth comparing → ToT.

## The three guards (non-negotiable)

An unattended loop without all three of these is a runaway waiting to happen. Install every one before the first hands-off run.

1. **Hard cap** — max iterations, wall-clock limit, or token budget. Stops runaways.
2. **Verifiable condition** — a machine-checkable fact (tests green, diff empty), never the model’s own „looks done.“
3. **Independent verification** — a separate context/subagent reviews the work. The implementer never grades itself.

Why independence matters: the context that wrote the code is the worst judge of whether the code is right — it’s already convinced. A fresh verifier with only the success condition and the output catches what the implementer rationalized away.

## State rules

– **Read first, write last** — load state before framing the task, write it only after verification passes. Writing state before verification is how a loop „remembers“ work it never actually finished.
– **Facts, not vibes** — record „Converted auth/session.py, tests pass,“ never „made good progress.“ Vibes accumulate into an unusable log; facts let the next iteration frame itself correctly.

## Minimal template

„`
Trigger: <schedule | event | goal-until-condition>
Frame: <one clear task, pulled from state, with explicit success condition>
Reason: <CoT: step-by-step | ToT: generate N branches, evaluate, pick one>
Run: <agent executes>
Verify: <independent check — different context or subagent, machine-checkable>
Record: <append fact to external state file, only on verified success>
Stop when: <explicit condition — never „when it looks finished“>
„`

## Worked example — nightly „green build“ loop

A concrete instance, to show what a filled-in template looks like. Task: keep a flaky test suite green overnight.

„`
Trigger: heartbeat — every night at 02:00, and on every push to main
Frame: „Read state.md. Take the first still-failing test. Make it pass
WITHOUT weakening the assertion. Success = that test green AND no
previously-green test now red.“
Reason: ToT to diagnose (branch: flaky timing? / bad fixture? / real
regression?), evaluate each against the stack trace, commit to one;
then CoT to implement the chosen fix step-by-step.
Run: agent edits code + test, runs the suite
Verify: independent subagent re-runs the FULL suite from a clean checkout
with only the diff and the success condition — it never sees the
implementer’s reasoning, only „are all tests green, yes/no.“
Record: on pass only: append „Fixed test_checkout_timeout (flaky sleep →
deterministic clock), full suite green“ to state.md
Stop when: state.md lists zero failing tests, OR 8 iterations reached, OR
30 min wall-clock — whichever hits first.
„`

Notice all three guards are present (8-iteration cap, „all tests green“ is machine-checkable, the verifier is a separate clean-checkout subagent), and state is written facts-only, after verification.

## First loop checklist (for a new loop instance)

– [ ] Picked one recurring, boring, frequent chore.
– [ ] Wrote down the conventions/instructions a new teammate would need.
– [ ] Chose CoT or ToT for the reasoning stage, and justified why.
– [ ] Installed all three guards before the first unattended run.
– [ ] Ran it supervised for a week, reading every output.
– [ ] Only then scheduled it to run unattended.

## Anti-patterns to avoid

– **Self-graded success** — letting the agent declare its own success („looks complete“ is not a condition).
– **State amnesia** — skipping external memory, which causes repeated, wasted re-work.
– **Orchestration tax** — scaling parallel loops faster than your own review bandwidth.
– **Cognitive surrender** — stopping caring about what the loop produces.

## Output

When the user wants the resulting loop design as a deliverable (a spec file, a runbook, a starter script), write it to `/mnt/user-data/outputs/` and present it. A typical deliverable is a filled-in Minimal template plus the state-file schema and the three guards spelled out for their specific chore. Keep the loop spec itself in English if it’s documentation the user will version; keep the surrounding conversation in Czech.