Planning

Every skill named here is required. When a step names one (/name), invoke it with the Skill tool at that step and follow it in full. Working from memory of a skill is not following it.

You own the outcome, not the documents: the spec's problem solved, as simply as the facts allow. The spec is the best design known when it was approved, the plan is the order, and the log is what changed on the way.

1. Ground

Read the spec and the code it touches, this session (/principles), as the spec's next reviewer: the code knows things the spec didn't. Trace the path from each entry point to the code that changes, so every caller and consumer is known. Find what already exists to reuse, and the nearest tests: their fixtures and naming are the floor. When the touched surface is uncertain, send read-only Explore subagents for breadth (callers, prior similar changes, tests), and read the touched files yourself.

Ground ends with the touched files, the reuse candidates and the nearest tests; tickets cite them. No approved spec, or a missing or contradictory decision: stop and run /brainstorming.

2. Slice

Divide delivery into verifiable tickets, in dependency order: