chore: align to latest Way conventions

- AGENTS.md
- Skills
- Formatters

Author: odsod

.agents/skills/agents-md/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: agents-md
+description: This skill should be used when the user asks to "create AGENTS.md", "update AGENTS.md", "maintain agent docs", "set up CLAUDE.md", or needs to keep agent instructions concise. Guides discovery of local skills and enforces minimal documentation style.
+---
+
+# Maintaining AGENTS.md
+
+AGENTS.md is the canonical agent-facing documentation. Keep it minimal—agents are capable and don't need hand-holding.
+
+## File Setup
+
+1. Create `AGENTS.md` at project root
+2. Create symlink: `ln -s AGENTS.md CLAUDE.md`
+
+## Before Writing
+
+Discover local skills to reference:
+
+```bash
+find .claude/skills -name "SKILL.md" 2>/dev/null
+ls plugins/*/skills/*/SKILL.md 2>/dev/null
+```
+
+Read each skill's frontmatter to understand when to reference it.
+
+## Writing Rules
+
+- **Headers + bullets** - No paragraphs
+- **Code blocks** - For commands and templates
+- **Reference, don't duplicate** - Point to skills: "Use `db-migrate` skill. See `.claude/skills/db-migrate/SKILL.md`"
+- **No filler** - No intros, conclusions, or pleasantries
+- **Trust capabilities** - Omit obvious context
+
+## Required Sections
+
+### Package Manager
+Which tool and key commands only:
+```markdown
+## Package Manager
+Use **pnpm**: `pnpm install`, `pnpm dev`, `pnpm test`
+```
+
+### Commit Attribution
+Always include this section. Agents should use their own identity:
+```markdown
+## Commit Attribution
+AI commits MUST include:
+```
+Co-Authored-By: (the agent model's name and attribution byline)
+```
+Example: `Co-Authored-By: Claude Sonnet 4 <noreply@example.com>`
+```
+
+### Key Conventions
+Project-specific patterns agents must follow. Keep brief.
+
+### Local Skills
+Reference each discovered skill:
+```markdown
+## Database
+Use `db-migrate` skill for schema changes. See `.claude/skills/db-migrate/SKILL.md`
+
+## Testing
+Use `write-tests` skill. See `.claude/skills/write-tests/SKILL.md`
+```
+
+## Optional Sections
+
+Add only if truly needed:
+- API route patterns (show template, not explanation)
+- CLI commands (table format)
+- File naming conventions
+
+## Anti-Patterns
+
+Omit these:
+- "Welcome to..." or "This document explains..."
+- "You should..." or "Remember to..."
+- Content duplicated from skills (reference instead)
+- Obvious instructions ("run tests", "write clean code")
+- Explanations of why (just say what)
+- Long prose paragraphs
+
+## Example Structure
+
+```markdown
+# Agent Instructions
+
+## Package Manager
+Use **pnpm**: `pnpm install`, `pnpm dev`
+
+## Commit Attribution
+AI commits MUST include:
+```
+Co-Authored-By: (the agent model's name and attribution byline)
+```
+
+## API Routes
+[Template code block]
+
+## Database
+Use `db-migrate` skill. See `.claude/skills/db-migrate/SKILL.md`
+
+## Testing
+Use `write-tests` skill. See `.claude/skills/write-tests/SKILL.md`
+
+## CLI
+| Command | Description |
+|---------|-------------|
+| `pnpm cli sync` | Sync data |
+```

.agents/skills/way-go-style/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: way-go-style
+description: Guide for writing idiomatic, effective, and standard Go code. Use this skill when writing, refactoring, or reviewing Go code to ensure adherence to established conventions and best practices.
+---
+
+# Way Go Style
+
+## Project Setup (AGENTS.md)
+
+Go projects MUST include this skill's **Way Specific Conventions** in their `AGENTS.md` file to ensure compliance.
+
+1.  **Reference this skill**: Under "Local Skills".
+2.  **Copy Conventions**: Copy the **Way Specific Conventions** section below into `AGENTS.md` under "Key Conventions".
+
+## Way Specific Conventions
+
+- **Testing**: Use standard `testing` and `github.com/google/go-cmp/cmp` **only**. No frameworks (Testify, Ginkgo, etc.).
+- **Linting**: Run `GolangCI-Lint` v2. Configure via project-specific `.golangci.yml`.
+- **Build**: Use `way-magefile` skill.
+- **Encore**: Use `encore-go-*` skills. Encore conventions (e.g., globals) take precedence.
+
+## Overview
+
+This skill provides a condensed reference for writing high-quality Go code, synthesizing advice from "Effective Go", Google's "Code Review Comments", and other authoritative sources. It focuses on idiomatic usage, correctness, and maintainability.
+
+## Effective Go Idioms
+
+Critical idioms from [Effective Go](references/effective_go.html).
+
+### Control Flow & Error Handling
+- **Defer Evaluation:** Arguments to deferred functions are evaluated **immediately** at the call site (not at execution).
+- **Init Scope:** Use `if err := f(); err != nil` to restrict variable scope.
+- **Switch:** Use tagless `switch { case condition: ... }` instead of long `if-else` chains.
+- **Internal Panic/Recover:** Use `panic` to simplify deep error handling in complex internal code (e.g., parsers), but **always** `recover` at the package boundary to return a standard `error`.
+
+### Types & Interfaces
+- **Functional Adapters:** Define methods on function types (e.g., `type MyFunc func()`) to satisfy interfaces. See `http.HandlerFunc`.
+- **Interface Verification:** Use a global blank assignment to ensure a type satisfies an interface at compile time: `var _ Interface = (*Type)(nil)`.
+
+## Google Style Decisions & Best Practices
+
+Key decisions from the [Google Go Style Guide](references/google/index.md) and [Code Review Comments](references/CodeReviewComments.md).
+
+### Core Principles
+- **Clarity:** "Clear to the reader" is priority #1. Explain *why*, not just *what*.
+- **Simplicity:** "Least Mechanism". Prefer core constructs (slices, maps) over complex abstractions.
+- **Concision:** High signal-to-noise ratio. Avoid boilerplate.
+
+### Naming & Structure
+- **Packages:** Single-word, lowercase (e.g., `task`, not `task_manager`). **Avoid** `util`, `common`.
+- **Receivers:** 1-2 letter abbreviations (e.g., `c` for `Client`). **NEVER** use `me`, `this`, `self`.
+- **Constants:** Always `MixedCaps` (e.g., `MaxLength`), even if exported. **NEVER** `MAX_LENGTH`.
+- **Getters:** `Owner()` (not `GetOwner`).
+- **Interfaces:** One-method interfaces -> `Method` + `-er` (e.g., `Reader`). Define in the **consumer** package. Keep them small.
+
+### Functions & Methods
+- **Receiver Type:**
+  - **Pointer (`*T`):** If mutating, contains `sync.Mutex`, or large struct.
+  - **Value (`T`):** Maps, channels, functions, small immutable structs.
+  - **Consistency:** Prefer all pointers or all values for a type's methods.
+- **Pass Values:** Don't pass pointers to small types (`*string`, `*int`) just to save memory.
+- **Synchronous:** Prefer synchronous APIs. Let the caller decide to use goroutines.
+- **Must Functions:** `MustXYZ` panic on failure. Use **only** for package-level init or test helpers.
+
+### Error Handling
+- **Flow:** Handle errors immediately (`if err != nil { return err }`). Keep "happy path" unindented. Avoid `else`.
+- **Structure:** Use `%w` with `fmt.Errorf` to wrap errors for programmatic inspection (`errors.Is`).
+- **Panics:** **Never** panic in libraries. Return errors. `log.Fatal` is okay in `main`.
+- **Strings:** Lowercase, no punctuation (e.g., `fmt.Errorf("something bad")`) for easy embedding.
+
+### Concurrency
+- **Lifetimes:** Never start a goroutine without knowing how it stops.
+- **Context:** Always first arg `ctx context.Context`. **Never** store in structs.
+- **Copying:** **Do not copy** structs with `sync.Mutex` or `bytes.Buffer`.
+
+### Testing
+- **Framework:** Use `testing` package. No assertion libraries (use `cmp` for diffs).
+- **Helpers:** Mark setup/teardown functions with `t.Helper()`.
+- **Failure Messages:** `YourFunc(%v) = %v, want %v`. (Got before Want).
+- **Table-Driven:** Use field names in struct literals for clarity.
+- **Subtests:** Use `t.Run()` for clear scope and filtering. Avoid slashes in names.
+
+### Global State & Init
+- **Avoid Globals:** Libraries should not rely on package-level vars. Allow clients to instantiate (`New()`).
+- **Initialization:** Use `:=` for non-zero values. Use `var t []T` (nil) for empty slices.
+- **Imports:** Group order: Stdlib, Project/Vendor, Side-effects (`_`). No `.` imports.
+
+## Practical Go Cheat Sheet
+
+Best practices for maintainable Go from **Dave Cheney's** [Practical Go](references/dave-cheney-practical-go.md).
+
+### Guiding Principles
+- **Simplicity, Readability, Productivity:** The core values. Clarity > Brevity.
+- **Identifiers:** Choose for clarity. Length proportional to scope/lifespan. Don't include type in name (e.g., `usersMap` -> `users`).
+
+### Design & Structure
+- **Package Names:** Name for what it *provides* (e.g., `http`), not what it contains. Avoid `util`, `common`.
+- **Project Structure:** Prefer fewer, larger packages. Arrange files by import dependency.
+- **API Design:** Hard to misuse. Avoid multiple params of same type. Avoid `nil` params.
+- **Interfaces:** Let functions define behavior they require (e.g., take `io.Writer` not `*os.File`).
+- **Zero Value:** Make structs useful without explicit initialization (e.g., `sync.Mutex`, `bytes.Buffer`).
+
+### Concurrency & Errors
+- **Concurrency:** Leave it to the caller. Never start a goroutine without knowing when/how it stops.
+- **Errors:** Eliminate error handling by eliminating errors (e.g., `bufio.Scanner`). Handle errors once (don't log AND return).
+- **Return Early:** Use guard clauses. Keep the "happy path" left-aligned.
+
+## Available References
+
+Detailed documentation available in the `references/` directory:
+
+- **[Effective Go](references/effective_go.html):** (HTML) The foundational guide to idiomatic Go.
+- **[Code Review Comments](references/CodeReviewComments.md):** Common comments made during Go code reviews at Google.
+- **[Google Style Guide](references/google/index.md):** Complete set of Google's Go style documents.
+  - [Guide](references/google/guide.md): Core guidelines.
+  - [Decisions](references/google/decisions.md): Normative style decisions.
+  - [Best Practices](references/google/best-practices.md): Evolving guidance.
+- **[Practical Go](references/dave-cheney-practical-go.md):** **Dave Cheney's** advice on writing maintainable Go programs.