القائمة
Use immediately before moving or publishing a checkpoint, and after downloading it, to generate or verify a lightweight SHA-256 file manifest.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | checkpoint-integrity |
| description | Use immediately before moving or publishing a checkpoint, and after downloading it, to generate or verify a lightweight SHA-256 file manifest. |
This is a narrow file-integrity check, not a model-quality or inference-contract gate. It hashes the checkpoint bundle without loading the model. Evaluation and deployment audits own semantic correctness.
Assemble the exact files to publish or move. Include weights, model config, processors, normalization assets, and useful README/training records.
Exclude optimizer state, caches, transient W&B staging files, and symlink aliases unless the user explicitly wants them.
Generate the manifest immediately before transfer:
uv pip install -e ../autohpc/checkpoint-integrity
manifest-checkpoint <checkpoint_or_publish_dir>
Upload or copy the bundle, including CHECKPOINT_MANIFEST.json.
After download, and before eval or deployment, run:
verify-checkpoint <downloaded_dir>
Stop if a declared file is missing or its size/hash changed. Extra files are
warnings by default because registries may add metadata such as
.gitattributes; use --strict when exact contents are required.
Use before running a checkpoint on a robot or inference rig to audit the real sensor-to-action chain using saved model assets, runner code, and live or replay samples.
Use when evaluating checkpoints to maintain a persistent log of what was evaluated, the metrics, qualitative assessment, and verdict.
Use before committing to a full training run to reconcile a base model's baked-in expectations against the training config and the actual dataset, catching semantic mismatches (normalization, feature order, units, encoding) that build and run fine but silently ruin results.
Use when submitting, monitoring, or reviewing HPC training runs to maintain a persistent log of each run's config, status, results, and next steps.
Use when running ML training workflows on Slurm-based HPC clusters, including environment setup, data and image transfer, job submission, monitoring, debugging, and storage cleanup, especially when notes are ad-hoc, usernames differ, or commands may expose secrets.
Use when preparing cluster-ready containers by validating a repo locally with Docker and promoting the result into the container artifact or runtime required by the target cluster.