القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| 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.
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.
