diff options
| -rw-r--r-- | .claude/commands/start-work.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/.claude/commands/start-work.md b/.claude/commands/start-work.md index b9e87c8..935cab5 100644 --- a/.claude/commands/start-work.md +++ b/.claude/commands/start-work.md @@ -161,7 +161,7 @@ Then produce an approach that covers: - Pairwise or combinatorial tests, if parameter-heavy (see `/pairwise-tests`). 7. **Migration and backwards-compat surface.** DB migration? API contract change? Frontend consumer impact? Config shape change? Flag if yes and describe the scope. 8. **Feature flag.** Does this ship behind a flag or direct? Always worth asking once. -9. **Commit decomposition.** One commit, or N commits? Each commit should be one logical change per `commits.md`. Size the Review-and-Publish ceremony ahead of time. +9. **Commit decomposition.** One commit, or N commits? Each commit should be one logical change per `commits.md`. Default to bundling tests + the feature they cover into a single `feat(scope): X with tests` (or `fix(scope): X with tests`) commit — the test and the code under test belong together for review. Split into separate `test:` + `feat:` commits only when the test work is its own substantial review surface (characterization tests, fixture infrastructure, a new test harness) or when the failing test serves as a deliberate bug-report artifact in a `fix:` narrative. Size the Review-and-Publish ceremony ahead of time. 10. **Branch name.** Following the project convention: `fix/<ID>-slug`, `feature/<ID>-slug`, `chore/<ID>-slug`, or `test/<ID>-slug`. Unticketed work uses a short descriptive slug. ### Gate @@ -175,8 +175,8 @@ If the user redirects the approach, update the plan and re-present rather than s Follow the red-green-refactor cycle from `testing.md`. 1. **Create the branch** using the name decided in Phase 3. -2. **Red.** Write a failing test that demonstrates the bug or captures the new desired behavior. Run it. Confirm it fails for the right reason, not because the test itself is broken. Commit as `test: <desc>`. -3. **Green.** Write the minimal code to make the test pass. Do not generalize yet. Do not add features the test does not require. Commit as `fix:` or `feat:`. +2. **Red.** Write a failing test that demonstrates the bug or captures the new desired behavior. Run it. Confirm it fails for the right reason, not because the test itself is broken. +3. **Green.** Write the minimal code to make the test pass. Do not generalize yet. Do not add features the test does not require. Commit as `feat(scope): <desc> with tests` (or `fix(scope): <desc> with tests`) — bundle test + implementation per the commit-decomposition decision in Phase 3 step 9. Split into separate `test:` + `feat:` commits only when that decision called for it. 4. **Edge cases.** Add tests in all three categories per `testing.md`: - Normal: happy path, typical input. - Boundary: empty inputs, nulls, minimum and maximum values, single-element collections, Unicode, long strings, time and timezone boundaries, concurrent access. |