convert cursor rules to skills

Author: Mbeaulne

.claude/skills/e2e-testing/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: e2e-testing
+description: Playwright E2E testing best practices for this project. Use when writing, modifying, or reviewing E2E tests.
+---
+
+# E2E Testing Best Practices (Playwright)
+
+## Setup
+
+- Use Playwright helpers from `tests/e2e/helpers.ts`
+- Use `data-testid` attributes for stable selectors
+- Write descriptive test names that explain user behavior
+- Ensure tests are isolated and can run independently
+
+## Never Use Hard-Coded Timeouts
+
+```typescript
+// Bad
+await element.click();
+await page.waitForTimeout(200);
+
+// Good
+await element.click();
+await expect(otherElement).toBeVisible();
+```
+
+## Use Playwright's Auto-Waiting
+
+```typescript
+// Bad
+if (await element.isVisible()) {
+  await element.click();
+}
+
+// Good
+await expect(element).toBeVisible();
+await element.click();
+```
+
+## Never Use Non-Null Assertions
+
+```typescript
+// Bad
+const box = await element.boundingBox();
+const x = box!.x;
+
+// Good
+const box = await element.boundingBox();
+if (!box) {
+  throw new Error("Unable to locate element bounding box");
+}
+const x = box.x;
+```
+
+## Don't Await Locators (They're Lazy)
+
+```typescript
+// Bad
+const button = await page.getByTestId("submit");
+
+// Good
+const button = page.getByTestId("submit");
+await expect(button).toBeVisible();
+```
+
+## Use Consistent Assertion Patterns
+
+```typescript
+// Bad
+expect(await element).toHaveText("text");
+expect(await element.isVisible()).toBe(true);
+
+// Good
+await expect(element).toHaveText("text");
+await expect(element).toBeVisible();
+```
+
+## Prefer Semantic Selectors
+
+Priority order:
+1. `getByRole()` - Best for accessibility
+2. `getByTestId()` - Best for test stability (preferred for this app)
+3. `getByText()` - Good for static content
+4. `locator()` with data attributes - When above don't work
+5. CSS selectors - Last resort
+
+## Test Isolation
+
+- Each test should set up its own state
+- Don't depend on test execution order (unless using serial mode intentionally)
+- Clean up after tests in `afterEach` or `afterAll`
+
+## Helper Functions
+
+- Leverage existing helpers from `tests/e2e/helpers.ts`
+- Create new helpers for repeated workflows
+- Keep helpers focused and reusable
+
+## Add Meaningful Error Context
+
+```typescript
+// Okay
+await expect(element).toBeVisible();
+
+// Better
+await expect(element, "Component should appear after loading").toBeVisible();
+```
+
+## Test User Behavior, Not Implementation
+
+```typescript
+// Bad - implementation detail
+await expect(button).toHaveClass("bg-blue-500");
+
+// Good - user-visible behavior
+await expect(button).toBeVisible();
+await expect(button).toBeEnabled();
+await expect(button).toHaveText("Submit");
+```

.claude/skills/project-conventions/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: project-conventions
+description: Project conventions for Pipeline Studio App including file structure, imports, code quality, and general rules. Use when writing new code, creating files, or organizing imports.
+---
+
+# Project Conventions
+
+## Project Overview
+
+React + TypeScript application for building and running ML pipelines using drag and drop. Uses Vite, TailwindCSS v4, ShadCN, Radix UI, React Flow, and Monaco Editor.
+
+## File Structure & Imports
+
+- Use absolute imports with `@/` prefix for src directory
+- Follow existing folder structure:
+  - `src/components/` for all React components
+  - `src/hooks/` for custom hooks
+  - `src/types/` for TypeScript definitions
+  - `src/utils/` for utility functions
+  - `src/services/` for API and business logic
+- **Import order**: external packages -> internal modules -> relative imports
+- Use simple-import-sort rules (already configured in ESLint)
+- Do not use barrel exports
+
+## Code Quality
+
+- Follow ESLint rules (configured in eslint.config.js)
+- Use Prettier for formatting
+- Write tests using Vitest for unit tests, Playwright for E2E
+- Use descriptive variable and function names
+- Add JSDoc comments for complex functions
+- Prefer early returns to reduce nesting
+
+## Comments & Documentation
+
+- Use JSDoc for public APIs
+- Add comments for complex business logic
+- **Explain "why" not "what" in comments**
+- Keep comments up to date with code changes
+- Avoid writing redundant comments for functions and variables that are self-explanatory
+
+## Error Handling
+
+- Use proper error boundaries
+- Handle async errors with try/catch
+- Use toast notifications for user-facing errors
+- Log errors appropriately
+
+## React Flow Specific
+
+- Use `@xyflow/react` for flow diagrams
+- Follow existing node types and edge patterns
+- Keep flow state management consistent with existing patterns
+- Use proper node and edge typing
+
+## Specific Project Patterns
+
+- Use Monaco Editor for code editing features
+- Use localforage for client-side storage
+- Follow existing authentication patterns
+- Use proper task node and pipeline handling patterns
+- Follow the existing component library structure
+- **Do not modify componentSpec structure** without express permission
+
+## Don't Do
+
+- Don't use CSS-in-JS or styled-components
+- Don't use inline styling (`style={styles}`) except where strictly necessary
+- Don't use relative imports for `@/components/ui`
+- Don't create new global state without good reason
+- Don't bypass existing abstractions without discussion
+
+## Planning & Documentation
+
+When asked to create planning documents, architecture decisions, or investigation notes:
+- **Always save to `.local/`** - This directory is gitignored for local-only files
+- Use descriptive filenames: `.local/feature-name-planning.md`, `.local/bug-investigation.md`
+
+## Optional "While We're Here" Cleanup
+
+After completing a code generation task, scan the surrounding area for small, low-risk improvements. **Only offer** if ALL conditions are met:
+
+1. **Small scope**: Affects < 30 lines of code
+2. **Low risk**: Purely cosmetic or minor refactoring (not logic changes)
+3. **Same file**: In a file you already modified
+4. **Clear benefit**: Improves readability, removes dead code, or fixes obvious issues
+
+Don't be naggy — only offer once per task, and only if genuinely worthwhile.

.claude/skills/react-patterns/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: react-patterns
+description: React and React Compiler patterns for this project. Use when writing React components, hooks, providers, or working with React Compiler compatibility.
+---
+
+# React Patterns
+
+## Core Rules
+
+- Use functional components with hooks exclusively (no class components)
+- Use proper dependency arrays in useEffect
+- Follow the existing component structure
+- Use React 19 features and patterns
+- **Import modules from React**: `import module from react`. Do not use inline `React.[module]`
+
+## Component Structure
+
+```typescript
+// ComponentName/index.ts
+export { ComponentName } from './ComponentName';
+
+// ComponentName/ComponentName.tsx
+interface ComponentNameProps {
+  // props
+}
+
+export const ComponentName = ({ }: ComponentNameProps) => {
+  // component logic
+  return (
+    // JSX
+  );
+};
+```
+
+## Custom Hooks
+
+- Prefix with `use`
+- Return objects for multiple values, not arrays
+- Use proper TypeScript return types
+- Follow existing patterns in `src/hooks/`
+
+## Provider Pattern
+
+```typescript
+const Context = createContext<ContextType | null>(null);
+
+export const Provider = ({ children }: { children: ReactNode }) => {
+  // provider logic
+  return <Context.Provider value={value}>{children}</Context.Provider>;
+};
+
+export const useContext = () => {
+  const context = useContext(Context);
+  if (!context) throw new Error('useContext must be used within Provider');
+  return context;
+};
+```
+
+## State Management
+
+- Use Tanstack Query for server state
+- Use Tanstack Router for routing
+- Use React hooks for local component state
+- Use Context providers for app-wide state (see existing providers in `src/providers/`)
+- **Use `useRequiredContext`** to simplify context usage and avoid null checks
+
+## React Compiler
+
+This project uses the React Compiler for automatic memoization. Files/directories are incrementally adopted in `react-compiler.config.js`.
+
+### Writing React Compiler Compatible Code
+
+**For new files**, ensure they follow React Compiler rules from the start:
+
+1. **Don't mutate values during render**
+   ```typescript
+   // Bad - mutating during render
+   const items = props.items;
+   items.push(newItem);
+
+   // Good - create new reference
+   const items = [...props.items, newItem];
+   ```
+
+2. **Don't read/write refs during render**
+   ```typescript
+   // Bad - reading ref during render
+   const value = myRef.current;
+   return <div>{value}</div>;
+
+   // Good - read refs in effects or callbacks
+   useEffect(() => {
+     const value = myRef.current;
+   }, []);
+   ```
+
+3. **Follow Rules of Hooks strictly** - no conditional hooks, no hooks in loops, proper dependency arrays
+
+4. **Avoid patterns the compiler can't optimize**
+   - Don't spread props with `{...props}` unnecessarily
+   - Avoid dynamic property access on objects when possible
+   - Keep component logic predictable
+
+### Adding Files to React Compiler
+
+When a file is added to `react-compiler.config.js`:
+- Remove unnecessary `useCallback` and `useMemo` (compiler handles this)
+- Verify no compiler violations with `npm run validate`
+- Test the component still works correctly
+
+### React Compiler Config Structure
+
+Files are organized by cleanup effort in `react-compiler.config.js`:
+- Top section: Already enabled directories/files
+- Middle: Ready to enable (0 useCallback/useMemo)
+- Bottom (commented): Need cleanup before enabling
+
+## Performance
+
+- **Do not use `useMemo`, `useCallback`, or `memo` manually** — the React Compiler handles memoization automatically
+- If you encounter existing `useMemo`/`useCallback`/`memo` in a file, remove them when the file is enabled in `react-compiler.config.js`
+- Lazy load heavy components when possible
+- Follow existing patterns for optimization