nethttp-architect

Generates a Go microservice skeleton with routing, validation, and Swiss Army knife features.

3|Updated Feb 26, 2026
One-click install
npx skills add https://github.com/ralvarezdev/ralvaskills --skill nethttp-architect
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: nethttp-architect
Source: https://github.com/ralvarezdev/ralvaskills/tree/main/skills/frameworks/nethttp-architect
Command: npx skills add https://github.com/ralvarezdev/ralvaskills --skill nethttp-architect

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Reduces boilerplate and architectural drift when building production-grade Go services with the standard library net/http, providing a clear layout, strict validation, and consistent error handling.

Core Features & Use Cases

  • Feature-based project structure with internal packages for handlers, services, repositories, and DTOs.
  • RFC 7807 compliant error handling and graceful shutdown patterns for robust production services.
  • OpenAPI generation support via getkin/kin-openapi to keep API specs in sync.

Quick Start

Create a new Go module and initialize a net/http skeleton following the feature-based layout described.

Frequently Asked Questions about nethttp-architect

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

FAQPage Schema
How do I structure a production-grade net/http service in Go?

Structure a production-grade net/http service using a feature-based internal layout with dedicated packages for handlers, services, repositories, and DTOs to reduce architectural drift and boilerplate.

How does RFC 7807 error handling work with Go stdlib ServeMux?

RFC 7807 error handling with Go stdlib ServeMux enforces consistent API error responses by applying standardized problem details, ensuring robust error communication across net/http services.

Can I generate OpenAPI specs for a Go net/http project without a framework?

Generate OpenAPI specs for Go net/http projects using the getkin/kin-openapi library, keeping API specifications in sync with your standard library ServeMux routing and DTOs.

Does this approach require a specific Go version for net/http routing?

This net/http routing approach requires Go 1.22 or later to leverage the enhanced standard library ServeMux pattern matching, with compatibility targeting Go 1.26.

What's the best way to reduce boilerplate in Go standard library services?

Reduce boilerplate in Go standard library services by adopting disciplined routing, strict validation, and graceful shutdown patterns within a feature-based project structure.

Why use net/http stdlib instead of a third-party router for Go APIs?

Use the net/http stdlib instead of third-party routers to minimize dependencies while enforcing strict validation and RFC 7807 compliant error handling natively in Go 1.22+.