organization-best-practices

organization-best-practices 技能概览

这个技能能帮你完成什么

organization-best-practices skill 是一份面向实战的指南，帮助你用 Better Auth 落地多租户组织模型，尤其适合那些真正要解决的问题并不是基础认证接入，而是访问控制、团队成员关系、邀请流程和角色设计的场景。对于正在评估 organization-best-practices 是否适合 Access Control、又不想从零拼凑各类插件文档的开发者来说，它尤其有用。

哪类读者最适合使用

如果你正在构建以下类型的产品或能力，就很适合使用这个技能：

• 带 workspace 或 organization 的 SaaS 产品
• 围绕团队和成员的基于角色的访问控制
• 基于邀请的 onboarding 流程
• 需要组织所有者、管理员委派和成员上限的应用

如果你已经在使用 Better Auth，或者正在判断它的 organization 插件是否覆盖你的租户模型，这个技能会非常契合。

它真正解决的工作问题

大多数用户并不是单纯在找“组织功能”。他们真正需要的是一套可靠的方法来：

• 在现有认证栈中加入 orgs
• 自动分配 owner
• 控制谁可以创建组织
• 清晰地管理成员角色
• 正确连接服务端和客户端插件，避免配置不一致
• 在测试流程前先把数据库迁移正确完成

这个技能的价值在于，它把这些彼此依赖的配置和步骤压缩成了一条清晰的工作流。

为什么它不同于普通提示词

普通提示词可以让 AI “用 Better Auth 搭一个 organizations 功能”，但这个技能是围绕 Better Auth organization 插件的真实流程来组织的：服务端插件、客户端插件、migration，以及数据库校验。正因为如此，它更适合用来做安装决策，也更容易产出符合库本身预期结构的实现步骤。

安装前最该先确认什么

最关键的采用判断其实很简单：你的应用是否能自然映射到 Better Auth 的 organization 模型？如果你需要组织创建、邀请管理、角色分配，以及类似 RBAC 的访问模式，通常答案是可以。如果你需要高度定制的租户语义、跨组织策略引擎，或者非常规的权限继承关系，那就要预期你会在这个基础技能之外做进一步扩展。

如何使用 organization-best-practices 技能

从真实安装上下文开始，而不是先写提示词

实用的 organization-best-practices install 路径，起点是你的 Better Auth 配置，而不是 prompt。先读 SKILL.md，再对照你当前的 auth setup。这个技能默认你会补上：

• 服务端的 organization()
• 客户端的 organizationClient()
• 一步 migration：npx @better-auth/cli migrate
• 针对 organization 相关数据表的数据库检查

如果你的应用还没有用 Better Auth，这个技能并不是一份完整的 auth 迁移指南。

先读这个文件

在让 agent 生成代码之前，先看 better-auth/organization/SKILL.md。这里包含了信息密度最高的工作流：安装、客户端接入、组织创建，以及组织创建控制。由于这个仓库的结构本身比较精简，先读 skill 文件，基本就能拿到几乎所有真正有用的实现上下文。

先确认最低必需配置

一个正确的第一版实现，通常至少包括：

1. 添加服务端插件：
   import { organization } from "better-auth/plugins"
2. 添加客户端插件：
   import { organizationClient } from "better-auth/client/plugins"
3. 运行：
   npx @better-auth/cli migrate
4. 确认数据库里已经出现 organization、member 和 invitation 相关表

很多人会在第 4 步踩坑：应用代码看起来都对了，但 schema 实际并不完整，最后就会导致排查方向完全跑偏。

让技能拿到它真正需要的输入

想得到高质量的 organization-best-practices usage 结果，你需要把影响访问控制设计的约束明确告诉 agent，比如：

• 谁可以创建 organization
• 用户是否可以加入多个 org
• 预期有哪些角色，比如 owner、admin、member
• onboarding 是仅邀请制还是自助开通
• org 和 membership 的数量限制
• 现在是否需要 teams，还是后面再加

如果没有这些输入，最终通常只会得到一套“能编译通过”的通用配置，但它并不能反映你的治理模型。

把模糊目标写成高质量提示

弱提示词：

Set up Better Auth organizations.

强提示词：

Add Better Auth organization support to my app. Users can create up to 3 organizations, each org can have up to 50 members, only users with canCreateOrg: true may create organizations, creators should become owner, and we need client-side organization creation plus invitation-ready schema setup. Show the server config, client config, migration step, and what database tables I should verify.

更强的版本之所以效果更好，是因为它明确提供了限制条件、创建策略、默认角色预期，以及要交付的具体内容。

用分阶段工作流，不要一口气提一个大需求

高质量的 organization-best-practices guide 通常会按这个顺序推进：

1. 先让 AI 处理服务端插件安装
2. 再处理客户端插件安装
3. 然后要 migration 和验证步骤
4. 接着补组织创建流程
5. 再补组织创建限制和角色逻辑
6. 最后再落到你应用里的路由或 action 访问控制检查

这样做可以减少 AI 编造“胶水代码”的情况，也更方便你逐步审查安全敏感的设计决定。

尽早把重点放在 Access Control 决策上

对于 organization-best-practices for Access Control，最重要的设计问题不是“怎么创建 org”，而是“你的权限模型到底是什么”。建议尽早明确：

• 谁是 owner
• admin 是否可以邀请或移除成员
• 角色变更是否受限制
• 哪些操作是 org 作用域内的
• 个人账户和组织账户是否共存

如果这些问题一开始不定义清楚，AI 生成的代码往往会默认给出偏宽松的权限，后面再收紧会很麻烦。

一个实用的实现请求示例

尽量让请求和你的应用结构绑定，例如：

I already use Better Auth in a Next.js app. Add the organization plugin on the server and client, generate the migration command sequence, create an example authClient.organization.create call, and show how to block organization creation unless the user has a paid plan flag in their profile.

这种写法效果好，是因为它同时给出了框架上下文、当前技术栈、需要修改的代码区域，以及一条明确的策略规则。

留意最常见的采用阻碍

最常见的阻碍包括：

• 配了服务端插件，却忘了客户端插件
• 没有执行 migration，或者 migration 不完整
• 默认“自定义角色已经存在”，但并没有定义如何执行这些角色约束
• 把 org setup 误当成完整授权设计
• 没有提前确认你的产品除了顶层 org membership 之外，是否还需要 teams

这个技能能帮助你把插件连起来，但应用层的权限检查依然需要你自己定义。

什么时候这个技能够用，什么时候不够

当你需要的是一套清晰的 Better Auth organizations 基线方案，以及一条低猜测成本的接入路径时，这个技能就足够了。但如果你需要以下能力，它本身就不够：

• 完整的企业级权限矩阵
• 特定领域的合规控制
• 外部目录同步
• 高级跨租户策略组合

这类场景更适合把这个技能当作基础搭建工具，再在其上叠加你自己的授权模型。

organization-best-practices 技能 FAQ

这个技能主要是做安装配置，还是做授权设计？

两者都覆盖，但优先是安装配置。这个技能最有价值的地方，是帮你把 Better Auth 的 organization 插件正确装好，同时为 RBAC 风格的访问控制提供一个合理起点。它不能替代完整的授权架构评审。

organization-best-practices 适合新手吗？

适合，前提是你已经理解 Better Auth 的基础用法。它的步骤很具体：加服务端和客户端插件、执行迁移、验证数据表、再创建 organization。不过对于新手来说，仍然可能需要额外帮助，才能把业务规则映射成角色和权限。

为什么它比普通 AI 提示词更好？

organization-best-practices skill 的价值，在于它把 AI 的输出范围收束到 Better Auth organization 的真实工作流上。这会显著减少插件名、迁移步骤和创建流程上的歧义。普通提示词往往至少会漏掉其中一块。

它能直接支持 Access Control 场景吗？

可以，尤其适合 organization-best-practices for Access Control 这类需求：你的应用需要 owner/member 结构、邀请机制、组织限制和基于角色的行为控制。但要注意，这个技能提供的是基础框架，不是适用于所有应用的完整权限系统。

什么情况下不该用这个技能？

如果你根本没在用 Better Auth，或者你的租户模型和 organization/member/invitation 这套模式差异很大，就不建议使用。另一个不太适合的情况是：你在连基础 org 支持都还没跑通之前，就已经需要极度定制的授权语义。

我需要从这个 skill 仓库本身安装什么东西吗？

通常不需要。你更多是把这个技能当作指导，然后应用到你的 Better Auth 项目里。真正的安装工作发生在你的应用内部：配置 Better Auth 插件，并执行 npx @better-auth/cli migrate，而不是在这个 skill 目录里安装一个大型独立包。

如何改进 organization-best-practices 技能的使用效果

告诉 AI 你的策略规则，而不只是框架信息

想提升 organization-best-practices 的输出质量，最有效的方法之一，是提供真正影响治理模型的规则：

• 谁可以创建 org
• 创建后默认角色是什么
• 每个用户最多能创建多少 org
• 每个 org 的成员上限是多少
• 谁有邀请权限
• billing 或套餐状态是否会影响访问权限

这些信息对生成代码的影响，通常比你的前端框架是什么还大。

明确要求做 schema 校验

一个高价值的改进方式，是明确要求 agent 输出 migration 之后的检查清单。例如：

After setup, tell me exactly which organization, member, and invitation tables should exist and how I should verify them before testing the UI.

这样能更早发现 migration 失败，也能让输出更接近真实可执行的操作指南。

把 org 接入和应用权限拆开处理

一个常见失败模式，是把插件安装和路由级授权逻辑混在同一个 prompt 里。更好的做法是拆成两步：

• prompt 1: install and configure Better Auth organizations
• prompt 2: define app permission checks for owners, admins, and members

这样分开以后，代码会更干净，也更不容易出现 AI 自行发明抽象层的问题。

一开始就说明你的角色模型

如果你需要的不止 owner，要尽早说清楚。例如：

We need owner, admin, billing, and member. Admins can invite, billing can manage subscriptions, members cannot change org settings.

这能显著提升 organization-best-practices usage 的效果，因为 AI 可以围绕真实动作生成示例，而不是停留在泛泛的角色标签上。

第一轮完成后，再追问边界情况

在初始接入完成后，继续围绕失败路径和边界条件追问：

• 邀请被重复发送时会怎样？
• 一个用户能否加入多个 organization？
• ownership transfer 应该怎么做？
• 谁可以移除最后一个 owner？
• 达到 org 限额后应该发生什么？

这些问题，才是把 demo 推向生产可用访问模型的关键。

让生成代码贴合你当前的文件布局

另一个很实用的改进方式，是直接告诉 agent 你的 auth 代码放在哪里。例如：

My server auth config is in src/lib/auth.ts and my client auth setup is in src/lib/auth-client.ts. Update those files instead of generating new placeholders.

这样可以避免输出一堆和你仓库结构对不上的低价值样板代码。

把这个技能用来做判断，而不只是拿代码片段

organization-best-practices guide 最大的价值，不只是样例代码本身，而是帮助你在投入更多实现成本之前，先判断 Better Auth 的 organization 插件是否真的适合你的租户模型和访问控制需求。先用它验证匹配度，再在模型清晰之后要代码，通常效果最好。