@withmata/blueprints 0.2.0 → 0.3.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,314 +0,0 @@
1
- ---
2
- description: Install Better Auth + Drizzle auth system
3
- ---
4
-
5
- # Scaffold Auth Blueprint
6
-
7
- Scaffold the `auth-better-auth` blueprint into the current project. Read the full blueprint first, then adapt it to this project's stack.
8
-
9
- ## Step 1: Read the Blueprint
10
-
11
- Read the full BLUEPRINT.md and all code files from the auth blueprint:
12
-
13
- ```
14
- blueprints/features/auth-better-auth/BLUEPRINT.md
15
- blueprints/features/auth-better-auth/files/**/*
16
- ```
17
-
18
- If these files are not in the current project, look for them at `~/Documents/WithMata/my-blueprints/blueprints/features/auth-better-auth/`. If still not found, ask the user for the path to their blueprints repo.
19
-
20
- ## Step 1.5: Read Project Context
21
-
22
- Check if `.project-context.md` exists in the target project root:
23
-
24
- - **If it exists**: read it to understand:
25
- - Product name and scope (from Discovery)
26
- - npm scope, workspace layout, server framework (from Foundation)
27
- - What other blueprints are already installed (from Installed Blueprints)
28
- - Use this information to pre-fill configuration questions in Step 3 and adapt file paths in Step 4
29
-
30
- - **If it does not exist**: proceed normally — explore the project manually (Step 2) and ask all configuration questions (Step 3)
31
-
32
- When project context provides clear answers, skip the corresponding questions in Step 3. For example:
33
- - Context says `server_framework: hono` -> do not ask about server framework
34
- - Context says `npm_scope: "@acme"` -> use `@acme` for package references
35
- - Context has `auth-better-auth` in Installed Blueprints -> warn about existing install
36
-
37
- ## Step 1.7: Check Blueprint Dependencies
38
-
39
- Read the Blueprint Dependencies section from `auth-better-auth/BLUEPRINT.md`.
40
-
41
- For `features/db-drizzle-postgres` (required):
42
- - Check `.project-context.md` for `db-drizzle-postgres` under `## Installed Blueprints`
43
- - If installed: proceed normally
44
- - If NOT installed, check filesystem:
45
- - Monorepo: does `packages/db/` exist?
46
- - Single-repo: does `src/db/` exist?
47
- - If db directory exists (but not in project context): note it, proceed normally — the scaffold command already handles merging
48
- - If neither installed nor directory exists:
49
- - Ask: "Auth requires a database package. The db-drizzle-postgres blueprint establishes the schema-group pattern that auth builds on. Install it first? (Y/n)"
50
- - If yes: run `/scaffold-db` first, then continue with auth
51
- - If no: warn about missing patterns, proceed with creating a minimal db structure for auth only
52
-
53
- For `foundation/monorepo-turbo` (recommended):
54
- - If not present: mention once: "Tip: The monorepo-turbo foundation blueprint provides workspace structure that auth integrates with. Consider running `/scaffold-foundation` first."
55
- - Continue without blocking.
56
-
57
- ## Step 2: Understand the Target Project
58
-
59
- Before making any changes, explore the target project to understand:
60
-
61
- ### 2a. Detect Project Type
62
-
63
- Check `.project-context.md` for `project_type`. If not present, detect:
64
-
65
- - **Monorepo indicators**: `pnpm-workspace.yaml`, `turbo.json`, `nx.json`, `lerna.json`, or `"workspaces"` in root `package.json`
66
- - **Single-repo indicators**: Single `package.json` at root, `src/` directory, no workspace config
67
-
68
- Confirm with user: "This looks like a [monorepo|single-repo] project. Is that right?"
69
-
70
- Record the project type in `.project-context.md` if not already there.
71
-
72
- ### 2b. Explore Structure
73
-
74
- **If monorepo:**
75
- 1. What workspaces exist? Where do apps, APIs, and packages live?
76
- 2. Is there a Hono server, Express server, or is it Next.js-only? Where are API routes?
77
- 3. Is Drizzle already set up? Is there a shared DB package?
78
- 4. Is this Next.js? What version? Is there an existing middleware.ts?
79
-
80
- **If single-repo:**
81
- 1. What framework is this? (Next.js, Node/Express, Hono, Bun?)
82
- 2. Does `src/db/` or `lib/db/` exist?
83
- 3. What import convention is used? (`@/` paths, `#` subpath imports, relative?)
84
- 4. Is there an existing `middleware.ts`?
85
-
86
- **Both:**
87
- 5. Existing auth to replace or integrate with?
88
- 6. UI library? Styling approach?
89
- 7. Package manager?
90
- 8. Validation — Zod, t3-env?
91
- 9. Data fetching — SWR, TanStack Query?
92
-
93
- Skip exploration for anything already documented in `.project-context.md`.
94
-
95
- ## Step 3: Ask Clarifying Questions
96
-
97
- Before scaffolding, ask the user about their preferences. Use the blueprint's "Hard Requirements vs Recommended Defaults" table. Specifically ask:
98
-
99
- 1. **Organization plugin** — "Do you need multi-tenant organizations (teams/workspaces with member management and invitations), or is this a single-tenant app?"
100
-
101
- 2. **Database setup** — "Should auth use a separate database, or share the existing app database?" (Recommend separate if no strong preference.)
102
-
103
- 3. **Social providers** — "Which social login providers do you want? Google is included by default. Any others (GitHub, Discord, etc.)?"
104
-
105
- 4. **Email provider** — "The blueprint uses Resend for transactional emails (verification, password reset, invitations). Do you want to use Resend, or a different provider?"
106
-
107
- 5. **Defaults check** — "The blueprint recommends these tools (which may already match your project). Want to go with the defaults, or change any?"
108
- - Zod for validation
109
- - t3-env for environment variable validation
110
- - SWR (`useSWRMutation`) for auth mutation hooks
111
- - react-hook-form for auth forms
112
-
113
- Skip questions where the answer is obvious from the project structure or from `.project-context.md`.
114
-
115
- ## Step 4: Adapt and Scaffold
116
-
117
- Based on the project structure, project context, and user answers, adapt the blueprint files:
118
-
119
- ### 4a. Database Layer
120
-
121
- **If monorepo:**
122
- - Copy/adapt `files/db/drizzle.config.ts` → `packages/db/drizzle/auth/drizzle.config.ts`
123
- - Copy `files/db/auth-schema.ts` as a reference (the actual schema will be auto-generated)
124
- - Add the `"./auth"` export to `packages/db/package.json`
125
- - Add `auth:generate` and `auth:migrate` scripts to `packages/db/package.json`
126
-
127
- **If single-repo:**
128
- - Copy/adapt `files/db/drizzle.config.ts` → `drizzle/auth/drizzle.config.ts` (at project root)
129
- - Adjust schema paths to `"./src/db/auth/schema.ts"` (relative to root)
130
- - Create `src/db/auth/` directory for auth schema
131
- - No separate package.json export needed — use direct imports
132
-
133
- ### 4b. Server Layer
134
-
135
- **If monorepo:**
136
- - Copy/adapt `files/server/auth.ts` → `apis/server/src/auth/index.ts`
137
- - Replace `{{APP_NAME}}`, `{{EMAIL_FROM}}`, `{{SCOPE}}`
138
- - Copy/adapt `files/server/auth-db.ts` → `apis/server/src/db/auth.ts`
139
- - Copy/adapt `files/server/middleware.ts` → `apis/server/src/middleware/auth.ts`
140
- - Merge auth env vars into `apis/server/src/env.ts`
141
-
142
- **If single-repo:**
143
- - Copy/adapt `files/server/auth.ts` → `src/lib/auth/index.ts`
144
- - Replace `{{APP_NAME}}`, `{{EMAIL_FROM}}`
145
- - Adjust DB import to use direct path: `import { db } from "@/db/auth/client"` or `#db/auth/client`
146
- - Copy/adapt `files/server/auth-db.ts` → `src/lib/db/auth.ts`
147
- - Default to Next.js API routes (no separate Hono server)
148
- - Merge auth env vars into existing `env.ts` (or create one)
149
-
150
- **Both:**
151
- - If the project uses a different server framework than Hono, adapt the middleware while keeping the core `auth.api.getSession({ headers })` pattern
152
-
153
- ### 4c. Mount Auth Handler
154
-
155
- **If monorepo with Hono server:**
156
- - Add CORS config + `app.on(["POST", "GET"], "/api/auth/*", ...)` handler in `apis/server/`
157
-
158
- **If single-repo or Next.js API routes:**
159
- - Create `app/api/auth/[...all]/route.ts` with `toNextJsHandler(auth)`
160
- - No CORS config needed (same origin)
161
-
162
- **Other frameworks:** Follow the platform integration section in BLUEPRINT.md
163
-
164
- ### 4d. Client Layer
165
-
166
- **If monorepo:**
167
- - Copy client files to `apps/web/auth/`
168
- - Add `"#auth/*": "./auth/*"` import alias to `apps/web/package.json`
169
-
170
- **If single-repo:**
171
- - Copy client files to `src/auth/`
172
- - Add `"#auth/*": "./src/auth/*"` import alias to root `package.json` (or use `@/auth/*` if that's the convention)
173
-
174
- **Both:**
175
- - Adapt `files/client/auth-client.ts` — adjust baseURL for deployment setup
176
- - If using org plugin: copy all `files/client/context/`, `hooks/`, `schema/`, `types/` files
177
- - If NOT using org plugin: only copy `files/client/schema/auth.ts`
178
-
179
- ### 4e. Route Protection
180
-
181
- - Copy/adapt `files/middleware/route-protection.ts` into the project's Next.js middleware
182
- - If middleware.ts already exists, MERGE the auth logic into it — don't overwrite
183
- - If using Hono standalone mode: add API proxy rewrites to `next.config.ts`
184
-
185
- ### 4f. Project Scripts
186
-
187
- **If monorepo:**
188
- - Add `auth:generate` script to the server package (runs `@better-auth/cli generate`)
189
- - Add `auth:generate`, `auth:migrate`, `auth:setup` to root `package.json` (Turbo wrappers)
190
- - Add `auth:generate` and `auth:migrate` tasks to `turbo.json` (both `cache: false`)
191
-
192
- **If single-repo:**
193
- - Add scripts directly to root `package.json`:
194
- - `auth:generate` -> `npx @better-auth/cli@latest generate --config ./src/lib/auth/index.ts --output ./src/db/auth/schema.ts --yes`
195
- - `auth:migrate` -> `drizzle-kit generate --config ./drizzle/auth/drizzle.config.ts && drizzle-kit migrate --config ./drizzle/auth/drizzle.config.ts`
196
- - `auth:setup` -> `pnpm auth:generate && pnpm auth:migrate`
197
- - No Turbo tasks needed
198
-
199
- ## Step 5: Update Project Context
200
-
201
- Append an entry to `.project-context.md` under `## Installed Blueprints`:
202
-
203
- ```yaml
204
- ### auth-better-auth
205
- blueprint: auth-better-auth
206
- choices:
207
- database: <user's choice>
208
- auth_db_isolation: <separate|shared>
209
- server_framework: <hono|next.js>
210
- organization_plugin: <true|false>
211
- social_providers: [<list>]
212
- email_provider: <resend|other>
213
- env_validation: <t3-env|other>
214
- form_validation: <zod|other>
215
- data_fetching: <swr|other>
216
- files_created:
217
- - <list of all files created or modified>
218
- env_vars_added:
219
- - <list of env vars>
220
- scripts_added:
221
- - <list of scripts>
222
- ```
223
-
224
- If `.project-context.md` does not exist, create it with the standard header and the Installed Blueprints section. Log a note: "No discovery or foundation context found. Consider running `/discover` and `/scaffold-foundation` for a complete project context."
225
-
226
- Also append any significant architectural decisions to the `## Architecture Decisions` section.
227
-
228
- ### Inject Maintenance Rules
229
-
230
- Append the condensed maintenance rules to the target project's rules file(s):
231
-
232
- 1. If `CLAUDE.md` exists in the target project → append rules there
233
- 2. If `AGENTS.md` exists in the target project → append rules there
234
- 3. If both exist → append to both (keep them in sync)
235
- 4. If neither exists → ask the user which AI coding tool(s) they use:
236
- - Claude Code → create CLAUDE.md with a `## Maintenance Rules` section
237
- - OpenCode or Cursor → create AGENTS.md with a `## Maintenance Rules` section (both tools read AGENTS.md)
238
- - Multiple tools → create all applicable files
239
-
240
- The maintenance rules content is identical regardless of which file it goes into:
241
-
242
- ```markdown
243
- ### auth-better-auth maintenance
244
- - After modifying Better Auth server config, plugins, or providers: run `pnpm auth:generate && pnpm auth:migrate`
245
- - After updating `better-auth` package: run `pnpm auth:generate`, check for schema changes, migrate if needed
246
- - After adding/changing env vars: update all `.env` files and verify `pnpm dev` starts clean
247
- - After changing `BETTER_AUTH_URL` or `FRONTEND_DOMAIN`: verify CORS config and OAuth callback URLs
248
- - After any auth changes: verify `{BETTER_AUTH_URL}/api/auth/ok` responds
249
- - Never edit the auto-generated auth schema directly — modify the Better Auth config and regenerate
250
- ```
251
-
252
- If the `## Maintenance Rules` heading already exists (from another blueprint), only add the `### auth-better-auth maintenance` subsection — do not duplicate the heading.
253
-
254
- ## Step 6: Output Summary
255
-
256
- After scaffolding, provide the user with a clear summary:
257
-
258
- ### Packages to Install
259
-
260
- List every package that needs to be installed, grouped by workspace:
261
-
262
- ```
263
- # Server (apis/server or wherever auth lives)
264
- pnpm add better-auth drizzle-orm pg resend @t3-oss/env-core zod dotenv
265
-
266
- # Client (apps/web)
267
- pnpm add better-auth swr react-hook-form @hookform/resolvers zod @t3-oss/env-nextjs
268
-
269
- # DB package (packages/db) — dev deps
270
- pnpm add -D drizzle-kit pg
271
- ```
272
-
273
- Adjust based on what's already installed in the project.
274
-
275
- ### Environment Variables
276
-
277
- List every env var that needs to be set, with example values:
278
-
279
- ```env
280
- # Server
281
- BETTER_AUTH_URL=http://localhost:4000
282
- BETTER_AUTH_SECRET= # Generate: openssl rand -base64 32
283
- AUTH_DATABASE_URL= # PostgreSQL connection URL
284
- FRONTEND_DOMAIN=http://localhost:3000
285
- GOOGLE_CLIENT_ID= # From Google Cloud Console
286
- GOOGLE_CLIENT_SECRET= # Redirect URI: {BETTER_AUTH_URL}/api/auth/callback/google
287
- RESEND_API_KEY= # From resend.com
288
-
289
- # Client (.env.local in web app)
290
- NEXT_PUBLIC_API_URL=http://localhost:4000
291
- NEXT_PUBLIC_FRONTEND_URL=http://localhost:3000
292
- ```
293
-
294
- ### Manual Steps Remaining
295
-
296
- List anything that can't be automated:
297
-
298
- 1. **Create a PostgreSQL database** for auth (if using separate auth DB)
299
- 2. **Set up Google OAuth** — create OAuth 2.0 credentials in Google Cloud Console, add redirect URI
300
- 3. **Set up Resend** — create an account, verify your domain, get API key
301
- 4. **Run auth setup** — `pnpm auth:setup` (generates schema + runs migrations)
302
- 5. **Build auth UI pages** — follow the Auth Flows section in BLUEPRINT.md to create the pages matching your design system
303
- 6. **Test the auth flow** — sign up, verify email, sign in, create org (if applicable)
304
-
305
- ### Files Created
306
-
307
- List every file that was created or modified, with a one-line description.
308
-
309
- ## Important Notes
310
-
311
- - If the Better Auth skills are installed (`npx skillsadd better-auth/skills`), invoke `/best-practices` for quick-reference on configuration. If not available, refer to the Better Auth docs and References section in BLUEPRINT.md.
312
- - When adapting code, preserve the `// CONFIGURE:` comments so the user can find customization points later.
313
- - If the project structure differs significantly from the blueprint's assumptions, explain the differences and suggest how to adapt rather than forcing the blueprint's structure.
314
- - Never overwrite existing files without asking. If a file exists (like `middleware.ts` or `env.ts`), merge the auth additions into it.
@@ -1,274 +0,0 @@
1
- ---
2
- description: Scaffold the Drizzle ORM + PostgreSQL database package blueprint
3
- ---
4
-
5
- # Scaffold DB Blueprint
6
-
7
- Scaffold the `db-drizzle-postgres` blueprint into the current project. Read the full blueprint first, then adapt it to this project's stack.
8
-
9
- ## Step 1: Read the Blueprint
10
-
11
- Read the full BLUEPRINT.md and all template files from the db blueprint:
12
-
13
- ```
14
- blueprints/features/db-drizzle-postgres/BLUEPRINT.md
15
- blueprints/features/db-drizzle-postgres/files/**/*
16
- ```
17
-
18
- If these files are not in the current project, look for them at `~/Documents/WithMata/my-blueprints/blueprints/features/db-drizzle-postgres/`. If still not found, ask the user for the path to their blueprints repo.
19
-
20
- ## Step 1.5: Read Project Context
21
-
22
- Check if `.project-context.md` exists in the target project root:
23
-
24
- - **If it exists**: read it to understand:
25
- - Product name and scope (from Discovery)
26
- - npm scope, workspace layout, TypeScript config package name (from Foundation)
27
- - What other blueprints are already installed (from Installed Blueprints)
28
- - Use this information to pre-fill configuration questions in Step 3 and adapt file paths in Step 4
29
-
30
- - **If it does not exist**: proceed normally — explore the project manually (Step 2) and ask all configuration questions (Step 3)
31
-
32
- When project context provides clear answers, skip the corresponding questions in Step 3. For example:
33
- - Context says `npm_scope: "@acme"` -> use `@acme` for package references
34
- - Context has `db-drizzle-postgres` in Installed Blueprints -> warn about existing install
35
- - Context has `auth-better-auth` installed -> `packages/db/` likely exists already
36
-
37
- ## Step 2: Understand the Target Project
38
-
39
- Before making any changes, explore the target project to understand:
40
-
41
- ### 2a. Detect Project Type
42
-
43
- Check `.project-context.md` for `project_type`. If not present, detect:
44
-
45
- - **Monorepo indicators**: `pnpm-workspace.yaml`, `turbo.json`, `nx.json`, `lerna.json`, or `"workspaces"` in root `package.json`
46
- - **Single-repo indicators**: Single `package.json` at root, `src/` directory, no workspace config
47
-
48
- Confirm with user: "This looks like a [monorepo|single-repo] project. Is that right?"
49
-
50
- Record the project type in `.project-context.md` if not already there (add `project_type: monorepo` or `project_type: single-repo` under `## Foundation`).
51
-
52
- ### 2b. Explore Structure
53
-
54
- **If monorepo:**
55
- 1. What workspaces exist? Where do apps, APIs, and packages live?
56
- 2. Does `packages/db/` already exist? (The auth blueprint may have created it.) If so, what exports, scripts, and schema groups are already present?
57
- 3. What npm scope is used? Check root or any workspace `package.json`.
58
- 4. What is the shared TypeScript config package name? Check `config/typescript-config/` or similar.
59
- 5. Does `turbo.json` exist? Are there any existing db-related tasks?
60
- 6. Does `pnpm-workspace.yaml` include `packages/*`?
61
-
62
- **If single-repo:**
63
- 1. Does `src/db/` already exist? If so, what's in it?
64
- 2. What framework is this? (Next.js, Node/Express, Hono, Bun?)
65
- 3. What import convention is used? (`@/` paths, `#` subpath imports, relative?)
66
- 4. Is there an existing `.env` or `.env.local`?
67
-
68
- **Both:**
69
- - Package manager — pnpm, npm, yarn, or bun?
70
-
71
- Skip exploration for anything already documented in `.project-context.md`.
72
-
73
- ## Step 3: Ask Clarifying Questions
74
-
75
- Before scaffolding, ask the user about their preferences:
76
-
77
- 1. **Schema group name** — "What should your main schema group be called? This groups related database tables together (e.g., 'core' for your main application data, 'app' for a simpler name). Default: `core`"
78
-
79
- 2. **Include example entity?** — "Include an example entity file demonstrating the full Drizzle pattern (pgTable, pgEnum, indexes, type exports)? Recommended if this is your first time using Drizzle." (Default: yes)
80
-
81
- 3. **Include seed script?** — "Include a seed script template for populating development data?" (Default: yes)
82
-
83
- 4. **Connection helper** — "Should the database connection helper live in the db package (simpler — import and use directly), or will each consuming app create its own connection (more flexible — each app controls its own pool settings)?" (Default: in db package)
84
-
85
- 5. **Existing `packages/db/`** — If it already exists (e.g., from the auth blueprint): "I found an existing `packages/db/` package. I'll add the new schema group to it without overwriting existing files. Does that sound right?"
86
-
87
- Skip questions where the answer is obvious from the project structure or from `.project-context.md`.
88
-
89
- ## Step 4: Adapt and Scaffold
90
-
91
- Based on the project structure, project context, and user answers, adapt the blueprint files.
92
-
93
- ### 4a. Project Setup
94
-
95
- **If monorepo — Package Setup (or merge if exists):**
96
-
97
- If `packages/db/` does NOT exist:
98
- - Create the full package: `package.json`, `tsconfig.json`, `.env.example`
99
- - Replace all placeholders:
100
- - `{{SCOPE}}` -> the project's npm scope (e.g., `@acme`)
101
- - `{{GROUP}}` -> the schema group name (e.g., `core`)
102
- - `{{GROUP_UPPER}}` -> uppercase for env vars (e.g., `CORE`)
103
-
104
- If `packages/db/` already exists:
105
- - Merge the new schema group's export into existing `package.json` exports
106
- - Merge new scripts into existing scripts (don't overwrite existing ones like `build`, `typecheck`, `clean`)
107
- - Skip `tsconfig.json` if it already exists and looks correct
108
- - Add `{{GROUP_UPPER}}_DATABASE_URL` to existing `.env.example`
109
-
110
- **If single-repo — Directory Setup:**
111
-
112
- - Create `src/db/` directory (no separate `package.json` — use root)
113
- - Add `{{GROUP_UPPER}}_DATABASE_URL` to root `.env.example` (or `.env` if that's the convention)
114
- - No separate `tsconfig.json` needed — inherits from root
115
- - Replace placeholders in files: `{{GROUP}}`, `{{GROUP_UPPER}}`
116
- - Skip `{{SCOPE}}` — use direct imports instead (`@/db/{{GROUP}}` or `#db/{{GROUP}}`)
117
-
118
- ### 4b. Schema Group Files
119
-
120
- - Create `src/{{GROUP}}/` directory
121
- - Copy example entity file (if user said yes) — replace all placeholders
122
- - Create barrel `index.ts` with re-exports
123
- - Copy `client.ts` helper (if user chose "in db package") — replace placeholders
124
-
125
- ### 4c. Drizzle Config
126
-
127
- - **Monorepo:** Create `packages/db/drizzle/{{GROUP}}/` directory
128
- - **Single-repo:** Create `drizzle/{{GROUP}}/` at project root
129
- - Copy `drizzle.config.ts` — replace `{{GROUP}}`, `{{GROUP_UPPER}}`
130
- - Adjust schema file paths based on project type:
131
- - Monorepo: `"./src/{{GROUP}}/example.ts"` (relative to `packages/db/`)
132
- - Single-repo: `"./src/db/{{GROUP}}/example.ts"` (relative to project root)
133
- - Verify schema file paths match actual files created in 4b
134
-
135
- ### 4d. Seed Script (optional)
136
-
137
- - Create `src/scripts/` directory (if it doesn't exist)
138
- - Copy `seed.ts` — replace placeholders, adjust entity imports
139
- - If a seed script already exists, ask before overwriting
140
-
141
- ### 4e. Project Integration
142
-
143
- **If monorepo:**
144
- - Add `{{GROUP}}:generate`, `{{GROUP}}:migrate` tasks to `turbo.json` (both `cache: false`) — merge into existing tasks
145
- - Add convenience scripts to root `package.json`:
146
- - `db:generate` -> `turbo run {{GROUP}}:generate --filter={{SCOPE}}/db --no-cache`
147
- - `db:migrate` -> `turbo run {{GROUP}}:migrate --filter={{SCOPE}}/db --no-cache`
148
- - `db:studio` -> `turbo run drizzle:studio:{{GROUP}} --filter={{SCOPE}}/db --no-cache`
149
- - `db:seed` -> `turbo run seed --filter={{SCOPE}}/db --no-cache`
150
- - Verify `pnpm-workspace.yaml` includes `packages/*`
151
-
152
- **If single-repo:**
153
- - Add scripts directly to root `package.json` (direct drizzle-kit calls, no Turbo):
154
- - `db:generate` -> `drizzle-kit generate --config ./drizzle/{{GROUP}}/drizzle.config.ts`
155
- - `db:migrate` -> `drizzle-kit generate --config ./drizzle/{{GROUP}}/drizzle.config.ts && drizzle-kit migrate --config ./drizzle/{{GROUP}}/drizzle.config.ts`
156
- - `db:studio` -> `drizzle-kit studio --config ./drizzle/{{GROUP}}/drizzle.config.ts`
157
- - `db:seed` -> `tsx src/db/scripts/seed.ts`
158
- - Add drizzle-orm, dotenv as dependencies and drizzle-kit, pg, @types/pg, tsx as devDependencies
159
- - No `turbo.json` changes needed
160
-
161
- ## Step 5: Update Project Context
162
-
163
- Append an entry to `.project-context.md` under `## Installed Blueprints`:
164
-
165
- ```yaml
166
- ### db-drizzle-postgres
167
- blueprint: db-drizzle-postgres
168
- choices:
169
- schema_group: <group name>
170
- include_example: <true|false>
171
- include_seed: <true|false>
172
- connection_helper: <in-db-package|per-app>
173
- files_created:
174
- - <list of all files created or modified>
175
- env_vars_added:
176
- - <GROUP_UPPER>_DATABASE_URL
177
- scripts_added:
178
- db_package:
179
- - <group>:generate
180
- - <group>:migrate
181
- - drizzle:studio:<group>
182
- - seed
183
- root:
184
- - db:generate
185
- - db:migrate
186
- - db:studio
187
- - db:seed
188
- turbo_tasks:
189
- - <group>:generate
190
- - <group>:migrate
191
- ```
192
-
193
- If `.project-context.md` does not exist, create it with the standard header and the Installed Blueprints section. Log a note: "No discovery or foundation context found. Consider running `/discover` and `/scaffold-foundation` for a complete project context."
194
-
195
- ### Inject Maintenance Rules
196
-
197
- Append the condensed maintenance rules to the target project's rules file(s):
198
-
199
- 1. If `CLAUDE.md` exists in the target project -> append rules there
200
- 2. If `AGENTS.md` exists in the target project -> append rules there
201
- 3. If both exist -> append to both (keep them in sync)
202
- 4. If neither exists -> ask the user which AI coding tool(s) they use:
203
- - Claude Code -> create CLAUDE.md with a `## Maintenance Rules` section
204
- - OpenCode or Cursor -> create AGENTS.md with a `## Maintenance Rules` section (both tools read AGENTS.md)
205
- - Multiple tools -> create all applicable files
206
-
207
- The maintenance rules content is identical regardless of which file it goes into:
208
-
209
- ```markdown
210
- ### db-drizzle-postgres maintenance
211
- - After creating a new schema file: add it to `drizzle/<group>/drizzle.config.ts` schema array AND the group's `index.ts` barrel export
212
- - After any schema change: run `pnpm <group>:generate && pnpm <group>:migrate`
213
- - After adding a new schema group: create drizzle config, add package.json export, add scripts (see BLUEPRINT.md "Adding a New Schema Group")
214
- - After updating drizzle-orm/drizzle-kit: run generate and check migration diff for unexpected changes
215
- - Never use glob patterns in drizzle.config.ts schema — always list files explicitly, excluding index.ts
216
- ```
217
-
218
- If the `## Maintenance Rules` heading already exists (from another blueprint), only add the `### db-drizzle-postgres maintenance` subsection — do not duplicate the heading.
219
-
220
- ## Step 6: Output Summary
221
-
222
- After scaffolding, provide the user with a clear summary:
223
-
224
- ### Packages to Install
225
-
226
- List every package that needs to be installed. Adjust based on project type and what's already installed:
227
-
228
- **If monorepo:**
229
- ```bash
230
- # In packages/db/
231
- pnpm add drizzle-orm dotenv
232
- pnpm add -D drizzle-kit pg @types/pg tsx typescript
233
- ```
234
-
235
- **If single-repo:**
236
- ```bash
237
- # At project root
238
- pnpm add drizzle-orm dotenv
239
- pnpm add -D drizzle-kit pg @types/pg tsx
240
- ```
241
-
242
- ### Environment Variables
243
-
244
- ```env
245
- # Monorepo: packages/db/.env | Single-repo: .env at root
246
- {{GROUP_UPPER}}_DATABASE_URL=postgresql://user:password@localhost:5432/{{GROUP}}_db
247
- ```
248
-
249
- ### Manual Steps Remaining
250
-
251
- 1. **Create a PostgreSQL database** — `createdb {{GROUP}}_db` (or use your database hosting provider)
252
- 2. **Set DATABASE_URL** — update the `.env` file with your actual connection string
253
- 3. **Install dependencies** — `pnpm install` from the project root
254
- 4. **Generate initial migration** — `pnpm db:generate`
255
- 5. **Apply migration** — `pnpm db:migrate`
256
- 6. **Verify** — `pnpm db:studio` (should open Drizzle Studio showing your tables)
257
- 7. **(Optional) Run seed** — `pnpm db:seed` (inserts sample data)
258
-
259
- ### Files Created
260
-
261
- List every file that was created or modified, with a one-line description.
262
-
263
- ### Next Steps
264
-
265
- - Replace the example entity with your actual domain entities
266
- - For each new entity: copy the example file pattern, then follow the "Adding New Entities" checklist in BLUEPRINT.md
267
- - If you need authentication: run `/scaffold-auth` — it will add auth schemas to the existing `packages/db/`
268
-
269
- ## Important Notes
270
-
271
- - When adapting code, preserve the `// CONFIGURE:` comments so the user can find customization points later.
272
- - If the project structure differs significantly from the blueprint's assumptions, explain the differences and suggest how to adapt rather than forcing the blueprint's structure.
273
- - Never overwrite existing files without asking. If a file exists (like `package.json` or `turbo.json`), merge the new additions into it.
274
- - If `packages/db/` already exists from the auth blueprint, be especially careful to merge — not overwrite — the `package.json` exports, scripts, and dependencies.