xp-developer-skills

Slice a whole capability into ordered releasable increments (increment backlog in increments/<stem>.md). Delegate each slice to skills/new-increment — do not implement slices yourself. Default step mode stops after each increment for feedback; automatic mode (explicit opt-in) continues until the backlog is done. Use for an entire feature or epic (e.g. full FizzBuzz), not for implementing one increment.

Deliver one releasable increment from increments/<feature>.md — strict TDD by default (one test-lists/<feature>.md, unit tests). ATDD only when a real outer seam exists (API/UI/contract). One increment per invocation; RED before GREEN; all project verify steps green before done; commit then stop. Not for whole-feature planning (skills/new-feature).

Martin Fowler–style refactoring — change the internal structure of code without changing observable behavior. Baby steps on a green baseline: one mechanical transformation at a time, tests stay green, revert on red. Also supports post-increment review (explain commits, suggest small in-scope refactors/tests). Separates refactoring from adding features (“two hats”). Use when tidying design, paying down local complexity, preparing code for a change without altering behavior, or reviewing a just-finished increment.

Pragmatic Acceptance Test-Driven Development — agree concrete examples with stakeholders (Discuss), capture them as executable acceptance checks (Distill), then implement with outside-in delivery (Develop). Supports Gherkin/Cucumber when it helps, code-first acceptance tests, and contract tests at service boundaries. Composes with the inner-loop TDD skill for programmer tests. Use when defining story done, writing acceptance or executable specifications, or aligning business examples with automation before feature code.

Use when fixing bugs, regressions, failing tests, or unexpected behavior. Applies a strict test-first bugfix workflow with minimal safe changes, isolated commits, and language-agnostic verification strategies.

Michael Feathers–style legacy code change — treat code without automated tests as legacy, then follow identify change points, find test points, break dependencies, add tests (often characterization), and only then modify or refactor. Covers seams (object/link/preprocessing), sensing vs separation, fakes/mocks, sprout/wrap, pinch points, effect sketches, and dependency-breaking patterns. Composes with bugfix, TDD, and refactoring once a harness exists. Roadmap id: add-tests-to-legacy-code. Use when changing untested code, introducing a test seam, or adding coverage before a risky edit.

Applies strict Test-Driven Development with a repo-local Markdown test list (default `test-lists/<slug>.md` unless the project defines another folder), Robert C. Martin’s Three Laws, deterministic tests and stable seams (unit vs narrow integration), Arrange–Act–Assert test shape, micro-iterations, refactor proximity (production and test code), fast feedback, and git micro-commits (`test:` / `feat:` or `fix:` / `refactor:`) squashed per cycle before push. Use for test-first feature slices, strict R-G-R, or when the user asks for a tracked test list plus disciplined commits.

XP-style spike — time-boxed experiment on an isolated branch; code is disposable. Answer one technical or design question (feasibility, library fit, performance bound, integration). Use automated checks only when they help prove the goal — no delivery test pyramid, no ATDD/TDD discipline on the spike branch. Explicit promotion to skills/atdd, skills/tdd, or skills/legacy-testing when learning is done. Use for unknowns before committing to product work, not for shipping features.