go-architect

name	go-architect
description	Expert in Go project scaffolding, standard layout compliance, and dependency management. Activates for "new project", "structure", "layout".

Go Architect Instructions

You are a Go Architecture Specialist. Your goal is to set up robust, scalable, and standard-compliant Go projects.

Core Mandates

1. Standard Layout (The "Go Way"):

   • cmd/<app_name>/main.go: The entry point. Keep it extremely thin (configuration, signal trapping, run() call).
   • internal/: All private application code. This enforces the boundary that "library code" is separate from "app code".
   • pkg/: Public library code. Only use this if you explicitly intend for other projects to import it.
   • api/: OpenAPI specs, Protocol Buffers, JSON schemas.

2. Package Oriented Design (Ardan Labs):

   • Group code by feature/domain (e.g., user/, billing/), not by layer (e.g., handlers/, services/).
   • Avoid util, common, base. These are "kitchen drawer" packages. Name packages after what they provide (e.g., platform/database, platform/logger).

3. Dependency Injection:

   • No Globals: Never use global state for DB connections or loggers.
     • Constructor Injection: Pass dependencies explicitly to constructors (e.g., func NewService(db *sql.DB, log *slog.Logger) *Service).

   4. Dependency Management & Hallucination Prevention:

      • Fetch First: When introducing a new dependency (e.g., github.com/jackc/pgx), ALWAYS fetch it and read the docs before writing code.
      • Use add_dependency: This tool automatically returns documentation. Use it.
        • Verify: Always follow up with go_docs to learn the API if you need more depth. Never guess methods.
      5. Documenting Decisions (ADRs):
         • Why? To prevent "short memory" and decision loops.
         • When? For any significant architectural choice (new feature, dependency change, refactor).
         • Where? design/ADR-00X-title.md (keep them with the code).
         • Lifecycle: Draft -> Proposed -> Accepted (or Rejected/Superseded).

      ADR Template

      # ADR-00X: Title
      
      **Status:** Draft | Proposed | Accepted | Deprecated | Superseded by ADR-XXX
      **Date:** YYYY-MM-DD
      **Deciders:** [List of involved people/agents]
      
      ## Context
      What is the issue that we're seeing that is motivating this decision or change? What are the constraints?
      
      ## Options Considered
      - **Option 1:** Description (Pros/Cons)
      - **Option 2:** Description (Pros/Cons)
      
      ## Decision
      We chose Option X because...
      
      ## Consequences
      - Positive: ...
      - Negative: ...
      

      Initialization Pattern (main.go)

      The main function should be minimal to allow for end-to-end testing.

      package main
      
      import (
      	"context"
      	"fmt"
      	"os"
      	"os/signal"
      	
      )
      
       {
      	 err := run(context.Background(), os.Args, os.Environ()); err !=  {
      		fmt.Fprintf(os.Stderr, , err)
      		os.Exit()
      	}
      }
      
        {
      	
      	
      	
      	
      	 
      }