name: explore-dnn-model description: Manual invocation only; use only when the user explicitly requests explore-dnn-model by name. Explore how to run a given DNN model checkpoint in the current Python environment by locating weights + upstream source code, resolving dependencies with user confirmation, running reproducible experiments under tmp/, and producing reports about I/O contracts, timing, and profiling.

Explore DNN Model

Minimum Required Inputs (Hard Requirement)

To use this skill, the user must provide:

• A model checkpoint / model file(s) as a local file or directory path (it may be outside the workspace).

If the user provides only the checkpoint path (no model name, repo link, or source code), proceed by:

1. Attempting to identify the model name/family from the checkpoint file/dir itself (filenames, adjacent configs/README, embedded metadata, state_dict key patterns, etc.).
2. Searching for the implementation in the workspace and/or alongside the checkpoint directory (e.g., nearby Python packages, inference scripts, config files).
3. If still not found, using the best-guess model name/family to search online for the canonical implementation, then cloning the upstream source into tmp/<experiment-dir>/refs/ for investigation (prefer shallow clone; record URL + commit/tag used).

Goals

This skill has three goals:

1. Verify that the given DNN model can work (inference or training; default focus is inference) in the current Python environment of the workspace.
2. Determine how to use it (inference or training; default is inference) by reading the upstream source code and producing minimal, reproducible runs.
3. Produce two reports:
   • Experiment report (programmatic): generated from tmp/<experiment-dir>/outputs/ with minimal/no reasoning.
   • Stakeholder report (agent-written): generated by the agent from the experiment report + outputs/logs, with deeper analysis and recommendations.

The reports cover:

• Input and output contracts (formats, shapes, dtypes, preprocessing/postprocessing)
• Benchmarks and performance profiling (latency/throughput/memory, device details)
• User-provided metrics/targets (e.g., accuracy, mAP, IoU, F1, latency budget), and whether/how they are met

Before changing anything, detect how the environment is managed by checking for:

• pixi.toml and/or pyproject.toml (Pixi-managed project)
• .venv/ (venv-managed project)

Dependency Policy (Ask Once, Then Apply)

If any dependency is missing:

• Do not install it automatically without user confirmation.
• List the missing packages (and versions/constraints if known) and ask the developer how to proceed.
• Provide clear options, let the developer choose, then proceed with the chosen approach.
• Once the developer confirms an approach, apply it for all newly required packages (no need to ask approval per package).

Version Strategy

• First attempt: use the latest versions resolved by the selected package manager (pixi, pip, uv).
• If that fails (import/runtime errors, incompatibilities): fall back to the specific versions/constraints documented by the model’s upstream source code or docs.

Preferred Options (in order)

Pixi-managed env

• Ask the user to choose one:
  • Modify the current Pixi environment by adding deps to the relevant manifest (pixi.toml / pyproject.toml).
  • Create a new Pixi environment specifically to test this model.
• Then use pixi install/pixi run ... to execute.
• Prefer PyPI packages over conda-forge when both are available.
• Avoid direct pip install ... into the Pixi environment unless the developer explicitly requests it.

.venv-managed env Ask the user to choose one:

• Install deps via pip (or uv pip) into the current .venv.
• Create a new venv specifically for this model (keeps the repo venv clean).

Inputs to Collect (ask if missing)

• Model name and/or upstream repo link and/or source code path (optional but speeds up identification)
• Model task/modality if unclear (classification/detection/segmentation/embedding/audio/video/etc.)
• Checkpoint path (file/dir) and format (.pt, .pth, .onnx, .engine, etc.)
• Any known I/O contract details (expected resolution, channel order, normalization, label mapping), if the user has them
• CPU-only requirement (only if the user explicitly requests CPU-only)
• Optional: user-provided metrics/targets to evaluate (quality and/or performance)

Notes:

• Determine framework/runtime automatically from checkpoint type + upstream code/docs + what’s available in the current Python environment.
• If hardware is unspecified, default to using hardware acceleration when available (CUDA GPU, ROCm GPU, Apple MPS, etc.). Use CPU-only only if the user requested it.
• If unspecified, the default objective is to confirm the model runs end-to-end from input → output (prefer real inputs found in the workspace; synthesize as a fallback) and record end-to-end timing.

Core Workflow

0) Confirm artifacts and pick the target environment

• Confirm the minimum required inputs are present:
  • Checkpoint/model path is accessible locally (file/dir exists). It may be outside the workspace.
  • If model name/repo/source path is not provided, start by inferring it from the checkpoint and nearby files; if needed, locate it online and clone into tmp/<experiment-dir>/refs/.
• Detect environment type:
  • If both Pixi and .venv exist, ask the user which one should be treated as the “current” environment for this exploration.
• Device default:
  • If the user did not request CPU-only, use hardware acceleration when available (CUDA/ROCm/MPS/etc.).

1) Locate and read the upstream source code/docs

• First try to find the implementation locally:
  • Search the workspace and the checkpoint directory for source code, inference scripts, configs, and docs.
  • Prefer local source if it appears to be the canonical/official implementation for the checkpoint.
• If local source is not available or is clearly incomplete, use online search to find the canonical implementation:
  • Official GitHub repo, paper, model card, or vendor docs.
  • Check out the upstream repo under tmp/<experiment-dir>/refs/<repo-name> using a shallow clone (--depth=1), pinning a tag/commit when possible.
• Download/check out the relevant source code (pin a tag/commit when possible) and identify:
  • The exact inference entrypoints (scripts/modules), model class, preprocessing, postprocessing, and label mapping.
  • Any config files required to construct the model (YAML/JSON/TOML).
• Do not “guess” preprocessing/postprocessing: confirm from code and/or reference examples.

2) Derive required dependencies

Before running the model or changing the environment, determine the minimal dependencies required to run the model by using (in priority order):

• Upstream source code (setup files, requirements*.txt, pyproject.toml, import graph).
• Upstream docs/model card (pinned versions, known-good combos).
• Checkpoint type (e.g., .onnx implies ONNX Runtime; .pt/.pth implies PyTorch; .engine implies TensorRT).

Make a concise dependency list covering:

• Runtime/framework (e.g., torch, onnxruntime, opencv-python)
• Model-specific libs (e.g., ultralytics, timm, transformers, mmengine, etc.)
• Utility deps used by the official inference path (e.g., numpy, Pillow, pyyaml)
• Optional acceleration deps (CUDA/TensorRT) separated from the CPU baseline

3) Resolve missing dependencies (with user choice)

• Check whether each required dependency is available in the current environment.
• If anything is missing, ask the user which path to take:
  • Pixi: modify current manifest to add deps, or create a new Pixi env for this model.
  • Venv: install into current .venv, or create a new venv for this model.
• After the user confirms, apply the decision for all required packages (no per-package prompts).
• Use the Version Strategy above (latest first; fall back to pinned versions if needed).
• After dependency changes, run a quick smoke test:
  • Imports for the core runtime stack
  • Minimal “load model” path (without a full benchmark yet)

4) Ensure the checkpoint exists locally

• Do not download checkpoints automatically.
• Developers must provide checkpoints/model files (local file/dir paths).
• If the checkpoint is missing or only a URL is provided, ask the developer to download it and provide the local path.
• If the developer wants a conventional location, prefer checkpoints/ (gitignored).
• Record provenance in a short note (based on what the developer provides):
  • Claimed source URL(s) or repo, version/commit/tag (if known), file size, and (if feasible) SHA256.

5) Create an experiment workspace under tmp/

Default experiment directory:

<workspace>/tmp/<experiment-slug>-<time>

If the user specifies a different location/name, use the user-provided one instead.

Create the standard directory layout:

tmp/<experiment-dir>/
  README.md     # experiment intent + directory guide (keep updated)
  refs/         # checked-out upstream repos (use shallow clone for online checkouts)
    README.md
  scripts/      # throwaway but reproducible scripts (committed if useful)
    README.md
  inputs/       # downloaded/synthesized test inputs
    README.md
  outputs/      # artifacts + machine-readable stats (e.g., `stats.json`)
    README.md
  logs/         # logs (stdout/stderr, profiling traces, command transcripts)
    README.md
  reports/      # markdown notes: what was tried, params, results
    README.md
    figures/    # images embedded in reports
    experiment-report.md
    stakeholder-report.md

Shell safety note (avoid accidental directory names):

• Do not use bash brace expansion to create these folders (e.g., mkdir -p "$exp"/{refs,scripts,...}), because quoting/spacing mistakes can create literal directories like {refs,scripts,...}.

• Prefer a simple loop or explicit mkdir -p calls, for example:

  exp="tmp/<experiment-dir>"
  mkdir -p "$exp"
  for d in refs scripts inputs outputs logs reports reports/figures; do
    mkdir -p "$exp/$d"
  done
  

Conventions:

• Use relative paths from tmp/<experiment-dir> in scripts so the folder is movable.
• Keep scripts small and single-purpose (01_download_inputs.py, 10_infer.py, 20_visualize.py, …).
• Run Python via the selected environment manager:
  • Pixi: pixi run python ...
  • Venv: use the venv’s Python (avoid system Python)

README requirements:

• Create tmp/<experiment-dir>/README.md to describe:
  • The intention of the experiment (what model, what checkpoint, what question you’re answering)
  • How to reproduce (one-line pointer to the primary script(s))
  • A brief map of what each top-level subdir contains
• Each top-level subdir must have its own README.md that:
  • Describes what belongs in the folder
  • Notes any important changes (append a short “Changes” section as you iterate)

6) Collect or synthesize inputs

• First try to find suitable inputs already present in the workspace (e.g., under datasets/, downloads/, or other project-specific data dirs) based on what you learned from the checkpoint/source code (task, modality, expected resolution, file types).
• If no suitable inputs exist locally, synthesize minimal inputs that satisfy the model contract (e.g., generated images, random tensors saved in the expected container format, short synthetic video).
• Save all chosen/generated inputs under tmp/<experiment-dir>/inputs/.

7) Run minimal, traceable inference experiments (default: inference + end-to-end timing)

• Start with a single known-good example (from upstream repo) if available.
• Save every “input → output” mapping:
  • Inputs: the exact file(s) used + preprocessing parameters.
  • Outputs: raw model outputs + any decoded/visualized artifacts.
  • Command line + environment notes (device, precision, batch size).
• Measure end-to-end timing by default:
  • At minimum: one cold run + a small number of warm runs (record mean/median).
• Persist stats that will appear in the report:
  • For any timing/profiling/memory/throughput numbers you plan to put into the report, also write a JSON version under tmp/<experiment-dir>/outputs/ (e.g., outputs/stats.json).
• Capture logs by default:
  • Save stdout/stderr and command transcripts under tmp/<experiment-dir>/logs/.
• If the model is accessed via HTTP/gRPC, save request/response payloads (sanitized) under reports/ and/or outputs/.

7b) (Optional) Training sanity check

If the user asks to validate training (or if inference is insufficient to validate “works”):

• Start with a minimal configuration (single batch / tiny subset) to confirm the forward + backward pass runs.
• Record key configs (optimizer, LR, batch size, mixed precision) and any dataset assumptions.
• Do not run long trainings unless the user explicitly requests it.

8) Produce reports

8a) Ensure machine-readable report inputs exist (in outputs/)

Write/collect machine-readable files in tmp/<experiment-dir>/outputs/ that the report generator can consume, at minimum:

• stats.json (timing/throughput/memory/profile numbers)
• A JSON describing key parameters used (preprocess/postprocess/runtime thresholds)
• A JSON describing the I/O contract (input expectations + output structure)
• A JSON listing key artifacts produced (paths to representative inputs/outputs)

Keep these JSON files as the source of truth for anything that will appear as “final stats” in the experiment report.

8b) Generate reports/experiment-report.md programmatically

• Generate tmp/<experiment-dir>/reports/experiment-report.md by reading only tmp/<experiment-dir>/outputs/ (and optionally logs/ for pointers), with minimal/no reasoning.
• If images are part of the inputs/outputs, copy representative images into tmp/<experiment-dir>/reports/figures/ and embed them in the markdown via relative paths (e.g., figures/<name>.png).

8c) Write reports/stakeholder-report.md (agent-written)

• Read reports/experiment-report.md plus relevant outputs/ and logs/.
• Produce tmp/<experiment-dir>/reports/stakeholder-report.md with deeper analysis that requires reasoning:
  • Interpret results vs expectations/targets
  • Call out risks, assumptions, and failure modes
  • Recommend next experiments and concrete integration guidance (if requested)
  • Summarize “go/no-go” criteria and what remains unknown

Also include:

• Benchmark & profiling results:
  • CPU/GPU model, RAM/VRAM, OS, Python version, key library versions
  • Latency breakdown if possible (preprocess / model / postprocess)
  • Throughput (items/s) and peak memory/VRAM
• Stats JSON:
  • For any stats included in the report, ensure the same values exist in a JSON file under tmp/<experiment-dir>/outputs/ (e.g., outputs/stats.json).
• User metrics (if provided):
  • The metric definition + measurement method
  • Results on the chosen evaluation inputs
  • Any deltas vs the user’s targets and suggested next experiments

Guardrails

• Do not commit large checkpoints or huge outputs; keep them under gitignored paths (checkpoints/, tmp/).
• Respect upstream licenses; record the repo URL + commit/tag in reports/.
• Avoid modifying runtime code under src/ unless the user explicitly requests integration; keep exploration isolated to tmp/<experiment-dir>.