create-claude-workspace 1.1.72 → 1.1.74

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

@@ -112,6 +112,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**: specify the `nx generate` command (e.g., `nx g @nx/js:library --directory=libs/auth/domain --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.

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

@@ -115,6 +115,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]/ui/`, `libs/[feature]/feature/`, `libs/[feature]/data-access/`, etc.). NEVER put multiple features' types/components into a single shared library (e.g. `shared/types` with `scan.ts`, `streak.ts` is WRONG — each gets `libs/scan/domain/`, `libs/streak/domain/`). `libs/shared/ui/` is ONLY for truly generic UI primitives (buttons, modals, layout) used across multiple features.
 **For new libraries/components**: specify the generator command from the frontend profile (e.g., `nx g @nx/angular:library ...` or `nx g @nx/react:component ...`). Test runner, linter, and style defaults are configured in `nx.json` — do not repeat them. The orchestrator will run these commands before writing code.
 **NEVER manually configure build tools** (tsup, esbuild, rollup, webpack, vite for build). Do NOT create config files for these — Nx generators handle build configuration. Internal monorepo libs don't need a build step; publishable libs get `--bundler` from the generator.
 

package/dist/template/.claude/profiles/angular.md

@@ -264,22 +264,55 @@ npx themecraft generate    # generates type-safe SCSS from tokens.json
 4. `@themecraft/core/themes` → `variables()` mixin emits CSS custom properties at `:root`
 5. `@themecraft/angular` → `provideTheme()` for runtime switching, `provideThemeServer()` for SSR (no FOUC)
 
-**Component SCSS** — import generated variables, NEVER call `color-var()`/`size-var()` directly:
+**Component SCSS** — import via package name, NEVER use relative paths, NEVER call `color-var()`/`size-var()` directly:
 ```scss
-@use 'generated/theme/colors' as colors;
-@use 'generated/theme/sizes' as sizes;
-@use 'generated/theme/typography' as typo;
-@use '@themecraft/core/theming' as theming;
+// Import via package name (configured in tsconfig/package.json paths)
+// SCSS @use automatically uses the last path segment as namespace — no `as` needed
+@use 'theme/colors';
+@use 'theme/sizes';
+@use 'theme/typography';
+@use '@themecraft/core/theming';
 
 .card {
   background: colors.$surface;
   color: colors.$on-surface;
   padding: sizes.$card-padding;
-  @include typo.body-primary();
+  @include typography.body-primary();
   @include theming.theme-transition();  // smooth theme switch
 }
 ```
 
+**SCSS import rules:**
+- ALWAYS import via package/library name (e.g. `@use 'theme/colors'`)
+- NEVER use relative paths (`../../theme/src/generated/...`) — they break on refactoring and are unreadable
+- NEVER use redundant `as` aliases that match the last path segment (`@use 'theme/colors' as colors` → just `@use 'theme/colors'`). Only use `as` when you need a different name.
+
+**Making theme resolvable by package name (priority order):**
+1. **Workspace dependency in package.json** (preferred) — add the theme library as a workspace dependency so SCSS resolves it from `node_modules`:
+   ```jsonc
+   // package.json (root or consuming app)
+   {
+     "dependencies": {
+       "@[prefix]/theme": "workspace:./libs/shared/ui/theme"  // bun/pnpm
+       // or "file:./libs/shared/ui/theme" for npm
+     }
+   }
+   ```
+   Then `<PM> install` creates the link. SCSS `@use '@[prefix]/theme/colors'` resolves automatically.
+2. **`stylePreprocessorOptions.includePaths`** (fallback) — if workspace dependency is not feasible:
+   ```jsonc
+   // project.json or angular.json
+   {
+     "build": {
+       "options": {
+         "stylePreprocessorOptions": {
+           "includePaths": ["libs/shared/ui/theme/src"]
+         }
+       }
+     }
+   }
+   ```
+
 **How it works:** `npx themecraft generate` reads `tokens.json` and produces typed SCSS files (`generated/theme/colors.scss`, `sizes.scss`, `typography.scss`) that wrap `color-var()`/`size-var()` internally. Components consume these generated variables — never the raw accessor functions.
 
 **Token source (pick one):**
@@ -410,6 +443,7 @@ When reviewing Angular code, check:
 - Resource disposal (ImageBitmap.close(), stream.stop(), BroadcastChannel.close())
 - No memory leaks in effects or event listeners
 - Theme compliance: generated @themecraft SCSS variables — no hardcoded colors/sizes, no direct `color-var()`/`size-var()` calls
+- SCSS imports: via package name (no relative paths), no redundant `as` aliases
 - Lazy loading via loadComponent/loadChildren, no eager page imports
 - @defer for heavy below-fold components
 - Naming: PascalCase components, lib- selectors, kebab-case files

package/dist/template/.claude/profiles/react.md

@@ -167,22 +167,42 @@ npx themecraft generate    # generates type-safe SCSS from tokens.json
 4. `@themecraft/core/themes` → `variables()` mixin emits CSS custom properties at `:root`
 5. `ThemeManager` (from `@themecraft/core/runtime`) — runtime theme switching, storage persistence, FOUC prevention
 
-**Component SCSS** (`.module.scss`) — import generated variables, NEVER call `color-var()`/`size-var()` directly:
+**Component SCSS** (`.module.scss`) — import via package name, NEVER use relative paths, NEVER call `color-var()`/`size-var()` directly:
 ```scss
-@use 'generated/theme/colors' as colors;
-@use 'generated/theme/sizes' as sizes;
-@use 'generated/theme/typography' as typo;
-@use '@themecraft/core/theming' as theming;
+// Import via package name — SCSS @use uses last path segment as namespace automatically
+@use 'theme/colors';
+@use 'theme/sizes';
+@use 'theme/typography';
+@use '@themecraft/core/theming';
 
 .card {
   background: colors.$surface;
   color: colors.$on-surface;
   padding: sizes.$card-padding;
-  @include typo.body-primary();
+  @include typography.body-primary();
   @include theming.theme-transition();
 }
 ```
 
+**SCSS import rules:**
+- ALWAYS import via package/library name (e.g. `@use 'theme/colors'`)
+- NEVER use relative paths (`../../theme/src/generated/...`) — they break on refactoring and are unreadable
+- NEVER use redundant `as` aliases that match the last path segment (`@use 'theme/colors' as colors` → just `@use 'theme/colors'`). Only use `as` when you need a different name.
+
+**Making theme resolvable by package name (priority order):**
+1. **Workspace dependency in package.json** (preferred) — add the theme library as a workspace dependency so SCSS resolves it from `node_modules`:
+   ```jsonc
+   // package.json (root or consuming app)
+   {
+     "dependencies": {
+       "@[prefix]/theme": "workspace:./libs/shared/ui/theme"  // bun/pnpm
+       // or "file:./libs/shared/ui/theme" for npm
+     }
+   }
+   ```
+   Then `<PM> install` creates the link. SCSS `@use '@[prefix]/theme/colors'` resolves automatically.
+2. **Bundler/framework SCSS config** (fallback) — e.g. `sassOptions.includeDirs` in `next.config.js`, or Vite `css.preprocessorOptions.scss.includePaths`.
+
 **How it works:** `npx themecraft generate` reads `tokens.json` and produces typed SCSS files (`generated/theme/colors.scss`, `sizes.scss`, `typography.scss`) that wrap `color-var()`/`size-var()` internally. Components consume these generated variables — never the raw accessor functions.
 
 **Token source (pick one):**
@@ -294,6 +314,7 @@ When reviewing React code, check:
 - Server/client separation: Flag WARN if a module mixes server and browser logic without clear boundaries
 - No memory leaks in effects, event listeners, or subscriptions
 - Theme compliance: generated @themecraft SCSS variables — no hardcoded colors/sizes, no direct `color-var()`/`size-var()` calls
+- SCSS imports: via package name (no relative paths), no redundant `as` aliases
 - Code splitting: `React.lazy` + `Suspense` for heavy routes/components, no eager imports of page-level components
 - Dynamic imports for heavy third-party libraries
 - Naming: PascalCase components, camelCase hooks, kebab-case files

package/dist/template/.claude/profiles/svelte.md

@@ -168,24 +168,44 @@ npx themecraft generate    # generates type-safe SCSS from tokens.json
 4. `@themecraft/core/themes` → `variables()` mixin emits CSS custom properties at `:root`
 5. `ThemeManager` (from `@themecraft/core/runtime`) — runtime switching, storage, FOUC prevention
 
-**Component SCSS** — import generated variables, NEVER call `color-var()`/`size-var()` directly:
+**Component SCSS** — import via package name, NEVER use relative paths, NEVER call `color-var()`/`size-var()` directly:
 ```svelte
 <style lang="scss">
-  @use 'generated/theme/colors' as colors;
-  @use 'generated/theme/sizes' as sizes;
-  @use 'generated/theme/typography' as typo;
-  @use '@themecraft/core/theming' as theming;
+  // Import via package name — SCSS @use uses last path segment as namespace automatically
+  @use 'theme/colors';
+  @use 'theme/sizes';
+  @use 'theme/typography';
+  @use '@themecraft/core/theming';
 
   .card {
     background: colors.$surface;
     color: colors.$on-surface;
     padding: sizes.$card-padding;
-    @include typo.body-primary();
+    @include typography.body-primary();
     @include theming.theme-transition();
   }
 </style>
 ```
 
+**SCSS import rules:**
+- ALWAYS import via package/library name (e.g. `@use 'theme/colors'`)
+- NEVER use relative paths (`../../theme/src/generated/...`) — they break on refactoring and are unreadable
+- NEVER use redundant `as` aliases that match the last path segment (`@use 'theme/colors' as colors` → just `@use 'theme/colors'`). Only use `as` when you need a different name.
+
+**Making theme resolvable by package name (priority order):**
+1. **Workspace dependency in package.json** (preferred) — add the theme library as a workspace dependency so SCSS resolves it from `node_modules`:
+   ```jsonc
+   // package.json (root or consuming app)
+   {
+     "dependencies": {
+       "@[prefix]/theme": "workspace:./libs/shared/ui/theme"  // bun/pnpm
+       // or "file:./libs/shared/ui/theme" for npm
+     }
+   }
+   ```
+   Then `<PM> install` creates the link. SCSS `@use '@[prefix]/theme/colors'` resolves automatically.
+2. **SvelteKit SCSS config** (fallback) — `css.preprocessorOptions.scss.includePaths` in `vite.config.ts`.
+
 **How it works:** `npx themecraft generate` reads `tokens.json` and produces typed SCSS files (`generated/theme/colors.scss`, `sizes.scss`, `typography.scss`) that wrap `color-var()`/`size-var()` internally. Components consume these generated variables — never the raw accessor functions.
 
 **Token source (pick one):**
@@ -298,6 +318,7 @@ When reviewing Svelte code, check:
 - `$lib/` imports — no deep relative paths (`../../../`)
 - `$lib/server/` for server-only modules — enforced by SvelteKit
 - Theme compliance: generated @themecraft SCSS variables — no hardcoded colors/sizes, no direct `color-var()`/`size-var()` calls
+- SCSS imports: via package name (no relative paths), no redundant `as` aliases
 - Lazy loading: routes auto-split, dynamic `import()` for heavy non-route components
 - Accessibility: all Svelte compiler a11y warnings resolved (not suppressed)
 - No `{@html}` without sanitization

package/dist/template/.claude/profiles/vue.md

@@ -193,24 +193,44 @@ npx themecraft generate    # generates type-safe SCSS from tokens.json
 4. `@themecraft/core/themes` → `variables()` mixin emits CSS custom properties at `:root`
 5. `ThemeManager` (from `@themecraft/core/runtime`) — runtime switching, storage, FOUC prevention
 
-**Component SCSS** — import generated variables, NEVER call `color-var()`/`size-var()` directly:
+**Component SCSS** — import via package name, NEVER use relative paths, NEVER call `color-var()`/`size-var()` directly:
 ```vue
 <style scoped lang="scss">
-@use 'generated/theme/colors' as colors;
-@use 'generated/theme/sizes' as sizes;
-@use 'generated/theme/typography' as typo;
-@use '@themecraft/core/theming' as theming;
+// Import via package name — SCSS @use uses last path segment as namespace automatically
+@use 'theme/colors';
+@use 'theme/sizes';
+@use 'theme/typography';
+@use '@themecraft/core/theming';
 
 .card {
   background: colors.$surface;
   color: colors.$on-surface;
   padding: sizes.$card-padding;
-  @include typo.body-primary();
+  @include typography.body-primary();
   @include theming.theme-transition();
 }
 </style>
 ```
 
+**SCSS import rules:**
+- ALWAYS import via package/library name (e.g. `@use 'theme/colors'`)
+- NEVER use relative paths (`../../theme/src/generated/...`) — they break on refactoring and are unreadable
+- NEVER use redundant `as` aliases that match the last path segment (`@use 'theme/colors' as colors` → just `@use 'theme/colors'`). Only use `as` when you need a different name.
+
+**Making theme resolvable by package name (priority order):**
+1. **Workspace dependency in package.json** (preferred) — add the theme library as a workspace dependency so SCSS resolves it from `node_modules`:
+   ```jsonc
+   // package.json (root or consuming app)
+   {
+     "dependencies": {
+       "@[prefix]/theme": "workspace:./libs/shared/ui/theme"  // bun/pnpm
+       // or "file:./libs/shared/ui/theme" for npm
+     }
+   }
+   ```
+   Then `<PM> install` creates the link. SCSS `@use '@[prefix]/theme/colors'` resolves automatically.
+2. **Vite SCSS config** (fallback) — `css.preprocessorOptions.scss.includePaths` in `vite.config.ts`.
+
 **How it works:** `npx themecraft generate` reads `tokens.json` and produces typed SCSS files (`generated/theme/colors.scss`, `sizes.scss`, `typography.scss`) that wrap `color-var()`/`size-var()` internally. Components consume these generated variables — never the raw accessor functions.
 
 **Token source (pick one):**
@@ -324,6 +344,7 @@ When reviewing Vue code, check:
 - SSR/Client separation: Flag WARN if a composable mixes server and browser logic
 - `<style scoped>` on all components — no unscoped styles leaking globally
 - Theme compliance: generated @themecraft SCSS variables — no hardcoded colors/sizes, no direct `color-var()`/`size-var()` calls
+- SCSS imports: via package name (no relative paths), no redundant `as` aliases
 - Lazy loading: `defineAsyncComponent` for heavy components, dynamic imports for routes
 - No `v-html` without sanitization (XSS risk)
 - Props defined with TypeScript types via `defineProps<{ ... }>()` — not runtime-only validation

package/dist/template/.claude/templates/claude-md.md

@@ -56,7 +56,28 @@ When running in autonomous/unattended mode (via `autonomous.mjs` or non-interact
 ### App Separation Principle
 
 - **`apps/` are thin shells** — each app is just configuration + routing + bootstrap. Minimal code.
-- **`libs/` contain all logic** — each domain has an **entry point library** that composes and re-exports functionality from its sub-libraries. Apps import only from these entry points.
+- **`libs/` contain all logic** — each domain/feature has its **own library group** with sub-libraries per layer. Apps import only from entry points.
+- **Feature-first library organization (STRICT)** — every distinct feature/domain gets its own group of libraries:
+  ```
+  libs/
+    scan/           # feature: scan
+      domain/       # scan types, schemas, interfaces
+      ui/           # scan UI components
+      feature/      # scan smart components
+      data-access/  # scan HTTP/DB services
+    streak/         # feature: streak
+      domain/
+      ui/
+      feature/
+    achievement/    # feature: achievement
+      domain/
+      feature/
+    shared/         # ONLY truly cross-domain code
+      ui/           # generic UI primitives (buttons, modals)
+      domain/       # cross-domain types (if any)
+      infrastructure/
+  ```
+  **NEVER dump multiple features into a single library** (e.g. `shared/types` with `scan.ts`, `streak.ts`, `achievement.ts`). Each feature owns its types in its own `domain/` library.
 - **Frontend and backend are separate apps** with separate build configurations per environment:
   - `apps/[APP_NAME]/` — Frontend application
   - `apps/api/` — Backend API (if applicable)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-claude-workspace",
-  "version": "1.1.72",
+  "version": "1.1.74",
   "description": "Scaffold a project with Claude Code agents for autonomous AI-driven development",
   "type": "module",
   "bin": {