new-handler

Create HTTP API endpoints with hexagonal architecture conventions.

Updated Mar 25, 2026
One-click install
npx skills add https://github.com/guarzo/slabledger --skill new-handler
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: new-handler
Source: https://github.com/guarzo/slabledger/tree/main/.claude/skills/new-handler
Command: npx skills add https://github.com/guarzo/slabledger --skill new-handler

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Enables teams to add a new HTTP API endpoint following the hexagonal architecture pattern, ensuring clean separation between adapters, domain services, and routing.

Core Features & Use Cases

  • Handler placement: add the new endpoint logic to the appropriate internal/adapters/httpserver/handlers/{domain}.go file.
  • Route wiring: register the new route in internal/adapters/httpserver/routes.go with the correct authentication level.
  • Data contracts & testing: define request/response types, implement handler tests using domain services, and utilize mocks for isolation.
  • Consistency & safety: ensure handlers delegate to domain services and avoid direct database access.

Quick Start

Create a new HTTP API endpoint following the hexagonal architecture pattern by adding a new handler, wiring its route, and implementing tests.

Frequently Asked Questions about new-handler

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new HTTP API endpoint in a Go hexagonal architecture project?

Adding a new HTTP API endpoint in Go hexagonal architecture involves placing handler logic in internal/adapters/httpserver/handlers/{domain}.go, wiring routes in routes.go, and defining request/response types to ensure separation between adapters and domain services.

What is the correct way to wire routes for an HTTP handler in a Go backend service?

Wiring routes for an HTTP handler requires registering the new endpoint in internal/adapters/httpserver/routes.go with the correct authentication level, ensuring handlers delegate to domain services and avoid direct database access.

How should I test an HTTP handler using domain services and mocks in Go?

Testing an HTTP handler using domain services and mocks involves implementing handler tests that utilize mocks for isolation, ensuring handlers delegate to domain services rather than accessing the database directly.

Does this approach support backend services organized into adapters, domains, and routes?

Yes, this approach specifically supports backend services organized into adapters, domains, and routes by guiding how to structure handlers, route wiring, and tests across domains while enforcing conventions for dependency wiring.

Why should HTTP handlers avoid direct database access in a hexagonal architecture?

HTTP handlers should avoid direct database access in hexagonal architecture to maintain clean separation between adapters and domain services, ensuring handlers delegate to domain services instead of coupling directly with the database.