—
name: loopcraft
description: Designs a bounded, verifiable agent loop only when the user explicitly asks for a loop, recurring automation, or an unattended workflow. Default to a single, non-looping solution. Use L2 Dreaming only when the user writes `/loopcraft dreaming`.
—

# Loopcraft — conservative edition

Communicate in Czech; keep these technical terms in English: loop, trigger, verifier, state, budget, hard cap, blast radius.

## Default behaviour

Start with **L0 — no loop**. Give one focused prompt or plan. Do not create, suggest, simulate, or run an agent loop merely because a task is repetitive or could be automated.

Use **L1 — one bounded loop** only when the user explicitly asks for a loop, scheduled automation, heartbeat, or goal-until-condition workflow.

Use **L2 — Dreaming** only when the user writes exactly `/loopcraft dreaming` and supplies all required limits below. Never infer this request, offer it proactively, or escalate from L1 automatically.

Never ask for or reveal private chain-of-thought. State only a short decision and its reasons.

## Pick the level

– **L0:** no machine-checkable completion condition, or one-off work.
– **L1:** one sequential, repeatable task with a machine-checkable completion condition.
– **L2:** only explicit `/loopcraft dreaming`; at least three independent chunks with disjoint file scopes and a separate check for each.

If a level’s conditions are not met, choose the lower level and say why in one sentence.

## Required guards

No loop may be designed or run until these are concrete numbers or facts:

1. **Done condition:** a machine-checkable fact, such as a named test command succeeding.
2. **Hard caps:** maximum iterations, total wall-clock time, total model calls, and total token or money budget.
3. **Blast radius:** a disposable branch or worktree; no production credentials, deployment, pushing, or destructive commands.
4. **Verifier:** an independent check that receives the result and acceptance criteria, not the worker’s rationale.

If any guard is missing, return a short checklist and stop. Never invent a budget or run an unbounded loop.

## L1 design

Return only this compact specification:

„`text
Level: L1
Goal:
Trigger:
Input state:
One iteration:
Acceptance check:
Stop conditions: done | iteration cap | time cap | call cap | budget cap | no progress twice
Blast radius:
Morning/report output:
„`

Use one worker and one verifier per iteration. Do not use parallel workers, sub-agents, ToT, or retries by default. A failed check is reported to the user; retry only if the user explicitly permits it, with a changed input and within the existing caps.

## L2 Dreaming — explicit-only

Before producing an L2 design, require all of the following from the user:

„`text
goal:
done_condition:
max_iterations:
max_minutes:
max_model_calls:
max_budget:
max_workers: (1–3)
isolated_worktree_or_branch:
„`

If any field is absent, ask for the missing fields and do nothing else.

L2 rules:

– At most three workers; workers may not create workers.
– Workers own disjoint paths and make no changes outside them.
– One planner pass per iteration, with a terse ranked list of at most three chunks.
– One independent verifier per worker; verifier sees only the diff and acceptance criteria.
– Stop immediately after two consecutive iterations with no verified progress.
– The runner must enforce time, call, and worker caps outside model-controlled state.
– A state file records facts only: completed chunks, failed checks, remaining caps, and the halt reason.
– Never deploy, push, access production, or perform destructive operations.

### L2 mini architecture

„`text
ORCHESTRATOR: reads STATE.json and stops if an external cap is reached.
PLANNER: selects at most three independent chunks.
WORKERS: each completes one chunk within its assigned paths.
VERIFIERS: independently check each worker’s diff against its criteria.
RECORDER: writes only verified facts and remaining limits to STATE.json.
„`

Use this minimal state schema. The runner, not the model, must enforce every cap:

„`json
{
„goal“: „verbatim user goal“,
„status“: „RUNNING | DONE | HALTED“,
„iteration“: 0,
„limits“: {
„iterations“: 3,
„minutes“: 30,
„model_calls“: 6,
„budget“: „user-supplied“
},
„done“: [],
„backlog“: [],
„failed“: [],
„no_progress_streak“: 0,
„halt_reason“: null
}
„`

Only the Recorder updates the file after verification. When `no_progress_streak` reaches 2, set `status` to `HALTED` and stop. The morning report contains: verified work, failures, remaining backlog, caps used, and any decision needed from the user.

## Output rules

For a design, return the smallest useful specification. Do not include long architecture essays, worked examples, templates not needed for the selected level, or a runner script unless the user explicitly asks for implementation.

When implementation is explicitly requested, first show the proposed caps and blast radius and ask for confirmation before creating a runnable loop.

## Anti-patterns

– Activating on a vague mention of automation.
– Treating a model-written state value as an enforced budget.
– Repeating unchanged failures.
– Running workers and verifiers without a real external cap.
– Giving workers permission to spawn workers.
– Passing large raw logs, full repositories, or full conversation histories when a targeted summary is enough.