Skip to main content

report

Read-only evo run reporting. Use when the user invokes /evo:report, asks what happened overnight, asks what improved recently, asks for the best/frontier candidates, asks for a quick score chart without opening the dashboard, or wants the scatter plot in chat output. Never run benchmarks, gates, Slurm commands, evo run, or ad-hoc verification scripts for report requests.

Zur Installation springen

Quellinformationen

Repository
evo-hq/evo
Letzte Quellaktivität
17. Juli 2026 um 16:52
Erkannte Sprache von SKILL.md
Englisch
Sterne
1.459
Forks
111

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
name
report
description
Read-only evo run reporting. Use when the user invokes /evo:report, asks what happened overnight, asks what improved recently, asks for the best/frontier candidates, asks for a quick score chart without opening the dashboard, or wants the scatter plot in chat output. Never run benchmarks, gates, Slurm commands, evo run, or ad-hoc verification scripts for report requests.
evo_version
0.8.0
# Report Report the current evo workspace from recorded state only. A report request is read-only, even if the user phrases it casually as "what happened?", "what got better?", "what should I pay attention to?", or "I just woke up". Do not spend compute while reporting: - Do not run `evo run`, `evo gate check`, benchmark commands, or project eval scripts. - Do not run `python bench.py`, `python slurm_eval.py`, `sbatch`, `srun`, `squeue`, `sacct`, or `scancel` to verify a result. - Do not create launcher, monitor, parsing, or analysis scripts. - Do not edit files. Use stored evo state instead: `evo report`, `evo status`, `evo tree`, `evo frontier`, `evo show <id>`, `evo diff <id>`, and immutable artifacts under `.evo/run_*/experiments/<exp>/attempts/<NNN>/`. For chart requests, render the dashboard's scatter plot as a colored terminal block, one chart per run, sized to the current terminal. ## What it shows Mirrors the web dashboard's score scatter (left rail of `evo dashboard`): - X = experiment creation order, Y = score - Dot color by status: green = committed valid result, red = failed, purple = active, grey = pending / evaluated / discarded / pruned - ★ marks the current best valid committed-result experiment. `pruned` with `prune_kind=exhausted` can still be best; `prune_kind=invalid` and its descendants cannot. - Yellow ring on dots that sit on the best-path spine (root → best) - Yellow stair line traces cumulative-best across valid committed-result experiments - ○ at the baseline for experiments that have no score yet (active / pending) Every run in the workspace is rendered, stacked top-to-bottom, with a header line showing `run_id · target · metric`. ## How to invoke Run: ```bash evo report ``` That is it. Print the output verbatim in your reply so the user sees the chart. Do not summarize the chart in prose — the visual is the point. Flags: - `--color always|never|auto` — force or suppress ANSI color. Default `auto` (color when stdout is a TTY). Pass `--color always` if you are piping through a host that strips TTY but renders ANSI in chat. - `--watch [SECONDS]` — live-refresh mode (like `nvidia-smi -l`). Re-reads the workspace every N seconds (default 2) and redraws in place. Ctrl-C to exit. Use this when you want to babysit a running optimization without manually re-invoking the report. ## When not to use - For one-off score lookups, `evo status` or `evo show <id>` is faster. - For navigating the tree shape, `evo tree` is the right command. - For interactive exploration (click a dot, open a drawer), point the user at `evo dashboard` instead. ## Overnight / Improvement Reports When the user asks what happened recently or what improved, summarize from recorded evo state: 1. Run `evo status`, `evo frontier`, and `evo tree`. 2. Use `evo show <id>` for the best node and any recent committed/evaluated nodes you mention. 3. Use `evo diff <id>` only to explain what changed in a recorded experiment. 4. If you need benchmark details, read the existing `outcome.json`, `benchmark.log`, or declared artifacts for that experiment. Treat missing artifacts as "not recorded", not as permission to rerun. Report: - best current experiment and score; - score delta versus baseline or parent; - top candidates/frontier if relevant; - failed/evaluated nodes that need attention; - any caveats about gates, missing held-out checks, or tied candidates. If the user wants fresh validation or reruns, ask them to explicitly start a new optimization or evaluation command. Do not infer that from a report request.
Auf GitHub ansehen