Define a skill for drafting tickets and implementation plans #129

New issue

Closed

opened 2026-09-27 11:01:58 +01:00 by liamjd · 0 comments

liamjd commented

2026-09-27 11:01:58 +01:00

Owner

Reminder: define a Claude Code skill for the ticket → outline → tests → review workflow described under "Division of labour" in CLAUDE.md.

The implementation plan Claude writes on the ticket is not specific enough to code against. On #57 (toast notifications), these were the gaps that caused confusion during implementation:

Signatures, not just names. Give full parameter and return types (e.g. focus_point(map: TerrainGrid) -> Vector3, and the static builders with their types).
Signal ownership. For each signal: whether it is custom or built into the engine, who emits it and who listens. focus_requested was never marked as custom, and toast_requested ended up wired backwards.
Wiring pattern. The pure static builder, the instance handler that calls it, and the emit. Spell out that signals ignore return values and that builders must not emit.
Scene structure. Which node goes where (e.g. ToastNotifier under Game, not UIHUDLayer), any root/child split (Toast slot + %Panel), and the %unique names the tests depend on.
Each method's job in a line, especially for existing code the implementer did not write (e.g. "CameraRig.focus_on sets global_position then calls _clamp_to_map()").

The skill should require these in the outline posted on the ticket.

Reminder: define a Claude Code skill for the ticket → outline → tests → review workflow described under "Division of labour" in CLAUDE.md. The implementation plan Claude writes on the ticket is not specific enough to code against. On #57 (toast notifications), these were the gaps that caused confusion during implementation: - **Signatures, not just names.** Give full parameter and return types (e.g. `focus_point(map: TerrainGrid) -> Vector3`, and the static builders with their types). - **Signal ownership.** For each signal: whether it is custom or built into the engine, who emits it and who listens. `focus_requested` was never marked as custom, and `toast_requested` ended up wired backwards. - **Wiring pattern.** The pure static builder, the instance handler that calls it, and the emit. Spell out that signals ignore return values and that builders must not emit. - **Scene structure.** Which node goes where (e.g. ToastNotifier under Game, not UIHUDLayer), any root/child split (Toast slot + %Panel), and the %unique names the tests depend on. - **Each method's job in a line**, especially for existing code the implementer did not write (e.g. "`CameraRig.focus_on` sets `global_position` then calls `_clamp_to_map()`"). The skill should require these in the outline posted on the ticket.

liamjd referenced this issue from a commit

2026-09-28 05:57:24 +01:00

Add a ticket workflow skill with a required outline structure (#129)

liamjd added reference 129-ticket-planning-skill

2026-09-28 05:57:59 +01:00

liamjd referenced this issue from a commit

2026-09-29 18:57:34 +01:00

Fold the #117 trial run into the ticket skill (#129)

liamjd referenced this issue from a pull request that will close it,

2026-09-29 18:57:47 +01:00

Ticket workflow skill with a required outline structure (#129) #138

liamjd closed this issue