generate-policy

hieupvXmasEve's avatarfrom hieupvXmasEve

Generates a Laravel Policy class for authorization logic. Use when adding permission checks for a model or resource (e.g., "Create a policy for the Course model").

⭐0stars🔀0forks📁View on GitHub🕐Updated Jan 6, 2026
[Code Generation]

When & Why to Use This Skill

This Claude skill automates the creation of Laravel Policy classes to streamline authorization logic and access control. By generating standardized boilerplate code for model-level permissions, it ensures that PHP developers can quickly implement secure, consistent, and modular authorization checks following Laravel best practices.

Use Cases

  • Securing new resources: Rapidly generate a Policy class for a specific model (e.g., 'Course' or 'Invoice') to define granular access rights for viewing, creating, and updating records.
  • Implementing modular authorization: Automatically place Policy files within specific module directories (e.g., app/Modules/Academic/Policies) with correct namespaces for clean architecture.
  • Standardizing permission checks: Use the generated boilerplate to consistently apply Laravel's '$user->can()' logic across various CRUD actions like 'viewAny', 'restore', and 'forceDelete'.
  • Enforcing model ownership: Easily extend the generated code to include ownership checks, ensuring users can only modify resources they created (e.g., $user->id === $model->user_id).
namegenerate-policy
descriptionGenerates a Laravel Policy class for authorization logic. Use when adding permission checks for a model or resource (e.g., "Create a policy for the Course model").
allowed-toolsWrite, Read

Generate Policy

This skill generates a standard Laravel Policy class to handle authorization, typically placed within a Module.

Instructions

  1. Identify Parameters:

    • Module: (e.g., Academic, Identity). If unsure, ask or infer from the Model location.
    • Model: The model being protected (e.g., Course).
    • Permissions: Identify standard permission names (e.g., course.view, course.create, course.update, course.delete).

  2. Determine Path:

    • app/Modules/{Module}/Policies/{Model}Policy.php

  3. Generate Code:

    • Namespace: App\Modules\{Module}\Policies
    • Methods: viewAny, view, create, update, delete, restore, forceDelete.
    • Logic: Use $user->can('permission_name').
    • Strict typing: User $user, Model $model.

Template

<?php

namespace App\Modules\Academic\Policies;

use App\Models\User;
use App\Modules\Academic\Models\Course;
use Illuminate\Auth\Access\HandlesAuthorization;

class CoursePolicy
{
    use HandlesAuthorization;

    /**
     * Determine whether the user can view any models.
     */
    public function viewAny(User $user): bool
    {
        return $user->can('course.view');
    }

    /**
     * Determine whether the user can view the model.
     */
    public function view(User $user, Course $course): bool
    {
        return $user->can('course.view');
    }

    /**
     * Determine whether the user can create models.
     */
    public function create(User $user): bool
    {
        return $user->can('course.create');
    }

    /**
     * Determine whether the user can update the model.
     */
    public function update(User $user, Course $course): bool
    {
        return $user->can('course.update');
    }

    /**
     * Determine whether the user can delete the model.
     */
    public function delete(User $user, Course $course): bool
    {
        return $user->can('course.delete');
    }
}

Best Practices

  • Granular Permissions: Avoid generic admin checks if possible; use specific permissions like course.view.
  • Model Ownership: If a user can only edit their own records, add $user->id === $model->user_id.
  • Registration: Remind the user to register the policy in the AuthServiceProvider or the Module's ServiceProvider if auto-discovery doesn't work.