mcpField
S
solid-go

solid-go

github.com/fusengineDevelopment3439 installsUpdated 2w ago
Repository

About solid-go

solid-go is a coding skill for Go projects that guides agents in applying modular architecture and SOLID principles. It specifies code organization, reuse checks, interface conventions, and implementation workflow.

Key features

  1. 01Feature-based internal modules
  2. 02Shared core for reusable code
  3. 03DRY checks before implementation
  4. 04Small interfaces in ports directories
  5. 05Templates for modules and tests

Use cases

  1. 01Organizing a new Go feature
  2. 02Checking for reusable services before coding
  3. 03Scaffolding handlers, services, and tests

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/fusengine/claude-plugins --skill solid-go

After installing, type/solid-goin Claude Code to confirm it loaded.

Details

From the project README
SOLID Go enforces a modular architecture for Go 1.27+: every feature lives under `internal/modules/[feature]/` (handlers, services, repositories, ports, models) with shared code in `internal/core/`, interfaces (ports) live only in `ports/` directories and stay small (1-3 methods, the Go idiom), functions accept interfaces but return structs, and every exported function carries a godoc comment.

Before writing any new code it requires a DRY check against internal/core/services and internal/core/ports. See solid-principles.md for the overview, the per-principle references for SRP/OCP/LSP/ISP/DIP detail, architecture-patterns.md for hexagonal/modular layout, and the templates for module/service/interface/handler/error/test scaffolding.

SOLID Go - Modular Architecture

Agent Workflow (MANDATORY)

Before ANY implementation, spawn 3 agents in parallel, one Agent call each with a name:

  1. fuse-ai-pilot:explore-codebase - Analyze existing architecture
  2. fuse-ai-pilot:research-expert - Verify Go docs via Context7
  3. fuse-ai-pilot:sniper - Post-implementation validation

DRY - Reuse Before Creating (MANDATORY)

Before writing ANY new code:

  1. Grep the codebase for similar interfaces, services, or logic
  2. Check shared locations: internal/core/services/, internal/core/ports/
  3. If similar code exists -> extend/reuse instead of duplicate
  4. If code will be used by 2+ features -> create it in internal/core/

Architecture (Modules MANDATORY)

LayerLocation
Handlersinternal/modules/[feature]/handlers/
Servicesinternal/modules/[feature]/services/
Repositoriesinternal/modules/[feature]/repositories/
Ports (interfaces)internal/modules/[feature]/ports/
Modelsinternal/modules/[feature]/models/
Sharedinternal/core/{services,ports,models}/

NEVER use flat internal/ structure - always internal/modules/[feature]/


Critical Rules (MANDATORY)

RuleValue
File limitFUSE_SOLID_MAX_LINES
HandlersThin, delegate to services
Interfacesports/ directory ONLY
GodocEvery exported function documented
Accept interfacesReturn structs
Small interfaces1-3 methods max (Go idiom)

Reference Guide

Concepts
TopicReferenceWhen to consult
SOLID Overviewsolid-principles.mdQuick reference
SRPsingle-responsibility.mdFat structs
OCPopen-closed.mdAdding providers
LSPliskov-substitution.mdContracts
ISPinterface-segregation.mdFat interfaces
DIPdependency-inversion.mdInjection
Architecturearchitecture-patterns.mdHex/modular
Templates
TemplateWhen to use
module.mdFeature module structure
service.mdBusiness logic service
interface.mdPort definition
handler.mdHTTP handler
error.mdCustom errors
test.mdTable-driven tests

Forbidden

Anti-PatternFix
Files over FUSE_SOLID_MAX_LINESSplit by responsibility
Interfaces in impl filesMove to ports/ directory
Fat interfaces (4+ methods)Split into small interfaces
Flat internal/ structureUse internal/modules/[feature]/
init() for dependency wiringUse constructor injection

Comments

Markdown supported