go-linter-driven-development

Preparatory refactoring — reshape the code a planned change will touch, so the feature lands add-only

Run quality analysis only - tests + plain lint + hunter/skeptic review, combined report, no auto-fix

Start complete linter-driven autopilot workflow (Phases 1-5, incl. the autonomous PREPARE sub-phase 1.5)

Run quality gates loop until all green (tests+linter+review → fix → repeat)

Check if code is commit-ready (final verification, no auto-fix)

WHEN: Spawned programmatically by the documentation skill (after it writes godocs and feature docs) and by the pre-commit-review skill (when the diff contains comment lines), receiving a payload — R9's comment policy section and the Comment Value Toolbox catalog — pasted into the spawn prompt. Not auto-triggered by user requests. Read-only adversarial reviewer with a single obsession: comment value. Judges every comment in the diff against the three-test standard (toolbox-value, tier budget, plain English); every non-KEEP verdict names the toolbox item the replacement should deliver.

WHEN: Spawned programmatically by the linter-driven-development skill in Phase 3 to run the lint-fix loop in an isolated context, keeping the loop's token noise out of the main conversation. Not auto-triggered by user requests. Fixes mechanical lint issues; escalates complexity/design failures with a rule route instead of redesigning.

WHEN: Spawned programmatically by the pre-commit-review skill after hunters report, receiving the type/package-extraction findings plus a payload (R1's juiciness scorecard and the CIDR over-abstraction case file) pasted into the spawn prompt. Not auto-triggered by user requests. Read-only devil's advocate: tries to kill each proposed extraction; every refutation must ship a cheaper alternative.

WHEN: Spawned programmatically by the pre-commit-review skill — one hunter per rule, in parallel — with a full rule file (rules/R*.md) pasted into the spawn prompt. Not auto-triggered by user requests. Read-only, single-obsession reviewer: hunts violations of exactly one rule across a diff scope and returns evidence-backed findings.

FORWARD view over rules/ — domain type design and architectural planning for Go code BEFORE it exists. Use when planning new features, designing self-validating types, preventing primitive obsession, or when refactoring reveals need for new types. Dispatches into the Design guidance sections of rules/R1-R8 and R10-R12.

The repo-brain author/maintainer: writes behavior-focused documentation and wires it into the documentation network defined by rules/R9-repo-brain.md. FEATURE mode (default): after feature implementation or bug fixes — invoked by @linter-driven-development (Phase 5) — to document HOW THE PRODUCT BEHAVES and wire it into the network. BOOTSTRAP mode: on request ("set up docs", "create an index", "make this repo AI-navigable", /wire-repo-brain) or when FEATURE mode finds no doc root — discovers the doc root, builds index.md, wires CLAUDE.md, wires missing code→docs edges, reports gaps. NOT a changelog - documents current behavior, not change history.

META ORCHESTRATOR for any Go code change that should end in a commit (features, bug fixes, refactors). WHEN: User requests Go code work (implement, fix, add, refactor), mentions "@ldd"/"ldd", or runs a /go-ldd-* command in a Go project. Runs the five-phase workflow (PREPARE is an autonomous sub-phase, 1.5): DESIGN → PREPARE → IMPLEMENT (per-behavior TDD loop) → FULL LINT (lint-fixer agent) → REVIEW (per slice) → SHIP.

ADVISORY pre-commit review that orchestrates parallel single-obsession rule hunters, an over-abstraction skeptic, and a comment critic against the diff. Spawns read-only agents (rule-hunter, overabstraction-skeptic, comment-critic); NEVER edits code. Invoked by @linter-driven-development (Phase 4), by @refactoring (after pattern application), or manually for standalone code review. Categorizes findings as Bugs, New Practice (when in Rome), Design Debt, Readability Debt, or Polish Opportunities. Does NOT block commits.

BACKWARD view over rules/ — routes linter and review failures to the rule whose Fix pattern owns the repair. Use when linter fails with complexity issues (cyclomatic, cognitive, maintainability) or when code feels hard to read/maintain. Also runs PREPARATORY mode: reshape code an approved plan touches, before the first RED, so the feature lands add-only. Applies storifying, type extraction, function extraction, conditional-dispatch, and mutation-discipline patterns via rules/R1-R8 and R10-R12.