Create Auth
Build or migrate Better Auth integrations for TypeScript and JavaScript apps with secure defaults, incremental rollout, and explicit verification.
Standards snapshot (March 2026)
- Start from the smallest viable auth surface, then layer features after the core flow works.
- Keep implementation and rollout aligned to
OWASP Top 10:2025 expectations for auth, session, and access-control safety.
- Prefer incremental migration over full rewrites when existing auth already exists.
- Validate live auth behavior, not just config shape.
Philosophy
- Secure defaults come first; feature richness comes second.
- Build the smallest working auth surface before layering plugins and providers.
- Favor incremental cutovers over high-risk rewrites.
When to use
- Adding Better Auth to a new app.
- Migrating an existing app to Better Auth.
- Adding concrete auth features such as OAuth, passkeys, 2FA, magic links, or org flows.
When not to use
- Performing a review-only audit with no implementation work.
- Working on a non-Better-Auth authentication stack.
- Discussing product-level auth trade-offs without committing to implementation.
Required inputs
- Framework and runtime context.
- Database adapter or storage choice.
- Desired auth features and plugins.
- Existing auth constraints, migration risks, or route structure.
Deliverables
- Step-by-step setup or migration path.
- Required files and expected file locations.
- Schema and migration commands.
- Verification steps for sign-up, sign-in, sign-out, and session persistence.
- If requested, a structured status report with a
schema_version field.
Constraints
- Redact secrets, tokens, client secrets, and sensitive auth data by default.
- Do not invent provider credentials, callback URLs, or migration assumptions.
- Do not skip schema or route validation just because the config looks correct.
Failure mode
- If the user only wants review or guidance, route to
best-practices.
- If framework or adapter details are missing and they materially change the setup path, stop and ask for them.
- If required secrets or provider details are unavailable, block safely rather than inventing a partial setup.
Workflow
- Identify framework, runtime, database adapter, and current auth state.
- Choose the smallest safe Better Auth setup for that environment.
- Create the server config and client integration points.
- Add routes or handlers and the requested plugins.
- Generate or apply schema changes.
- Validate the full auth flow before expanding feature scope.
Implementation lanes
- New project:
- install Better Auth
- create auth config
- add route handler
- run schema setup
- validate core flow
- Existing project without auth:
- map current app structure
- integrate Better Auth with minimal disruption
- wire existing pages or flows
- validate session behavior
- Migration:
- audit current auth
- plan incremental cutover
- migrate features in batches
- verify no session or route regressions
Tooling and references
- Use better-auth.com/docs for current syntax.
- Use local references as needed:
references/contract.yaml
references/evals.yaml
- Use assets only when the task benefits from packaged auth examples or supplemental materials in
assets/.
Validation
- Verify sign-up, sign-in, sign-out, and session persistence.
- Verify plugin-dependent behavior after each new feature is added.
- Verify migrations or generated schema changes ran successfully.
- Fail fast at the first missing prerequisite or broken auth flow.
Anti-patterns
- Enabling too many auth features before the base flow works.
- Skipping migrations after adding plugins.
- Disabling CSRF or origin checks without mitigations.
- Storing secrets in source control or echoing them in logs.
Examples
- Add Better Auth to a Next.js app with Prisma.
- Migrate this existing auth flow to Better Auth incrementally.
- Add passkeys and Google OAuth to this Better Auth setup.
See Also
| Skill |
When to use together |
| [[security-best-practices]] |
Apply secure defaults during auth implementation |
| [[1password]] |
Inject auth secrets via 1Password CLI |
| [[mcp-builder]] |
Secure MCP server authentication using Better Auth |
| [[security-threat-model]] |
Model auth attack surface before implementing |
Topic map: [[security-ops]]
Remember
Treat auth rollout like infrastructure. The core flow must work cleanly before you make it richer.
Gotchas
- None yet. Capture recurring failures here as symptom -> cause -> do instead -> check.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: create-auth3description: Implement or migrate Better Auth in TypeScript or JavaScript apps with secure defaults. Use when the user wants Better Auth added or changed in code, not just reviewed. Use when this capability is needed.4---56# Create Auth78Build or migrate Better Auth integrations for TypeScript and JavaScript apps with secure defaults, incremental rollout, and explicit verification.910## Standards snapshot (March 2026)11- Start from the smallest viable auth surface, then layer features after the core flow works.12- Keep implementation and rollout aligned to `OWASP Top 10:2025` expectations for auth, session, and access-control safety.13- Prefer incremental migration over full rewrites when existing auth already exists.14- Validate live auth behavior, not just config shape.1516## Philosophy17- Secure defaults come first; feature richness comes second.18- Build the smallest working auth surface before layering plugins and providers.19- Favor incremental cutovers over high-risk rewrites.2021## When to use22- Adding Better Auth to a new app.23- Migrating an existing app to Better Auth.24- Adding concrete auth features such as OAuth, passkeys, 2FA, magic links, or org flows.2526## When not to use27- Performing a review-only audit with no implementation work.28- Working on a non-Better-Auth authentication stack.29- Discussing product-level auth trade-offs without committing to implementation.3031## Required inputs32- Framework and runtime context.33- Database adapter or storage choice.34- Desired auth features and plugins.35- Existing auth constraints, migration risks, or route structure.3637## Deliverables38- Step-by-step setup or migration path.39- Required files and expected file locations.40- Schema and migration commands.41- Verification steps for sign-up, sign-in, sign-out, and session persistence.42- If requested, a structured status report with a `schema_version` field.4344## Constraints45- Redact secrets, tokens, client secrets, and sensitive auth data by default.46- Do not invent provider credentials, callback URLs, or migration assumptions.47- Do not skip schema or route validation just because the config looks correct.4849## Failure mode50- If the user only wants review or guidance, route to `best-practices`.51- If framework or adapter details are missing and they materially change the setup path, stop and ask for them.52- If required secrets or provider details are unavailable, block safely rather than inventing a partial setup.5354## Workflow551. Identify framework, runtime, database adapter, and current auth state.562. Choose the smallest safe Better Auth setup for that environment.573. Create the server config and client integration points.584. Add routes or handlers and the requested plugins.595. Generate or apply schema changes.606. Validate the full auth flow before expanding feature scope.6162## Implementation lanes63- New project:64 - install Better Auth65 - create auth config66 - add route handler67 - run schema setup68 - validate core flow69- Existing project without auth:70 - map current app structure71 - integrate Better Auth with minimal disruption72 - wire existing pages or flows73 - validate session behavior74- Migration:75 - audit current auth76 - plan incremental cutover77 - migrate features in batches78 - verify no session or route regressions7980## Tooling and references81- Use [better-auth.com/docs](https://better-auth.com/docs) for current syntax.82- Use local references as needed:83 - `references/contract.yaml`84 - `references/evals.yaml`85- Use assets only when the task benefits from packaged auth examples or supplemental materials in `assets/`.8687## Validation88- Verify sign-up, sign-in, sign-out, and session persistence.89- Verify plugin-dependent behavior after each new feature is added.90- Verify migrations or generated schema changes ran successfully.91- Fail fast at the first missing prerequisite or broken auth flow.9293## Anti-patterns94- Enabling too many auth features before the base flow works.95- Skipping migrations after adding plugins.96- Disabling CSRF or origin checks without mitigations.97- Storing secrets in source control or echoing them in logs.9899## Examples100- Add Better Auth to a Next.js app with Prisma.101- Migrate this existing auth flow to Better Auth incrementally.102- Add passkeys and Google OAuth to this Better Auth setup.103104## See Also105106| Skill | When to use together |107|---|---|108| [[security-best-practices]] | Apply secure defaults during auth implementation |109| [[1password]] | Inject auth secrets via 1Password CLI |110| [[mcp-builder]] | Secure MCP server authentication using Better Auth |111| [[security-threat-model]] | Model auth attack surface before implementing |112113**Topic map:** [[security-ops]]114115## Remember116Treat auth rollout like infrastructure. The core flow must work cleanly before you make it richer.117118## Gotchas119- None yet. Capture recurring failures here as symptom -> cause -> do instead -> check.120121---122> Converted and distributed by [TomeVault](https://tomevault.io/claim/jscraik) — claim your Tome and manage your conversions.123<!-- tomevault:4.0:skill_md:2026-04-13 -->