← ClaudeAtlas

consumer-regression-suitelisted

Build every downstream consumer of VibeTags against a chosen VibeTags version and report which ones actually pass. Use when the user says "regression suite", "consumer sweep", "test the consumers", "check the downstream repos", "does the new version break anything", or before cutting a VibeTags release.
PIsberg/vibetags · ★ 15 · Web & Frontend · score 77
Install: claude install-skill PIsberg/vibetags
# Consumer regression suite VibeTags' own 1537 tests say the processor works. They say nothing about whether a real consumer still builds. This skill answers that second question, for every Java repo under `../` that depends on VibeTags. The executable core is `scripts/consumer-sweep.sh` in this repo. This document is the judgement around it: what to run, what a result means, and what not to believe. ## Step 1 — Decide which VibeTags the sweep is testing Two different questions, and they need different setups. Ask which one is wanted if it is not obvious from the request. **"Does the released version still work?"** Use the published version directly. Nothing to install; consumers resolve it from Maven Central. **"Does what we are about to release still work?"** `main` is usually ahead of the newest tag, so the published artifact is not the code under test. Check first: ```bash git -C <vibetags> log "$(git -C <vibetags> tag --sort=-v:refname | head -1)"..main --oneline ``` If that is non-empty, build and install `main` locally: ```bash cd vibetags-annotations && mvn install -DskipTests cd ../vibetags && mvn install -DskipTests cd ../vibetags-bom && mvn install ``` Installing `main` under a version number that is also on Central makes the local copy differ from the published one for every later build on this machine. Say so, and offer the cleanup in Step 5. Installing under a fresh `-SNAPSHOT` avoids it but means no consumer PR can pin the result. ## Step