@withmata/blueprints 0.3.5 → 0.5.0

package/.claude/skills/new-project/SKILL.md

@@ -12,19 +12,14 @@ Take a product from idea to running code. This command walks through the full li
 Load all available blueprints so you understand what's possible:
 
 ```
-~/.withmata/blueprints/blueprints/discovery/product-discovery/BLUEPRINT.md
+~/.withmata/blueprints/blueprints/discovery/*/BLUEPRINT.md
 ~/.withmata/blueprints/blueprints/discovery/product-discovery/templates/*
 ~/.withmata/blueprints/blueprints/foundation/monorepo-turbo/BLUEPRINT.md
 ~/.withmata/blueprints/blueprints/foundation/monorepo-turbo/files/**/*
-```
-
-Also scan for available feature blueprints:
-
-```
 ~/.withmata/blueprints/blueprints/features/*/BLUEPRINT.md
 ```
 
-Only consider a feature blueprint "available" if its BLUEPRINT.md has `Status: Complete` (not a placeholder). If not found, run `npx @withmata/blueprints` to install.
+Only consider a blueprint "available" if its BLUEPRINT.md has `Status: Complete`. If not found, run `npx @withmata/blueprints` to install.
 
 ## Step 2: Assess Current State
 
@@ -33,39 +28,107 @@ Before doing anything, understand where this project stands.
 **Check `.project-context.md`** in the target project root. This file tracks what has already been done:
 
 - **Has a `## Product Discovery` section?** Discovery is complete.
+- **Has `marketing-copywriting` under `## Installed Blueprints`?** Marketing copy exists.
+- **Has `design-system` under `## Installed Blueprints`?** Design system is defined.
 - **Has a `## Foundation` section?** Foundation is scaffolded.
-- **Has entries under `## Installed Blueprints`?** Some features are already installed.
+- **Has other entries under `## Installed Blueprints`?** Features are installed.
 
 **Explore the target directory:**
 
-- Empty directory? Fresh start — begin from Stage 1.
-- Has `docs/product/`? Discovery was done (even without a context file).
+- Empty directory? Fresh start.
+- Has `docs/product/`? Discovery was done.
+- Has `docs/pages/`? Marketing copy was written.
+- Has `docs/design/`? Design system was defined.
 - Has `package.json`, `turbo.json`, workspace dirs? Foundation was done.
-- Has auth files, DB packages, etc.? Features were installed.
+- Has auth files, DB packages, UI components, etc.? Features were installed.
+
+## Step 3: Choose a Pathway
+
+Based on what you found, present the appropriate options. Lead with the product, not the tech.
+
+---
 
-## Step 3: Determine Starting Point
+### If nothing exists (fresh start):
 
-Based on what you found, tell the user where things stand. Lead with the product, not the tech:
+"This is a fresh start. What kind of project are you kicking off?
 
-- **Nothing exists**: "This is a blank slate. Let's start by figuring out what you're building and who it's for — then we'll set up the codebase to support it."
+1. **Build a product** (recommended)
+   Define what you're building, write the marketing, design the look, then set up the codebase and wire in features. The full journey from idea to running code.
+   *Stages: Discovery → Marketing Copy → Design System → Foundation → Features*
 
-- **Discovery done, nothing else**: "You've already defined [product name] — [problem statement in one line]. We've got a clear picture of the product. Let's turn that into something you can ship."
+2. **Quick start with design**
+   Skip product discovery — jump straight to defining the visual identity and setting up the codebase. Best when you already know what you're building but want it to look unique.
+   *Stages: Design System → Foundation → Features*
 
-- **Discovery + Foundation done**: "The product is defined and the codebase is ready. Based on what [primary archetype] needs, let's wire in the right capabilities."
+3. **Quick start**
+   Skip straight to code. Set up the codebase and start adding features immediately. Best for tinkering, prototyping, or experiments.
+   *Stages: Foundation → Features*
 
-- **Everything done**: "This project looks fully set up. Want to add more capabilities, or revisit any of the product decisions?"
+You can always add product docs (`/discover`), marketing copy (`/copywrite`), or a design system (`/design-system`) later."
 
-If the user wants to start at a specific stage, let them. If they want to redo a completed stage, confirm before proceeding (it may be destructive).
+- **Build a product** → Stage 1 → 2 → 3 → 4 → 5 → 6
+- **Quick start with design** → Stage 3 → 4 → 5 → 6
+- **Quick start** → Stage 4 → 5 → 6
+
+For quick start modes, create a minimal `.project-context.md`:
+```yaml
+## Foundation
+quick_start: true
+```
 
 ---
 
-## Stage 1: Discovery
+### If discovery exists but no code:
 
-> "Before we write any code, let's get clear on what we're building and why it matters."
+"You've already defined [product name] — [problem statement]. Here's what we can do next:
+
+1. **Continue the journey** — Write marketing copy, define visual identity, then set up the codebase.
+   *Next: Marketing Copy → Design System → Foundation → Features*
+
+2. **Jump to code** — Set up the codebase now, come back to marketing and design later.
+   *Next: Foundation → Features*"
+
+If marketing copy also exists, adjust to show design system and/or foundation as next options. Always show what's already done and what's available.
+
+---
+
+### If codebase exists (foundation or single-repo detected):
+
+"This project has a codebase already. Here's what's available:
+
+**Discovery & Design** (produce docs, not code):
+- `/discover` — Product discovery [done ✓ / not started]
+- `/copywrite` — Marketing page copy [done ✓ / not started]
+- `/design-system` — Visual identity & tokens [done ✓ / not started]
+
+**Features** (wire into the codebase):
+- `/scaffold-env` — Environment variables [installed ✓ / available]
+- `/scaffold-tailwind` — Tailwind design system [installed ✓ / available]
+- `/scaffold-ui` — UI component library [installed ✓ / available]
+- `/scaffold-db` — Database [installed ✓ / available]
+- `/scaffold-auth` — Authentication [installed ✓ / available]
+
+What do you want to work on?"
+
+This is the **existing project** pathway — no forced order, just a menu of what's available with status indicators.
+
+---
+
+### If everything is done:
+
+"This project looks fully set up — [list what's installed]. Want to add more capabilities, revisit any decisions, or start building?"
+
+---
+
+## Stages
 
-This is the most important stage. Everything downstream — the architecture, the features, the trade-offs — flows from what we define here. Don't rush it.
+Each stage is self-contained. The skill runs them in order for the full lifecycle, but any stage can be entered independently based on the pathway chosen.
 
-Follow the full discovery process from the product-discovery blueprint. This is a rigorous product conversation — challenge assumptions, research the market, and push until the product thesis is sharp. You'll work through:
+### Stage 1: Product Discovery
+
+> "Before we write any code, let's get clear on what we're building and why it matters."
+
+Follow the full discovery process from the product-discovery blueprint. This is a rigorous product conversation — challenge assumptions, research the market, push until the product thesis is sharp.
 
 1. **Initial Framing** — What are you building? Who is it for? Why does it need to exist?
 2. **Problem Deep Dive** — 5 Whys to get past symptoms to root cause
@@ -73,163 +136,156 @@ Follow the full discovery process from the product-discovery blueprint. This is
 4. **Solution Positioning** — Competitive landscape, differentiation, "why now?"
 5. **Synthesis** — Distill everything into a defensible product thesis
 
-Use the templates from the blueprint to generate:
-
+Output:
 ```
 docs/product/
-├── product-thesis.md        # The 2-minute read — pillars, metrics, positioning
-├── product-brief.md         # Supporting research and detail
+├── product-thesis.md
+├── product-brief.md
 └── users/
-    ├── archetype-[name].md  # Vivid portraits of who you're building for
-    └── research-summary.md  # Evidence and sources
+    ├── archetype-[name].md
+    └── research-summary.md
 ```
 
 Create or update `.project-context.md` with the `## Product Discovery` section.
 
-### Pause Point
+**Pause:** "We've defined [product name] around [N] core pillars: [list them]. The primary user is [archetype]. Ready for the next stage, or want to stop here?"
 
-After discovery is complete, connect what was defined to what comes next:
+### Stage 2: Marketing Copy (Optional)
 
-"We've defined [product name] around [N] core pillars: [list them]. The primary user is [archetype] — [one-line description of their world]. This gives us a clear foundation to build on. Want to set up the codebase now, or let this sit and come back to it?"
+> "Now that we know what we're building, let's write the words that sell it."
 
-If stopping: "Whenever you're ready, run `/scaffold-foundation` to set up the project, or `/new-project` again to pick up where we left off."
+Read the marketing-copywriting BLUEPRINT.md at `~/.withmata/blueprints/blueprints/discovery/marketing-copywriting/BLUEPRINT.md`.
 
----
+The `/copywrite-landing` skill is best for the first page (usually a homepage or main landing page). After that, offer additional pages via `/copywrite` (pricing, about, features, etc.).
 
-## Stage 1.5: Project Type
+Output: `docs/pages/` with structured copy files.
 
-After discovery is complete, determine the project type:
+**Pause:** "We've got copy for [list pages]. Ready to define the visual identity, or move to code?"
 
-"Now let's set up the codebase. Are you building a:
-1. **Monorepo** — multiple packages, shared config, Turborepo (recommended for larger products with separate frontend/backend/packages)
-2. **Single-repo** — one application, everything in one package.json (simpler for smaller products or standalone apps)"
+### Stage 3: Design System (Optional)
 
-Record the choice in `.project-context.md` under `## Foundation`:
-```yaml
-project_type: monorepo  # or single-repo
-```
+> "Let's make your product look like YOUR product, not a template."
 
-- If **monorepo**: proceed to Stage 2 (Foundation)
-- If **single-repo**: skip Stage 2 entirely, proceed to Stage 3 (Features). Note in context: "Foundation skipped — single-repo project."
+Read the design-system BLUEPRINT.md at `~/.withmata/blueprints/blueprints/discovery/design-system/BLUEPRINT.md`.
 
----
-
-## Stage 2: Foundation
+Walk through: creative direction → colors → typography → spacing → layout → components → shadows → animation → generate outputs.
 
-> "The product is defined. Let's build the structure to support it."
+Output: `docs/design/design-system.md` + `docs/design/shared-styles.css`
 
-> **Note:** Skip this stage for single-repo projects — proceed directly to Stage 3.
+**Pause:** "Your visual identity is defined — [creative north star]. Custom tokens are ready. When we scaffold Tailwind, these will be used automatically."
 
-Read the discovery context from `.project-context.md` to inform technical decisions:
+### Stage 4: Project Type
 
-- Derive the npm scope from the product name (e.g., "Acme Dashboard" -> `@acme`)
-- Use the product pillars and archetype needs to inform any trade-offs
-- Apply technical constraints from discovery if any were noted
+"Are you building a:
+1. **Monorepo** — multiple packages, shared config, Turborepo (recommended for larger products)
+2. **Single-repo** — one application, one package.json (simpler for standalone apps)"
 
-Follow the foundation blueprint process. Only three questions — skip any already answered by project context:
-
-1. **npm scope** — defaults from product name
-2. **Project name** — human-readable, for metadata and page titles
-3. **Node.js version** — defaults to `>=22`
+Record in `.project-context.md` under `## Foundation`:
+```yaml
+project_type: monorepo  # or single-repo
+```
 
-Scaffold the monorepo skeleton: root configs, TypeScript config package, Tailwind config package, Next.js app shell, and empty workspace directories for future blueprints.
+- **Monorepo** → proceed to Stage 5
+- **Single-repo** → skip Stage 5, proceed to Stage 6. Note: "Foundation skipped — single-repo project."
 
-After scaffolding:
+### Stage 5: Foundation (Monorepo Only)
 
-1. Run `pnpm install` to verify the workspace is valid
-2. Briefly verify the dev server boots: `pnpm dev`
-3. Append the `## Foundation` section to `.project-context.md`
+> "Let's build the structure to support the product."
 
-### Pause Point
+Skip for single-repo projects.
 
-After foundation is complete, bridge to features by referencing the product:
+Read discovery context to inform technical decisions:
+- Derive npm scope from product name
+- Apply technical constraints from discovery
 
-"The codebase is ready — [scope] monorepo with Turborepo, Biome, and a Next.js app shell. Now let's think about what [product name] needs to actually work. Want to look at what's available, or stop here for now?"
+Three questions (skip any already answered):
+1. **npm scope** — defaults from product name
+2. **Project name** — human-readable
+3. **Node.js version** — defaults to `>=22`
 
-If stopping: "You can add capabilities anytime. Run `/scaffold-auth` for authentication, or `/new-project` to see all available blueprints."
+Scaffold the monorepo skeleton. After scaffolding:
+1. Run `bun install`
+2. Verify `bun dev` boots
+3. Append `## Foundation` to `.project-context.md`
 
----
+**Pause:** "The codebase is ready. Want to add features now?"
 
-## Stage 3: Features
+### Stage 6: Features
 
-> "Let's wire in what [product name] needs to deliver on its core pillars."
+> "Let's wire in what the product needs."
 
-If discovery was completed, reference the product pillars and archetype needs when presenting features. Connect each blueprint back to the product — don't just list technical capabilities.
+If discovery was completed, reference product pillars when presenting features. If not, present a straightforward capability list.
 
-List the available feature blueprints. Read each `BLUEPRINT.md` under `blueprints/features/*/` and show only those with `Status: Complete`.
+Read each `BLUEPRINT.md` under `blueprints/features/*/` and show only those with `Status: Complete`.
 
-**Present features in dependency order** — blueprints that others depend on should be listed first. Check each blueprint's `## Blueprint Dependencies` section. For example, db should be listed before auth (since auth requires db).
+**Present in dependency order** (db before auth, tailwind before UI):
 
-For each available blueprint, show:
-- **Name** — human-readable
-- **What it enables for the product** — tie it to a pillar or user need when possible
-- **Dependencies** — note if it requires another blueprint (e.g., "requires Database")
-- **Command** — the slash command to run it individually
+```
+Available features:
 
-Example:
+  1. Environment Variables — /scaffold-env
+     Type-safe validated env vars. Standalone.
 
-```
-Based on what [product name] needs:
+  2. Tailwind Design System — /scaffold-tailwind
+     Full token system. Auto-detects custom design if /design-system was run.
 
-  1. Authentication (Better Auth + Drizzle) — /scaffold-auth
-     User accounts, login flows, route protection. Required for [relevant pillar].
-     If org plugin: team/workspace management for [archetype need].
-```
+  3. UI Component Library — /scaffold-ui
+     31 base components. Auto-installs Tailwind first.
 
-Ask: "Which of these does [product name] need? We'll set them up one at a time."
+  4. Database — /scaffold-db
+     Drizzle ORM + PostgreSQL with schema groups.
 
-If no discovery context exists, fall back to a straightforward capability list without the product framing.
+  5. Authentication — /scaffold-auth
+     Better Auth + organizations. Requires Database.
 
-### For Each Selected Feature
+Which of these does the project need?
+```
 
-1. Read the feature's BLUEPRINT.md and all its files
-2. Read `.project-context.md` to understand current state
-3. Follow the blueprint's scaffolding process (ask its configuration questions, adapt files, etc.)
-4. Append the feature's entry to `## Installed Blueprints` in .project-context.md
+For each selected feature:
+1. Read the BLUEPRINT.md and all template files
+2. Read `.project-context.md` for current state
+3. Follow the scaffold process
+4. Append to `## Installed Blueprints`
 
-After each feature is installed, ask: "[Feature] is wired in. Want to add another, or is [product name] ready to start building on?"
+After each: "[Feature] is wired in. Want to add another?"
 
 ---
 
-## Step 7: Final Summary
+## Final Summary
 
-Once the user is done (whether after one stage or all three), provide a summary that connects the product to the technical foundation:
+Once the user is done (whether after one stage or all six):
 
 ### What We Built
-
-- **The product** (if discovery ran) — what it is, who it's for, the core pillars it delivers on
-- **The codebase** (if foundation ran) — how the project structure supports the product
-- **The capabilities** (if features ran) — what's wired in and how it maps to product needs
+- **The product** (if discovery ran) — what it is, who it's for, the core pillars
+- **The marketing** (if copy ran) — what pages were created
+- **The visual identity** (if design ran) — the creative north star, key design decisions
+- **The codebase** (if foundation ran) — how the structure supports the product
+- **The capabilities** (if features ran) — what's wired in
 
 ### Getting Started
-
 ```
-pnpm dev          # Start the development server
+bun dev          # Start the development server
 ```
 
 ### Environment Variables to Set
-
 List any env vars that need values (aggregated from all stages).
 
 ### Manual Steps Remaining
-
-List anything that can't be automated (aggregated from all stages).
+List anything that can't be automated.
 
 ### What's Next
-
-Suggest next steps in terms of product progress, not just technical tasks. Reference specific commands:
-
-- "The product thesis identified [pillar] as a core pillar — `/scaffold-auth` wires in the user accounts and access control to support that."
+Suggest next steps in terms of product progress:
 - "Run `/audit` to see all available blueprints and what would benefit your project."
 - "Start building the core product experience — the [archetype]'s primary workflow."
+- Reference specific commands for capabilities not yet installed.
 
 ---
 
 ## Important Notes
 
-- **Resumable** — this command always checks `.project-context.md` before starting. Run it again anytime to pick up where you left off, or use the individual stage commands (`/discover`, `/scaffold-foundation`, `/scaffold-auth`).
+- **Resumable** — this command always checks `.project-context.md` before starting. Run it again anytime to pick up where you left off, or use individual commands (`/discover`, `/copywrite`, `/design-system`, `/scaffold-foundation`, `/scaffold-auth`).
 - **Non-destructive** — never overwrite existing files without asking. If a stage was already completed, confirm before redoing it.
 - **Product-first** — every technical decision should trace back to the product definition. When in doubt, reference the pillars, the archetype, and the problem statement.
-- **Conversational** — this is a guided conversation, not a script. Adapt to the user's pace. If they want to skip ahead, let them. If they want to dig deeper into a stage, follow their lead.
-- **Project context is the source of truth** — every stage reads it, every stage appends to it. This is how stages communicate with each other across sessions.
-- **Maintenance rules accumulate** — each stage injects its maintenance rules into the project's rules file(s). These rules tell the AI coding tool what actions to take after certain types of changes. They accumulate as more blueprints are installed — the monorepo rules from foundation, plus auth rules, plus database rules, etc. The tool reads these at the start of every session.
+- **Conversational** — this is a guided conversation, not a script. Adapt to the user's pace. If they want to skip ahead, let them. If they want to dig deeper, follow their lead.
+- **Project context is the source of truth** — every stage reads it, every stage appends to it. This is how stages communicate across sessions.
+- **Any stage can be run independently** — the individual skills (`/discover`, `/copywrite`, `/design-system`, `/scaffold-tailwind`, etc.) work standalone. `/new-project` orchestrates them, but they don't depend on it.

package/.claude/skills/scaffold-auth/SKILL.md

@@ -104,7 +104,7 @@ Before making any changes, explore the target project to understand:
 
 Check `.project-context.md` for `project_type`. If not present, detect:
 
-- **Monorepo indicators**: `pnpm-workspace.yaml`, `turbo.json`, `nx.json`, `lerna.json`, or `"workspaces"` in root `package.json`
+- **Monorepo indicators**: `turbo.json`, `"workspaces"` in root `package.json`, `pnpm-workspace.yaml`, `nx.json`, or `lerna.json`
 - **Single-repo indicators**: Single `package.json` at root, `src/` directory, no workspace config
 
 Confirm with user: "This looks like a [monorepo|single-repo] project. Is that right?"
@@ -235,7 +235,7 @@ Based on the project structure, project context, and user answers, adapt the blu
 - Add scripts directly to root `package.json`:
   - `auth:generate` -> `npx @better-auth/cli@latest generate --config ./src/lib/auth/index.ts --output ./src/db/auth/schema.ts --yes`
   - `auth:migrate` -> `drizzle-kit generate --config ./drizzle/auth/drizzle.config.ts && drizzle-kit migrate --config ./drizzle/auth/drizzle.config.ts`
-  - `auth:setup` -> `pnpm auth:generate && pnpm auth:migrate`
+  - `auth:setup` -> `bun auth:generate && bun auth:migrate`
 - No Turbo tasks needed
 
 ## Step 5: Update Project Context
@@ -286,9 +286,9 @@ Then append:
 
 ```markdown
 ### auth-better-auth maintenance
-- After modifying Better Auth server config, plugins, or providers: run `pnpm auth:generate && pnpm auth:migrate`
-- After updating `better-auth` package: run `pnpm auth:generate`, check for schema changes, migrate if needed
-- After adding/changing env vars: update all `.env` files and verify `pnpm dev` starts clean
+- After modifying Better Auth server config, plugins, or providers: run `bun auth:generate && bun auth:migrate`
+- After updating `better-auth` package: run `bun auth:generate`, check for schema changes, migrate if needed
+- After adding/changing env vars: update all `.env` files and verify `bun dev` starts clean
 - After changing `BETTER_AUTH_URL` or `FRONTEND_DOMAIN`: verify CORS config and OAuth callback URLs
 - After any auth changes: verify `{BETTER_AUTH_URL}/api/auth/ok` responds
 - Never edit the auto-generated auth schema directly — modify the Better Auth config and regenerate
@@ -306,13 +306,13 @@ List every package that needs to be installed, grouped by workspace:
 
 ```
 # Server (apis/server or wherever auth lives)
-pnpm add better-auth drizzle-orm pg resend @t3-oss/env-core zod dotenv
+bun add better-auth drizzle-orm pg resend @t3-oss/env-core zod dotenv
 
 # Client (apps/web)
-pnpm add better-auth swr react-hook-form @hookform/resolvers zod @t3-oss/env-nextjs
+bun add better-auth swr react-hook-form @hookform/resolvers zod @t3-oss/env-nextjs
 
 # DB package (packages/db) — dev deps
-pnpm add -D drizzle-kit pg
+bun add -d drizzle-kit pg
 ```
 
 Adjust based on what's already installed in the project.
@@ -343,7 +343,7 @@ List anything that can't be automated:
 1. **Create a PostgreSQL database** for auth (if using separate auth DB)
 2. **Set up Google OAuth** — create OAuth 2.0 credentials in Google Cloud Console, add redirect URI
 3. **Set up Resend** — create an account, verify your domain, get API key
-4. **Run auth setup** — `pnpm auth:setup` (generates schema + runs migrations)
+4. **Run auth setup** — `bun auth:setup` (generates schema + runs migrations)
 5. **Build auth UI pages** — follow the Auth Flows section in BLUEPRINT.md to create the pages matching your design system
 6. **Test the auth flow** — sign up, verify email, sign in, create org (if applicable)
 

package/.claude/skills/scaffold-db/SKILL.md

@@ -78,7 +78,7 @@ Before making any changes, explore the target project to understand:
 
 Check `.project-context.md` for `project_type`. If not present, detect:
 
-- **Monorepo indicators**: `pnpm-workspace.yaml`, `turbo.json`, `nx.json`, `lerna.json`, or `"workspaces"` in root `package.json`
+- **Monorepo indicators**: `turbo.json`, `"workspaces"` in root `package.json`, `pnpm-workspace.yaml`, `nx.json`, or `lerna.json`
 - **Single-repo indicators**: Single `package.json` at root, `src/` directory, no workspace config
 
 Confirm with user: "This looks like a [monorepo|single-repo] project. Is that right?"
@@ -93,7 +93,7 @@ Record the project type in `.project-context.md` if not already there (add `proj
 3. What npm scope is used? Check root or any workspace `package.json`.
 4. What is the shared TypeScript config package name? Check `config/typescript-config/` or similar.
 5. Does `turbo.json` exist? Are there any existing db-related tasks?
-6. Does `pnpm-workspace.yaml` include `packages/*`?
+6. Does the root `package.json` `workspaces` field include `packages/*`? (Or does `pnpm-workspace.yaml` if using pnpm?)
 
 **If single-repo:**
 1. Does `src/db/` already exist? If so, what's in it?
@@ -102,7 +102,7 @@ Record the project type in `.project-context.md` if not already there (add `proj
 4. Is there an existing `.env` or `.env.local`?
 
 **Both:**
-- Package manager — pnpm, npm, yarn, or bun?
+- Package manager — bun (default), pnpm, npm, or yarn?
 
 Skip exploration for anything already documented in `.project-context.md`.
 
@@ -183,7 +183,7 @@ If `packages/db/` already exists:
   - `db:migrate` -> `turbo run {{GROUP}}:migrate --filter={{SCOPE}}/db --no-cache`
   - `db:studio` -> `turbo run drizzle:studio:{{GROUP}} --filter={{SCOPE}}/db --no-cache`
   - `db:seed` -> `turbo run seed --filter={{SCOPE}}/db --no-cache`
-- Verify `pnpm-workspace.yaml` includes `packages/*`
+- Verify root `package.json` `workspaces` field includes `packages/*` (or `pnpm-workspace.yaml` if using pnpm)
 
 **If single-repo:**
 - Add scripts directly to root `package.json` (direct drizzle-kit calls, no Turbo):
@@ -248,7 +248,7 @@ Then append:
 ```markdown
 ### db-drizzle-postgres maintenance
 - After creating a new schema file: add it to `drizzle/<group>/drizzle.config.ts` schema array AND the group's `index.ts` barrel export
-- After any schema change: run `pnpm <group>:generate && pnpm <group>:migrate`
+- After any schema change: run `bun <group>:generate && bun <group>:migrate`
 - After adding a new schema group: create drizzle config, add package.json export, add scripts (see BLUEPRINT.md "Adding a New Schema Group")
 - After updating drizzle-orm/drizzle-kit: run generate and check migration diff for unexpected changes
 - Never use glob patterns in drizzle.config.ts schema — always list files explicitly, excluding index.ts
@@ -267,15 +267,15 @@ List every package that needs to be installed. Adjust based on project type and
 **If monorepo:**
 ```bash
 # In packages/db/
-pnpm add drizzle-orm dotenv
-pnpm add -D drizzle-kit pg @types/pg tsx typescript
+bun add drizzle-orm dotenv
+bun add -d drizzle-kit pg @types/pg tsx typescript
 ```
 
 **If single-repo:**
 ```bash
 # At project root
-pnpm add drizzle-orm dotenv
-pnpm add -D drizzle-kit pg @types/pg tsx
+bun add drizzle-orm dotenv
+bun add -d drizzle-kit pg @types/pg tsx
 ```
 
 ### Environment Variables
@@ -289,11 +289,11 @@ pnpm add -D drizzle-kit pg @types/pg tsx
 
 1. **Create a PostgreSQL database** — `createdb {{GROUP}}_db` (or use your database hosting provider)
 2. **Set DATABASE_URL** — update the `.env` file with your actual connection string
-3. **Install dependencies** — `pnpm install` from the project root
-4. **Generate initial migration** — `pnpm db:generate`
-5. **Apply migration** — `pnpm db:migrate`
-6. **Verify** — `pnpm db:studio` (should open Drizzle Studio showing your tables)
-7. **(Optional) Run seed** — `pnpm db:seed` (inserts sample data)
+3. **Install dependencies** — `bun install` from the project root
+4. **Generate initial migration** — `bun db:generate`
+5. **Apply migration** — `bun db:migrate`
+6. **Verify** — `bun db:studio` (should open Drizzle Studio showing your tables)
+7. **(Optional) Run seed** — `bun db:seed` (inserts sample data)
 
 ### Files Created
 

package/.claude/skills/scaffold-env/SKILL.md

@@ -78,7 +78,7 @@ Before making any changes, explore the target project to understand:
 
 Check `.project-context.md` for `project_type`. If not present, detect:
 
-- **Monorepo indicators**: `pnpm-workspace.yaml`, `turbo.json`, `nx.json`, `lerna.json`, or `"workspaces"` in root `package.json`
+- **Monorepo indicators**: `turbo.json`, `"workspaces"` in root `package.json`, `pnpm-workspace.yaml`, `nx.json`, or `lerna.json`
 - **Single-repo indicators**: Single `package.json` at root, `src/` directory, no workspace config
 
 Confirm with user: "This looks like a [monorepo|single-repo] project. Is that right?"
@@ -226,12 +226,12 @@ After scaffolding, provide the user with a clear summary:
 
 **Next.js apps:**
 ```bash
-pnpm add @t3-oss/env-nextjs zod
+bun add @t3-oss/env-nextjs zod
 ```
 
 **Backend apps:**
 ```bash
-pnpm add @t3-oss/env-core zod dotenv
+bun add @t3-oss/env-core zod dotenv
 ```
 
 ### Files Created
@@ -255,7 +255,7 @@ import { env } from "./env.js";
 
 - Fill in `.env.local` with your actual values (use `.env.example` as reference)
 - As you add features, add their env vars to the schema files and `.env.example`
-- Run `pnpm dev` to verify env validation passes
+- Run `bun dev` to verify env validation passes
 
 ## Important Notes