grill-destination

Interview the user to produce a concrete destination.md at <target_repo>/autosprint/destination.md. This file is the sole input to autosprint's planning phase — the single fixed point the PIT loop iterates toward.

The interview walks three passes through the canonical concerns. At each section the user picks one of these outcomes:

• Answer it → user dictates the answer; you write it into destination.md.
• Accept the recommended default (only for sections that ship one) → you write the default content as-is.
• Modify the recommended default (only for sections that ship one) → user dictates changes; you write the modified version. If the modification carries non-trivial reasoning, flag that the change deserves an ADR entry recording the rationale.
• Let autosprint decide → you write a destination-shaped sentence with an *(Open — autosprint to decide.)* marker. Autosprint will resolve in a future sprint, recording rationale in adr.md.
• Skip → you don't add the section to destination.md at all. (Allowed only in passes 2 and 3.)

The resulting file contains only the sections the user picked into. Everything else stays out — no empty placeholders, no aspirational sections nobody intends to fill in.

Where things live

destination.md is the destination — the GPS coordinate the PIT loop descends toward. It lives at <target_repo>/autosprint/destination.md and is the load-bearing input the planner reads on every sprint.

Sibling locations under <target_repo>/autosprint/:

• inputs/ — supporting human-authored material the destination may reference. Half-finished data models, domain glossary, project description, design notes. Read on demand, not on every sprint. destination.md is authoritative; if a file in inputs/ contradicts it, the file in inputs/ is wrong and gets updated. Each file in inputs/ is anchored by humans; agents may append to designated AI-append sections (e.g. ## AI-observed inconsistencies) but never modify human content above them. Pattern: destination.md's "Referenced inputs" section names which inputs/ files matter for which kinds of tasks.
• adr.md — append-only history of technical decisions. Read by Plan and Implement on every sprint as context for what's already locked in. Both humans and the implementor agent author entries here. To change a decision, append a new entry that references the old one under **Supersedes:** — old entries stay in the file as history.
• plan.md — loop state authored by the planner. Not an input to the grill skill.
• logs/, cache/ — agent-generated bookkeeping. Never touch by hand.

Plus the standard agent file:

• <target_repo>/CLAUDE.md — agent navigation context (folder layout, conventions, "we use uv not pip"). Loaded on every agent invocation. Not part of this interview, but updated by autosprint as project shape changes.

Before starting

1. Always re-read destination.md at the start of each session, even if you've seen it earlier in conversation. The file may have been edited externally between sessions; conversation memory can be stale and lead to working from an outdated snapshot. Follow its links: when destination.md references other files — markdown links, inputs/ files named under "Referenced inputs", adr.md, any path mentioned in prose — read those too. A destination is only as sound as the material it leans on, and a stale, missing, or contradicted linked file is itself a finding for Pass 0.
2. Check if <target_repo>/autosprint/destination.md exists.
   • If yes, load it and run in refine mode: start with Pass 0 — Assess the existing destination (below) to judge what's already there, then walk each section and the not-yet-present Pass 2 / Pass 3 sections — focusing the interview on what Pass 0 flagged as weak or missing rather than re-walking solid sections.
   • If no, choose between fresh mode and mature-repo mode:
     • Fresh mode — repo is greenfield (no source code, or only a stub README). Design the destination from scratch.
     • Mature-repo mode — repo already has substantial code (≥10 source files, real README, active commit history). Real intent already lives in the code; extract a first-draft destination from it, then validate with the user.
3. To pick fresh vs mature: list the target one level deep, count source files (*.py, *.ts, *.go, *.rs, *.js, etc.), check whether README.md has real content (>200 chars, not a placeholder), and skim recent commit messages if available. Use judgement — when in doubt, ask the user.
4. If a file at a different path already serves this purpose (e.g. docs/vision.md), ask the user before creating a duplicate.

Mature-repo mode (extract before grilling)

When the repo has real code already, the destination is partly latent in what's been built. Inspect first, then validate.

1. Read inputs that reveal intent (what + why), in this order:
   • README.md — usually the closest thing to a stated purpose.
   • Top-level docstrings on the main module / package.
   • Folder structure one level deep — names like api/, models/, cli/ reveal shape.
   • Public-facing entry points (CLI commands, HTTP routes, exported functions) — read their signatures and docstrings, not their bodies.
   • requirements.txt / pyproject.toml / package.json / Dockerfile — reveals current technical decisions.
   • Existing autosprint/adr.md if present — extracts of current technical state.
   • Recent commit messages (last 20–30) — what features have been actively added.
2. Do NOT read implementation details unless they reveal a technical decision you'll need.
3. Draft tentative answers for each section based on what you found. Tag each draft with its source — "(extracted from README)", "(inferred from folder names)", "(based on requirements.txt)" — so the user knows which parts to validate hardest.
4. Present each section's draft and ask the user to pick one of the three outcomes (answer / let autosprint decide / skip). The user's job is validation and correction, not authoring from scratch.

Fresh mode (the original interview)

Used when the repo is greenfield. Do NOT read source code or folder structure — those would bias the user toward describing what exists instead of what they want. README + top-level docstrings are still OK as Purpose prefill. Walk the three passes asking one section at a time; the user is starting from a blank slate and benefits from focus.

Interview style

• Always lead with a recommendation. Like the grill-me skill — for every section, put a concrete recommended answer on the table before asking, never just an open question. For sections that ship a canonical default, that's the default. For the rest, draft one from context — the repo, the Pass 0 assessment, what the user has already said — and label it clearly as your recommendation. The user then accepts it, edits it, defers it ("let autosprint decide"), or skips. A bare "what do you want for X?" is a last resort, not the default move.
• Soft on vision (Purpose, Users, Non-goals): some vagueness is legitimate. Don't force numbers onto feelings.
• Hard on constraints and success criteria: these must be concrete or the planner can't act on them. "Should be cheap" is worthless; "must cost under $1/sprint" is actionable.
• Break vagueness with pick-from-options: when the user gives a vague answer, propose 2–3 concrete versions and ask them to pick or edit. Don't ask "can you be more specific?" — it produces more vagueness.
• Always offer the fork at each section, even when the user is engaged with answering — they may want to defer parts to autosprint or accept a default.

The fork at each section

At each section in the interview, after the question is posed and (in mature-repo / refine mode) the draft proposed, present the available options. Some sections ship a recommended default (an opinionated starting answer for settled best-practice cases); others don't. The fork shape depends on which:

Sections that ship a recommended default (Project shape, Code-quality invariants, and any other section whose default appears in the canonical example file):

1. Accept the default — you write the default content as-is into destination.md. Frictionless for the common case.
2. Modify the default — user dictates changes; you write the modified version. If the modification carries non-trivial reasoning (e.g. "we don't use uv because we're locked to Poetry by another team"), tell the user: "I'll record that reasoning as an ADR — it's load-bearing context the planner should see." Then both write the modified content into destination.md AND draft a brief ADR entry (Decision / Why / Alternatives considered) to append to adr.md. Trivial cosmetic tweaks (renaming a folder, adding a sub-bullet) don't need an ADR.
3. Let autosprint decide — see below.
4. Skip — Pass 2 and Pass 3 only.

Sections that don't ship a default (Purpose, Users, Desired behavior, Non-goals, Constraints, Target platform, Success criteria, and most Pass 3 sections):

1. Accept or edit my recommended answer — you've already put a concrete recommendation on the table (see "Always lead with a recommendation"); the user accepts it as-is or dictates edits, and you write the result into destination.md, replacing the italic prompt. A user who prefers to author from scratch still can — but the recommendation goes on the table first.
2. Let autosprint decide — see below.
3. Skip — Pass 2 and Pass 3 only.

The "let autosprint decide" path (both fork shapes): prompt the user for a one-sentence framing of the question before generating the destination-shaped sentence — autosprint needs enough context to actually decide, and a vague open marker produces mush. Example exchange: *"OK, autosprint decides. Briefly: what's

Content truncated.