Token导航 LogoToken导航TokenDH.com
研究检索只读github未标认证来源可访问clear审计通过

epic-permissions史诗权限

Agent Skill

epic-permissions 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

371

周安装

15

GitHub Stars

5,492

下载量

116
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:epic-permissions(史诗权限)
来源仓库:https://github.com/epicweb-dev/epic-stack
仓库路径:skills/epic-permissions
安装命令:
npx skills add https://github.com/epicweb-dev/epic-stack --skill epic-permissions
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/epicweb-dev/epic-stack --skill epic-permissions

简介

Epic 权限技能实现基于角色的访问控制(RBAC),支持细粒度权限划分和服务器端校验机制。

  • 适合需要限制路由访问、实施“拥有者 vs 任意用户”权限模型或动态调整角色策略的应用。
  • 所有权限判断必须显式编码,禁止依赖隐式规则或隐藏逻辑绕过安全检查。
  • 安装命令为 npx skills add https://github.com/epicweb-dev/epic-stack --skill epic-permissions。
  • 生产环境中应定期审计权限分配,确保遵循最小权限原则并及时回收冗余授权。

SKILL.md

Epic Stack: Permissions

When to use this skill

Use this skill when you need to:

  • Implement role-based access control (RBAC)
  • Validate permissions on server-side or client-side
  • Create new permissions or roles
  • Restrict access to routes or actions
  • Implement granular permissions (own vs any)

Patterns and conventions

Permissions Philosophy

Following Epic Web principles:

Explicit is better than implicit - Always explicitly check permissions. Don't assume a user has access based on implicit rules or hidden logic. Every permission check should be visible and clear in the code.

Example - Explicit permission checks:

// ✅ Good - Explicit permission check
export async function action({ request }: Route.ActionArgs) {
	const userId = await requireUserId(request)

	// Explicitly check permission - clear and visible
	await requireUserWithPermission(request, 'delete:note:own')

	// Permission check is explicit and obvious
	await prisma.note.delete({ where: { id: noteId } })
}

// ❌ Avoid - Implicit permission check
export async function action({ request }: Route.ActionArgs) {
	const userId = await requireUserId(request)
	const note = await prisma.note.findUnique({ where: { id: noteId } })

	// Implicit check - not clear what permission is being checked
	if (note.ownerId !== userId) {
		throw new Response('Forbidden', { status: 403 })
	}
	// What permission does this represent? Not explicit
}

Example - Explicit permission strings:

// ✅ Good - Explicit permission string
const permission: PermissionString = 'delete:note:own'
// Clear: action (delete), entity (note), access (own)

await requireUserWithPermission(request, permission)

// ❌ Avoid - Implicit or unclear permissions
const canDelete = checkUserCanDelete(user, note)
// What permission is this checking? Not explicit

RBAC Model

Epic Stack uses an RBAC (Role-Based Access Control) model where:

  • Users have Roles
  • Roles have Permissions
  • A user's permissions are the union of all permissions from their roles

Permission Structure

Permissions follow the format: action:entity:access

Components:

  • action: The allowed action (create, read, update, delete)
  • entity: The entity being acted upon (user, note, etc.)
  • access: The access level (own, any, own,any)

Examples:

  • create:note:own - Can create own notes
  • read:note:any - Can read any note
  • delete:user:any - Can delete any user (admin)
  • update:note:own - Can update only own notes

Prisma Schema

Models:

model Permission {
  id          String @id @default(cuid())
  action      String // e.g. create, read, update, delete
  entity      String // e.g. note, user, etc.
  access      String // e.g. own or any
  description String @default("")

  roles Role[]

  @@unique([action, entity, access])
}

model Role {
  id          String @id @default(cuid())
  name        String @unique
  description String @default("")

  users       User[]
  permissions Permission[]
}

model User {
  id    String @id @default(cuid())
  // ...
  roles Role[]
}

Validate Permissions Server-Side

Require specific permission:

import { requireUserWithPermission } from '#app/utils/permissions.server.ts'

export async function action({ request }: Route.ActionArgs) {
	const userId = await requireUserWithPermission(
		request,
		'delete:note:own', // Throws 403 error if doesn't have permission
	)

	// User has the permission, continue...
}

Require specific role:

import { requireUserWithRole } from '#app/utils/permissions.server.ts'

export async function loader({ request }: Route.LoaderArgs) {
	const userId = await requireUserWithRole(request, 'admin')

	// User has admin role, continue...
}

Conditional permissions (own vs any) - explicit:

export async function action({ request }: Route.ActionArgs) {
	const userId = await requireUserId(request)

	// Explicitly determine ownership
	const note = await prisma.note.findUnique({
		where: { id: noteId },
		select: { ownerId: true },
	})

	const isOwner = note.ownerId === userId

	// Explicitly check the appropriate permission based on ownership
	await requireUserWithPermission(
		request,
		isOwner ? 'delete:note:own' : 'delete:note:any', // Explicit permission string
	)

	// Permission check is explicit and clear
	// Proceed with deletion...
}

Validate Permissions Client-Side

Check if user has permission:

import { userHasPermission, useOptionalUser } from '#app/utils/user.ts'

export default function NoteRoute({ loaderData }: Route.ComponentProps) {
	const user = useOptionalUser()
	const isOwner = user?.id === loaderData.note.ownerId

	const canDelete = userHasPermission(
		user,
		isOwner ? 'delete:note:own' : 'delete:note:any',
	)

	return (
		<div>
			{canDelete && (
				<button onClick={handleDelete}>Delete</button>
			)}
		</div>
	)
}

Check if user has role:

import { userHasRole } from '#app/utils/user.ts'

export default function AdminRoute() {
	const user = useOptionalUser()
	const isAdmin = userHasRole(user, 'admin')

	if (!isAdmin) {
		return <div>Access Denied</div>
	}

	return <div>Admin Panel</div>
}

Create New Permissions

En Prisma Studio o seed:

// prisma/seed.ts
await prisma.permission.create({
	data: {
		action: 'create',
		entity: 'post',
		access: 'own',
		description: 'Can create their own posts',
		roles: {
			connect: { name: 'user' },
		},
	},
})

Permiso con múltiples niveles de acceso:

await prisma.permission.createMany({
	data: [
		{
			action: 'read',
			entity: 'post',
			access: 'own',
			description: 'Can read own posts',
		},
		{
			action: 'read',
			entity: 'post',
			access: 'any',
			description: 'Can read any post',
		},
	],
})

Assign Roles to Users

When creating user:

const user = await prisma.user.create({
	data: {
		email,
		username,
		roles: {
			connect: { name: 'user' }, // Assign 'user' role
		},
	},
})

Assign multiple roles:

await prisma.user.update({
	where: { id: userId },
	data: {
		roles: {
			connect: [{ name: 'user' }, { name: 'moderator' }],
		},
	},
})

Permissions and Roles Seed

Seed example:

// prisma/seed.ts

// Create permissions
const permissions = await Promise.all([
	// User permissions
	prisma.permission.create({
		data: {
			action: 'create',
			entity: 'note',
			access: 'own',
			description: 'Can create own notes',
		},
	}),
	prisma.permission.create({
		data: {
			action: 'read',
			entity: 'note',
			access: 'own',
			description: 'Can read own notes',
		},
	}),
	prisma.permission.create({
		data: {
			action: 'update',
			entity: 'note',
			access: 'own',
			description: 'Can update own notes',
		},
	}),
	prisma.permission.create({
		data: {
			action: 'delete',
			entity: 'note',
			access: 'own',
			description: 'Can delete own notes',
		},
	}),
	// Admin permissions
	prisma.permission.create({
		data: {
			action: 'delete',
			entity: 'user',
			access: 'any',
			description: 'Can delete any user',
		},
	}),
])

// Create roles
const userRole = await prisma.role.create({
	data: {
		name: 'user',
		description: 'Standard user',
		permissions: {
			connect: permissions.slice(0, 4).map((p) => ({ id: p.id })),
		},
	},
})

const adminRole = await prisma.role.create({
	data: {
		name: 'admin',
		description: 'Administrator',
		permissions: {
			connect: permissions.map((p) => ({ id: p.id })),
		},
	},
})

Permission Type

Type-safe permission strings:

import { type PermissionString } from '#app/utils/user.ts'

// Tipo: 'create:note:own' | 'read:note:own' | etc.
const permission: PermissionString = 'delete:note:own'

Parsear permission string:

import { parsePermissionString } from '#app/utils/user.ts'

const { action, entity, access } = parsePermissionString('delete:note:own')
// action: 'delete'
// entity: 'note'
// access: ['own']

Common examples

Example 1: Proteger action con permiso

// app/routes/users/$username/notes/$noteId.tsx
export async function action({ request }: Route.ActionArgs) {
	const userId = await requireUserId(request)
	const formData = await request.formData()
	const { noteId } = Object.fromEntries(formData)

	const note = await prisma.note.findFirst({
		select: { id: true, ownerId: true, owner: { select: { username: true } } },
		where: { id: noteId },
	})

	if (!note) {
		throw new Response('Not found', { status: 404 })
	}

	const isOwner = note.ownerId === userId

	// Validate permiso según si es propietario o no
	await requireUserWithPermission(
		request,
		isOwner ? 'delete:note:own' : 'delete:note:any',
	)

	await prisma.note.delete({ where: { id: note.id } })

	return redirect(`/users/${note.owner.username}/notes`)
}

Example 2: Mostrar UI condicional basada en permisos

export default function NoteRoute({ loaderData }: Route.ComponentProps) {
	const user = useOptionalUser()
	const isOwner = user?.id === loaderData.note.ownerId

	const canDelete = userHasPermission(
		user,
		isOwner ? 'delete:note:own' : 'delete:note:any',
	)
	const canEdit = userHasPermission(
		user,
		isOwner ? 'update:note:own' : 'update:note:any',
	)

	return (
		<div>
			<h1>{loaderData.note.title}</h1>
			<p>{loaderData.note.content}</p>

			{(canEdit || canDelete) && (
				<div className="flex gap-2">
					{canEdit && (
						<Link to="edit">
							<Button>Edit</Button>
						</Link>
					)}
					{canDelete && (
						<DeleteNoteButton noteId={loaderData.note.id} />
					)}
				</div>
			)}
		</div>
	)
}

Example 3: Ruta solo para admin

// app/routes/admin/users.tsx
export async function loader({ request }: Route.LoaderArgs) {
	await requireUserWithRole(request, 'admin')

	const users = await prisma.user.findMany({
		select: {
			id: true,
			email: true,
			username: true,
		},
	})

	return { users }
}

export default function AdminUsersRoute({ loaderData }: Route.ComponentProps) {
	return (
		<div>
			<h1>All Users</h1>
			{loaderData.users.map(user => (
				<div key={user.id}>{user.username}</div>
			))}
		</div>
	)
}

Example 4: Create new permission and assign it

// Migración o seed
async function setupPostPermissions() {
	// Create post permissions
	const createOwn = await prisma.permission.create({
		data: {
			action: 'create',
			entity: 'post',
			access: 'own',
			description: 'Can create own posts',
		},
	})

	const readAny = await prisma.permission.create({
		data: {
			action: 'read',
			entity: 'post',
			access: 'any',
			description: 'Can read any post',
		},
	})

	// Assign to user role
	await prisma.role.update({
		where: { name: 'user' },
		data: {
			permissions: {
				connect: [{ id: createOwn.id }, { id: readAny.id }],
			},
		},
	})
}

Common mistakes to avoid

  • Implicit permission checks: Always explicitly check permissions - make permission requirements visible in code
  • Not validating permissions on server-side: Always validate permissions in action/loader, never trust client-side only
  • Forgetting to verify own vs any: Explicitly determine if user is owner before validating permission
  • Not using correct helpers: Use requireUserWithPermission for server-side and userHasPermission for client-side - explicit helpers
  • Not creating unique permissions: Use @@unique([action, entity, access]) in schema - explicit permission structure
  • Assuming permissions instead of verifying: Always verify explicitly, even if you think user has the permission
  • Not handling 403 errors: Helpers throw errors that must be handled by ErrorBoundary
  • Not using types: Use PermissionString type for type-safety - explicit types
  • Hidden permission logic: Don't hide permission checks in utility functions - make them explicit at the call site

References

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Claude Code

26.93%
按下载量换算31

OpenCode

21.37%
按下载量换算25

Gemini CLI

15.93%
按下载量换算18

windsurf

13.26%
按下载量换算15

Antigravity

8.18%
按下载量换算9

github-copilot

3.64%
按下载量换算4

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。

来源信息

继续浏览同类 Skills