- Home
- Skills
- Busirocket
- Agents Skills
- Busirocket Nextjs
busirocket-nextjs_skill
0
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill busirocket/agents-skills --skill busirocket-nextjs- SKILL.md3.2 KB
Overview
This skill provides patterns and rules for building thin, maintainable Next.js App Router route handlers (route.ts). It focuses on input validation, clear server/client boundaries, standardized JSON responses, and correct use of HTTP status codes. Use it to create or refactor API endpoints that delegate business logic to services.
How this skill works
The skill enforces a thin-handler approach: validate request data, call a service function, and return a standardized JSON response. It separates I/O and business logic out of the handler into services, uses validation helpers or schemas, and maps outcomes to proper HTTP status codes and response shapes. It also documents rules for server vs client components and serializable props.
When to use it
- Creating new app/api/**/route.ts API endpoints
- Refactoring existing route handlers to remove business logic
- Validating request inputs and preventing unvalidated output
- Standardizing JSON responses and status codes across endpoints
- Deciding or enforcing server vs client component boundaries
Best practices
- Keep handlers thin: validate, call services/, return response
- Never perform business logic or external I/O inside handlers
- Never return raw or unvalidated request input to clients
- Return { data } on success and { error: { code, message } } on error
- Use appropriate HTTP status codes (200/201/204, 4xx for client, 500 for server)
- Keep client components minimal and only when necessary; serialize props
Example use cases
- Implementing a POST /api/users route: validate body, call services/createUser, return 201 with { data }
- Refactoring a monolithic handler that reads DB directly into a thin handler + services pattern
- Adding request validation with Zod or guard helpers to protect against unknown inputs
- Creating consistent error handling middleware that maps service errors to { error } shapes
- Deciding whether a component should be server or client based on state and browser APIs
FAQ
Validation belongs at the handler boundary; use shared schemas or guard helpers and then pass validated data to services.
What response shape should I return on success?
Return a JSON object with a top-level data key, e.g. { data: ... }, and use error objects for failures.