Skip to content
Back to skills

Ds Handoff

ASecurity

Packages a project so someone else can rerun it — pinned environment, model card, and a rerunnable artifact. Hard gate — refuses to proceed without exact pinned versions. Use when someone asks to make work reproducible, pin dependencies, or write a model card. Use when a project is being handed to another person or team.

  • 3 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 6, 2026
datarustgo

Security analysis

A100/100

Scanned September 6, 2026

npx -y skills add StamKavid/last-ds-mile --skill ds-handoff --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Ds Handoff?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Ds Handoff
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/stamkavid-ds-handoff/badge)](https://www.skillsdirectory.com/skills/stamkavid-ds-handoff)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: ds-handoff
description: Packages a project so someone else can rerun it — pinned environment, model card, and a rerunnable artifact. Hard gate — refuses to proceed without exact pinned versions. Use when someone asks to make work reproducible, pin dependencies, or write a model card. Use when a project is being handed to another person or team.
---

# ds-handoff — Reproducibility & Handoff

## Overview

Packages the finished work so someone else can rerun it, trust it, and know its limits —
the last mile the whole plugin is named for.

## When to Use

- The model or analysis is ready to be shared, deployed, or handed to another team.
- After `/ds-report` has produced the stakeholder narrative and limitations.
- NOT for: further tuning or re-evaluation — if the model isn't finished, go back to
  `/ds-model` or `/ds-evaluate` first.

## Core Process

1. **Gate check:** confirm the environment is pinned — a lockfile, or a
   `requirements.txt`/`environment.yml` with exact versions, not bare package names. If
   it isn't pinned, stop and pin it before continuing.
2. Write a model card: what it predicts, a training-data summary, the metric and its
   baseline lift, known limitations (from `/ds-report`), and intended vs. out-of-scope
   use.
3. Confirm the notebook or script reruns cleanly top-to-bottom in a fresh
   kernel/environment before considering the work done.
4. Serialize the model artifact together with its version and the training-data
   hash/date, recorded alongside it.
5. Write to `.last-ds-mile/stages/10-handoff.md`: the model card, the environment pin
   location, the rerun confirmation, and the artifact location.

## Common Rationalizations

See `ds-method` for the shared Rationalizations that apply to every stage, in particular
"it's just exploratory, I'll clean this up before shipping" — the notebook-nobody-could-
rerun failure mode this stage exists to prevent.

## Red Flags

| Red Flag | What it usually means |
|---|---|
| The environment file lists packages with no version numbers | This is exactly the condition the Gate Check above exists to catch — unpinned environments are how "works on my machine" ships. |

See `ds-method` for the shared Red Flags that apply to every stage.

See `lessons/the-notebook-nobody-could-rerun.md` for a real example of a
handoff that looked done but wasn't reproducible.

## Verification

- [ ] Gate check passed: the environment is pinned with exact versions.
- [ ] Model card written, including intended and out-of-scope use.
- [ ] Notebook or script reruns cleanly in a fresh environment.
- [ ] `.last-ds-mile/stages/10-handoff.md` written.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.