Explore AI Agent Skills & Claude Prompts

Use this skill whenever the user mentions testing, test automation, or anything related to verifying application behavior. Triggers on general testing intent: "test the app", "test this", "lets test", "write tests", "add tests", "run tests", "e2e tests", "end-to-end tests", "browser testing", "UI testing", "functional testing", "test automation", "automate tests", "test scenario", "test case", "happy path", "smoke test", "regression test", "test coverage", "QA", "quality assurance". Also triggers on framework-specific keywords: Playwright tests, @civitas-cerebrum/element-interactions, @civitas-cerebrum/element-repository, Steps API, ElementRepository, ElementInteractions, baseFixture, ContextStore, page-repository.json, or any request to write, fix, or add to a Playwright test in this project. Also use when asked to add entries to a page-repository JSON file, use fixtures, select dropdowns, verify elements, wait for states, or perform any browser interaction through this framework. Always consult this skill b

bug-report

Use when a defect, issue, or unexpected behavior is found during testing and needs to be reported in a defect tracking system (Jira). Use when asked to write, create, or file a bug ticket, defect report, or issue report.

journey-mapping

Map user journeys through a web application before writing tests. Discovers pages, builds app context incrementally, identifies all user flows, and prioritizes them by business impact. This is a mandatory prerequisite for coverage expansion (test-composer) and the full pipeline. Invoke when: starting a full E2E suite, before coverage expansion, before any major test composing activity, or when asked to "map the app", "discover user journeys", "map user flows", or "understand the app".

test-catalogue

Use when asked to "produce a test catalogue", "generate a scenario report", "catalogue the suite", "client-ready catalogue", "export the scenario inventory", or any request for a stakeholder-facing list answering "what scenarios are we running, and why?". Opt-in and on-demand only: never activates during test writing, coverage expansion, repair, or debugging. Requires a sentinel-bearing `tests/e2e/docs/journey-map.md` and at least one spec file to be present.

contract-testing

Use whenever a backend HTTP endpoint is being consumed in a test — write, run, review, or just call. The skill owns the structured shape every API interaction should produce: status code expectations, response-schema assertion, error-envelope validation, header coverage. It auto- activates on the explicit-intent triggers (contract test, schema test, pact, OpenAPI conformance, lock API contract, verify API shape, breaking change detection, consumer-driven contract, provider verification, API compatibility, spec conformance, ensure API hasn't changed) AND on any test or planned test that calls `steps.apiGet`, `steps.apiPost`, `steps.apiPut`, `steps.apiDelete`, `steps.apiPatch`, `steps.apiHead`, `steps.verifyApiStatus`, or `steps.verifyApiHeader` — even inside a UI-flow spec. The rationale: every backend call deserves at minimum a status-code + error-envelope assertion; without those the test silently passes when the endpoint regresses. Also activates on phrases that signal a backend interaction is about to land

test-composer

Use this skill to compose the full test portfolio for **one** user journey — happy path, error states, edge cases, mobile, negative flows, and data-lifecycle variants — and to drive that journey to high test coverage. Triggers on requests like "write all tests for the login journey", "compose tests for journey X", or when invoked by coverage-expansion with a journey reference. Do NOT use for iterating across an entire application — that is coverage-expansion. Do NOT use for writing a single test scenario — this skill composes the journey's whole variant set.

workflow-reviewer

Subagent-only skill. Loaded by every workflow-reviewer-phase<N>: / workflow-reviewer-pass<N>: / workflow-reviewer-cycle<N>: dispatch. Reviews the closing handover of an onboarding phase, a coverage-expansion pass, or a journey-mapping cycle against the canonical methodology exit criteria; returns verdict approve | reject | escalate per the workflow-reviewer.schema.json contract. Owns the 3-cycle reject cap and the skip / early-stop authorisation rules. Triggers when the brief carries one of the three role prefixes, or when the orchestrator names the skill in a Skill-tool invocation.

test-repair

Use this skill to restore a rotted Playwright test suite to a stable, verified green state. Triggers on requests like "repair the suite", "fix my tests", "restore green", "heal the suite", "the tests are broken", "the suite rotted", "triage the failures", "diagnose the whole suite", "my suite is flaky", "the app changed and now tests fail everywhere". Also auto-escalates from `failure-diagnosis`, `test-composer`, or `bug-discovery` when a single run produces many failures (≥5 failures or ≥30% of executed tests) or when failures repeat across diagnostic attempts — batch clustering finds shared root causes faster than per-failure diagnosis at scale. Those callers explicitly invoke this skill via the Skill tool when their own escalation criteria fire (no always-load reliance). Do NOT use for a single failing test — that stays with `failure-diagnosis`. Do NOT use to find new bugs adversarially — that is `bug-discovery`. Do NOT use to write new tests — that is `test-composer`.

companion-mode

Use when a QA engineer needs ad-hoc functional verification of a specific task with rich evidence (per-step screenshots, video, trace, HAR, console) — not a durable suite test, not a full coverage pass, not bug-hunting. Triggers on "companion mode", "companion entry mode", "QA companion", "verify this flow with evidence", "evidence package for X", "screenshot every step", "record this scenario", "video of this flow", "evidence-backed test", "daily QA task", "manual test assistance", "help me check that <feature> still works", "show me proof that X works", "capture screenshots while you do this", "run a quick verification with proof". Use for single-task functional verification with evidence output. Do NOT use to grow a durable test suite (that is Stages 1-4 of `element-interactions`), to expand coverage iteratively (that is `coverage-expansion`), to compose a journey portfolio (that is `test-composer`), to hunt bugs adversarially (that is `bug-discovery`), to repair a rotted suite (that is `test-repair`), or

selector-development

Use when test authoring needs a stable selector for an element that has none — and only when the test work lives in the same project as the frontend source. Adds a single inert test attribute (data-testid or the project's detected convention) to the offending element, runs an 8-step hook-enforced guardrail pipeline (typecheck + unit + e2e + visual diff), and lets the calling skill resume. Triggers from Stage 2 inspection escalation (no stable selector found), from failure-diagnosis (fragile-selector root cause), or directly when the user says "add stable selectors to <X>" / "audit selectors across the app". Never modifies structure, class, id, aria, handlers, or text — only appends one attribute. Refuses if the workspace doesn't contain both frontend source and tests/e2e/. Two modes: JIT (one element, default) and Audit (whole-app workflow, opt-in).

schedule Updated 1 month ago

bug-discovery

Use when asked to "find bugs", "break the app", "bug hunt", "quality audit", "edge case testing", "stress test the app", "exploratory testing", "find issues", or "bug discovery". Triggers on any request for systematic adversarial testing of a web application after an existing test suite passes. Do NOT use for writing initial tests — that is element-interactions Stages 1-4. Do NOT use for expanding coverage — one journey's variant set is test-composer; whole-app iteration is coverage-expansion. Do NOT use for evidence-first single-task verification — that is companion-mode. Use only when the goal is to actively discover bugs.

coverage-expansion

Iteratively expand E2E test coverage across an entire mapped application. Owns priority ordering, journey-by-journey iteration, parallel dispatch for independent journeys, model selection per journey size, and map reconciliation between passes. Calls the test-composer skill per journey for compositional passes and invokes bug-discovery per journey for adversarial passes; does not compose tests itself. Runs in three modes: `breadth` (one horizontal sweep, fast); `standard` (three compositional passes + two adversarial passes + ledger dedup, journey-by-journey — the default); or `depth` (strict per-journey parallel on every pass, ~20× the dispatch cost — picked explicitly for high-fidelity audits). Triggers on "increase coverage", "expand tests", "iterative coverage", "deep coverage pass", and when invoked by the onboarding skill as its Phase 5.