Add contrib-search Claude Code skill; delegate rector-live-test module discovery to it
The rector development skills repeatedly need to search real contrib code for a deprecated pattern (a method, function, constant, or property a rector targets) to answer two recurring questions: 1. Is this pattern actually present in real contrib code, and how widespread is it? (used when judging whether a rector false-positive is a realistic risk, and when picking a real module to extract a PHPStan message from) 2. Which D11-compatible contrib modules exercise this rector, so it can be live-tested? Today this logic lives inline in the `rector-live-test` skill (steps 1-3) and is copy-referenced ad hoc elsewhere. It should be a first-class, reusable skill. ## Proposal Add a `contrib-search` skill (`.claude/skills/contrib-search/`) built around the `api.tresbien.tech` code index, with two exit points: - **Quick mode (default)** - run one search query, report hit count + a few decoded example call sites. Answers question 1 without installing or ranking anything. - **Full mode (`--full`)** - additionally filter hits to D11-compatible modules ranked by install count, producing a module list ready to live-test. Answers question 2. Scope is contrib-only (every query includes `-r:drupal` to exclude core); the skill does not search core. No Drupal GitLab blob-search fallback. Then thin `rector-live-test` so its module-discovery steps delegate to `contrib-search --full`, removing the duplicated search mechanics. ## Rationale - One canonical home for the tresbien query mechanics (the `-r:drupal` requirement, regex escaping / HTTP 418 on unescaped `(`, the `Result.Files[]` shape, the `drupal-core` / `drupal-usage` repo-config filters). - Quick mode is the lightweight lookup reached for constantly during review and QA; forcing it through the full live-test pipeline is overkill. - Removes duplication between `rector-live-test` and other skills that need the same search.
issue