Menu
When to write e2e tests, where to put them, and how to verify them. Apply to any task touching UI, filters, forms, or interactions.
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.
Architecture Decision Record format and rules for the developer agent. Load when the implementation introduces a structural decision worth remembering 6 months later — new pattern, new dependency, deliberate departure from convention, non-obvious schema choice. Skip for naming and file-layout micro-choices. No ADR is the default.
Coding practices for backend development in Atomic CRM. Use when deciding whether backend logic is needed, or when creating/modifying database migrations, views, triggers, RLS policies, edge functions, or custom dataProvider methods that call Supabase APIs.
Remove one or more of the initial CRM resources (contacts, companies, deals, tags, tasks) from the codebase. Use when the user asks to delete, remove, or strip out one or several of these built-in resources. Runs the delete-initial-resource.ts script to drop each resource's own folder, then guides cleanup of every file that references them.
Playwright E2E testing patterns — web-first assertions, user-visible locators, network interception, fixtures, authentication, and parallel execution. Use when building or reviewing E2E tests with Playwright, when setting up browser testing for a web app, or when migrating from Cypress or Selenium.
Domain-by-domain interview to produce $CLAUDE_PROJECT_DIR/docs/project-context.json. Invoked once by the orchestrator; the orchestrator then conducts all turns directly using Read/Write/Edit — no agent dispatching.
Shadcn/ui theming and component customization — CSS variables, OKLCH colors, dark mode, variants, wrappers. Load for any ticket involving colors, theme, UI layout, or component styling.
| name | e2e-conventions |
| description | When to write e2e tests, where to put them, and how to verify them. Apply to any task touching UI, filters, forms, or interactions. |
Reference for whether an e2e test is required, where it goes, and what it must assert. For the assertion/locator patterns inside the spec, see
Skill({skill: "playwright-testing"}).
A change requires an e2e test if it touches any of:
Exception: pure CSS or a DB-migration-only change. State this explicitly in the task notes.
Under e2e/, named after the feature:
e2e/<feature-name>.spec.ts
If the work is tracked under a ticket id, you may prefix the file with it (e.g. e2e/TASK-001-deal-importance.spec.ts) to make it easy to find — but the ticket id is not required.
Write the spec alongside the implementation. The reviewer checks that the spec exists and asserts the right thing. CI runs it — don't run it locally yourself.
e2e/*.spec.ts added.e2e/, or that asserts nothing user-visible.e2e/.playwright-testing patterns.