Run any Skill in Manus with one click

regression-sweep

Stars124

Forks28

UpdatedJuly 21, 2026 at 15:15

Run a broad health check across a Nimara surface — checkout, SEO/metadata, performance, or a page-type matrix — and report findings, instead of verifying one ticket. Use this skill whenever the user asks for a regression pass, a smoke/health check, a "sweep" of an area, a performance audit (Lighthouse), an SEO/meta check, or "test everything on <page/flow>". Fans out across page types, channels, and devices, then summarises pass/fail with evidence. Do NOT use to retest a specific reported bug (use bug-retest-triage) or to design cases from a spec (use test-case-design).

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

mirumee

mirumee/nimara-ecommerce

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name

regression-sweep

description

Regression Sweep

Run a broad, repeatable health check across a surface and report — breadth over depth. Use this for "is anything broken across X" rather than a single defect.

Operating principles

Cover the matrix. Enumerate the axes for the surface (page type × channel × device × env) and sweep representatives — don't spot-check one page. See [[Coverage Maps]].
Cheapest reliable method per signal. curl+grep for SEO/structural, local Lighthouse for perf, Playwright for interactive flows, response listeners for contracts. See [[Test Method Playbooks]].
Right environment. Test the real storefronts (dev/stage/demo), not the nimara.store landing page; mind channel prefixes (/ = US, /gb = GB). See [[Environments & Access Matrix]].
Report findings, don't auto-file. Summarise pass/fail with evidence; only open tickets when the user asks, generalising to classes.

Workflow

PICK SURFACE & AXES — e.g. SEO across {Home, PLP, PDP, CMS} × {US, GB}; or perf across {dev, stage, demo} × {Home, PLP, PDP} × {mobile, desktop}; or checkout smoke across {US, GB} × {guest, logged-in}.
BASELINE (if any) — note prior scores/expected values to compare against.
SWEEP — run each cell with its method; capture evidence under qa/triage/evidence/<sweep-name>/. Independent cells parallelise well.
REPORT — matrix of cell → result → delta-from-baseline; flag regressions and known-flaky cells ([[Known Flaky, Blocked & Backend-Only]]); record method caveats (perf fluctuates, code-inspection vs deployed build).
HANDOFF (if asked) — turn confirmed regressions into bugs via [[Defect Taxonomy & Severity]] + [[Jira & Board 74 Operating Manual]].

References

[[Coverage Maps]] · [[Test Method Playbooks]] · [[Environments & Access Matrix]] · [[Known Flaky, Blocked & Backend-Only]]

More from this repository

same repository

bug-retest-triage

mirumee/nimara-ecommerce

Retest a reported defect on the live Nimara board (Jira project MS, board 74) and give it an evidence-backed verdict — still reproduces → Open, fixed → Done, blocked → leave In testing and ask. Use this skill whenever the user asks to retest, re-verify, triage, or work through reported bugs/tickets one at a time; to "run the Phase 2 flow"; to pick the next ticket off the To Do column; or to confirm whether a fix holds. Works one ticket at a time on a board shared with human QA. Do NOT use for designing new test cases from a spec (use test-case-design) or for a broad regression pass (use regression-sweep).

2026-07-21124

grilling

mirumee/nimara-ecommerce

Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

2026-07-21124

handoff

mirumee/nimara-ecommerce

Compact the current conversation into a handoff document for another agent to pick up.

2026-07-21124

llm-wiki-bookkeeping

mirumee/nimara-ecommerce

Keep an LLM-wiki coherent while ingesting sources, filing durable knowledge, auditing or repairing its graph, reconciling indexes and logs after content changes, or recording architecture decisions. Use the target wiki's AGENTS.md as the sole authority for its schema, locations, templates, links, provenance, and bookkeeping rules.

2026-07-21124

llm-wiki

mirumee/nimara-ecommerce

Retrieve and verify existing project knowledge from llm-wiki. Use when the user asks to find, explain, compare, or cite existing strategy, persona, product, quality, PRD, RFC, ADR, or source notes.. Use QMD only for discovery, verify the full Markdown source.

2026-07-21124

prd-modeling

mirumee/nimara-ecommerce

Define and draft Product Requirements Documents (PRDs) inside an LLM-wiki product workspace. Use when the user wants to create, rewrite, refine, or stress-test a PRD or Product Requirements Document, or turn an initiative or feature brief into product requirements. Run a business-value-first, one-question-at-a-time grilling, capture confirmed decisions in the PRD, and stop at an approved PRD without designing the technical solution, decomposing tasks, estimating.

2026-07-21124

name

regression-sweep

description

Regression Sweep

Run a broad, repeatable health check across a surface and report — breadth over depth. Use this for "is anything broken across X" rather than a single defect.

Operating principles

Cover the matrix. Enumerate the axes for the surface (page type × channel × device × env) and sweep representatives — don't spot-check one page. See [[Coverage Maps]].
Cheapest reliable method per signal. curl+grep for SEO/structural, local Lighthouse for perf, Playwright for interactive flows, response listeners for contracts. See [[Test Method Playbooks]].
Right environment. Test the real storefronts (dev/stage/demo), not the nimara.store landing page; mind channel prefixes (/ = US, /gb = GB). See [[Environments & Access Matrix]].
Report findings, don't auto-file. Summarise pass/fail with evidence; only open tickets when the user asks, generalising to classes.

Workflow

PICK SURFACE & AXES — e.g. SEO across {Home, PLP, PDP, CMS} × {US, GB}; or perf across {dev, stage, demo} × {Home, PLP, PDP} × {mobile, desktop}; or checkout smoke across {US, GB} × {guest, logged-in}.
BASELINE (if any) — note prior scores/expected values to compare against.
SWEEP — run each cell with its method; capture evidence under qa/triage/evidence/<sweep-name>/. Independent cells parallelise well.
REPORT — matrix of cell → result → delta-from-baseline; flag regressions and known-flaky cells ([[Known Flaky, Blocked & Backend-Only]]); record method caveats (perf fluctuates, code-inspection vs deployed build).
HANDOFF (if asked) — turn confirmed regressions into bugs via [[Defect Taxonomy & Severity]] + [[Jira & Board 74 Operating Manual]].

References

[[Coverage Maps]] · [[Test Method Playbooks]] · [[Environments & Access Matrix]] · [[Known Flaky, Blocked & Backend-Only]]