agentleFS
tim-osterhustim-osterhus/millrace-skills/skills/fine-tuning/SKILL.md

fine-tuning

Skill0 starsChanged 7 months agoApache-2.0View on GitHub

Guardrail for using fine-tuning pipelines through CLI or YAML: SFT, preference tuning, LoRA settings, checkpoint evaluation, and experiment tracking.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Start with a smoke run.

    line 31
  2. Distinctive:

    Do not train before validating data.

    line 37
  3. Distinctive:

    Do not change source code when the requested surface is CLI or YAML usage.

    line 38
  4. Distinctive:

    Do not adopt a checkpoint from training loss alone.

    line 39
  5. Distinctive:

    Use held-out evals and task-specific metrics.

    line 40
  6. Distinctive:

    Keep secrets and private data out of logs, configs, and published artifacts.

    line 42
  7. Distinctive:

    Run a one-step or tiny-slice smoke test.

    line 61
  8. Distinctive:

    Run the full job only after smoke passes.

    line 62
  9. Distinctive:

    Start with dataset validation and smoke execution.

    line 75

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Fine Tuning

Purpose

Help agents operate a fine-tuning workflow through an existing CLI or YAML configuration without modifying training system source code. This skill covers run planning, dataset requirements, LoRA settings, monitoring, checkpoint comparison, and adoption decisions.

Quick Start

  1. Confirm the task is to use the training system, not edit it.
  2. Validate dataset schema, splits, labels, length, and sensitive content before training.
  3. Start with a smoke run.
  4. Log configuration, baseline metrics, checkpoint metrics, and artifacts.
  5. Compare checkpoints against held-out evals before adoption.
  6. Preserve rollback and reproducibility.

Operating Constraints

  • Do not train before validating data.
  • Do not change source code when the requested surface is CLI or YAML usage.
  • Do not adopt a checkpoint from training loss alone.
  • Use held-out evals and task-specific metrics.
  • Track seeds, model, dataset version, LoRA config, runtime, hardware, and commands.
  • Keep secrets and private data out of logs, configs, and published artifacts.

Inputs This Skill Expects

  • Training CLI or YAML schema.
  • Dataset files, split definitions, and validation rules.
  • Baseline model and baseline eval results.
  • Training objective, hardware, runtime, budget, and artifact destination.
  • Checkpoint evaluation command or metric policy.

Output Contract

  • Provide a validated training plan or blocked status.
  • Include exact CLI/YAML settings, dataset version, smoke command, full run command, and evaluation command.
  • Report checkpoint results against baseline and held-out data.
  • State adopt, reject, or iterate with the reason.

Procedure

  1. Identify training type and target behavior.
  2. Validate dataset and split integrity.
  3. Choose conservative initial hyperparameters and LoRA settings.
  4. Run a one-step or tiny-slice smoke test.
  5. Run the full job only after smoke passes.
  6. Monitor logs and save artifacts.
  7. Evaluate checkpoints and compare to baseline.
  8. Record decision and rollback path.

Pitfalls And Gotchas

  • Treating lower training loss as product improvement.
  • Leaking eval rows into training.
  • Forgetting tokenizer length and truncation checks.
  • Publishing private data through model cards or logs.
  • Tuning many hyperparameters without controlled experiment records.

Progressive Disclosure

Start with dataset validation and smoke execution. Expand into advanced tuning, preference methods, cloud jobs, or LoRA surgery only when baseline training evidence justifies it.

Verification Pattern

  • Confirm dataset validation passes before training.
  • Confirm smoke run passes before full run.
  • Confirm checkpoint evaluation uses held-out data.
  • Confirm adoption criteria include quality, safety, latency, and rollback.
  • Confirm run metadata is reproducible.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.