Feature Kickoff

Feature kickoff

Interview first, criteria second, code never. This skill produces one file — docs/features/<slug>.md — containing the goal and the acceptance criteria the user agreed to, and — if the user confirms — the feature branch to work on. Implementation is a separate request.

The point is to force the question how will we know this is done? before the first line of code, in a codebase where "works on my machine" can mean "works in NINA mode, on a phone, in German, with the mount already connected".

Step 0 — do not skip to the answer

A one-line idea is not a spec. Do not start reading implementation files to guess what the user wants, and do not propose a design. If the request is actually a bug fix, a locale change or a one-liner, say so and stop — this skill is overhead for those.

Step 1 — ask about the goal

Ask in one round, not one question at a time. Use AskUserQuestion for anything with enumerable options and free text for the rest.

Always establish:

1. Outcome, not mechanism. What can the user do afterwards that they cannot do today? If the answer describes a button, ask what the button is for.
2. Trigger. Which real session moment does this serve — setup, framing, running sequence, meridian flip, teardown, troubleshooting?
3. Runtime modes. NINA/WPF, PINS/headless, or both? Never assume both, and never assume one.
4. Surface. New view, existing view, plugin, settings, wizard step?
5. Non-goals. What must explicitly not change. Ask directly — this is the field users skip and reviewers need.

Do not ask what the code already answers. Check src/views, src/store and src/services/api/ first if the feature may already exist in part; a question whose answer is in the repo wastes the user's turn.

Step 2 — ground the criteria before writing them

Read enough to make the criteria concrete rather than generic. Typically:

• the store that owns the state (src/store/),
• the API surface it needs (src/services/api/, and whether the endpoint exists at all on the plugin server / Advanced API / pinsdaemon),
• the nearest existing screen to match.

If the feature needs a backend endpoint that does not exist yet, that is an acceptance criterion of its own and a dependency on the plugin-server repo — name it explicitly. Load the api-endpoint skill when that is the case.

Step 3 — write criteria that can fail

Each criterion is one observable outcome, phrased so a reviewer can decide pass/fail without asking the author. Format: given a state, when an action, then an observable result.

Bad — cannot fail:

1. The cooler UI is improved.
2. Errors are handled properly.

Good — can fail:

1. Given a connected camera, when the target temperature is set to -10 °C,
   the cooling progress is visible within one poll cycle (2 s).
2. Given the backend restarts mid-cooldown, the view shows the disconnected
   state instead of the last known temperature.
3. In PINS mode the same flow works without `TempChangeRunning`, using the
   feature-detected fallback.

Aim for 4–8 criteria. More than that means the feature should be split, and saying so is part of this skill's job.

Step 4 — the dimensions that are always in scope

Walk this list explicitly and write a criterion for every one that applies. Say in the file which ones were considered and ruled out — a ruled-out dimension is information, an unmentioned one is an oversight.

For domain-specific constraint blocks and validation commands, reuse the matching variant in docs/AGENT_TASK_TEMPLATE.md instead of inventing new ones. Do not restate them here.