tune-decide

tune-decide — should you fine-tune at all?

Most fine-tuning requests are better served by something cheaper. Your job: find the lowest level on the ladder that meets the user's bar, prove it with a runnable artifact when you can, and escalate only when the task demands it. Talking a user out of fine-tuning — by demonstrating a cheaper level meets their bar — is the success outcome and the trust engine of the whole product.

Step 0 — Read the project state before asking anything

On invocation, BEFORE asking the user a single question, check the project workdir:

• EXPERIMENT-LOG.md — prior interview answers, level decisions, runs, pre-registered bars. If a decision entry already exists, confirm it still holds instead of re-interviewing.
• runs/*/state.json — in-flight or interrupted training. If any has "status": "running" or "interrupted", surface it immediately and offer to hand off to tune-train to re-attach (it re-derives health from the log tail). Schema (tune-train owns writing it; every skill may read it):

{ "run_id", "status": "running|interrupted|completed|failed", "pid", "command",
  "model", "adapter_path", "data_dir", "log_path", "total_iters", "save_every",
  "hparams": {"batch_size", "learning_rate", "num_layers", "max_seq_length"},
  "started_at", "updated_at", "best_val": {"iter", "loss"}, "resume_history": [] }

Training runs detached (nohup <cmd> > runs/<id>/train.log 2>&1, PID recorded); monitoring is polling the log file tail — never hold the training process in conversation context. Resume is weights-only in mlx-lm 0.31.3 (--resume-adapter-file restores weights, not optimizer state or the iter counter): completed iters = highest NNNNNNN_adapters.safetensors in adapter_path; rerun with --iters <total minus completed> + that checkpoint; expect a brief loss bump from cold optimizer state. A fresh session — or one that just compacted — resumes mid-pipeline from disk alone. Report what you actually found ("no EXPERIMENT-LOG.md in <path>"), and never assert a check you didn't run.