test-inventorylisted

Phase 1 of the test-readiness pipeline. Crawls a target repo, classifies every meaningful unit of code (business logic, service boundary, HTTP route, error path, external integration, user journey), prescribes the appropriate test layer (unit / integration / smoke / E2E) using the rubrics, ranks each by criticality (critical / high / medium), groups units into features with importance tags (revenue-path / security-path / core / auxiliary), and tags canary eligibility. Outputs a deduplicated inventory — each functional unit appears exactly once at its canonical layer per the no-duplicate-coverage rule. Writes `docs/test-readiness/test-inventory.md`. Invoke when the `/test-inventory` command runs.
app-vitals/shipwright · ★ 14 · Testing & QA · score 75

Install: claude install-skill app-vitals/shipwright

# test-inventory skill ## Purpose Build the **inventory** — the source-of-truth ledger of what should be tested in this repo, at which layer, with what priority. ## When invoked By the `/test-inventory` command. The repo path arrives as `$ARGUMENTS` (defaults to `.`). ## Process ### Step 0 — load the decisions registry 1. Check for `.claude/shipwright/test-readiness-decisions.md` in the target repo root. 2. **If it does not exist**, treat this as "no decisions configured" — the same graceful no-op `consolidation-scan` uses for a missing `.claude/shipwright/consolidation-decisions.md` (see `consolidation-scan/SKILL.md`'s Step 1). Print: "No test-readiness-decisions.md found — no decisions configured." and continue to Step 1 with an empty decisions list. This is expected on a repo that hasn't recorded any resolved ambiguous items yet — it is not an error. 3. **If it exists**, load it and parse its entries the same generic, defensive way `consolidation-scan`'s Step 1 parses `consolidation-decisions.md`: read each `###` entry for its **Item**, **Decision**, **Rationale**, and **Revisit** fields where present, but do not hardcode assumptions about the registry's exact heading/field layout beyond those four fields — skip any entry you can't confidently interpret rather than failing the whole load. 4. Build an in-memory decisions list: one entry per parsed record, holding at least its item description, decision, and revisit condition (if any). 5.