go-design-principles

Review Go code for SOLID principle and idiomatic design violations.

Updated May 5, 2026
One-click install
npx skills add https://github.com/trypanic/skills --skill go-design-principles
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: go-design-principles
Source: https://github.com/trypanic/skills/tree/main/go-design-principles
Command: npx skills add https://github.com/trypanic/skills --skill go-design-principles

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill eliminates the risk of writing inconsistent, non-idiomatic Go code that violates core design principles, which leads to hard-to-maintain codebases, frequent bugs, and onboarding friction for team members.

Core Features & Use Cases

  • SOLID Principles Reframed for Go: Adapts classic SOLID rules (SRP, OCP, LSP, ISP, DIP) to Go's composition and interface-first paradigm, avoiding unnecessary object-oriented ceremony.
  • Idiomatic Design Guardrails: Enforces best practices including consumer-owned interfaces, forbidden generic package names (util/common/helpers), primitive type wrapping, immutability, and feature envy detection to keep code clear and maintainable.
  • Type-Driven Design Guidance: Supports creation of sealed sum-type interfaces, state machine models, and validating constructors to make illegal states unrepresentable at compile time.
  • Use Case: Use this Skill during Go code reviews, when designing new domain models or packages, or when refactoring legacy Go code to align with team design standards and reduce technical debt.

Quick Start

Request a design review of your Go package to identify violations of SOLID principles, generic naming, and feature envy, and get actionable refactoring guidance aligned with Go best practices.

Frequently Asked Questions about go-design-principles

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

FAQPage Schema
How do I apply SOLID principles in Go without object-oriented ceremony?

Apply SOLID principles in Go by adapting them to its composition and interface-first paradigm. This approach enforces consumer-owned interface design and single responsibilities without relying on traditional class inheritance, keeping codebases maintainable.

What is the best way to fix generic package names like util or common in a Go codebase?

Fix generic package names by enforcing idiomatic Go design guardrails that ban util, common, and helpers packages. Refactoring these generic names clarifies module boundaries and aligns your code with standard Go best practices.

How do I use type-driven design to make illegal states unrepresentable in Go?

Use type-driven design in Go by creating sealed sum-type interfaces, state machine models, and validating constructors. This approach enforces immutability and ensures illegal states are caught at compile time rather than causing runtime bugs.

How do I detect feature envy and primitive type wrapping issues during a Go code review?

Detect feature envy and primitive type wrapping issues by requesting a design review of your Go package. This process identifies SOLID violations and provides actionable refactoring guidance aligned with Go's idiomatic standards.

Can I use this to refactor legacy Go code to enforce team design standards?

Yes, you can refactor legacy Go code to enforce team design standards. This process resolves non-idiomatic patterns, reduces technical debt, and aligns existing packages with SDK-based error handling and immutability rules.