autosprint: Skill for Claude Code

Vet the pending tasks in <target_repo>/autosprint/plan.md for agent-readiness — whether an implement agent could pick each one up and execute it without guessing — and sharpen the weak ones with the user.

This is the plan-level companion to grill-destination. grill-destination sharpens the destination; grill-plan sharpens the next steps toward it. It is meant to be used during the hand-review of a plan that autosprint plan just drafted — a second pair of eyes on executability, before an autosprint run executes the plan as-is.

What this skill is NOT

It does not re-plan. Generating tasks from scratch — reading the gap between the repo and destination.md and proposing what to do — is the Plan phase's job (autosprint plan). grill-plan vets and sharpens the tasks that are already in plan.md. It may sharpen, split, drop, or reframe a task, but it never invents a fresh plan. If the plan is wrong at the root (wrong tasks entirely), the fix is to re-run autosprint plan or hand-author plan.md — not this skill.

It also does not second-guess strategy. Whether a task is the right priority is the user's call and the planner's job. grill-plan asks one question per task: could an agent execute this as written?

Run it between autosprint runs, not while a loop is live — a running loop rewrites plan.md itself and would clobber your edits.

Before starting

1. Read <target_repo>/autosprint/plan.md — the ## Pending section is the subject. Leave ## Recent completed alone.
2. Read destination.md and adr.md for context — a task must move toward the destination and must not contradict a locked decision.
3. Read the actual code the tasks refer to. A task's claim ("the parser silently swallows errors") must be verified against the real code — a task aimed at a problem that doesn't exist is not ready.

The rubric — is a task agent-ready?

Judge each pending task against all of these:

• Concrete — names files, functions, or observable behavior. "Improve the code" fails; "split the 400-line run_implement in implement_phase.py" passes.
• Scoped — one coherent piece of work. Not a mega-task spanning many files, not so trivial it's noise. The trailing (N) story-point tag must be present and sane; anything clearly above SPRINT_STORY_POINT_MAX must be split.
• Has a done-condition — there is a way to know it is finished: a test that would pass, an observable behavior, a check. A task with no done-condition is one an agent cannot finish.
• Self-contained — does not depend on a decision nobody has made. A decision in disguise — "use uv to add numpy for the vector math" — hides the unmade decision "do we want numpy?". That is not ready: it needs deciding (and recording in adr.md), not implementing.
• Real — the problem it describes actually exists in the current code. Verify against the code, not the task's say-so. A task may carry an explicit (unverified: <…>) tag where the planner flagged a claim it could not check — treat those as your first priority: verify the tagged claim against the code, then strip the tag once confirmed, or sharpen/drop the task if the claim is false.
• Destination-aligned — closes distance to something in destination.md. A task that does not is orphan scope.
• Distinct — does not overlap or duplicate another pending task.