autosprint

Interview the user to produce or refine autosprint/destination.md — the sole target-state input to the autosprint PIT loop. For an existing destination.md it first assesses each section against a quality rubric and recommends fixes, then walks a 3-pass interview (Foundation, Quality bar, Optional concerns). Every section gets a recommended answer and one of three outcomes — answered with a concrete answer, marked open for autosprint to decide, or skipped entirely. Use when the user says "grill me about destination", wants to write or revise destination.md, or is starting a new project.

After a general destination grilling, run a data-science-specific second pass to clarify staged workflow, exploration budgets, metrics, and experiment logging. Use when the user has finished grill-destination on a data-science project and says "grill me on data science", or when the project's purpose involves model training, experimentation, or metric-driven iteration.

Vet and sharpen the pending tasks in autosprint/plan.md so each is agent-ready before an autosprint run executes them. Walks plan.md task by task against an executability rubric — concrete, scoped, testable, self-contained, real, destination-aligned — and flags weak tasks with a sharper rewrite, a split, a drop, or a convert-to-decision. Use during the hand-review of a plan drafted by `autosprint plan`, or whenever the user wants to tighten a plan before running it. Use when the user says "grill the plan", "sharpen plan.md", "are these tasks agent-ready", or "review the plan".

Build autosprint/waypoint.md from a GitHub issue. Fetches the issue via `gh`, extracts purpose and acceptance criteria from its body and comments, interviews the user only when needed to fill genuine gaps, then renders the waypoint following the canonical template. The autosprint loop will then aim at the issue exclusively until the team lead concludes the waypoint state is satisfied. Use when the user says "make a waypoint from issue

Estimate how much of autosprint/destination.md is already implemented — a fast "how far along the route are we" read. Decomposes destination.md into discrete requirements, checks each against the actual codebase and its tests, and reports a status table (done / partial / not started / unclear) with code evidence plus a headline count. Read-only — it measures distance to the destination, it does not plan or change anything. Use when the user asks "how far are we", "how far from destination", "how much is done", "what's left to build", or "are we close".

Refactor Python code following project conventions — structure, style, error handling, formatting. Use when user asks to refactor, clean up, or improve Python code, or mentions error handling.

Consolidate a test suite by deleting overlap, parametrising clones, and pruning dead coverage — never at the cost of losing a line of coverage. Use when user asks to refactor tests, deduplicate tests, or mentions test bloat, test consolidation, or "too many tests".

Read `todos.md` at the repo root and execute each unchecked task in order, marking `[]` → `[x]` in the file as each task completes. Each `[]` line marks the start of a task; the text following it (until the next `[]` or end of file) is the task description. Use when the user says "see todos.md", "do todos", "run todos", or otherwise asks to process the todos file.