diff --git a/.agent/ARCHITECTURE.md b/.agent/ARCHITECTURE.md
index 99ca60a1b..b06314e41 100644
--- a/.agent/ARCHITECTURE.md
+++ b/.agent/ARCHITECTURE.md
@@ -9,7 +9,7 @@
 Antigravity Kit is a modular system consisting of:
 
 - **20 Specialist Agents** - Role-based AI personas
-- **36 Skills** - Domain-specific knowledge modules
+- **37 Skills** - Domain-specific knowledge modules
 - **11 Workflows** - Slash command procedures
 
 ---
@@ -37,7 +37,7 @@ Specialist AI personas for different domains.
 | `orchestrator`           | Multi-agent coordination   | parallel-agents, behavioral-modes                        |
 | `project-planner`        | Discovery, task planning   | brainstorming, plan-writing, architecture                |
 | `frontend-specialist`    | Web UI/UX                  | frontend-design, react-best-practices, tailwind-patterns |
-| `backend-specialist`     | API, business logic        | api-patterns, nodejs-best-practices, database-design     |
+| `backend-specialist`     | API, business logic        | api-patterns, nodejs-best-practices, go-pro, database-design |
 | `database-architect`     | Schema, SQL                | database-design, prisma-expert                           |
 | `mobile-developer`       | iOS, Android, RN           | mobile-design                                            |
 | `game-developer`         | Game logic, mechanics      | game-development                                         |
@@ -57,7 +57,7 @@ Specialist AI personas for different domains.
 
 ---
 
-## 🧩 Skills (36)
+## 🧩 Skills (37)
 
 Modular knowledge domains that agents can load on-demand. based on task context.
 
@@ -79,6 +79,7 @@ Modular knowledge domains that agents can load on-demand. based on task context.
 | `nestjs-expert`         | NestJS modules, DI, decorators |
 | `nodejs-best-practices` | Node.js async, modules         |
 | `python-patterns`       | Python standards, FastAPI      |
+| `go-pro`                | Go idioms, concurrency, clean arch |
 
 ### Database
 
@@ -267,7 +268,7 @@ For details, see [scripts/README.md](scripts/README.md)
 | Metric              | Value                         |
 | ------------------- | ----------------------------- |
 | **Total Agents**    | 20                            |
-| **Total Skills**    | 36                            |
+| **Total Skills**    | 37                            |
 | **Total Workflows** | 11                            |
 | **Total Scripts**   | 2 (master) + 18 (skill-level) |
 | **Coverage**        | ~90% web/mobile development   |
diff --git a/.agent/agents/backend-specialist.md b/.agent/agents/backend-specialist.md
index ad306ef7a..56624b4e5 100644
--- a/.agent/agents/backend-specialist.md
+++ b/.agent/agents/backend-specialist.md
@@ -3,7 +3,7 @@ name: backend-specialist
 description: Expert backend architect for Node.js, Python, and modern serverless/edge systems. Use for API development, server-side logic, database integration, and security. Triggers on backend, server, api, endpoint, database, auth.
 tools: Read, Grep, Glob, Bash, Edit, Write
 model: inherit
-skills: clean-code, nodejs-best-practices, python-patterns, api-patterns, database-design, mcp-builder, lint-and-validate, powershell-windows, bash-linux, rust-pro
+skills: clean-code, nodejs-best-practices, python-patterns, go-pro, api-patterns, database-design, mcp-builder, lint-and-validate, powershell-windows, bash-linux, rust-pro
 ---
 
 # Backend Development Architect
diff --git a/.agent/skills/go-pro/SKILL.md b/.agent/skills/go-pro/SKILL.md
new file mode 100644
index 000000000..2ce3cdc9b
--- /dev/null
+++ b/.agent/skills/go-pro/SKILL.md
@@ -0,0 +1,295 @@
+---
+name: go-pro
+description: Go development principles and decision-making. Idiomatic patterns, concurrency, clean architecture, project structure, testing, and performance. Teaches thinking, not copying.
+allowed-tools: Read, Write, Edit, Glob, Grep
+---
+
+# Go Pro
+
+> Go development principles and decision-making for 2025.
+> **Learn to THINK like a Go developer, not memorize syntax.**
+
+---
+
+## ⚠️ How to Use This Skill
+
+This skill teaches **decision-making principles**, not fixed code to copy.
+
+- ASK user for framework/library preference when unclear
+- Choose pattern based on PROJECT CONTEXT (scale, team, lifetime)
+- Standard Library first—add dependencies only when justified
+
+### 📁 Deep-Dive References
+
+Load these **only when the specific topic is relevant** to the user's request:
+
+| Reference | When to Load |
+|-----------|------|
+| `references/concurrency.md` | Goroutines, channels, errgroup, context patterns |
+| `references/frameworks.md` | Framework selection (net/http vs Chi vs Gin vs Fiber) |
+| `references/database.md` | ORM/driver selection, sqlc, migrations, connection pooling |
+| `references/testing.md` | Table-driven tests, benchmarks, fuzz, mocking |
+| `references/performance.md` | pprof, escape analysis, memory layout, GC tuning |
+| `references/clean-architecture.md` | Layered architecture, DI, domain-driven structure |
+| `references/api-design.md` | HTTP handlers, JSON, middleware, graceful shutdown |
+
+---
+
+## 1. Go Philosophy (Non-Negotiable)
+
+### Core Tenets
+
+```
+"Simplicity is complicated." — Rob Pike
+
+├── Clear is better than clever
+├── A little copying is better than a little dependency
+├── Don't panic (literally—avoid panic in library code)
+├── Accept interfaces, return structs
+├── Make the zero value useful
+└── Errors are values, not exceptions
+```
+
+### Standard Library First
+
+```
+Before adding a dependency, ask:
+├── Can `net/http` handle this? (Go 1.22+ has pattern routing)
+├── Can `encoding/json` handle this?
+├── Can `database/sql` handle this?
+├── Can `log/slog` handle this? (Go 1.21+ structured logging)
+└── Will this dependency survive 5 years?
+
+Add dependency ONLY when:
+├── Significant complexity reduction (e.g., sqlc, pgx)
+├── Non-trivial to implement (e.g., JWT validation)
+└── Well-maintained with clear ownership
+```
+
+---
+
+## 2. Project Structure
+
+### Decision Tree
+
+```
+How big is the project?
+│
+├── Single binary / Script / CLI tool
+│   └── Flat layout
+│       ├── main.go
+│       ├── handler.go
+│       ├── store.go
+│       └── go.mod
+│
+├── Medium service (1 team, 1 domain)
+│   └── Standard layout
+│       ├── cmd/server/main.go
+│       ├── internal/
+│       │   ├── handler/
+│       │   ├── service/
+│       │   ├── repository/
+│       │   └── model/
+│       ├── pkg/            # Only if reuse is real
+│       └── go.mod
+│
+└── Large system (multi-domain, multi-team)
+    └── Domain-driven layout
+        ├── cmd/
+        │   ├── api/main.go
+        │   └── worker/main.go
+        ├── internal/
+        │   ├── user/        # Domain package
+        │   │   ├── handler.go
+        │   │   ├── service.go
+        │   │   ├── repository.go
+        │   │   └── model.go
+        │   ├── order/       # Domain package
+        │   └── platform/    # Shared infra
+        │       ├── database/
+        │       ├── logger/
+        │       └── middleware/
+        └── go.mod
+```
+
+### Key Rules
+
+```
+├── cmd/        → Entry points ONLY (wire up, start server)
+├── internal/   → Private application code (compiler-enforced)
+├── pkg/        → Truly reusable libraries (use sparingly!)
+│
+├── NEVER put business logic in cmd/
+├── NEVER put HTTP concerns in service layer
+├── NEVER import internal/ from another module
+└── Keep main.go thin (< 50 lines ideally)
+```
+
+---
+
+## 3. Error Handling
+
+### Idiomatic Error Handling
+
+```
+Core patterns:
+├── if err != nil { return fmt.Errorf("doing X: %w", err) }
+├── Wrap errors with context using %w verb
+├── Use errors.Is() for sentinel error comparison
+├── Use errors.As() for type assertion on errors
+├── Return errors, don't panic (except truly unrecoverable)
+└── Handle errors at the right level (don't swallow!)
+
+Error wrapping chain:
+├── Repository:  fmt.Errorf("query user %d: %w", id, err)
+├── Service:     fmt.Errorf("get user profile: %w", err)
+├── Handler:     Log full error, return sanitized HTTP error
+└── Client sees: {"error": "user not found"} (no internals!)
+```
+
+### Custom Error Types
+
+```
+When to create custom errors:
+├── Need to carry structured data (error code, field name)
+├── Need to distinguish error categories (NotFound, Conflict)
+├── Need to map to HTTP status codes
+└── Shared across multiple packages
+
+When sentinel errors are enough:
+├── Simple "not found" / "already exists" cases
+├── Single package usage
+└── No extra data needed
+```
+
+### Error Design Principles
+
+```
+├── Errors should be opaque to callers (use Is/As, not string matching)
+├── Package-level sentinel: var ErrNotFound = errors.New("not found")
+├── Don't log AND return the same error (pick one per layer)
+├── Handler layer: log + return HTTP response
+├── Service layer: wrap + return
+└── Repository layer: wrap + return
+```
+
+---
+
+## 4. Interface Design
+
+### Core Principles
+
+```
+"The bigger the interface, the weaker the abstraction." — Rob Pike
+
+├── Accept interfaces, return concrete types
+├── Define interfaces where they are USED, not implemented
+├── Keep interfaces small (1-3 methods ideal)
+├── Use implicit satisfaction (no "implements" keyword needed)
+└── io.Reader / io.Writer are the gold standard
+
+Interface location:
+├── Consumer package defines the interface
+├── Producer package returns concrete struct
+├── This allows testing without mocks of the whole world
+└── Example: service/ defines Repository interface,
+    repository/ returns *PostgresRepo struct
+```
+
+---
+
+## 5. Logging & Observability
+
+### Structured Logging (Go 1.21+)
+
+```
+Use log/slog (stdlib):
+├── slog.Info("user created", "user_id", id, "email", email)
+├── Structured key-value pairs
+├── JSON output for production
+├── Text output for development
+├── Create child loggers with With()
+└── No need for zerolog/zap unless specific features needed
+
+Logging levels:
+├── Debug → Development diagnostics
+├── Info  → Normal operations
+├── Warn  → Recoverable issues
+├── Error → Failures requiring attention
+└── NEVER log sensitive data (passwords, tokens, PII)
+```
+
+---
+
+## 6. Go Modules & Dependencies
+
+```
+├── go mod init → Start new module
+├── go mod tidy → Clean up go.mod/go.sum
+├── go mod vendor → Vendor dependencies (optional)
+├── go mod verify → Verify integrity
+│
+├── Pin major versions in go.mod
+├── Review go.sum changes in code review
+├── Use govulncheck for vulnerability scanning
+├── Prefer fewer, well-maintained dependencies
+└── Check license compatibility
+```
+
+### Build & Release
+
+```
+├── go build -ldflags "-s -w" → Strip debug for smaller binary
+├── CGO_ENABLED=0 → Static binary (no C dependencies)
+├── Use multi-stage Docker builds
+├── Cross-compile: GOOS=linux GOARCH=amd64 go build
+└── Use goreleaser for automated releases
+```
+
+---
+
+## 7. Anti-Patterns to Avoid
+
+### ❌ DON'T:
+- Use `init()` for complex initialization (hard to test, surprising)
+- Use `panic` in library code (return errors instead)
+- Ignore errors with `_ = someFunc()` without explicit comment
+- Use global mutable state (use dependency injection)
+- Use `interface{}` / `any` when generics (Go 1.18+) work better
+- Import from another project's `internal/` package
+- Use Gin/Fiber for simple APIs where `net/http` suffices
+- Store `context.Context` in struct fields
+- Start goroutines without lifecycle management
+- Use `sync.Mutex` when a channel is more appropriate
+
+### ✅ DO:
+- Choose framework based on actual project needs
+- Write table-driven tests for all business logic
+- Use `context.Context` for cancellation and timeouts
+- Profile before optimizing
+- Keep interfaces small (1-3 methods)
+- Use `errgroup` for concurrent operations
+- Run `go vet`, `staticcheck`, `golangci-lint` in CI
+- Use `sqlc` or `pgx` for database interactions
+- Document exported functions and types
+- Use `go generate` for code generation workflows
+
+---
+
+## 8. Decision Checklist
+
+Before implementing:
+
+- [ ] **Asked user about framework preference?**
+- [ ] **Chosen net/http vs framework for THIS context?**
+- [ ] **Decided project structure scale?** (flat / standard / domain-driven)
+- [ ] **Planned error handling strategy?** (sentinel / custom types / wrapping)
+- [ ] **Identified concurrency needs?** (goroutines, channels, errgroup)
+- [ ] **Chosen database approach?** (raw SQL, sqlc, GORM)
+- [ ] **Planned testing strategy?** (table-driven, integration, benchmarks)
+- [ ] **Considered clean architecture necessity?** (skip if simple CRUD)
+- [ ] **Set up linting?** (golangci-lint with project config)
+
+---
+
+> **Remember**: Go's power is in its simplicity. Don't fight the language—embrace `if err != nil`, small interfaces, explicit code, and the standard library. The best Go code looks boring—and that's the point.
diff --git a/.agent/skills/go-pro/references/api-design.md b/.agent/skills/go-pro/references/api-design.md
new file mode 100644
index 000000000..0804abbc4
--- /dev/null
+++ b/.agent/skills/go-pro/references/api-design.md
@@ -0,0 +1,73 @@
+# API Design Principles
+
+> Deep-dive reference for Go HTTP API design. Load when user builds REST APIs, middleware, or JSON handlers.
+
+## HTTP Handler Patterns
+
+```
+Go 1.22+ ServeMux patterns:
+├── mux.HandleFunc("GET /users/{id}", handler.GetUser)
+├── mux.HandleFunc("POST /users", handler.CreateUser)
+├── Method + path in one string
+└── Path parameters via r.PathValue("id")
+
+Middleware chain:
+├── func Middleware(next http.Handler) http.Handler
+├── Compose: Logger(Auth(RateLimit(handler)))
+├── Use for: logging, auth, CORS, recovery, metrics
+└── Keep middleware focused (single responsibility)
+```
+
+## JSON Handling
+
+```
+Encoding/Decoding:
+├── Use json.NewDecoder(r.Body) for requests (streaming)
+├── Use json.NewEncoder(w) for responses
+├── Define struct tags: `json:"field_name,omitempty"`
+├── Use json.RawMessage for deferred parsing
+├── Limit request body size: http.MaxBytesReader
+└── Set Content-Type header: "application/json"
+
+Validation:
+├── Validate after decoding, not during
+├── Use struct tags + validator package for complex rules
+├── Return 422 for validation errors with field-level details
+└── Sanitize output (never expose internal struct fields)
+```
+
+## Response Format
+
+```
+Consistent API response:
+├── Success: { "data": {...} }
+├── Error:   { "error": { "code": "NOT_FOUND", "message": "..." } }
+├── List:    { "data": [...], "pagination": { "total": N, "page": 1 } }
+│
+├── Always return JSON (even for errors)
+├── Use appropriate HTTP status codes
+└── Include request ID in response headers
+```
+
+## Error Response Mapping
+
+| Domain Error | HTTP Status | Error Code |
+|-------------|-------------|------------|
+| Not found | 404 | `NOT_FOUND` |
+| Validation failed | 422 | `VALIDATION_ERROR` |
+| Already exists | 409 | `CONFLICT` |
+| Unauthorized | 401 | `UNAUTHORIZED` |
+| Forbidden | 403 | `FORBIDDEN` |
+| Internal error | 500 | `INTERNAL_ERROR` |
+
+## Graceful Shutdown
+
+```
+Production servers must handle shutdown:
+├── Listen for os.Signal (SIGINT, SIGTERM)
+├── Call server.Shutdown(ctx) with timeout
+├── Finish in-flight requests
+├── Close database connections
+├── Flush logs
+└── Exit cleanly
+```
diff --git a/.agent/skills/go-pro/references/clean-architecture.md b/.agent/skills/go-pro/references/clean-architecture.md
new file mode 100644
index 000000000..23a47f0c3
--- /dev/null
+++ b/.agent/skills/go-pro/references/clean-architecture.md
@@ -0,0 +1,79 @@
+# Clean Architecture in Go
+
+> Deep-dive reference for layered architecture and dependency injection in Go. Load when user designs service structure or needs DI patterns.
+
+## Layer Separation
+
+```
+Request Flow:
+│
+├── Handler (Transport Layer)
+│   ├── HTTP/gRPC specifics
+│   ├── Parse request, validate input
+│   ├── Call service method
+│   └── Format response
+│
+├── Service (Business Logic Layer)
+│   ├── Pure business rules
+│   ├── Depends on repository INTERFACES
+│   ├── No HTTP, no SQL
+│   └── Testable in isolation
+│
+├── Repository (Data Access Layer)
+│   ├── Database queries
+│   ├── Implements repository interface
+│   ├── No business logic
+│   └── Returns domain models
+│
+└── Model (Domain Layer)
+    ├── Structs representing business entities
+    ├── No dependencies on other layers
+    └── Validation methods optional
+```
+
+## Dependency Injection
+
+```
+DI in Go (no magic, no framework needed):
+├── Constructor injection via New* functions
+│   func NewUserService(repo UserRepository) *UserService
+│
+├── Wire up in cmd/main.go:
+│   db := database.Connect(cfg)
+│   userRepo := postgres.NewUserRepository(db)
+│   userService := service.NewUserService(userRepo)
+│   userHandler := handler.NewUserHandler(userService)
+│
+├── For large projects, consider google/wire
+│   (compile-time DI code generation)
+│
+└── AVOID runtime DI containers (not idiomatic Go)
+```
+
+## When Clean Architecture is Overkill
+
+```
+Skip full layering when:
+├── Simple CRUD with < 5 entities
+├── CLI tools or scripts
+├── Prototypes / POCs
+└── Single-person, short-lived projects
+
+Use full layering when:
+├── Multiple developers
+├── Complex business rules
+├── Long-lived project (> 1 year)
+├── Need to swap infrastructure
+└── Extensive testing required
+```
+
+## Directory Mapping
+
+```
+Clean architecture → Go project:
+├── Domain/Model     → internal/domain/ or internal/model/
+├── Use Cases        → internal/service/
+├── Interfaces       → internal/handler/ (HTTP), internal/grpc/ (gRPC)
+├── Infrastructure   → internal/repository/, internal/platform/
+└── Entry point      → cmd/server/main.go (wiring)
+```
diff --git a/.agent/skills/go-pro/references/concurrency.md b/.agent/skills/go-pro/references/concurrency.md
new file mode 100644
index 000000000..68c4baf2f
--- /dev/null
+++ b/.agent/skills/go-pro/references/concurrency.md
@@ -0,0 +1,74 @@
+# Concurrency Patterns
+
+> Deep-dive reference for Go concurrency. Load when user works with goroutines, channels, or parallel processing.
+
+## When to Use What
+
+| Pattern | Use When |
+|---------|----------|
+| `goroutine + channel` | Fan-out/fan-in, pipelines |
+| `sync.WaitGroup` | Wait for N goroutines to complete |
+| `errgroup.Group` | Wait + collect first error + cancel others |
+| `sync.Mutex/RWMutex` | Protect shared state |
+| `sync.Once` | One-time initialization |
+| `context.Context` | Cancellation, timeout, request-scoped values |
+
+## The Golden Rules
+
+```
+Concurrency rules:
+├── Always pass context.Context as first parameter
+├── Never start a goroutine without knowing how it will stop
+├── Use errgroup for concurrent operations that can fail
+├── Prefer channels for communication, mutexes for state
+├── Don't communicate by sharing memory—share memory by communicating
+├── Always handle context cancellation
+└── Use sync.Pool for frequently allocated objects (measure first!)
+
+Context propagation:
+├── Accept ctx in every function that does I/O
+├── Pass ctx to downstream calls
+├── Check ctx.Err() in long loops
+├── Use context.WithTimeout for external calls
+└── NEVER store context in a struct
+```
+
+## Goroutine Lifecycle
+
+```
+ALWAYS ensure goroutine cleanup:
+├── Use context for cancellation
+├── Use done channels for signaling
+├── Defer cleanup in goroutines
+├── Prevent goroutine leaks
+└── Log goroutine lifecycle in debug mode
+```
+
+## Common Patterns
+
+### Fan-Out / Fan-In
+```
+Use when: Processing N items concurrently, collecting results
+├── Spawn N goroutines (fan-out)
+├── Collect results via channel (fan-in)
+├── Use errgroup to handle errors
+└── Limit concurrency with semaphore channel
+```
+
+### Pipeline
+```
+Use when: Multi-stage data processing
+├── Each stage: goroutine reading from input channel
+├── Process → send to output channel
+├── Close output channel when input is exhausted
+└── Cancel pipeline via context
+```
+
+### Worker Pool
+```
+Use when: Rate-limiting concurrent work
+├── Fixed number of goroutines reading from job channel
+├── Results sent to result channel
+├── Backpressure via buffered channels
+└── Graceful shutdown via context cancellation
+```
diff --git a/.agent/skills/go-pro/references/database.md b/.agent/skills/go-pro/references/database.md
new file mode 100644
index 000000000..7c58ddac0
--- /dev/null
+++ b/.agent/skills/go-pro/references/database.md
@@ -0,0 +1,58 @@
+# Database Patterns
+
+> Deep-dive reference for Go database access. Load when user works with SQL, ORM, or database design.
+
+## ORM/Driver Selection
+
+| Tool | Best For |
+|------|----------|
+| `database/sql` + raw SQL | Full control, simple queries |
+| `sqlc` | Type-safe SQL → Go code generation |
+| `pgx` | PostgreSQL-specific features, performance |
+| `GORM` | Rapid prototyping, complex relations |
+| `Bun` | Modern ORM, good performance |
+| `ent` | Graph-based schema, code generation |
+
+## Database Principles
+
+```
+├── Use connection pooling (sql.DB handles this)
+├── Always use context-aware queries (QueryContext, ExecContext)
+├── Use prepared statements for repeated queries
+├── Close rows immediately: defer rows.Close()
+├── Scan into structs, not individual variables
+├── Use transactions for multi-step operations
+├── Set reasonable timeouts via context
+└── Monitor connection pool metrics
+
+sqlc recommendation (for most projects):
+├── Write SQL → Generate type-safe Go code
+├── No runtime reflection
+├── Catches SQL errors at compile time
+├── Works with PostgreSQL, MySQL, SQLite
+└── Pairs perfectly with pgx driver
+```
+
+## Migration Strategy
+
+```
+├── golang-migrate/migrate  → SQL-based, simple
+├── goose                   → SQL or Go-based
+├── atlas                   → Declarative, modern
+│
+├── ALWAYS use versioned migrations
+├── NEVER modify existing migration files
+├── Test migrations up AND down
+└── Run migrations separately from app startup
+```
+
+## Connection Pool Tuning
+
+```
+sql.DB configuration:
+├── SetMaxOpenConns()     → Match your DB max connections
+├── SetMaxIdleConns()     → ~25% of max open
+├── SetConnMaxLifetime()  → 5-15 minutes
+├── SetConnMaxIdleTime()  → 1-3 minutes
+└── Monitor with db.Stats()
+```
diff --git a/.agent/skills/go-pro/references/frameworks.md b/.agent/skills/go-pro/references/frameworks.md
new file mode 100644
index 000000000..11f5a4953
--- /dev/null
+++ b/.agent/skills/go-pro/references/frameworks.md
@@ -0,0 +1,67 @@
+# Framework Selection (2025)
+
+> Deep-dive reference for Go web framework selection. Load when user needs to choose or compare frameworks.
+
+## Decision Tree
+
+```
+What are you building?
+│
+├── API with simple routing (Go 1.22+)
+│   └── net/http (ServeMux now supports patterns!)
+│
+├── REST API with middleware needs
+│   └── Chi (lightweight, net/http compatible)
+│
+├── High-performance API / Microservice
+│   └── Gin or Echo (battle-tested, fast)
+│
+├── Maximum performance (benchmarks matter)
+│   └── Fiber (fasthttp-based, Express-like API)
+│
+├── gRPC service
+│   └── google.golang.org/grpc + protobuf
+│
+└── CLI tool
+    └── cobra + viper
+```
+
+## Comparison Principles
+
+| Factor | net/http | Chi | Gin | Fiber |
+|--------|----------|-----|-----|-------|
+| **Best for** | Simple APIs, Go 1.22+ | Composable middleware | Production REST APIs | Max throughput |
+| **Dependencies** | Zero | Minimal | Moderate | fasthttp (non-std) |
+| **net/http compatible** | ✅ | ✅ | ❌ (own context) | ❌ (fasthttp) |
+| **Middleware ecosystem** | Manual | Rich, composable | Rich, built-in | Growing |
+| **Learning curve** | Low | Low | Low | Low |
+
+## Selection Questions to Ask:
+1. Does the project need to stay net/http compatible?
+2. Is raw throughput critical (>100K req/s)?
+3. Does the team already know a specific framework?
+4. How important is the middleware ecosystem?
+
+> **Default recommendation for new projects**: `net/http` (Go 1.22+) or `Chi` for composability. Only reach for Gin/Fiber when justified.
+
+## Go 1.22+ ServeMux Patterns
+
+```
+New routing capabilities:
+├── mux.HandleFunc("GET /users/{id}", handler.GetUser)
+├── mux.HandleFunc("POST /users", handler.CreateUser)
+├── Method + path in one string
+├── Path parameters via r.PathValue("id")
+├── Precedence rules: more specific patterns win
+└── No need for Chi/Gorilla for simple routing anymore
+```
+
+## Middleware Pattern
+
+```
+Standard middleware signature:
+├── func Middleware(next http.Handler) http.Handler
+├── Compose: Logger(Auth(RateLimit(handler)))
+├── Use for: logging, auth, CORS, recovery, metrics
+└── Keep middleware focused (single responsibility)
+```
diff --git a/.agent/skills/go-pro/references/performance.md b/.agent/skills/go-pro/references/performance.md
new file mode 100644
index 000000000..5b8291d25
--- /dev/null
+++ b/.agent/skills/go-pro/references/performance.md
@@ -0,0 +1,69 @@
+# Performance
+
+> Deep-dive reference for Go performance profiling and optimization. Load when user needs to profile or optimize Go code.
+
+## Profiling First (Measure, Don't Guess)
+
+```
+Tools:
+├── go tool pprof      → CPU, memory, goroutine profiling
+├── go test -bench     → Micro-benchmarks
+├── go test -benchmem  → Memory allocation counts
+├── runtime/trace      → Execution tracer
+├── expvar / metrics   → Runtime metrics endpoint
+└── go build -gcflags="-m" → Escape analysis
+
+Common optimizations (ONLY after profiling):
+├── Reduce allocations (sync.Pool, pre-allocate slices)
+├── Use strings.Builder for string concatenation
+├── Avoid interface{}/any in hot paths
+├── Use struct embedding to reduce pointer chasing
+├── Pre-size maps and slices: make([]T, 0, expectedCap)
+├── Use io.Reader/Writer for streaming (avoid loading all into memory)
+└── Consider msgpack/protobuf over JSON for internal services
+```
+
+## Memory Layout
+
+```
+Struct field ordering matters:
+├── Group same-size fields together
+├── Larger fields first, smaller fields last
+├── Reduces padding, saves memory
+├── Use fieldalignment linter to detect issues
+└── ONLY matters at scale (millions of structs)
+```
+
+## Escape Analysis
+
+```
+Understanding heap vs stack:
+├── go build -gcflags="-m" shows escape decisions
+├── Variables that escape to heap = allocation = GC pressure
+├── Returning pointer to local variable → escapes
+├── Interface conversion → may escape
+├── Closures capturing variables → may escape
+└── Reducing escapes = reducing GC pauses
+```
+
+## Benchmark Patterns
+
+```
+Writing benchmarks:
+├── func BenchmarkXxx(b *testing.B) { for i := 0; i < b.N; i++ { ... } }
+├── Use b.ResetTimer() after setup
+├── Use b.ReportAllocs() for allocation tracking
+├── Compare with benchstat for statistical significance
+├── Run: go test -bench=. -benchmem -count=10
+└── Profile: go test -bench=. -cpuprofile=cpu.prof
+```
+
+## GC Tuning
+
+```
+├── GOGC=100 (default) — collect when heap doubles
+├── GOMEMLIMIT (Go 1.19+) — set soft memory limit
+├── Monitor with runtime.ReadMemStats()
+├── Reduce allocations > tuning GC
+└── Use sync.Pool for frequently allocated objects
+```
diff --git a/.agent/skills/go-pro/references/testing.md b/.agent/skills/go-pro/references/testing.md
new file mode 100644
index 000000000..275519d1a
--- /dev/null
+++ b/.agent/skills/go-pro/references/testing.md
@@ -0,0 +1,67 @@
+# Testing
+
+> Deep-dive reference for Go testing patterns. Load when user writes tests, benchmarks, or fuzz tests.
+
+## Table-Driven Tests (Idiomatic Go)
+
+```
+Pattern:
+├── Define test cases as slice of structs
+├── Loop through cases with t.Run(name, func)
+├── Each case: input → expected output
+├── Name each case descriptively
+├── Add edge cases and error cases
+└── Use t.Parallel() when tests are independent
+
+Benefits:
+├── Easy to add new cases
+├── Clear what's being tested
+├── Consistent structure across codebase
+└── Great for debugging (run single case)
+```
+
+## Testing Strategy
+
+| Type | Purpose | Tools |
+|------|---------|-------|
+| **Unit** | Business logic, pure functions | `testing` (stdlib) |
+| **Integration** | Database, external services | `testcontainers-go` |
+| **Benchmark** | Performance measurement | `testing.B` |
+| **Fuzz** | Input discovery (Go 1.18+) | `testing.F` |
+| **E2E** | Full API workflows | `net/http/httptest` |
+
+## Testing Principles
+
+```
+├── Use stdlib testing package first
+├── testify is OK for assertions (require/assert)
+├── Use httptest.NewServer for HTTP tests
+├── Use t.TempDir() for file-based tests
+├── Use testcontainers for real database tests
+├── Mock at interface boundaries only
+├── Benchmark before optimizing: go test -bench=.
+├── Fuzz test parsers and validators: go test -fuzz=.
+└── Use t.Helper() in test helper functions
+```
+
+## Test Organization
+
+```
+Where to put tests:
+├── Unit tests:        same package (foo_test.go)
+├── Black-box tests:   package foo_test (external perspective)
+├── Integration tests: //go:build integration tag
+├── Test fixtures:     testdata/ directory (auto-ignored by go build)
+└── Test helpers:      internal/testutil/ package
+```
+
+## Mocking Strategy
+
+```
+├── Define interfaces at consumer side
+├── Generate mocks: mockgen, moq, or hand-written
+├── Prefer hand-written fakes for simple interfaces
+├── Use mockgen for complex interfaces (many methods)
+├── NEVER mock what you don't own (wrap external deps first)
+└── Integration test > mocking when feasible
+```
diff --git a/.agent/skills/intelligent-routing/SKILL.md b/.agent/skills/intelligent-routing/SKILL.md
index 5c8814b00..4edd8ec4a 100644
--- a/.agent/skills/intelligent-routing/SKILL.md
+++ b/.agent/skills/intelligent-routing/SKILL.md
@@ -105,6 +105,7 @@ function analyzeRequest(userMessage) {
 | **Security**    | auth, login, jwt, password, hash, token    | `security-auditor`      |
 | **Frontend**    | component, react, vue, css, html, tailwind | `frontend-specialist`   |
 | **Backend**     | api, server, express, fastapi, node        | `backend-specialist`    |
+| **Go/Golang**   | go, golang, goroutine, gin, fiber, chi     | `backend-specialist`    |
 | **Mobile**      | react native, flutter, ios, android, expo  | `mobile-developer`      |
 | **Database**    | prisma, sql, mongodb, schema, migration    | `database-architect`    |
 | **Testing**     | test, jest, vitest, playwright, cypress    | `test-engineer`         |