Menu
Scaffold a Playwright Page Object plus a functional spec in tests/, following the POM conventions. Use when adding an end-to-end test for a feature or flow.
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.
Based on SOC occupation classification
Draft a high-quality GitHub bug report from a QA observation - dedup, fill the bug_report form fields. DRAFT ONLY: it never files the issue; it hands you a ready `gh issue create` command to run yourself. Use when QA finds a defect to report.
Draft a GitHub proposal (feature / enhancement / task) - dedup, classify the type, fill the proposal form fields. DRAFT ONLY: it never files the issue; it hands you a ready `gh issue create` command to run yourself. Use when proposing new capability, an improvement, or a unit of work (not a defect - that's /report-bug).
Draft a clear, reviewer-ready pull request description for the current branch (or an existing PR) - feature-first summary, motivation, test plan, linked issues - verified against the real diff. DRAFT ONLY: it never creates, edits, or pushes; it hands you a ready `gh pr create`/`gh pr edit` command to run yourself. Use when writing up a PR.
Scaffold a new backend HTTP endpoint / vertical slice in apps/backend (Zod schema + defineAction + service + mounter) following the slice conventions. Use when adding a backend endpoint, action, or resource.
Scaffold a new Tailor content extension - content element (ce), content container (cc), meta input (mi), or plugin (pl) - and wire it into the registry. Use when adding a new ce/cc/mi/pl extension to the platform.
Turn a bug (GitHub issue number or description) into a failing Playwright spec that reproduces it - POM-based, tagged @bug, linked to the issue, and marked test.fail() so CI stays green until a fix flips it red. Use to capture a known bug as a regression-first test.
| name | new-e2e |
| description | Scaffold a Playwright Page Object plus a functional spec in tests/, following the POM conventions. Use when adding an end-to-end test for a feature or flow. |
See tests/CLAUDE.md for the conventions and tests/pom/repository/ for
reference Page Objects.
Page Object. Add tests/pom/<area>/<Component>.ts - a class with a
(page, parent?) constructor, readonly Locator fields, and action
methods. Keep selectors here; never inline them in specs. Reuse an
existing POM if the component already has one.
Spec. Add tests/specs/functional/<area>/<name>.spec.ts that drives
the app through the POM. Seed state via the API using helpers/seed.ts
toX(page, ...) helpers (they seed AND navigate) - these call the seed
endpoint (api/SeedClient -> /api/seed/*) or the REST API
(api/ApiClient). For state the seed endpoint/API can't create, build it
through the POMs / the FE in the spec.
Pick the role (filename decides it). Default to admin - a plain
<name>.spec.ts runs as chrome-admin. Only use another role when the
test is specifically about that role's behaviour (permissions, access,
restricted UI): name the file <name>.default-user.spec.ts ->
chrome-default-user or <name>.collaborator.spec.ts ->
chrome-collaborator. Each role project depends on its setup-* project
for auth state.
Run one spec.
cd tests && pnpm playwright test specs/functional/<area>/<name>.spec.ts --project=chrome-admin
(the matching setup-admin project runs first).
Visual / a11y. Add Percy coverage under specs/visual/ and axe
under specs/a11y/ only if the feature needs it.
