// When to write e2e tests, where to put them, and how to verify them. Apply to any task touching UI, filters, forms, or interactions.
Multi-agent team workflow for implementing tickets with peer-to-peer communication inside a single shared team. Used by chat-orchestrator for COMPLEX requests only (planner → wave → teardown). Single source of truth for cross-agent messaging.
How and when to write a post-implementation reflection. Used by DEVELOPER after reviews are complete.
Domain-by-domain interview to produce /app/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.
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.
How to find a Git worktree by task number without hardcoding paths. Use in hooks or scripts that need to locate a specific task's worktree.
| 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. |
A task requires e2e tests if it touches any of:
Exception: if the task is pure CSS or a DB migration only, this must be explicitly noted in acceptance_criteria.
e2e/task-xxx-.spec.ts
Name the file after the ticket and feature — makes it easy for TEST-VALIDATOR to find it.
DEVELOPER writes them, TEST-VALIDATOR checks they exist and are syntactically valid. CI runs them — agents do not need to execute them locally.
npx tsc --noEmit e2e/task-xxx-*.spec.ts