Cut a LibreYOLO version release end to end: evidence-backed changelog built by fan-out agents over the release..dev diff, a gate scoreboard (unit CI, GPU e2e on Modal reusing the nightly, weight autodownload probe, wheel smoke, notices sync, docs drift, breaking-change sweep), the branch/tag/PyPI mechanics, post-publish verification, and the handoff to the marketing repo's announcement pipeline. Use whenever the user says "release", "cut vX.Y.Z", "ship a version", "prepare the changelog for the release", or "is dev ready to release?".
Use LibreYOLO as a computer vision library: run inference, train, validate, export, and track with object-detection / segmentation (and pose, classify, gaze, OBB, semantic, depth, point, restore) models on your own images and video. This is the guide for *using* the `libreyolo` pip package — not for contributing to or developing it. Use whenever someone wants to detect, segment, or track with a YOLO9 or RF-DETR model, train on a YOLO-format dataset, measure mAP, run inference on an exported model, or export to ONNX / TensorRT / OpenVINO / CoreML / NCNN / TFLite. Covers both the `libreyolo` CLI and the `from libreyolo import LibreYOLO` Python API.
Add or extend a LibreYOLO CLI command or flag correctly: the Typer + KeyValueCommand architecture, both argument grammars (key=value and --key value), the --json/--quiet/--help-json contract, mode-aware aliases, family-derived defaults, and the unit tests that gate CLI behavior. Use when someone asks to add a CLI command, add a flag to predict/train/val/export, expose a Python feature on the CLI, or when a CLI parsing bug is reported (bool flags, aliases, key=value quirks). API naming decisions belong to libreyolo-api-conventions; this is the implementation side.
Add a new task type to LibreYOLO (a new output kind like detect, segment, semantic, pose, classify, gaze, obb, point, depth, restore), as opposed to adding a model family to an existing task. Use when someone proposes a new capability that no current task's result/label/metric contract fits, e.g. "add OCR", "add 3D boxes", "add image enhancement as a task". Covers the decision (new task vs existing task), and the full wiring checklist: tasks.py registration, the Results payload class, dataset loader + schema, validator, trainer support, filename suffix, docs/ADR, and the tests that gate each piece. For porting a model into an existing task use libreyolo-port-model.
The rules every user-facing LibreYOLO surface must follow (Python API, CLI, dataset YAMLs, metric keys, Results fields) and the safe method for checking parity with the de-facto YOLO ecosystem conventions. Use when designing or reviewing any new public API, CLI command or flag, train/val kwargs, metric names, or Results attributes; when someone asks "what should this be called?", "should predict return a list?", or "is this compatible with standard YOLO tooling?"; or when an API-parity gap is reported. Encodes the AGENTS.md rule that user-facing APIs follow the ecosystem standard, and the license-safe way to verify that (docs only, never source).
Inspect, validate, produce, and debug LibreYOLO .pt checkpoint metadata. Use when a checkpoint won't load ("not a LibreYOLO checkpoint", wrong family/task/class-count errors), when writing or reviewing a conversion script, when deciding what a converter must emit, when preparing weights for HF upload, or when a schema change is proposed. Covers the inspection commands, the serialization helpers that are the only sanctioned writer/reader, the lean-vs-training checkpoint distinction, the legacy/foreign-weights paths and auto-conversion, and the contract-change protocol. The schema itself lives in docs/checkpoint_schema.md; this skill is how to work with it.
Work on LibreYOLO's export subsystem: debug a failing export, fix an exported model that predicts differently from the .pt, extend a format's coverage to a new family/task, or add a new export format. Use when someone reports "export to X fails", "the ONNX/TensorRT model gives different results", asks which formats a family supports, or wants a new format wired. Covers the exporter/backend twin architecture, the metadata round-trip contract, per-format quirks and extras, the parity-testing method, and the support-claim bar. For a user just running export, see use-libreyolo; for Hailo specifically, libreyolo-export-hailo.
Audit and maintain LibreYOLO's licensing and provenance surfaces, and handle contamination correctly. Use when adding ported code or weights (which notice files must change), when reviewing a PR for license risk, when someone asks "can we use/host/ship X?", when a family's provenance is questioned, or when GPL/AGPL/NC-licensed material may have touched the work. Covers the four notice surfaces and when each changes, the code-vs-weights license distinction, the decision table for common licenses, the contamination protocol, and the hard rules: no clean-room laundering, surface decisions to the maintainer instead of quietly "fixing" them.