메뉴
Drive the zicato evolve loop one stage at a time (propose → tournament) for inspecting or debugging a single round. Use only when you need to look inside what `zicato evolve` does internally; for normal operation run `zicato evolve`.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | zicato-step-loop |
| description | Drive the zicato evolve loop one stage at a time (propose → tournament) for inspecting or debugging a single round. Use only when you need to look inside what `zicato evolve` does internally; for normal operation run `zicato evolve`. |
zicato evolve is the happy path: it auto-resolves the contract, auto-opens an
epoch, then runs analyze-telemetry → propose → (apply) → tournament → promote
for --rounds rounds. This skill drives those stages by hand, one at a
time, so you can inspect each artifact between stages. Reach for it only when
debugging a single round — never as the normal way to run zicato.
Guardrail:
proposeandtournamentcall real LLMs and spend budget. Treat them as live runs — get the operator's explicit go-ahead before invoking them (AGENTS.md rule 1). Everything in the "inspect" steps below is read-only and safe. Use.venv/bin/zicato; neveruv syncmid-task.
The design docs (docs/design/CLI.md §3.5–3.8) describe zicato run,
zicato analyze, and zicato patch apply as separate steps. Those are not
in the shipped CLI. The real surface is:
| Doc form | Real CLI | Notes |
|---|---|---|
zicato run --generation vN --entry <id> [--tail] | (none) | No standalone runner. Runs happen inside tournament / evolve, which execute every board entry against each generation. |
zicato analyze | zicato analyze-telemetry | Decision-telemetry analyzer for the current epoch. |
zicato propose --output <file> | zicato propose | No --output; it writes experiment.json into the next generation dir itself. |
zicato patch apply --experiment <file> --as vN | (none) | No separate apply step. propose creates the candidate generation and writes its experiment in one shot; tournament / evolve apply patches internally. |
zicato tournament vN vM | zicato tournament PARENT CHILD | Positional generation ids. |
Always confirm with .venv/bin/zicato <cmd> --help before relying on a flag.
Z=.venv/bin/zicato
# 0. Inspect the surface the proposer may touch (read-only, no LLM).
$Z mutations --show preview # add --format json to script it
# 1. Analyzer: (re)build the decision-telemetry insight for this epoch.
# Writes insights/round_{N}.md (or insights/latest.md if --round omitted).
$Z analyze-telemetry --round 7 # spends no proposer budget
# 2. Propose: generate ONE Experiment for the next generation. (LLM — gated.)
# Writes generations/vN+1/experiment.json + per-patch files. No --output.
$Z propose # uses freshly-run detectors
$Z propose --patterns-from path/to/patterns.json # or pin a patterns file
# 3. (No separate apply.) Confirm the candidate generation now exists and read
# its hypothesis before scoring it.
$Z epoch list
sed -n '1,40p' .zicato/epochs/<epoch>/generations/vN+1/experiment.json
# 4. Tournament: score PARENT vs CHILD and decide promote/reject. (LLM — gated.)
$Z tournament v3 v4 # full: re-runs both generations
$Z tournament v3 v4 --mode fast # child vs parent's cached aggregate
$Z tournament v3 v4 --skip-regression # bypass the regression gate
tournament does NOT encode the verdict in its exit code. It prints a JSON
result payload and exits 0 for both promote and reject; a usage/config problem
raises a click.ClickException (exit 1). The fine-grained codes the design
docs describe (6=reject etc.) are not implemented — read the decision in
the printed JSON, do not branch on the exit code for promote-vs-reject.
All paths are under .zicato/epochs/<epoch>/:
insights/round_{N}.md — analyzer output (stage 1).generations/vN/experiment.json — hypothesis (written before scoring) +
patch_ids + the outcome block (written after the tournament).generations/vN/patches/*.json — one file per patch.generations/vN/runs/<entry>/{events.jsonl,loss.json} — per-entry telemetry.journal.md — appended at each promote/reject.Read these between stages rather than re-running. After any hand-edit of a
canonical file, run zicato reindex so index.db re-derives (see
zicato-index-ops).
zicato evolve (it orchestrates all of the above and
launches the dashboard; report its URL, default http://127.0.0.1:7892).zicato-triage-stuck-loop.zicato-design-experiment.docs/design/CLI.md — full subcommand reference and exit codes.docs/design/EPOCHS-AND-JOURNALING.md — the Experiment artifact + journal.docs/design/SCORING.md — what the tournament gate decides.docs/design/MUTATION-SURFACE.md — what mutations enumerates.zicato-index-ops, zicato-design-experiment,
zicato-triage-stuck-loop.The board-builder copilot's deep board-craft guide — designing board entries, judges, and the weighted loss through a GUI as a DRAFT applied on confirmation. Use when a copilot is helping an operator design a board, declare judges, shape the loss to express an objective, hold out a slice, or fix a toothless eval. Covers entries (single/multi-turn, expectations, tags incl. holdout, weight), judges (declared/in-run, judge_name, per_judge_weights, board_meta, the collusion-guarded emulator), and how the loss knobs combine to express an objective. Defers the exact scalar formula to SCORING.md, the schema to BOARD-FORMAT.md, anti-overfitting to OVERFITTING.md, discrimination diagnosis to LOOP-HEALTH.md.
The tournament-builder copilot's guide to helping an operator assemble a whole zicato evaluation contract through a GUI — structure, field_size/replicates, per-structure params, the board & train/holdout split, the overfitting block, the proposer (quality/screen/memory), the weights, and the promote gate incl. the evidence gate — as a DRAFT edited through tools and applied only on confirmation. Use when a copilot is walking an operator through building a tournament. Teaches the consequence-forward discipline (every choice carries a COST in board-runs and a CONTRACT impact — applying rolls the epoch) AND the statistical-soundness discipline (the margin must clear the measured noise floor; preflight the draft before burning rounds). Defers structure choice to zicato-design-tournament-structure, board craft to zicato-build-board, holdout detail to OVERFITTING.md, proposer to zicato-design-proposer, gate weights to SCORING.md.
The entry point for CHANGING zicato's own source (not operating a workspace). Routes to the full 14-chapter development guide under docs/dev-guide/ (~22k lines, code-grounded), and inlines the non-negotiables an agent must never skip — the 10 Golden Rules, the chapter map (which chapter owns which surface), the pre-commit verification ladder, and the ten shipped bugs with the one-line tell for each. Use whenever you edit orchestrator/proposer/tournament/selection/scoring/runtime/storage/supervisor/dashboard/builder/CLI code, add a contract knob, touch the evaluation statistics or the overfitting envelope, or write tests. The operator skills (zicato-evolve, zicato-design-boards, …) teach how to RUN the loop; this teaches how to safely CHANGE it.
Tier 2 run — the flagship operating skill for driving `zicato evolve` (the self-improving loop). Choose --rounds / --mode / --max-wall-clock-seconds / stop conditions, launch with the live dashboard, and report the URL. Use this to run an evolve loop. ENFORCES the live-run gate — a real-LLM evolve requires the user's explicit go-ahead.
Trace a zicato run through its telemetry — the canonical per-run events.jsonl and loss.json, and the harmonograf session that renders it — and relate zicato's own meta-loop session (the tool itself) to the per-board-run sessions (the system under test). Use when you need to follow what a specific run did, read its drift/loss profile, or deep-link into harmonograf.
Edit a zicato scoring.json — drift-loss weights, per_judge_weights/default_judge_weight, severity and per-kind weights, the declarative transform registry (pass_transform / drift_kind_aggregation), the dotted-spec scalar_fn / drift_reducer plugins, and the promotion gate (promote_margin + pass_rate_monotonicity). Use when calibrating how generations are scored or when tournament decisions disagree with operator intuition. Lower scalar = better.