create-auth-skill

create-auth-skill 技能概览

create-auth-skill 是做什么的

create-auth-skill 是一份用于在 TypeScript 或 JavaScript 应用中接入 Better Auth 的实施指南。它面向真实落地，而不只是讲概念：它会帮助 agent 识别应用框架、推断数据库栈、选择 adapter、接好认证路由、添加 provider，并搭建 sign-in / sign-up 流程。

谁适合使用 create-auth-skill

如果你已经确定要用 Better Auth，或者希望让 AI agent 少猜一点、代替你完成认证接入里那些重复劳动，那么 create-auth-skill 会很适合你。它既适用于新项目，也适用于已有代码库，尤其是在你需要登录、session、OAuth 和认证页面，但又不想手动梳理每一步集成细节时。

它真正解决的是什么问题

大多数用户并不是在找“认证教程”，而是想要一套能和自己现有技术栈对上的可运行认证基础。create-auth-skill for Access Control 的价值就在于：它会先做发现和规划，再改代码，从而减少对框架约定、包管理器、ORM 或现有认证库的错误假设。

它和普通通用提示词有什么不同

通用提示词往往一上来就开始写代码。而这个技能明确要求必须先进入规划阶段：先扫描仓库、识别可能的框架和数据层信号、提出结构化问题，并在写文件之前先总结实施方案。这个顺序就是它的核心差异，因为认证接入最常出问题的，往往不是示例代码本身，而是集成边界。

最适合与不适合的场景

当你明确要用 Better Auth，并且需要 agent 按你的项目实际情况来完成接入时，就该用 create-auth-skill。如果你还在不同 auth 产品之间犹豫、需要一套高度成型的权限模型，或者想要一份与 provider 无关的访问控制架构文档，那它就不是最佳选择。它很适合快速搭起 authentication 基础，但并不等同于完整的 application authorization 设计。

如何使用 create-auth-skill 技能

安装 create-auth-skill

从 Better Auth skills 仓库安装：

npx skills add https://github.com/better-auth/skills --skill create-auth

如果你的环境使用的是别的 skill loader 或 agent runtime，可以按对应 runtime 调整安装方式，但仓库路径仍应保持一致：better-auth/create-auth。

先看唯一真正关键的文件

这个技能的结构很轻。核心内容就在 better-auth/create-auth/SKILL.md 的 SKILL.md 文件里。仓库中没有可依赖的 resources/、references/ 或辅助脚本，因此 agent 的实际效果，很大程度取决于它是否严格遵循该文件里的分阶段工作流。

在改任何代码前，先读规划阶段

这个仓库里最重要的一条要求是：实现之前必须先做规划。技能要求 agent：

1. 扫描项目，
2. 一次性提出所有适用的规划问题，
3. 汇总实施方案，
4. 然后才开始实现。

如果你的 agent 跳过这套流程，create-auth-skill 的主要价值就会损失很多。

这个技能会自动识别什么

在向你提问之前，这个技能会先查找仓库中的一些信号，比如：

• 框架配置文件，如 next.config、svelte.config、nuxt.config、astro.config 或 vite.config
• Express 或 Hono 的入口文件
• ORM 和数据库线索，如 prisma/schema.prisma、drizzle.config 或数据库驱动依赖
• 现有认证包，例如 next-auth、lucia、clerk、supabase/auth 或 firebase/auth
• 用于识别包管理器的 lockfile

这很关键，因为识别得越准，错误安装命令和不匹配代码示例就越少。

哪些输入能让 create-auth-skill 用得更好

像“add auth”这种模糊请求通常信息太少。想把 create-auth-skill 用好，最好提供：

• framework 和版本
• runtime 与 package manager
• ORM 或数据库选型
• 是新项目还是迁移项目
• 需要哪些 provider，例如 email/password、GitHub、Google、magic link 或 passkeys
• 对 session、受保护路由和 callback URL 的要求
• 你是想生成 UI 页面，还是只做后端接线

一个更强的请求可以是：“Use Better Auth in my Next.js app with Prisma and PostgreSQL, keep pnpm, add email/password plus GitHub OAuth, protect /dashboard, and create sign-in and sign-up pages without replacing my current layout.”

怎么把目标写成可执行的 prompt

这个技能对应的优质 prompt，应该同时包含约束、目标输出和迁移背景。例如：

• “Scan the repo first and confirm the framework, ORM, and existing auth.”
• “Ask me all missing auth questions in one batch before editing files.”
• “Then implement Better Auth using my current package manager.”
• “Show the file plan before writing code.”
• “Do not remove existing middleware until you explain the migration path.”

这种 prompt 结构和技能本身的预期工作流一致，能减少只做一半或过早动手的实现。

实际使用时推荐的工作流

一个实用的 create-auth-skill guide 可以这样走：

1. 安装技能
2. 让 agent 先扫描仓库
3. 完整回答它的规划问题
4. 确认实施方案
5. 让它开始搭建 auth
6. 检查环境变量、provider secrets 和数据库迁移步骤
7. 运行应用，测试 sign-in、sign-out、session 检查和受保护路由

真正关键的决策点在第 4 步。如果方案里没有明确提到你的实际 framework、adapter、routes 和 providers，就先停下来修正，不要急着生成代码。

快速评估时的仓库阅读路径

如果你还在判断这个技能值不值得采用，建议按这个顺序阅读：

1. SKILL.md 里的 frontmatter，看清范围
2. Phase 1: Planning
3. 项目扫描部分
4. 结构化提问部分
5. 与你所用框架相关的实现部分

按这个路径读，基本就足以判断它在你的仓库里到底是能省时间，还是只是重复 Better Auth 文档。

使用前要清楚的实际边界

这个技能会把你指向 better-auth.com/docs 查看代码示例和语法细节。这意味着它更像是一套工作流和集成脚手架，而不是一本自包含的参考手册。你可以指望它帮你编排步骤、判断项目适配方式，但一旦你的技术栈有边缘情况，具体 API 细节还是要以官方文档为准。

create-auth-skill for Access Control 什么时候最有价值

对 create-auth-skill for Access Control 来说，它最擅长的是快速搭起 identity 和 session 流程，为后续的受保护页面、路由守卫和基于角色的逻辑打基础。它能帮你建立干净的 auth 基线，但在初始接入之后，你仍然需要自己补充 authorization rules、permission checks 和贴合业务领域的策略层。

create-auth-skill 技能 FAQ

create-auth-skill 适合新手吗？

适合，但前提是这个新手已经有一个 JavaScript 或 TypeScript 应用，并且明确要用 Better Auth。先规划后实现的方式，可以降低随手 copy-paste 接入导致出错的概率。不过它并不是一整套 auth 学习路径；新手仍然可能需要查 Better Auth 文档，理解相关概念和 provider 的精确配置方式。

它比直接让 AI 从零加 auth 更好吗？

通常是的。它的优势不在于藏了什么“神秘代码”，而在于工作流纪律。create-auth-skill 会要求 agent 先检查项目，再问对问题。很多时候，这正是“真正适配你技术栈的接入”与“启动就报错的接入”之间的区别。

create-auth-skill 会自动安装并搞定一切吗？

不会。这个技能会引导 agent 完成实现流程，但最终结果仍取决于你的 repo、依赖、环境变量、provider 凭证以及数据库状态。更准确地说，它是一份结构化实施 playbook，而不是一键安装器。

我可以在已有应用里使用 create-auth-skill 吗？

可以。实际上，它在已有应用里往往更有价值，因为它会在改代码前先识别 framework、ORM 和当前 auth 信号。不过，如果你是在从另一个 auth 库迁移，还是要特别仔细地审查 session、user 表、callbacks 和 route protection 相关部分。

什么情况下不该使用 create-auth-skill？

以下情况建议跳过：

• 你还没有决定要用 Better Auth
• 你首先需要的是厂商中立的 auth 架构建议
• 你的主要问题是 authorization policy 设计，而不是 login / session 搭建
• 你的技术栈不属于 Better Auth 示例主要覆盖的典型 JS/TS 应用模式

它也覆盖 authorization 吗？

只是在间接层面上覆盖。create-auth-skill for Access Control 能为访问控制提供所需的 authentication 基础，例如 sessions 和受保护入口。至于细粒度 authorization——角色、权限、租户规则和策略执行——仍然需要结合你的应用自行设计。

如何改进 create-auth-skill 的使用效果

为 create-auth-skill 提供完整的规划输入

想最快提升输出质量，最有效的做法就是把缺失信息前置。告诉 agent 你的 framework、DB、ORM、provider 列表、受保护路由、package manager，以及这是 greenfield 还是 migration。每少一条关键信息，猜测空间就会更大，也更容易改错文件。

在动手改文件前，先要求输出方案摘要

虽然这个技能本身已经强调规划，但你仍然应该明确要求它先给出一个简短实施方案，至少包括：

• 要创建或修改的文件
• 要启用的 auth 方法
• 所需 env vars
• migration 步骤
• testing checklist

这能更早暴露不匹配问题，也会让 create-auth-skill guide 在团队协作场景里更可靠。

明确说明迁移约束

一个很常见的失败模式，是过于激进地替换现有 auth。如果你已经有当前认证代码，要明确告诉 agent：哪些内容必须暂时保留、哪些地方不能出问题、是否需要并行迁移。相比大多数用户的预期，这些约束对实现策略的影响往往更大。

用路由和 UI 预期来强化 prompt

如果你想拿到真正可用的输出，请明确说明你需要的是：

• 只要 auth API handlers
• middleware 或 route guards
• sign-in 和 sign-up 页面
• account management 页面
• 服务端 session checks
• 客户端 hooks 或 helpers

否则，这个技能很可能给出“技术上没错、但实际不完整”的 auth 接入结果。

在信任生成代码前，先确认 framework 识别是否正确

由于这个技能依赖仓库扫描，多应用仓库和非常规目录结构都可能让识别出错。在 monorepo 中，要明确告诉 agent 应该操作哪个 app 目录。否则，它可能会读错 package.json、lockfile 或 framework config，最后生成不匹配的命令。

最后的语法核对以官方文档为准

这个技能本身就会指向 https://better-auth.com/docs。最后请用它来核对 provider 语法、adapter 选项和框架特定细节。最佳做法通常是：先用 create-auth-skill 做决策流程和项目适配，再回到官方文档逐项核对精确实现。

第一轮输出后，针对性迭代修正

不要只说“fix it”。第一轮输出之后，尽量给出具体反馈，例如：

• “Keep Drizzle, do not switch ORM.”
• “Use GitHub OAuth only; remove email/password.”
• “Protect only /app/*, not marketing routes.”
• “Match my existing UI components instead of creating standalone pages.”

这种定向修正能让技能更快收敛，因为整体 auth 脚手架通常已经八九不离十，剩下的问题多半都是集成细节。

重点盯这些常见薄弱点

最值得人工复查的地方通常包括：

• 环境变量命名以及缺失的 secrets
• OAuth provider 的 callback URLs
• 数据库 adapter 选择
• 框架特定目录中的路由放置位置
• middleware 的作用范围
• 服务端与客户端代码中的 session checks

这些都是即便 create-auth-skill usage 流程本身做得不错，仍然需要人工确认的高风险点。

用标准 prompt 模板提升团队采用效果

如果团队里有多人会使用这个技能，建议内部整理一个统一 prompt 模板，固定包含技术栈、app 路径、auth 方法、迁移状态和受保护路由范围。标准化 prompt 能让结果更可预测，也能减少重复的规划来回沟通。

如何判断 create-auth-skill 是否用得好

衡量 create-auth-skill 的效果，不能只看“有没有生成文件”。真正好的结果应该是：

• 能匹配你的实际 framework 和 package manager
• 保留项目里原本有意为之的约定
• 清楚列出所需 env vars
• 解释数据库和 provider 的配置步骤
• 最终留下的是一套可测试的 auth 流程，而不只是零散代码片段

这才是判断它是否值得继续用于生产工作流的正确标准。