feat: adopt pairwise-tests (PICT combinatorial) + cross-reference from existing testing skills

Forked verbatim from omkamal/pypict-claude-skill (MIT). LICENSE preserved.
Renamed from `pict-test-designer` to `pairwise-tests` — technique-first
naming so users invoking "pairwise" or "combinatorial" find it; PICT
remains the tool under the hood.

Bundle (skill-runtime only):
  pairwise-tests/SKILL.md                    (renamed, description rewritten)
  pairwise-tests/LICENSE                     (MIT, preserved)
  pairwise-tests/references/pict_syntax.md
  pairwise-tests/references/examples.md
  pairwise-tests/scripts/pict_helper.py      (Python CLI for model gen / output fmt)
  pairwise-tests/scripts/README.md

Upstream's repo-level docs (README, QUICKSTART, CONTRIBUTING, etc.) and
`examples/` dir (ATM + gearbox walkthroughs — useful as reading, not as
skill-runtime) omitted from the fork. Attribution footer added.

Cross-references so /add-tests naturally routes to /pairwise-tests when
warranted:

- add-tests/SKILL.md Phase 2 step 8: if a function in scope has 3+ parameters
  each taking multiple values, surface `/pairwise-tests` to the user before
  proposing normal category coverage. Default continues with /add-tests;
  user picks pairwise explicitly.
- claude-rules/testing.md: new "Combinatorial Coverage" section after the
  Normal/Boundary/Error categories. Explains when pairwise wins, when to
  skip (regulated / provably exhaustive contexts, ≤2 parameters, non-
  parametric testing), and points at /pairwise-tests.
- languages/python/claude/rules/python-testing.md: new "Pairwise /
  Combinatorial for Parameter-Heavy Functions" subsection under the
  parametrize guidance. Explains the pytest workflow: /pairwise-tests
  generates the matrix, paste into pytest parametrize block, or use
  pypict helper directly.

Mechanism note: cross-references are judgment-based — Claude reads the
nudges in add-tests/testing/python-testing and acts on them when appropriate,
not automatic dispatch. Craig can still invoke /pairwise-tests directly when
he already knows he wants combinatorial coverage.

Makefile SKILLS extended; make install symlinks /pairwise-tests globally.

1 files changed, 3 insertions, 2 deletions

diff --git a/add-tests/SKILL.md b/add-tests/SKILL.md
index 837810e..5803dd8 100644
--- a/add-tests/SKILL.md
+++ b/add-tests/SKILL.md
@@ -28,8 +28,9 @@ Work through four phases in order. Do not skip phases.
 
 6. Present a test plan as a markdown table with columns: File, Functions, Current Coverage, Proposed Tests, Priority (P0/P1/P2).
 7. For each proposed test, specify: target function, category (Normal / Boundary / Error), one-line description, and any mocking required. All three categories are required per function — see `testing.md` for category definitions.
-8. For large codebases, group the plan into batches (e.g., "Batch 1: core domain models, Batch 2: API endpoints").
-9. **Stop and ask the user for confirmation.** The user may add, remove, or reprioritize tests before you proceed. Do not write any test files until the user approves.
+8. **If a function has 3+ parameters with multiple values each, surface `/pairwise-tests`.** For that function, hand-writing exhaustive or even category-based cases risks either an explosion (N × M exhaustive) or under-coverage (3-5 ad-hoc tests miss pair interactions). Tell the user: "Function `<name>` has N parameters — would you rather generate a pairwise-covering matrix via `/pairwise-tests` for that function, or continue with normal `/add-tests` category coverage?" Default to continuing unless they pick pairwise. When in doubt, suggest pairwise for the combinatorial function and fall back to `/add-tests` for the rest.
+9. For large codebases, group the plan into batches (e.g., "Batch 1: core domain models, Batch 2: API endpoints").
+10. **Stop and ask the user for confirmation.** The user may add, remove, or reprioritize tests before you proceed. Do not write any test files until the user approves.
 
 ### Phase 3: Write