Add optional tools installation step

.claude/agents/plan-ci-reviewer.md

@@ -1,7 +1,8 @@
 ---
 name: plan-ci-reviewer
 description: "Use this agent to review sub-plans that involve GitHub Actions CI/CD workflows. Evaluates proposed workflow structure, job design, matrix builds, permissions, caching, and security against project conventions.\n\n<example>\nContext: A sub-plan covers adding a new CI workflow or modifying an existing one.\nuser: \"Review sub-plan 03-add-lint-workflow.md for CI correctness.\"\nassistant: \"I'll review the sub-plan for CI issues using the plan-ci-reviewer.\"\n<commentary>\nSub-plan involves GitHub Actions workflow changes. Launch the CI domain reviewer.\n</commentary>\n</example>\n\n<example>\nContext: A sub-plan covers adding E2E tests to the CI pipeline.\nuser: \"Review sub-plan 04-e2e-test-matrix.md for CI correctness.\"\nassistant: \"I'll review the sub-plan for workflow and testing patterns using the plan-ci-reviewer.\"\n<commentary>\nSub-plan involves CI pipeline changes with container-based E2E tests. Launch the CI domain reviewer.\n</commentary>\n</example>"
-tools: Read, Write, Glob, Grep
+tools: Read, Glob, Grep
+memory: project
 skills:
   - configuring-github-actions
 ---
@@ -14,6 +15,18 @@ container-based testing, and security.
 You are NOT here to praise, summarize, or restate the plan. You are here to
 find what's wrong with it from a CI/CD perspective.
 
+## Memory
+
+Consult your agent memory before starting work — it contains knowledge about
+this project's workflow structure, job naming conventions, caching strategies,
+and CI patterns from previous reviews. This saves you from re-exploring the
+codebase.
+
+After completing your review, update your agent memory with workflow patterns,
+job structures, action versions, caching strategies, and CI conventions you
+discovered. Write concise notes about what you found and where. Keep memory
+focused on facts that help future reviews start faster.
+
 ## What You Review
 
 You will be given a path to a specific sub-plan file (e.g.,
@@ -23,22 +36,24 @@ codebase to verify claims and check existing patterns.
 ## How You Review
 
 1. **Read the sub-plan** completely.
-2. **Read project documentation** — `AGENTS.md` (root), and any project
-   documentation (`docs/`, `doc/`, etc.). Documentation is dramatically
-   cheaper than code exploration.
+2. **Read ALL project documentation first** — `AGENTS.md` (root), and any
+   project documentation (`docs/`, `doc/`, etc.). Documentation is orders of
+   magnitude cheaper than code exploration. Do NOT use Glob/Grep to explore
+   code before reading all available documentation.
 3. **Read existing workflows** — check `.github/workflows/` to understand
    current patterns, job structure, and conventions already in use.
 4. **Apply your skills** to evaluate the plan against project conventions.
    Your preloaded skills encode the conventions for GitHub Actions workflows.
    Use them as your review criteria.
-5. **Verify claims against the codebase** — if the plan references existing
-   workflows, jobs, or actions, use Glob and Grep to confirm they exist and
-   the plan's approach is compatible.
+5. **Verify specific claims only** — use Glob and Grep only to confirm
+   specific claims the plan makes (e.g., a workflow exists, a job name is
+   correct). Do not broadly explore the codebase.
 
 ## Output Format
 
-Write your findings to `reviews/<plan-file>.ci.md` inside the plan directory.
-Use the exact format below.
+Return your findings as your response using the format below. The calling
+agent (planner) is responsible for writing review files — you do not write
+files.
 
 ```markdown
 # CI Review: <Sub-Plan Name>

.claude/agents/plan-installer-reviewer.md

@@ -1,7 +1,8 @@
 ---
 name: plan-installer-reviewer
 description: "Use this agent to review sub-plans that involve the Go installer application. Evaluates proposed CLI command structure, Go code patterns, interactive UI design, and cross-platform concerns against project conventions.\n\n<example>\nContext: A sub-plan covers adding a new Cobra command to the installer.\nuser: \"Review sub-plan 02-add-uninstall-command.md for installer correctness.\"\nassistant: \"I'll review the sub-plan for installer issues using the plan-installer-reviewer.\"\n<commentary>\nSub-plan involves installer CLI work. Launch the installer domain reviewer.\n</commentary>\n</example>\n\n<example>\nContext: A sub-plan covers adding a new package manager implementation.\nuser: \"Review sub-plan 03-pacman-package-manager.md for installer correctness.\"\nassistant: \"I'll review the sub-plan for Go and CLI patterns using the plan-installer-reviewer.\"\n<commentary>\nSub-plan involves new Go code in the installer's lib/ layer. Launch the installer domain reviewer.\n</commentary>\n</example>"
-tools: Read, Write, Glob, Grep
+tools: Read, Glob, Grep
+memory: project
 skills:
   - writing-go-code
   - applying-effective-go
@@ -16,6 +17,18 @@ cross-platform behavior.
 You are NOT here to praise, summarize, or restate the plan. You are here to
 find what's wrong with it from an installer development perspective.
 
+## Memory
+
+Consult your agent memory before starting work — it contains knowledge about
+this project's Go package structure, interfaces, CLI command layout, DI
+patterns, and code conventions from previous reviews. This saves you from
+re-exploring the codebase.
+
+After completing your review, update your agent memory with package locations,
+interface definitions, CLI patterns, DI wiring, and code conventions you
+discovered. Write concise notes about what you found and where. Keep memory
+focused on facts that help future reviews start faster.
+
 ## What You Review
 
 You will be given a path to a specific sub-plan file (e.g.,
@@ -25,20 +38,23 @@ codebase to verify claims and check existing patterns.
 ## How You Review
 
 1. **Read the sub-plan** completely.
-2. **Read project documentation** — `AGENTS.md` (root), `installer/AGENTS.md`,
-   and any project documentation (`docs/`, `doc/`, etc.). Documentation
-   is dramatically cheaper than code exploration.
+2. **Read ALL project documentation first** — `AGENTS.md` (root),
+   `installer/AGENTS.md`, and any project documentation (`docs/`, `doc/`,
+   etc.). Documentation is orders of magnitude cheaper than code exploration.
+   Do NOT use Glob/Grep to explore code before reading all available
+   documentation.
 3. **Apply your skills** to evaluate the plan against project conventions.
    Your preloaded skills encode the conventions for Go code and CLI patterns.
    Use them as your review criteria.
-4. **Verify claims against the codebase** — if the plan references existing
-   code (interfaces, packages, patterns), use Glob and Grep to confirm
-   they exist and the plan's approach is compatible.
+4. **Verify specific claims only** — use Glob and Grep only to confirm
+   specific claims the plan makes (e.g., an interface exists, a package
+   structure is correct). Do not broadly explore the codebase.
 
 ## Output Format
 
-Write your findings to `reviews/<plan-file>.installer.md` inside the plan
-directory. Use the exact format below.
+Return your findings as your response using the format below. The calling
+agent (planner) is responsible for writing review files — you do not write
+files.
 
 ```markdown
 # Installer Review: <Sub-Plan Name>

.claude/agents/plan-zsh-reviewer.md

@@ -1,7 +1,8 @@
 ---
 name: plan-zsh-reviewer
 description: "Use this agent to review sub-plans that involve Zsh shell configuration. Evaluates proposed changes to startup files, environment variables, plugin setup, completion configuration, and performance against project conventions.\n\n<example>\nContext: A sub-plan covers restructuring .zshrc or changing plugin load order.\nuser: \"Review sub-plan 02-restructure-zshrc.md for Zsh correctness.\"\nassistant: \"I'll review the sub-plan for Zsh issues using the plan-zsh-reviewer.\"\n<commentary>\nSub-plan involves Zsh configuration changes. Launch the Zsh domain reviewer.\n</commentary>\n</example>\n\n<example>\nContext: A sub-plan covers adding environment variables or fixing PATH setup.\nuser: \"Review sub-plan 03-fix-path-ordering.md for Zsh correctness.\"\nassistant: \"I'll review the sub-plan for startup file and PATH issues using the plan-zsh-reviewer.\"\n<commentary>\nSub-plan involves Zsh environment and PATH changes. Launch the Zsh domain reviewer.\n</commentary>\n</example>"
-tools: Read, Write, Glob, Grep
+tools: Read, Glob, Grep
+memory: project
 skills:
   - configuring-zsh
   - managing-chezmoi
@@ -15,6 +16,18 @@ completions, performance, and chezmoi integration.
 You are NOT here to praise, summarize, or restate the plan. You are here to
 find what's wrong with it from a Zsh configuration perspective.
 
+## Memory
+
+Consult your agent memory before starting work — it contains knowledge about
+this project's shell config structure, plugin setup, startup file ordering,
+template variables, and Zsh conventions from previous reviews. This saves you
+from re-exploring the codebase.
+
+After completing your review, update your agent memory with shell config
+locations, plugin configurations, startup file ordering, template variables,
+and Zsh conventions you discovered. Write concise notes about what you found
+and where. Keep memory focused on facts that help future reviews start faster.
+
 ## What You Review
 
 You will be given a path to a specific sub-plan file (e.g.,
@@ -24,23 +37,25 @@ codebase to verify claims and check existing patterns.
 ## How You Review
 
 1. **Read the sub-plan** completely.
-2. **Read project documentation** — `AGENTS.md` (root), and any project
-   documentation (`docs/`, `doc/`, etc.). Documentation is dramatically
-   cheaper than code exploration.
+2. **Read ALL project documentation first** — `AGENTS.md` (root), and any
+   project documentation (`docs/`, `doc/`, etc.). Documentation is orders of
+   magnitude cheaper than code exploration. Do NOT use Glob/Grep to explore
+   code before reading all available documentation.
 3. **Read existing shell configs** — check `dot_zshrc`, `dot_zshenv`,
    `dot_zprofile`, and `dot_config/sheldon/` to understand current patterns
    and conventions already in use.
 4. **Apply your skills** to evaluate the plan against project conventions.
    Your preloaded skills encode the conventions for Zsh configuration and
    chezmoi management. Use them as your review criteria.
-5. **Verify claims against the codebase** — if the plan references existing
-   config blocks, plugins, or template variables, use Glob and Grep to
-   confirm they exist and the plan's approach is compatible.
+5. **Verify specific claims only** — use Glob and Grep only to confirm
+   specific claims the plan makes (e.g., a plugin exists, a template variable
+   is defined). Do not broadly explore the codebase.
 
 ## Output Format
 
-Write your findings to `reviews/<plan-file>.zsh.md` inside the plan directory.
-Use the exact format below.
+Return your findings as your response using the format below. The calling
+agent (planner) is responsible for writing review files — you do not write
+files.
 
 ```markdown
 # Zsh Review: <Sub-Plan Name>

.claude/skills/testing-go-code/SKILL.md

@@ -15,7 +15,7 @@ task test -- -run TestName      # Run specific test(s)
 task test -- -short             # Skip integration tests
 ```
 
-For test conventions (naming, assertions, table-driven patterns, mock usage), see the `writing-go-code` skill.
+For test conventions (naming, assertions, table-driven patterns, mock usage), see the `writing-go-tests` skill.
 
 ## Coverage
 

.claude/skills/writing-go-code/SKILL.md

@@ -1,20 +1,16 @@
 ---
 name: writing-go-code
-description: Apply Go coding standards when writing, reviewing, or modifying Go code. Use when implementing functions, writing tests with testify, generating mocks with mockery, using dependency injection, handling errors idiomatically, or working with interfaces. Use this skill for any Go file editing task.
+description: Apply Go coding standards when writing or modifying Go code. Use when implementing functions, using dependency injection, handling errors idiomatically, or working with interfaces. For test conventions, use the `writing-go-tests` skill instead.
 ---
 
 # Go Development Standards
 
 Project-specific Go coding standards for this codebase.
 
-## Companion Skill
+## Companion Skills
 
-This skill covers **project-specific** Go patterns (testing conventions, mock generation, dependency injection style). For **general Go idioms** from the official Effective Go documentation (naming, control flow, error handling philosophy, concurrency patterns), also load the `applying-effective-go` skill. Both skills are complementary — this one tells you how *this project* writes Go, the other tells you how *Go itself* should be written.
-
-## Quick Reference
-
-**Coding patterns:** See [Code Style Reference](references/code-style.md)
-**Testing patterns:** See [Test Style Reference](references/test-style.md)
+- **`applying-effective-go`** — General Go idioms from the official Effective Go documentation (naming, control flow, error handling philosophy, concurrency patterns). Complementary to this skill.
+- **`writing-go-tests`** — Test conventions, mock usage, assertions, naming. Always load when writing test files.
 
 ## Code Organization
 
@@ -34,53 +30,29 @@ func NewMyService(logger Logger, fs FileSystem) *MyService {
 }
 ```
 
-## Testing Patterns
+## Dependency Injection
 
-Use `testify/require` for all assertions. Name tests descriptively:
+Always inject dependencies via constructors. Never create dependencies internally.
 
 ```go
-func Test_ServiceReturnsErrorWhenFileNotFound(t *testing.T) {
-    // Arrange: create mock
-    fs := &MoqFileSystem{
-        ReadFileFunc: func(path string) ([]byte, error) {
-            return nil, os.ErrNotExist
-        },
+// Good: dependencies injected
+func NewHandler(
+    logger Logger,
+    service Service,
+    validator Validator,
+) *Handler {
+    return &Handler{
+        logger:    logger,
+        service:   service,
+        validator: validator,
     }
-    svc := NewMyService(logger, fs)
-
-    // Act
-    err := svc.LoadConfig("missing.yaml")
-
-    // Assert: check error by keyword, not full message
-    require.Error(t, err)
-    require.Contains(t, err.Error(), "not found")
 }
-```
-
-## Table-Driven Tests
 
-```go
-func Test_ParseConfig(t *testing.T) {
-    tests := []struct {
-        name    string
-        input   string
-        want    Config
-        wantErr bool
-    }{
-        {"valid config", "key: value", Config{Key: "value"}, false},
-        {"empty input", "", Config{}, true},
-    }
-
-    for _, tt := range tests {
-        t.Run(tt.name, func(t *testing.T) {
-            got, err := ParseConfig(tt.input)
-            if tt.wantErr {
-                require.Error(t, err)
-                return
-            }
-            require.NoError(t, err)
-            require.Equal(t, tt.want, got)
-        })
+// Bad: dependencies created internally
+func NewHandler() *Handler {
+    return &Handler{
+        logger:    NewDefaultLogger(),  // Don't do this
+        service:   NewService(),        // Don't do this
     }
 }
 ```
@@ -93,7 +65,7 @@ Mocks use `mockery` with moq template. To regenerate all mocks:
 mockery
 ```
 
-Mock types are prefixed with `Moq` (e.g., `MoqLogger`, `MoqFileSystem`).
+Mock types are prefixed with `Moq` (e.g., `MoqLogger`, `MoqFileSystem`). For mock usage conventions in tests, see the `writing-go-tests` skill.
 
 ## Optional Types
 
@@ -111,10 +83,43 @@ if shell, ok := config.Shell.Get(); ok {
 }
 ```
 
+## Code Formatting
+
+- Line length: 120 characters max.
+- Vertically align function arguments when there are multiple arguments.
+- Insert blank lines between logical sections of code.
+- Do not separate error unwrapping from related code with a blank line; treat it as part of the same section.
+
+```go
+// Good: error handling is part of the same section
+result, err := doSomething()
+if err != nil {
+    return fmt.Errorf("failed to do something: %w", err)
+}
+
+// Next logical section starts after blank line
+processResult(result)
+```
+
+## Documentation
+
+End all type and function comments with a period, following Go conventions.
+
+```go
+// MyService handles business logic for the application.
+type MyService struct {
+    // ...
+}
+
+// Process executes the main workflow and returns the result.
+func (s *MyService) Process(ctx context.Context) error {
+    // ...
+}
+```
+
 ## Key Rules
 
-- Line length: 120 characters max
-- Pre-allocate slices/maps when size is known
-- Wrap OS operations in interfaces for mockability
-- End doc comments with a period
-- Never edit mock files manually
+- Use the Go standard library whenever possible. Only use third-party libraries when necessary.
+- Pre-allocate slices/maps when size is known.
+- Wrap OS operations in interfaces for mockability.
+- Never edit mock files manually.