Quick task or full phase?

This page decides how a ticket gets built. Claude proposes the size when it triages a ticket (label size:quick or size:phase). Sven only steps in when the proposal looks wrong.

Default: /gsd-quick

Most tickets are quick tasks. A quick task is one ticket, one pull request, one TestFlight build to try. It gets a short plan, an executor, tests and a verification step, but no discussion round and no separate research documents.

When it has to be a full phase

Use a full GSD phase (discuss, plan, execute, verify) as soon as one of these is true:

1. The data model or the CloudKit schema changes. New @Model types or new stored fields. The production CloudKit schema can only grow, never shrink, so these changes deserve a deliberate decision.

2. A new permission or background capability is needed. Notifications, background location modes, local network access, Bluetooth, anything that shows a system prompt to the user or affects battery.

3. Several tickets only make sense together. Example: engine hours, the Config view and the Stats view share one data model and one set of decisions.

4. A new component or external system is involved. A server, boat hardware, a weather or tide data source, a third-party SDK.

If none of these apply, it is a quick task, even if it touches several screens.

Extra flags for quick tasks

Situation	Command
Trivial edit, at most three files (typo, constant, config value)	/gsd-fast
Normal bug or small feature	/gsd-quick
A UX choice is open (where does the button go, what does the empty state say)	/gsd-quick --discuss
An Apple API is used that the project has not used before	/gsd-quick --research
Touches the one-tap logging path at the helm	/gsd-quick --validate

--discuss does not mean a long interview. With discuss_mode: assumptions, Claude writes down what it assumes and Sven corrects two or three points in the ticket.

Current backlog, sorted

Ticket	Size	Reason
GPX export (WAK-29)	quick	in progress, no model change
Free-text notes per event (WAK-16)	phase	new stored field on Event
Night mode (WAK-15)	quick --discuss	visual choices, no model change
Departure / safety checklist (WAK-32)	phase	new data type
Reefing / sail-trim sub-events (WAK-34)	phase	new event kinds are stored data
Tidal-gate event type (WAK-31)	phase	new event kind
Custom voyage names (WAK-8)	phase	new stored field (planned as Phase 5)
Engine hours, Config, Stats (WAK-10, -25, -26)	phase	shared model and decisions (Phase 6)
Weather per event (WAK-11)	phase	new data type (Phase 7)
Fuel log (WAK-30)	phase	new data type
Anchor watch alarm (WAK-27)	phase	background location and notifications
Distance under-reads (WAK-37)	quick --research	algorithm question, no model change. Done 2026-10-09
Start Voyage missing in history (WAK-38)	quick	logic fix. Done 2026-10-09

Note how many small-looking ideas are phases because they store something new. Batching several of them into one phase that changes the schema once is cheaper than four separate schema changes.