@quanticjs/create-app 0.1.1

package/templates/claude/skills/docker-dev/SKILL.md

@@ -0,0 +1,86 @@
+# Docker Dev Environment
+
+## Architecture
+```
+Backend (NestJS) → Docker Compose (volume-mounted, watch mode)
+Frontend (Vite)  → Native on host (NOT in Docker — HMR reliability)
+Infrastructure   → Docker internal network (no ports exposed except API + Keycloak)
+```
+
+## Commands
+| Action | Command |
+|--------|---------|
+| Start all | `docker compose up` |
+| Start with rebuild | `docker compose up --build` |
+| Start backend only | `docker compose up backend` |
+| View logs | `docker compose logs -f backend` |
+| Stop all | `docker compose down` |
+| Reset data | `docker compose down -v && docker compose up` |
+| Shell into container | `docker compose exec backend sh` |
+| Check health | `docker compose ps` |
+
+## Ports (exposed to host)
+| Port | Service | Purpose |
+|------|---------|---------|
+| 3000 | Backend API | Vite proxies `/api/*` and `/auth/*` here |
+| 8080 | Keycloak | OIDC browser redirects require direct access |
+| 5173 | Vite (native) | Frontend dev server — NOT in Docker |
+
+All other infrastructure (PostgreSQL, Redis, ELK, etc.) stays on Docker's internal network with no host ports.
+
+## Daily Workflow
+```bash
+# Terminal 1: Backend + infrastructure
+docker compose up
+
+# Terminal 2: Frontend (native Vite)
+cd client && npm run dev
+
+# Browser: http://localhost:5173
+```
+
+## Troubleshooting
+
+### Container won't start
+```bash
+docker compose logs <service> --tail=50
+docker compose ps  # check health status
+```
+
+### Database issues
+```bash
+docker compose exec postgres psql -U postgres -d autoflux
+npx typeorm migration:show    # check pending migrations
+npx typeorm migration:run     # apply pending
+```
+
+### Redis issues
+```bash
+docker compose exec redis redis-cli PING
+docker compose exec redis redis-cli MONITOR  # watch all commands
+```
+
+### Port conflicts
+```bash
+lsof -i :3000  # find what's using the port
+docker compose down && docker compose up  # restart clean
+```
+
+### Volume mount not syncing
+```bash
+docker compose restart backend  # force re-read of mounted source
+```
+
+## Adding Infrastructure
+1. Add service to `docker-compose.yml` with healthcheck
+2. Add to backend `depends_on` with `condition: service_healthy`
+3. Use Docker hostname in backend config (e.g., `postgres`, `redis`) — NOT `localhost`
+4. Do NOT expose port to host unless absolutely required
+
+## Rules
+- NEVER run Vite inside Docker — HMR is unreliable with volume mounts
+- NEVER expose infrastructure ports to host (except Keycloak for OIDC redirects)
+- NEVER hardcode API URLs in frontend — use relative paths (`/api/...`)
+- NEVER use `docker compose up` for tests — use `docker-compose.test.yml`
+- NEVER run services as root in production images
+- Backend uses Docker hostnames (`postgres`, `redis`, `keycloak`) — NOT `localhost`

package/templates/claude/skills/e2e-audit/SKILL.md

@@ -0,0 +1,85 @@
+# E2E Audit — Verify Existing Specs Against Real Pages
+
+## Usage
+```
+/e2e-audit                              # Audit all specs
+/e2e-audit client/e2e/projects-list.spec.ts   # Audit one spec
+```
+
+## What this does
+
+For each spec file in `client/e2e/`, open the corresponding page via Playwright MCP and compare what's on screen vs what the spec tests. Report gaps and fix them.
+
+**Announce "using Playwright MCP" before the first `browser_navigate`.**
+
+## Reproducing Failing Coded Specs
+
+If a coded spec in `client/e2e/` is failing in CI, do NOT guess at the fix from the stack trace alone. Open the exact route via MCP, read the accessibility tree, and diff it against the selectors in the failing test. Paste the a11y snapshot into the fix commit message so the next reviewer can see what the live DOM looked like.
+
+## Prerequisites
+
+1. Docker test stack running: `docker compose -f docker-compose.test.yml up -d`
+2. Frontend dev server running: `cd client && VITE_API_URL=http://localhost:3099 npm run dev -- --port 5199`
+3. Auth state saved (or authenticate via MCP on first `browser_navigate`)
+
+**IMPORTANT:** Always use the isolated test stack (`docker-compose.test.yml`) — NEVER `docker compose up` against the dev stack. Test ports: API 3099, Keycloak 8099, Frontend 5199.
+
+## Base URL
+
+`http://localhost:5199`
+
+## Process per spec file
+
+### 1. Read the spec
+Read the spec file. Note which route it tests, what selectors it uses, and which states it covers.
+
+### 2. Open the page via MCP
+- `browser_navigate` to the route
+- `browser_screenshot` to see the current layout
+- Read the accessibility tree
+
+### 3. Compare and report
+
+For each spec, check:
+
+| Check | Pass/Fail |
+|-------|-----------|
+| **All 4 states tested?** (happy, error, empty, loading) | |
+| **Selectors match real elements?** (heading text, button labels, etc.) | |
+| **No stale selectors?** (elements that no longer exist) | |
+| **No missing elements?** (interactive elements on page not tested) | |
+| **Auth boundary tested?** (unauthenticated redirect) | |
+| **No anti-patterns?** (CSS selectors, waitForTimeout, isVisible().toBe(true)) | |
+
+### 4. Fix issues found
+- Update stale selectors to match current accessibility tree
+- Add missing state tests (error, empty, loading)
+- Remove tests for elements that no longer exist
+- Add tests for new elements discovered via MCP
+
+## Spec files to audit
+
+```
+client/e2e/login.spec.ts
+client/e2e/dashboard.spec.ts
+client/e2e/projects-list.spec.ts
+client/e2e/create-project.spec.ts
+client/e2e/project-detail.spec.ts
+client/e2e/prompt-templates.spec.ts
+client/e2e/profile.spec.ts
+client/e2e/settings.spec.ts
+client/e2e/users.spec.ts
+```
+
+## Output format
+
+Print a summary table at the end:
+
+```
+| Spec | 4 States | Selectors OK | Anti-patterns | Action |
+|------|----------|--------------|---------------|--------|
+| login.spec.ts | 3/4 (missing empty) | OK | None | N/A — no data endpoint |
+| dashboard.spec.ts | 2/4 | OK | .animate-spin | Added loading test |
+| projects-list.spec.ts | 4/4 | 1 stale | None | Fixed heading selector |
+| ... | ... | ... | ... | ... |
+```

package/templates/claude/skills/e2e-full/SKILL.md

@@ -0,0 +1,132 @@
+# E2E Full — Orchestrated Test Suite
+
+Run all E2E skills in the correct sequence. Each phase feeds into the next.
+
+## Usage
+
+- `/e2e-full` — run all 3 phases in order
+- `/e2e-full scan` — run only the scan phase
+- `/e2e-full audit` — run only the audit phase
+- `/e2e-full verify` — run only the verify phase
+
+## Prerequisites
+
+- Base URL: `http://localhost:5199`
+- Docker test stack running: `docker compose -f docker-compose.test.yml up -d`
+- Frontend dev server running: `cd client && VITE_API_URL=http://localhost:3099 npm run dev -- --port 5199`
+
+Phase 0 handles the rest automatically.
+
+**IMPORTANT:** E2E tests MUST use the isolated test stack (`docker-compose.test.yml`) with separate ports — NEVER the dev stack. Test ports: API 3099, Keycloak 8099, Frontend 5199.
+
+## Execution Order
+
+### Phase 0: Clean Stack (automatic)
+
+**Purpose:** Guarantee a clean database, fresh containers, and a working MCP toolchain before any test phase runs.
+
+1. **MCP preflight** — verify the toolchain before touching Docker:
+   - `node --version` must report **v18 or higher**
+   - Confirm `.claude/mcp.json` pins a specific `@playwright/mcp` version (NOT `@latest`)
+   - Run `npx playwright install` to ensure browser binaries match the pinned MCP version
+2. Tear down any existing test stack:
+   ```bash
+   docker compose -f docker-compose.test.yml down -v
+   ```
+3. Rebuild and start the test stack:
+   ```bash
+   docker compose -f docker-compose.test.yml up -d --build
+   ```
+4. Wait for all services to be healthy (postgres, redis, keycloak, backend)
+5. Start frontend dev server on test port:
+   ```bash
+   cd client && VITE_API_URL=http://localhost:3099 npm run dev -- --port 5199 &
+   ```
+6. Save auth state for MCP journeys (against test stack):
+   ```bash
+   cd client && KEYCLOAK_PORT=8099 API_PORT=3099 npx tsx ../scripts/save-auth-state.ts
+   ```
+7. **MCP smoke test** — before declaring Phase 0 done, `browser_navigate` to `http://localhost:5199/` and confirm the accessibility tree returns. If MCP tools don't respond, STOP and report the MCP failure rather than running journeys blind.
+
+**Stop condition:** If any service fails to become healthy within 3 minutes, STOP and report which service is unhealthy. Do not proceed to Phase 1. If the MCP smoke test fails, STOP — re-check `.claude/mcp.json` and Node version.
+
+**Output:** Service health status table.
+
+---
+
+### Phase 1: Scan (`/e2e-scan`)
+
+**Purpose:** Find missing journey coverage before testing.
+
+1. Load `/e2e-scan` skill
+2. Execute the scan — it reads routes, forms, hooks, and diffs against existing specs in `client/e2e/`
+3. If gaps are found, the scan generates missing spec files
+
+**Stop condition:** None — scan always completes. Report any gaps found.
+
+**Output:** Gap report table + list of specs generated (if any).
+
+---
+
+### Phase 2: Audit (`/e2e-audit`)
+
+**Purpose:** Verify Playwright spec files match the real UI after code changes.
+
+1. Load `/e2e-audit` skill
+2. For each spec file in `client/e2e/`, open the page via MCP and compare selectors against the accessibility tree
+3. Report stale selectors, missing state tests, anti-patterns
+
+**Stop condition:** None — audit always completes. Report all findings.
+
+**Output:** Per-spec table with status (OK / STALE / MISSING) and recommended fixes.
+
+---
+
+### Phase 3: Verify (`/e2e-verify`)
+
+**Purpose:** Walk through all user journeys and confirm pages render, forms work, navigation flows.
+
+1. Load `/e2e-verify` skill
+2. Execute ALL journeys (currently 10) — do not stop early
+3. Report each journey as PASS / FAIL / SKIP / UNTESTED
+
+**Stop condition:** If more than 3 journeys FAIL, stop and report. Likely a systemic issue (auth expired, server down) rather than individual bugs.
+
+**Session recovery:** If any journey redirects to `/login` unexpectedly mid-run, the storage state has expired. Re-run `cd client && npx tsx ../scripts/save-auth-state.ts` and retry the failed journey ONCE before marking it FAIL.
+
+**Output:** Completion checklist table with result per journey.
+
+---
+
+## Final Report
+
+After all phases complete, produce a summary:
+
+```
+## E2E Full Run Summary
+
+| Phase | Status | Details |
+|-------|--------|---------|
+| 0. Clean Stack | DONE | test stack down -v + up --build, all services healthy |
+| 1. Scan | DONE | X gaps found, Y specs generated |
+| 2. Audit | DONE | X specs OK, Y stale, Z missing |
+| 3. Verify | DONE | X pass, Y fail, Z skip |
+
+### Failed Journeys (action required)
+- [Phase 3] Journey #N: <name> — <what failed>
+
+### Stale Specs (action required)
+- <spec file> — <selector> no longer matches
+
+### Gaps Added (review recommended)
+- <spec file> generated for <route>
+```
+
+## Rules
+
+- **NEVER skip Phase 0.** Every `/e2e-full` run starts with a clean `docker compose -f docker-compose.test.yml down -v` + `up --build`. Stale data causes false passes.
+- **NEVER use the dev stack (`docker compose up`) for E2E tests.** Always use `docker-compose.test.yml` with isolated test ports (API 3099, Keycloak 8099, Frontend 5199).
+- **NEVER skip a phase silently.** If you can't run a phase, report it as SKIPPED with reason.
+- **NEVER combine phases.** Each phase is a distinct section with its own output.
+- **If running a single phase** (e.g. `/e2e-full verify`), only run that phase and produce its section of the report.
+- **Context management:** If context is running low during Phase 3, mark remaining journeys as UNTESTED rather than silently omitting them.

package/templates/claude/skills/e2e-scan/SKILL.md

@@ -0,0 +1,171 @@
+# E2E Scan — Discover Missing Test Coverage & Generate Specs
+
+## Usage
+```
+/e2e-scan                         # Full scan — all pages, all flows
+/e2e-scan project                 # Scan only project-related flows
+/e2e-scan --report-only           # Report gaps without generating specs
+```
+
+## What this does
+
+Scans the codebase to discover all user-facing flows (pages, forms, multi-step wizards, interactions), compares them against existing Playwright specs in `client/e2e/`, reports gaps, and generates missing spec files.
+
+## Process
+
+### Phase 1: Discover All Flows
+
+Scan these sources to build a complete inventory of user-facing flows:
+
+#### 1a. Routes & Pages
+- Read the router config (React Router) for all route definitions
+- Read each page component in `client/src/pages/` — note form steps, tabs, interactive elements
+- Note protected vs public routes
+
+#### 1b. Multi-Step Forms
+- Search `client/src/pages/` for step-based forms (look for `step`, `currentStep`, `setStep`, stepper patterns)
+- For each form, list all steps and the fields/interactions in each step
+- Note form submission endpoints and success redirects
+
+#### 1c. Interactive Features
+- Search for drawers, modals, dialogs (`Dialog`, `Drawer`, `Sheet`) and what triggers them
+- Search for tab switchers (`Tabs`, `TabsList`, tab state) and what content each tab shows
+- Search for filter/search components and what they filter
+- Search for infinite scroll / pagination (`usePaginatedQuery`, "Load more")
+
+#### 1d. API-Driven Flows
+- Read `client/src/hooks/` for all `useApiQuery`/`useApiMutation` hooks — each mutation represents a flow
+- Note which hooks are used by which pages (grep for hook names in pages)
+- Pay attention to mutations that trigger navigation or state changes
+
+#### 1e. Schema Drift Check
+- Read backend DTOs (`src/**/dtos/*.dto.ts`) for field additions/removals
+- Cross-reference with E2E mock data — if a DTO field exists that no mock covers, the E2E coverage has a gap
+
+### Phase 2: Read Existing Test Coverage
+
+- List all spec files in `client/e2e/` — extract the routes and flows each covers
+- Read each spec to understand which states are tested (happy, error, empty, loading)
+- Build a coverage matrix: route → states tested
+
+### Phase 3: Gap Analysis
+
+For each discovered flow, check:
+
+| Check | Covered? |
+|-------|----------|
+| Page renders & basic navigation | Spec file exists? |
+| Happy path (data loads, displays correctly) | `test('shows ... on success')` exists? |
+| Error state (API failure) | `test('shows error')` exists? |
+| Empty state (no data) | `test('shows empty state')` exists? |
+| Loading state (skeleton/spinner) | `test('shows loading')` exists? |
+| Form submission + validation errors | Mutation flow tested? |
+| All tabs/views on the page | Each tab has assertions? |
+| Responsive (mobile viewport) | Mobile test exists? |
+
+### Phase 4: Report
+
+Print a gap analysis table:
+
+```
+## E2E Coverage Report
+
+| Route / Flow | Spec File | Happy | Error | Empty | Loading | Gap |
+|---|---|---|---|---|---|---|
+| /projects | projects.spec.ts | ✅ | ✅ | ❌ | ❌ | Missing empty + loading states |
+| /projects/:id | - | ❌ | ❌ | ❌ | ❌ | No spec file |
+| /settings | settings.spec.ts | ✅ | ❌ | N/A | ❌ | Missing error + loading |
+| ...
+
+### Summary
+- **Covered:** N routes with full 4-state coverage
+- **Partial:** M routes missing some states
+- **Uncovered:** K routes with no spec at all
+```
+
+### Phase 5: Generate Missing Specs
+
+For each uncovered or partially covered route, generate a spec file following the `/write-ui-tests` pattern:
+
+1. Create spec at `client/e2e/<route-name>.spec.ts`
+2. Include all 4 mandatory states (happy, error, empty, loading)
+3. Mock auth via `page.route('**/auth/me', ...)`
+4. Mock API endpoints via `page.route()`
+5. Use semantic locators (`getByRole`, `getByText`) — NEVER CSS selectors
+
+#### Spec template
+
+```typescript
+import { test, expect } from '@playwright/test';
+
+test.describe('<PageName> Page', () => {
+  test.beforeEach(async ({ page }) => {
+    await page.route('**/auth/me', route => route.fulfill({
+      status: 200,
+      contentType: 'application/json',
+      body: JSON.stringify({ keycloakId: 'kc-1', email: 'test@test.com', roles: ['user'] }),
+    }));
+  });
+
+  test('shows data on success', async ({ page }) => {
+    await page.route('**/api/<endpoint>*', route => route.fulfill({
+      status: 200, json: { data: [/* mock data */] },
+    }));
+    await page.goto('/<route>');
+    await expect(page.getByRole('heading', { name: '<expected>' })).toBeVisible();
+  });
+
+  test('shows error on API failure', async ({ page }) => {
+    await page.route('**/api/<endpoint>*', route => route.fulfill({ status: 500 }));
+    await page.goto('/<route>');
+    await expect(page.getByText(/something went wrong|error|try again/i)).toBeVisible();
+  });
+
+  test('shows empty state when no data', async ({ page }) => {
+    await page.route('**/api/<endpoint>*', route => route.fulfill({
+      status: 200, json: { data: [] },
+    }));
+    await page.goto('/<route>');
+    await expect(page.getByText(/no <items>/i)).toBeVisible();
+  });
+
+  test('shows loading while fetching', async ({ page }) => {
+    await page.route('**/api/<endpoint>*', async route => {
+      await new Promise(r => setTimeout(r, 2000));
+      await route.fulfill({ status: 200, json: { data: [] } });
+    });
+    await page.goto('/<route>');
+    // Assert skeleton visible
+  });
+});
+```
+
+### Phase 6: Verify Generated Specs
+
+- Read each generated spec to confirm selectors are plausible (based on component source)
+- Confirm mock data shape matches the actual API response DTOs
+- Run: `cd client && npx playwright test <spec-file> --reporter=list`
+
+## What NOT to do
+
+- Don't generate specs for static pages with no API calls (just a heading check is enough)
+- Don't duplicate coverage already in existing specs
+- Don't guess at selectors — read the component source to find actual text/roles
+- Don't test third-party service behavior
+- Don't test backend-only flows (those belong in `/write-backend-tests`)
+
+## Output
+
+End with a summary:
+
+```
+## Generated Specs
+
+- client/e2e/project-detail.spec.ts — covers /projects/:id (4 states)
+- client/e2e/settings.spec.ts — added missing error + loading tests
+
+## Still Needs Manual Attention
+
+- /ai-gateway/* — complex multi-step flow, needs manual spec design
+- /admin/* — requires admin role seeding
+```

package/templates/claude/skills/e2e-verify/SKILL.md

@@ -0,0 +1,145 @@
+# E2E Verify — Playwright MCP Journeys
+
+Walk through user journeys interactively using Playwright MCP browser control. No spec files, no selectors to maintain.
+
+**Announce "using Playwright MCP" before the first `browser_navigate`** — this prevents Claude from falling back to Bash-driven Playwright.
+
+## Viewport Matrix
+
+For journeys that verify rendering/layout, resize the browser and re-check at two viewports:
+
+| Viewport | Size | Purpose |
+|----------|------|---------|
+| Desktop | 1440 × 900 | Primary layout with sidebar |
+| Tablet | 768 × 1024 | Collapsed sidebar, responsive grid |
+
+Use `browser_resize` between viewports.
+
+## Prerequisites
+
+1. Docker test stack running: `docker compose -f docker-compose.test.yml up -d`
+2. Frontend dev server running: `cd client && VITE_API_URL=http://localhost:3099 npm run dev -- --port 5199`
+3. Auth state saved (against test stack): `cd client && KEYCLOAK_PORT=8099 API_PORT=3099 npx tsx ../scripts/save-auth-state.ts`
+   - This completes the BFF OIDC login flow and saves the httpOnly session cookie
+   - The app uses BFF cookies for auth — NOT sessionStorage/localStorage tokens
+4. If auth state is empty or expired, authenticate via MCP:
+   - Navigate to `/auth/login?provider=keycloak&returnTo=/`
+   - Fill Keycloak form (testuser / TestPassword1!)
+   - Verify redirect back to app with session cookie set
+
+**IMPORTANT:** Always use the isolated test stack (`docker-compose.test.yml`) — NEVER `docker compose up` against the dev stack. Test ports: API 3099, Keycloak 8099, Frontend 5199.
+
+## Base URL
+
+`http://localhost:5199`
+
+## Journeys
+
+### 1. Auth Boundaries
+1. Without auth, navigate to `/projects` — verify redirect to `/login`
+2. Navigate to `/login` — verify login page with Keycloak and Google sign-in buttons
+3. Authenticate via BFF `/auth/login?provider=keycloak` — verify Keycloak form, login, redirect to app
+4. After auth, navigate to `/login` — verify redirect to `/` (dashboard)
+
+### 2. Dashboard
+1. Navigate to `/` — verify heading "Dashboard"
+2. Verify welcome message shows user display name ("Welcome back, <name>")
+3. Verify "Getting Started" card with "Your AutoFlux workspace is ready" description
+4. Verify navigation hint to Projects
+
+### 3. Sidebar Navigation
+1. Verify sidebar renders with navigation links: Dashboard, Projects, Users, Settings
+2. Verify active link styling matches current route
+3. Click collapse toggle — verify sidebar collapses (icons only)
+4. Click expand toggle — verify sidebar expands back
+5. Verify logout button present and functional
+6. Verify admin links visible only for admin role (Prompt Templates)
+
+### 4. Projects List
+1. Navigate to `/projects` — verify heading "Projects"
+2. If projects exist — verify project cards render with name and GitHub repo URL
+3. If no projects — verify empty state "No projects yet" with "Create your first project" CTA
+4. Verify "New Project" link/button navigates to `/projects/new`
+
+### 5. Create Project
+1. Navigate to `/projects/new` — verify heading "Create Project"
+2. Verify form fields: Project Name input, GitHub Organization dropdown (async-loaded), Repository Name input
+3. Verify organization dropdown shows loading state then populates from GitHub API
+4. Enter repo name — verify real-time validation (alphanumeric, hyphens, underscores, dots)
+5. Enter invalid repo name (e.g. "my repo!") — verify validation error message
+6. Fill all fields with valid data — verify preview URL shows `github.com/<org>/<repo>`
+7. Click "Create Project" — verify submission spinner, then redirect to `/projects`
+8. Verify cancel button navigates back to `/projects`
+
+### 6. Project Detail & Planning
+1. Navigate to `/projects/:id` — verify project name heading, GitHub repo URL link
+2. Verify BRD upload section renders with drag-and-drop zone
+3. Verify "Start Planning" button is disabled before file selection
+4. Select a file (drag or click) — verify file name shown, "Start Planning" enabled, "Clear" visible
+5. Click "Start Planning" — verify spinner during upload
+6. After success — verify "Planning run started" message
+7. If API returns error — verify error message displayed
+
+### 7. Profile
+1. Navigate to `/profile` — verify heading "Profile"
+2. Verify avatar with initials (derived from display name)
+3. Verify display name, email, role, and user ID displayed
+4. Verify card layout with proper labels
+
+### 8. Admin — Prompt Templates
+1. Navigate to `/admin/prompt-templates` — verify heading "Prompt Templates"
+2. If templates exist — verify step cards with step number, name, template preview, approver roles
+3. If no templates — verify "None defined yet" empty state
+4. Click "Add Step" — verify create form opens with step name input, template textarea
+5. Fill form and submit — verify new step appears in list
+6. Click "Edit" on a template — verify inline edit mode with textarea
+7. Edit and save — verify updated content persists
+8. Verify error handling on create failure (validation error displayed)
+
+### 9. Settings (Stub)
+1. Navigate to `/settings` — verify heading "Settings" with "Configure your workspace" subtitle
+2. Verify "Workspace Settings" card with admin-only description
+
+### 10. Users (Stub)
+1. Navigate to `/users` — verify heading "Users" with "Manage users and their roles" subtitle
+2. Verify "User Management" card with admin-only description
+
+## Reporting
+
+**MANDATORY: Complete ALL journeys.** Do not stop early. If context is running low, summarize remaining journeys as UNTESTED rather than silently omitting them.
+
+For each journey, report:
+- **PASS** — all pages render correctly, navigation works
+- **FAIL** — specify which step failed and what was wrong (include screenshot)
+- **SKIP** — if prerequisite data doesn't exist
+- **UNTESTED** — journey was not attempted (context limit, blocker, etc.)
+
+### Completion Checklist (copy into your final report)
+
+```
+| #  | Journey                    | Result   |
+|----|----------------------------|----------|
+|  1 | Auth Boundaries            |          |
+|  2 | Dashboard                  |          |
+|  3 | Sidebar Navigation         |          |
+|  4 | Projects List              |          |
+|  5 | Create Project             |          |
+|  6 | Project Detail & Planning  |          |
+|  7 | Profile                    |          |
+|  8 | Admin — Prompt Templates   |          |
+|  9 | Settings (Stub)            |          |
+| 10 | Users (Stub)               |          |
+```
+
+**Every row must have a result.** An incomplete checklist is a failed run.
+
+## What MCP Covers vs What Coded Tests Cover
+
+| MCP Journeys | Coded Tests (`client/e2e/`) |
+|---|---|
+| Page renders correctly | Mock-based state assertions |
+| Navigation flows work | 4-state coverage (happy/error/empty/loading) |
+| Forms display fields & validate | API response shape verification |
+| Visual layout intact | Isolated page-level testing |
+| Interactive elements respond | Auth boundary testing |
+| File upload UX works | Form submission flows |

package/templates/claude/skills/fix-bug/SKILL.md

@@ -0,0 +1,33 @@
+# Fix Bug
+
+## Usage
+```
+/fix-bug <issue-number-or-description>
+```
+
+## Process (this order is mandatory)
+
+### Step 1: Reproduce
+- Read the bug report (issue, error log, or description)
+- Identify the failing behavior and expected behavior
+- Find the relevant code paths
+
+### Step 2: Regression Test FIRST
+- Write a test that reproduces the bug
+- Run it — **verify it fails** (this proves the bug exists and the test catches it)
+- If the test passes, your test is wrong — it does not reproduce the bug
+
+### Step 3: Fix
+- Analyze the root cause (not just the symptom)
+- Implement the minimal fix
+- Run the regression test — **verify it now passes**
+- Run `npm run build && npm test` — verify nothing else broke
+
+### Step 4: Commit
+- Commit with message: `fix: <what-was-fixed> (#<issue-number>)`
+
+## Rules
+- The regression test MUST exist before the fix — no exceptions
+- Fix the root cause, not the symptom
+- Keep the fix minimal — don't refactor surrounding code
+- Follow project conventions in CLAUDE.md and `.claude/rules/`