Implement the work described by the issue the user points you to.

Read the whole issue with its comments (gh issue view <n> --comments), and the parent spec in full when the issue is a delivery of one. A summary of the issue makes you build the summary.

Respect the spec's invariants. If you disagree with a decision in the spec, argue it in the PR instead of changing it on your own. The spec is what the reviewer checks your code against; a silent change leaves it describing something else, and a regressing spec implemented in silence is no better. Stopping to ask about an ambiguous instruction is worth more than obeying it.

Use /tdd where possible, at the seams the spec names.

Run typechecking regularly, single test files regularly, and the full test suite once at the end — in the foreground, waiting for it to finish inside the turn.

Docs the change made outdated are updated in the same PR.

Once done, use /code-review to review the work, and fix the real findings.