From laravel-api-tool-kit
Builds production-grade Laravel REST APIs using essa/api-tool-kit patterns (ApiResponse, QueryFilters, dynamicPaginate, EnumHelpers) and best practices for code quality, auth, testing, database.
npx claudepluginhub ahmedesa/laravel-api-tool-kitThis skill uses the workspace's default tool permissions.
This project uses the `essa/api-tool-kit` package. All API code MUST follow the standards in this skill — both the general Laravel best practices and the package-specific patterns.
knowledge/_TEMPLATE.mdrules/actions.mdrules/anti-patterns.mdrules/authorization.mdrules/code-quality.mdrules/controllers.mdrules/database.mdrules/ddd.mdrules/dependency-injection.mdrules/dtos.mdrules/enums.mdrules/events.mdrules/exceptions.mdrules/filters.mdrules/jobs.mdrules/models.mdrules/pagination.mdrules/repositories.mdrules/requests.mdrules/resources.mdProvides production-grade, idiomatic Laravel solutions with clean architecture, security best practices, performance optimizations, and modern standards for Laravel 10/11+. Use for features, refactoring, APIs, auth, services, DB interactions, and code reviews.
Build RESTful APIs with Laravel using API Resources, Sanctum authentication, rate limiting, and versioning. Use when creating API endpoints, transforming responses, or handling API authentication.
Provides Laravel knowledge base on architecture, DDD integration, Eloquent persistence, service container, security, queues, events, testing, and antipatterns for scalable PHP projects.
Share bugs, ideas, or general feedback.
This project uses the essa/api-tool-kit package. All API code MUST follow the standards in this skill — both the general Laravel best practices and the package-specific patterns.
essa/api-tool-kit is installed via ComposerController already uses the ApiResponse traitdateTimeFormat() global helper is availabledynamicPaginate() macro is registered on the query builderFill these in when installing the skill. The AI reads this section to match existing project conventions.
ulid ← change to id if this project uses auto-incrementsanctum ← change if different (e.g. api)Tests\TestCase ← change if the project uses a custom baseThe rules in the rules/ directory are pattern-based. While examples use standard Laravel paths (e.g., app/Models), they are designed to be mapped to any structure.
If the project uses a DDD structure, the rules apply to the corresponding domain folders. Folder naming may vary by project (e.g., Repository vs Repositories). Examples include:
app/Domain/{Domain}/Models/app/Domain/{Domain}/Actions/app/Domain/{Domain}/Repository/ (or Repositories/)app/Domain/{Domain}/DTO/ (or DTOs/)app/Domain/{Domain}/Filters/Note for AI: Always run ls app/Domain/ to identify the project's specific naming conventions before creating new files. Priority is always: Project Patterns > Global Rules.
If a specific project requires overrides (e.g., "We use id instead of ulid" or "We return raw arrays instead of DTOs"), do not modify these global rules. Instead:
AGENTS.md, CLAUDE.md, or .claude/rules/ for Claude Code).Before reading anything else, these rules apply universally:
declare(strict_types=1);private readonly promotiontrans() — never hardcodedSee rules/code-quality.md for the full baseline.
When working on a specific concern, read the corresponding rule file:
| Task | Read |
|---|---|
| Code style, types, naming, constants | rules/code-quality.md |
| Injecting dependencies | rules/dependency-injection.md |
| Events and listeners | rules/events.md |
| Standalone queued jobs | rules/jobs.md |
| Authorization and policies | rules/authorization.md |
| Error and exception handling | rules/exceptions.md |
| Writing feature tests | rules/testing.md |
| Database patterns, ULIDs, transactions, bulk ops | rules/database.md |
| External 3rd-party integrations | rules/services.md |
| DDD structure, domain boundaries, cross-domain rules | rules/ddd.md |
| Task | Read |
|---|---|
| Return a JSON response | rules/responses.md |
| Add filtering / sorting / search to an endpoint | rules/filters.md |
| Create a new Action class | rules/actions.md |
| Create a DTO for an Action or Service | rules/dtos.md |
| Write or review a Controller | rules/controllers.md |
| Write a FormRequest | rules/requests.md |
| Write an API Resource | rules/resources.md |
| Create or update a Model | rules/models.md |
| Create or update a Repository | rules/repositories.md |
| Create an Enum | rules/enums.md |
| Add pagination | rules/pagination.md |
| Task | Read |
|---|---|
| Before writing any code | rules/anti-patterns.md |
Follow workflows/new-endpoint.md for the full step-by-step process.
The order is always: Model → Migration → Filter → Enum → Requests → Resource → Policy → Action (if needed) → Controller → Language file → Route → Test
workflows/new-endpoint.md — add a complete CRUD resource from scratchworkflows/add-filter.md — add filtering to an existing modelworkflows/write-tests.md — write tests for any feature (decides test type, structure, actors, edge cases)workflows/code-review.md — multi-phase code review (structural + defense + scope discipline)workflows/investigate.md — structured debugging (data-first, multi-source, 15-min checkpoint)workflows/curl-test.md — test an endpoint with curl and cross-reference response vs DBworkflows/update-knowledge.md — save learnings into rules or knowledge filesworkflows/organize-knowledge.md — consolidate scattered docs into one-file-per-featureworkflows/create-workflow.md — capture a discovered process as a reusable workflowPer-feature accumulated knowledge lives in a knowledge/ directory. The exact location depends on your AI tool:
.claude/knowledge/[feature].md.agent/knowledge/[feature].mdknowledge/[feature].md (project root)Each file contains:
When investigating a bug, check knowledge/ first. When confirming a root cause, update knowledge/ before closing the session.