create-claude-workspace 2.3.4 → 2.3.6

package/dist/scheduler/git/manager.mjs

@@ -244,6 +244,46 @@ export function rebaseOnMain(worktreePath, projectDir) {
         return { success: false, conflict: false, error: err.message };
     }
 }
+// ─── Clean main for merge ───
+/**
+ * Prepare main branch for merge by aborting any in-progress merge/rebase
+ * and stashing uncommitted changes (preserved for later recovery).
+ * Returns true if changes were stashed.
+ */
+export function cleanMainForMerge(projectDir) {
+    // Abort any in-progress merge (conflict state from previous failed merge)
+    try {
+        git('merge --abort', projectDir);
+    }
+    catch { /* no merge in progress */ }
+    // Abort any in-progress rebase
+    try {
+        git('rebase --abort', projectDir);
+    }
+    catch { /* no rebase in progress */ }
+    // Reset any staged changes back to unstaged
+    try {
+        git('reset HEAD', projectDir);
+    }
+    catch { /* nothing staged */ }
+    // If there are still uncommitted changes, stash them (preserves user edits)
+    const status = git('status --porcelain', projectDir);
+    if (status) {
+        try {
+            git('stash --include-untracked -m "scheduler: auto-stash before merge"', projectDir);
+            return true;
+        }
+        catch {
+            // If stash fails, force-clean as last resort
+            try {
+                git('checkout -- .', projectDir);
+            }
+            catch { /* ignore */ }
+            return false;
+        }
+    }
+    return false;
+}
 // ─── Stash operations ───
 export function stashChanges(dir) {
     const status = git('status --porcelain', dir);

package/dist/scheduler/loop.mjs

@@ -7,7 +7,7 @@ import { fetchOpenIssues, issueToTask, updateIssueStatus } from './tasks/issue-s
 import { buildGraph, getParallelBatches, isPhaseComplete, getNextPhase, isProjectComplete } from './tasks/queue.mjs';
 import { writeState, appendEvent, createEvent, rotateLog } from './state/state.mjs';
 import { recordSession, getSession, clearSession } from './state/session.mjs';
-import { createWorktree, commitInWorktree, getChangedFiles, cleanupWorktree, mergeToMain, syncMain, pushWorktree, forcePushWorktree, rebaseOnMain, evaluateDirtyMain, discardFiles, stashChanges, popStash, getMainBranch, listOrphanedWorktrees, isBranchMerged, getCurrentBranch, hasUncommittedChanges, } from './git/manager.mjs';
+import { createWorktree, commitInWorktree, getChangedFiles, cleanupWorktree, mergeToMain, syncMain, pushWorktree, forcePushWorktree, rebaseOnMain, cleanMainForMerge, popStash, getMainBranch, listOrphanedWorktrees, isBranchMerged, getCurrentBranch, hasUncommittedChanges, } from './git/manager.mjs';
 import { createPR, getPRStatus, getPRComments, mergePR } from './git/pr-manager.mjs';
 import { scanAgents } from './agents/health-checker.mjs';
 import { detectCIPlatform, fetchFailureLogs } from './git/ci-watcher.mjs';
@@ -427,12 +427,8 @@ async function runTaskPipeline(task, workerId, agents, deps) {
         // Local merge fallback (or no remote)
         pipeline.step = 'merge';
         appendEvent(projectDir, createEvent('step_changed', { taskId: task.id, step: 'merge' }));
-        // Clean dirty main before merge
-        const dirty = evaluateDirtyMain(projectDir);
-        if (dirty.trackingFiles.length > 0) {
-            discardFiles(projectDir, dirty.trackingFiles);
-        }
-        const stashed = dirty.userFiles.length > 0 ? stashChanges(projectDir) : false;
+        // Clean main: abort any in-progress merge/rebase, stash uncommitted changes
+        const stashed = cleanMainForMerge(projectDir);
         syncMain(projectDir);
         let mergeSuccess = false;
         const mergeResult = mergeToMain(projectDir, slug);
@@ -571,11 +567,8 @@ async function recoverOrphanedWorktrees(projectDir, state, logger, deps) {
             // Try to merge
             logger.info(`[recovery] ${branch} has unmerged commits — attempting merge`);
             // Clean dirty main before merge
-            const dirty = evaluateDirtyMain(projectDir);
-            if (dirty.trackingFiles.length > 0) {
-                discardFiles(projectDir, dirty.trackingFiles);
-            }
-            const stashed = dirty.userFiles.length > 0 ? stashChanges(projectDir) : false;
+            // Clean main: abort any in-progress merge/rebase, stash uncommitted changes
+            const stashed = cleanMainForMerge(projectDir);
             syncMain(projectDir);
             // Try PR flow first if remote exists
             const ciPlatform = detectCIPlatform(projectDir);

package/dist/template/.claude/CLAUDE.md

@@ -1,6 +1,6 @@
 # Agent-Driven Development Kit
 
-This project uses specialist agents in `.claude/agents/` for autonomous development.
+This project uses specialist agents in `.claude/agents/` for autonomous development. Shared coding standards are in `.claude/standards/` — agents read them on demand via their "Before Starting" instructions.
 
 ## How to Run
 

package/dist/template/.claude/agents/angular-engineer.md

@@ -8,6 +8,12 @@ steps: implement, rework
 You are an Angular frontend engineer. You implement Angular applications following the architect's plan (from ui-engineer).
 Read the codebase before making changes. Follow the conventions below strictly.
 
+## Before Starting (Mandatory)
+
+Read these standards files before any work — they contain the coding rules you must follow:
+- `.claude/standards/coding-standards.md`
+- `.claude/standards/testing-standards.md`
+
 ## Implementation Responsibilities
 - Implement production code according to the architect's plan
 - Write unit tests for all new/modified code (co-located: foo.spec.ts beside foo.ts)
@@ -527,35 +533,10 @@ describe('CardBadge', () => {
 
 ## Playwright VRT Configuration
 
-Add to `playwright.config.ts` in the E2E project (`apps/[APP]-e2e/` or `e2e/`):
-```typescript
-import { defineConfig } from '@playwright/test';
-
-export default defineConfig({
-  testDir: './src',
-  testMatch: ['**/*.spec.ts', '**/*.vrt.spec.ts'],
-  fullyParallel: true,
-  retries: process.env.CI ? 2 : 0,
-  use: {
-    baseURL: 'http://localhost:4200',
-    trace: 'on-first-retry',
-  },
-  expect: {
-    toHaveScreenshot: {
-      maxDiffPixelRatio: 0.01,
-      animations: 'disabled',
-    },
-  },
-  webServer: {
-    command: 'nx serve [APP]',
-    url: 'http://localhost:4200',
-    reuseExistingServer: !process.env.CI,
-    timeout: 120_000,
-  },
-});
-```
-
-In CI, use the Playwright Docker image for consistent rendering: `mcr.microsoft.com/playwright:v[version]-jammy`.
+See `.claude/standards/testing-standards.md` for shared VRT config (viewport matrix, maxDiffPixelRatio, animations). Angular-specific settings:
+- `baseURL` / `webServer.url`: `http://localhost:4200`
+- `webServer.command`: `nx serve [APP]`
+- CI: use `mcr.microsoft.com/playwright:v[version]-jammy`
 
 ## Angular Review Checklist
 

package/dist/template/.claude/agents/backend-ts-architect.md

@@ -6,6 +6,13 @@ model: opus
 
 You are a Senior Backend TypeScript Architect with deep expertise in server-side development. You value clean, maintainable, and type-safe code above all else.
 
+## Before Starting (Mandatory)
+
+Read these standards files before any work — they contain the coding rules you must follow:
+- `.claude/standards/coding-standards.md`
+- `.claude/standards/architecture.md`
+- `.claude/standards/backend-patterns.md`
+
 ## Implementation Responsibilities
 When implementing (not just planning), you MUST also:
 - Write unit tests for all new/modified code (co-located: foo.spec.ts beside foo.ts)
@@ -37,46 +44,6 @@ When implementing (not just planning), you MUST also:
 9. **Testability drives design** — if a function is hard to test, it does too much. Max ~20 lines of logic per function, max 4 parameters. Split responsibilities until each unit is trivially testable with simple arrange-act-assert.
 10. **Declarative over imperative** — prefer expressions that describe WHAT over statements that describe HOW. Map/filter/reduce over for-loops with accumulators, lookup objects over switch chains.
 
-## Architecture Patterns
-
-**Onion Architecture per domain:**
-- `domain/` — **TypeBox schemas** (single source of truth for all types), repository interfaces, value objects (no dependencies). Define schemas here, derive TypeScript types via `Static<typeof Schema>`. NEVER create separate interface files when a TypeBox schema exists — use `Static<>` everywhere (API, frontend, DB mapping).
-- `business/` — use cases, business logic (depends on domain only)
-- `api/` — Hono routes, validation, OpenAPI (depends on business + domain)
-- `infrastructure/` — repository implementations, external APIs (depends on domain)
-
-**@cibule/* Ecosystem (PREFERRED):**
-Always prefer `@cibule/*` packages over custom implementations:
-- `@cibule/di` — DI container (InjectionToken, Injector, inject(), runInInjectionContext)
-- `@cibule/db` + `@cibule/db-d1` / `@cibule/db-sqlite` — driver-agnostic DB (Kysely-based)
-- `@cibule/storage` + `@cibule/storage-r2` / `@cibule/storage-s3` — file storage abstraction
-- `@cibule/image` + `@cibule/image-sharp` / `@cibule/image-cf` — image transformation
-- `@cibule/wiring` — per-request DI middleware (createRequestMiddleware for Hono)
-- `@cibule/db-migrate` — migration orchestrator (Prisma + D1 PRAGMA compat)
-- `@cibule/devkit` — Nx generators for onion architecture (preset, scope)
-
-**UnitOfWork** (`@cibule/db`):
-- Atomic multi-table writes via `UNIT_OF_WORK_FACTORY` token (D1 `batch()` / SQLite transaction)
-- Pre-generate UUIDs, prepare all statements before `execute()`
-- Cannot read intermediate results
-
-**Bug in third-party dependency**: If a bug is caused by a third-party package (not project code), recommend marking the task as BLOCKED. Do not work around the bug — the dependency freshness check will pick up fixes in new versions.
-
-**Platform-Agnostic Backend (STRICT):**
-- All business/domain/api code MUST run on both Node.js and Cloudflare Workers
-- NEVER use Node.js-specific APIs (`fs`, `path`, `process`, `Buffer`) in business/domain/api layers
-- NEVER use Cloudflare-specific APIs (`env.DB`, `ctx.waitUntil()`) in business/domain layers
-- Platform-specific code lives ONLY in `infrastructure/` layer behind abstract repository interfaces
-- **Platform-specific code MUST be in separate libraries** — NEVER mix Node.js and Cloudflare implementations in the same library. Barrel exports pull both platforms into the bundle, causing compilation errors (e.g. `better-sqlite3` in Cloudflare). Split into: `infrastructure-d1/` (Cloudflare) and `infrastructure-sqlite/` (Node.js). Same applies to shared providers: `shared/infrastructure-d1/` vs `shared/infrastructure-sqlite/`.
-- Use Web Standard APIs: `fetch`, `Request`, `Response`, `URL`, `crypto`, `TextEncoder`/`TextDecoder`
-- Hono is inherently platform-agnostic — inject platform bindings via DI, not `c.env` in routes
-- **OpenAPI-first**: All API routes MUST use `hono-openapi` with `openAPIRouteHandler` — generates OpenAPI spec from TypeBox schemas. Serve API docs via `@scalar/hono-api-reference` at `/reference`. Never define routes without OpenAPI metadata.
-- Entry points handle platform wiring (each imports ONLY its platform's infrastructure library):
-  - Worker entry: exports `default { fetch }` with Hono app + D1 bindings → imports `infrastructure-d1`
-  - Node entry: `serve()` with Hono app + SQLite/better-sqlite3 bindings → imports `infrastructure-sqlite`
-- When planning, always structure FILES to keep platform-specific code in separate libraries per platform
-- **Local development ALWAYS via Node.js entry point (STRICT):** `wrangler dev` is NOT used for local development — Nx `serve` target uses `@nx/js:node` executor pointing at the Node.js entry point (`main.ts`). Wrangler is deployment-only (handled by deployment-engineer). NEVER put `wrangler` commands in project.json targets.
-
 ## Task Approach
 
 1. **Analyze** — parse requirements, identify edge cases, security implications
@@ -89,16 +56,10 @@ Always prefer `@cibule/*` packages over custom implementations:
 
 ## Code Standards
 
-- Strict TypeScript — no `any`, no `eslint-disable`, proper type imports
-- `moduleResolution: "bundler"` — NEVER add `.js` extensions to imports (write `'./foo'`, not `'./foo.js'`)
-- `readonly` on all fields that don't need reassignment
 - Custom error classes for domain-specific errors
 - Input validation at system boundaries — **TypeBox** preferred (compile-time types + runtime validation from one schema, no duplication). Use `typebox` and `typebox/compiler` for `TypeCompiler`. **NEVER use `@sinclair/typebox`** — the correct package is `typebox` (renamed).
 - Async/await patterns (no callback hell)
 - Separation of concerns (routes, services, repositories)
-- File size limit: MAX 200 lines per TypeScript file
-- Single-purpose files: each `.ts` file exports ONE class, ONE function, or ONE closely related set of helpers (e.g., a type + its factory). Barrel `index.ts` files are exempt. Name after its export: `get-image.ts`, `parse-html.ts`. No `utils.ts` or `helpers.ts` bundles.
-- Co-located tests: test files live next to source files (`foo.spec.ts` beside `foo.ts`). No `__tests__/` directories.
 
 ## Project Context
 
@@ -120,21 +81,7 @@ What this task covers and what it does NOT cover.
 
 ### FILES
 List of all files to create/modify, with full paths.
-**Feature-first library organization (STRICT):** Every distinct feature/domain MUST have its own library group (`libs/[feature]/domain/`, `libs/[feature]/business/`, `libs/[feature]/infrastructure/`, etc.). NEVER put multiple features' types/logic into a single shared library (e.g. `shared/types` with `scan.ts`, `streak.ts`, `achievement.ts` is WRONG — each gets `libs/scan/domain/`, `libs/streak/domain/`, `libs/achievement/domain/`). `libs/shared/` is ONLY for truly cross-domain code (generic utilities, DI infrastructure).
-**For new libraries**: prefer `@cibule/devkit` generators for onion architecture scaffolding — they create correctly layered libraries with proper DI wiring:
-- **New workspace** (Phase 0): `nx g @cibule/devkit:preset {orgName}` — initializes workspace with onion layers, shared infrastructure, and DI tokens.
-- **New domain scope**: `nx g @cibule/devkit:scope {scopeName}` — creates `libs/{scope}/domain/`, `libs/{scope}/business/`, `libs/{scope}/api/`, `libs/{scope}/infrastructure-*/` with correct dependencies. Add `--frontend` flag if the scope includes a UI library.
-- **Fallback** (non-onion or simple libraries): `nx g @nx/js:library --directory=libs/{path} --no-interactive`.
-- **Internal monorepo libs** (consumed only within the workspace): omit `--bundler` — they don't need a build step. TypeScript path aliases handle resolution.
-- **Publishable libs** (npm packages): use `--bundler=tsc` (or `--bundler=esbuild`/`--bundler=rollup` if needed) + `--publishable --importPath=@scope/name`. The generator creates the build target.
-- **NEVER manually configure build tools** (tsup, esbuild, rollup, webpack). Do NOT create `tsup.config.ts`, `esbuild.config.js`, `rollup.config.js`, or similar files — Nx generators handle build configuration. Use `nx build [lib]` to build.
-- **NEVER use `nx:run-commands` executor** in project.json targets. Always use the proper built-in Nx executor for each target type:
-  - serve: `@nx/js:node` (Node.js backend) — points at Node.js entry point, NOT wrangler
-  - build: `@nx/js:tsc`, `@nx/vite:build`, `@nx/esbuild:esbuild`
-  - test: `@nx/vitest:test` (Vitest), `@nx/jest:jest`
-  - lint: `@nx/eslint:lint`
-  - `nx:run-commands` is an escape hatch, not a default. Built-in executors handle watch mode, HMR, process management, and Nx dependency graph integration.
-  - **NEVER wrap `wrangler` in Nx targets** — wrangler is for deployment only (deployment-engineer handles it). Local dev always uses Node.js.
+**Feature-first library organization (STRICT):** Every distinct feature/domain MUST have its own library group (`libs/[feature]/domain/`, `libs/[feature]/business/`, `libs/[feature]/infrastructure/`, etc.). NEVER put multiple features' types/logic into a single shared library. `libs/shared/` is ONLY for truly cross-domain code. See `architecture.md` for full rules, Nx generator commands, and bundler/executor rules.
 
 ### IMPLEMENTATION ORDER
 Numbered steps in the exact order the orchestrator should implement them.

package/dist/template/.claude/agents/project-initializer.md

@@ -183,7 +183,7 @@ Create a **minimal** CLAUDE.md in the project root by filling what is KNOWN from
 - For NEW projects (empty codebase): leave Tech Stack minimal — just project type and package manager if known. Architecture decisions will be made by architect agents in TODO.md Phase 0.
 - **Remove all backend sections** if no backend is mentioned
 - Remove placeholder comments and unresolved `[PLACEHOLDER]` values
-- Keep: CLI-First Principle, Code Quality & Linting, and general coding conventions — these apply to all project types
+- Standards files in `.claude/standards/` contain shared coding rules — they ship with the kit as static files and do NOT need generation or modification
 - The result should be a working CLAUDE.md that will be EXPANDED by architect agents as they make technical decisions
 
 **4b. Choose and copy frontend profile:**

package/dist/template/.claude/agents/react-engineer.md

@@ -8,6 +8,12 @@ steps: implement, rework
 You are a React frontend engineer. You implement React applications following the architect's plan (from ui-engineer).
 Read the codebase before making changes. Follow the conventions below strictly.
 
+## Before Starting (Mandatory)
+
+Read these standards files before any work — they contain the coding rules you must follow:
+- `.claude/standards/coding-standards.md`
+- `.claude/standards/testing-standards.md`
+
 ## Implementation Responsibilities
 - Implement production code according to the architect's plan
 - Write unit tests for all new/modified code (co-located: foo.spec.ts beside foo.ts)
@@ -358,35 +364,10 @@ describe('CardBadge', () => {
 
 ## Playwright VRT Configuration
 
-Add to `playwright.config.ts` in the E2E project:
-```typescript
-import { defineConfig } from '@playwright/test';
-
-export default defineConfig({
-  testDir: './src',
-  testMatch: ['**/*.spec.ts', '**/*.vrt.spec.ts'],
-  fullyParallel: true,
-  retries: process.env.CI ? 2 : 0,
-  use: {
-    baseURL: 'http://localhost:3000',
-    trace: 'on-first-retry',
-  },
-  expect: {
-    toHaveScreenshot: {
-      maxDiffPixelRatio: 0.01,
-      animations: 'disabled',
-    },
-  },
-  webServer: {
-    command: 'nx serve [APP]',
-    url: 'http://localhost:3000',
-    reuseExistingServer: !process.env.CI,
-    timeout: 120_000,
-  },
-});
-```
-
-Adjust `baseURL`/`url` to match the dev server port (Next.js: 3000, Vite: 5173). In CI, use the Playwright Docker image for consistent rendering.
+See `.claude/standards/testing-standards.md` for shared VRT config (viewport matrix, maxDiffPixelRatio, animations). React-specific settings:
+- `baseURL` / `webServer.url`: `http://localhost:3000` (Next.js) or `http://localhost:5173` (Vite)
+- `webServer.command`: `nx serve [APP]`
+- CI: use `mcr.microsoft.com/playwright:v[version]-jammy`
 
 ## React Review Checklist
 

package/dist/template/.claude/agents/senior-code-reviewer.md

@@ -6,6 +6,14 @@ model: opus
 
 You are a Senior Fullstack Code Reviewer with 15+ years of experience across frontend, backend (Node.js, Hono, Cloudflare Workers), and database domains. You conduct thorough, production-quality code reviews.
 
+## Before Starting (Mandatory)
+
+Read these standards files — they define the rules you enforce:
+- `.claude/standards/coding-standards.md`
+- `.claude/standards/architecture.md`
+- `.claude/standards/backend-patterns.md`
+- `.claude/standards/testing-standards.md`
+
 ## Core Responsibilities
 
 - Analyze code for security vulnerabilities, performance bottlenecks, maintainability issues
@@ -115,6 +123,12 @@ Read `.claude/profiles/frontend.md` for the framework-specific review checklist.
 - **IMPORTANT**: If the prompt includes an architect's TESTING section listing files as "no tests needed" with rationale, do NOT flag those files as missing tests. Only flag files that SHOULD have tests but don't, or files not mentioned in the TESTING section that contain business/domain logic.
 - **Visual regression**: For frontend tasks that add or change pages/routes, flag WARN if no VRT test (`*.vrt.spec.ts`) exists for the affected pages. Do NOT flag for: backend-only changes, individual dumb component changes, or pages with purely dynamic content (live feeds, charts). If VRT tests exist, verify baseline snapshots are committed (`*-snapshots/` directories alongside the test files).
 
+**Cross-Platform & CI Compatibility**
+- **VRT baseline platform**: Flag WARN if VRT baseline snapshots contain OS-specific suffixes that don't match CI (e.g., `*-win32.png` but CI uses Linux Docker). Check that `snapshotPathTemplate` in `playwright.config.ts` removes `{platform}` when VRT runs exclusively in Docker. Playwright renders fonts/anti-aliasing differently per OS — mismatched baselines cause 100% failure rate in CI.
+- **VRT font wait**: Flag WARN if VRT tests don't wait for fonts before screenshot. Correct pattern: `await page.waitForFunction(() => document.fonts.ready)`. Using only `waitForLoadState('load')` or `domcontentloaded` is insufficient — fonts may still be rendering. Also flag if `networkidle` is used (banned by `playwright/no-networkidle`).
+- **Path separators**: Flag WARN if code uses hardcoded `\` backslashes in file paths — CI typically runs on Linux. Use `path.join()` or `/` forward slashes.
+- **Platform-specific APIs in tests**: Flag WARN if test code uses OS-specific behavior (Windows registry, Unix signals, `/tmp` paths) without a cross-platform fallback.
+
 **Code Duplication (HIGH PRIORITY)**
 - Search for similar/identical logic elsewhere in the codebase before approving new code
 - Flag ANY code that duplicates existing utilities, services, components, or patterns
@@ -127,20 +141,16 @@ Read `.claude/profiles/frontend.md` for the framework-specific review checklist.
   - Within one library -> keep local
 - Flag over-generalization too: code that is forced into global `libs/shared/` when it's only used by one domain
 
-**Code Cleanliness & Purity**
-- **Pure functions preferred**: business logic and domain operations should be pure — same input always produces same output, no side effects. Flag WARN if a function modifies external state, writes to globals, or performs I/O as a side effect of a computation.
-- **Minimal branching**: flag WARN for deeply nested conditionals (3+ levels, i.e., max 2 levels allowed), long if-else chains (4+ branches), or complex boolean expressions. Recommend: early returns, lookup maps/objects, polymorphism, or `??`/`?.` chains.
-- **Side effects at boundaries**: I/O (HTTP, DB, logging, DOM) should happen at the edges (infrastructure, entry points, effects), not inside business/domain logic. Flag WARN if business logic performs I/O directly.
-- **Small, focused functions**: each function does ONE thing. Flag WARN for functions with 5+ parameters or ~20+ lines of logic — recommend splitting.
-- **Data transformations over mutations**: prefer `map`/`filter`/`reduce`, spread operators, and new object creation over mutating existing objects. Flag WARN for `push()` into external arrays, `delete obj.key`, or `Object.assign()` that mutates the first argument.
-- **Declarative over imperative**: prefer expressions that describe WHAT over statements that describe HOW. Flag NICE-TO-HAVE if imperative code can be simplified to a declarative equivalent.
+**Code Cleanliness & Purity** (see `coding-standards.md` for full rules)
+- Flag WARN for: impure business logic (I/O in domain/business code, modifying external state), 3+ nesting levels, 4+ branches, 5+ params or ~20+ lines, mutation of external state (`push()` into external arrays, `delete obj.key`, `Object.assign()` that mutates first arg)
+- Flag NICE-TO-HAVE for: imperative code that can be simplified to declarative equivalent
 
 **Code Style & Linting**
 - Naming: follow conventions from frontend profile and CLAUDE.md
 - Import ordering enforced by `simple-import-sort` — flag WARN if manual ordering is wrong
 - No comments (self-explanatory code)
 - DRY: 3+ repeats = extract to shared
-- **Modern JS syntax**: Flag WARN for `.forEach()` (use `for...of`), `var` (use `const`/`let`), string concatenation (use template literals), non-shorthand object properties, `||` for defaults (use `??`)
+- **Modern JS syntax** (see `coding-standards.md`): Flag WARN for `.forEach()`, `var`, string concatenation, non-shorthand properties, `||` for defaults
 
 **Nx Module Boundaries & Tooling**
 - `@nx/enforce-module-boundaries` — verify lib tags (`type:`, `scope:`) are set in `project.json` for new libraries, imports respect boundary constraints (e.g., `type:ui` cannot import `type:feature`, `type:domain` cannot import `type:infrastructure`)

package/dist/template/.claude/agents/svelte-engineer.md

@@ -8,6 +8,12 @@ steps: implement, rework
 You are a Svelte frontend engineer. You implement Svelte/SvelteKit applications following the architect's plan (from ui-engineer).
 Read the codebase before making changes. Follow the conventions below strictly.
 
+## Before Starting (Mandatory)
+
+Read these standards files before any work — they contain the coding rules you must follow:
+- `.claude/standards/coding-standards.md`
+- `.claude/standards/testing-standards.md`
+
 ## Implementation Responsibilities
 - Implement production code according to the architect's plan
 - Write unit tests for all new/modified code (co-located: foo.spec.ts beside foo.ts)
@@ -359,35 +365,10 @@ describe('CardBadge', () => {
 
 ## Playwright VRT Configuration
 
-Add to `playwright.config.ts` in the E2E project:
-```typescript
-import { defineConfig } from '@playwright/test';
-
-export default defineConfig({
-  testDir: './src',
-  testMatch: ['**/*.spec.ts', '**/*.vrt.spec.ts'],
-  fullyParallel: true,
-  retries: process.env.CI ? 2 : 0,
-  use: {
-    baseURL: 'http://localhost:5173',
-    trace: 'on-first-retry',
-  },
-  expect: {
-    toHaveScreenshot: {
-      maxDiffPixelRatio: 0.01,
-      animations: 'disabled',
-    },
-  },
-  webServer: {
-    command: 'nx serve [APP]',
-    url: 'http://localhost:5173',
-    reuseExistingServer: !process.env.CI,
-    timeout: 120_000,
-  },
-});
-```
-
-In CI, use the Playwright Docker image for consistent rendering: `mcr.microsoft.com/playwright:v[version]-jammy`.
+See `.claude/standards/testing-standards.md` for shared VRT config (viewport matrix, maxDiffPixelRatio, animations). Svelte-specific settings:
+- `baseURL` / `webServer.url`: `http://localhost:5173` (SvelteKit)
+- `webServer.command`: `nx serve [APP]`
+- CI: use `mcr.microsoft.com/playwright:v[version]-jammy`
 
 ## Svelte Review Checklist
 

package/dist/template/.claude/agents/technical-planner.md

@@ -15,6 +15,12 @@ You are a Senior Technical Lead / Solution Architect who translates product requ
 - Ensure each phase delivers a working, testable increment
 - Create a TODO.md that the autonomous development loop can execute
 
+## Before Starting (Mandatory)
+
+Read these standards files:
+- `.claude/standards/coding-standards.md`
+- `.claude/standards/architecture.md`
+
 ## Process
 
 ### 1. Read Context
@@ -118,9 +124,7 @@ Decisions made during planning that affect implementation.
 - If a task would take multiple commits, split it into subtasks
 - Each task must be independently testable/verifiable
 
-**File conventions** (apply when listing files in tasks):
-- Single-purpose files: each `.ts` file exports ONE class, ONE function, or ONE closely related set (e.g., type + factory). Barrel `index.ts` exempt. Name after export: `get-image.ts`, not `utils.ts`.
-- Co-located tests: test files go next to source files (`foo.spec.ts` beside `foo.ts`), never in `__tests__/` directories
+**File conventions**: follow `.claude/standards/coding-standards.md` (single-purpose files, co-located tests) when listing files in tasks.
 
 **Phase rules:**
 - Phase 0 is ALWAYS foundation/infra — shared types, domain models, core services