| name | infer-init |
| description | Use this skill to analyze inference code and configure the inference stage. Triggers when the user wants to set up inference for a model — analyzing what a prediction script needs (model weights, input data), what outputs and performance metrics it produces, and filling the 4 JSON config files. Use for: "analyze inference code", "set up inference", "configure inference stage", "what does this script need to run", "分析推理代码", "配置推理", "初始化infer", "设置推理流程". Not for running inference (use infer-run) or evaluation with ground truth (use eval-init).
|
/infer-init — Inference Stage Initialization
Analyze inference code and fill 4 JSON config files (schema only) in stages/inference/. The goal is to understand what the code needs and produces, so /infer-run can execute it correctly later.
How this skill works
The user brings inference code (a standalone predict.py, detection pipeline, or inference mode inside a larger codebase). You read it, figure out what it needs (model weights, input data) and what it produces (predictions, detections, visualizations, performance metrics like FPS), then capture that understanding in 4 structured JSON files.
These files are schema only — they define WHAT is needed, not WHERE to get it. Concrete paths come later during /infer-run. However, if the user volunteers source locations during init, record them.
Interaction approach
Ask one question at a time. Users find it overwhelming when asked to fill multiple fields simultaneously — each question should feel like a natural follow-up to the previous answer. Record the answer, then ask the next.
On entry
Follow the standard Workflow State Protocol from CLAUDE.md: push to stack, check dependencies (project.json exists, code available), locate project, resolve code directory. These are all documented in CLAUDE.md — follow them, don't duplicate them here.
Output: 4 JSON files
| File | What it captures |
|---|
config.json | Entry command, config format, framework, managed params |
artifacts.json | Static inputs — model weights, decoders, label maps (items only, no paths) |
input.json | Dynamic inputs — images, video, text fed per run (items only) |
output.json | What the code produces — result files, visualizations, metrics definitions |
For item/source schemas and type classification rules, read references/schemas.md.
Step 1: Analyze Code
Read all code files (*.py, *.sh, *.yaml, *.yml, *.json, *.toml) under the code directory.
For pattern recognition guidance (entry points, input/output detection, metrics extraction), read references/detection-patterns.md.
Determine:
- entry_command: how to run inference (e.g.,
python detect.py --source data/ --weights model.pt)
- config_format: argparse, yaml, omegaconf, json, hydra, or combination (e.g., "argparse+yaml")
- config_path: where the config file lives relative to code/
- framework: pytorch, onnxruntime, tensorrt, custom, etc.
- Artifacts -> model weights, decoders, label maps, static configs
- Inputs -> images, video, text, or directories of data
- Outputs -> prediction files, annotated images, JSON results, visualizations
- Metrics -> performance values the code reports (FPS, latency, throughput), with extraction patterns
- Required packages: run
python lifecycle/scripts/infer-init/scan_requirements.py <code_dir>. If it fails, check requirements.txt manually.
For metrics: after identifying them, ask the user which ones to track across runs. Their selection goes into output.json -> metrics.watch. Inference metrics are typically performance-oriented (FPS, latency, throughput) rather than accuracy metrics, which belong in the evaluation stage.
Step 2: Discover Real Config
Look for actual config files in the code directory:
- Check config_path from analysis
- Scan
configs/, config/, conf/ directories
- Prefer files named "infer", "inference", "predict", "detect", "default", "baseline", "base", "main"
- Pick the largest YAML file as fallback
If found, load all discovered parameters.
Step 3: Select Managed Parameters
Config files often have dozens of parameters. Instead of dumping them all, use progressive disclosure — this respects the user's attention and helps them focus on what matters:
3a. Show category summary:
Config: configs/default.yaml (47 parameters)
Categories:
Data paths: 5 params (input dirs, output dirs)
Model: 3 params (weights path, architecture, num_classes)
Runtime: 8 params (batch_size, num_workers, device, ...)
Preprocessing: 12 params (resize, normalize, augmentation, ...)
Postprocessing: 6 params (NMS threshold, confidence, ...)
Other: 13 params
Which categories do you want to see?
3b. Expand requested categories with current values, let user pick which MLClaw should manage per run.
3c. Record: selected params -> config.json -> runtime_params with ${artifact.xxx} / ${input.xxx} references where applicable. Unselected params stay in original config files untouched.
Step 4: Present Each File for Review
Show each JSON file one at a time in order: config.json -> artifacts.json -> input.json -> output.json.
For each file: show proposed content, then wait for the user to confirm before moving on. The reason for presenting one at a time is that each file builds on the previous — the user can catch issues early before they cascade. If the user says "skip", accept remaining files as-is.
Step 5: Validate
Run python lifecycle/scripts/infer-init/validate_refs.py <stage_dir>. If the script fails, check manually:
- Entry script file exists in code/
- All items have a valid
type field
${artifact.xxx} / ${input.xxx} / ${output.xxx} references match actual keys- config_path file exists (if specified)
- config_format is valid
Don't save if there are broken references — the user needs to fix those first, otherwise /infer-run will fail downstream.
Step 6: Save
Write all 4 JSON files to {project.root}/stages/inference/. Update workflow state per CLAUDE.md protocol. Offer /infer-run as next step.
