go-feature

Automate Go/Fiber feature development with layered tests and PostgreSQL CRUD.

3|Updated Mar 22, 2026
One-click install
npx skills add https://github.com/vndee/engineering-skills --skill go-feature
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: go-feature
Source: https://github.com/vndee/engineering-skills/tree/main/.claude/skills/go-feature
Command: npx skills add https://github.com/vndee/engineering-skills --skill go-feature

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Layer-by-layer discipline in Go/Fiber projects ensures every feature is designed, implemented, and validated across domain, application, infrastructure, and interfaces, preventing architectural drift and enabling reliable, maintainable code.

Core Features & Use Cases

  • Layer-by-layer TDD workflow: write unit tests for domain, then for application, infrastructure, and HTTP interfaces before implementing code.
  • Build inside-out approach: domain → application → infrastructure → interfaces to enforce clean boundaries.
  • Supports adding new API endpoints, business logic use cases, and CRUD operations with PostgreSQL in a clean architecture setup.
  • Enforces end-to-end test coverage across layers to reduce defects and improve maintainability.

Quick Start

Start by writing domain validation tests for the new feature, then implement the domain entity, repository interface, use case, infrastructure, and HTTP handler with tests.

Frequently Asked Questions about go-feature

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

FAQPage Schema
How do I structure a new Go Fiber API endpoint using clean architecture?

To structure a Go Fiber API endpoint with clean architecture, build inside-out from domain entities to application use cases, then infrastructure repositories, and finally HTTP interface handlers to enforce strict layer boundaries.

What is the test-driven development workflow for Go services with PostgreSQL?

The test-driven development workflow for Go services requires writing unit tests across domain, application, infrastructure, and interface layers before implementing code, ensuring PostgreSQL CRUD operations and business logic are fully validated.

How do I prevent architectural drift when adding business logic use cases in Go?

Prevent architectural drift in Go business logic by applying a layer-by-layer TDD workflow that builds from domain to application, infrastructure, and interfaces, enforcing clean boundaries and end-to-end test coverage.

Do I need to write tests for all layers when adding PostgreSQL CRUD operations in Go?

Yes, adding PostgreSQL CRUD operations in Go requires writing tests at the domain, application, infrastructure, and interface layers to reduce defects and ensure maintainable code across the clean architecture setup.

Can I use this TDD approach for existing Go Fiber projects without clean architecture?

This TDD approach is designed for clean architecture projects, requiring distinct domain, application, infrastructure, and interface layers. Existing Go Fiber projects without these boundaries would need structural refactoring before applying the workflow.