weka/linter-driven-development

Latest recorded source activity: October 28, 2026 at 18:46

SkillsMP catalog refreshed: November 2, 2026 at 18:02

skills collected: 32

GitHub stars: 7
GitHub forks: 1

Install with an AI assistant

Copy this prompt into the AI assistant you're using.

Follow https://skillsmp.com/skill-install/prompt.md to install Agent Skills from https://github.com/weka/linter-driven-development.

Repository README

Repository README source: README.md

Read the source README

Expand full README

<p align="center"> <img src="assets/logo.png" alt="Linter-Driven Development logo" width="320"> </p> <h1 align="center">Linter-Driven Development</h1> <p align="center"> A <a href="https://claude.ai/code">Claude Code</a> plugin marketplace for <b>linter-driven development</b> — workflows where quality gates (tests, linters, design review) guide your design instead of slowing you down. </p> ## How It Works Every code change goes through the same steps, in this order: **Design → Prepare → Implement (TDD) loop → Lint-Refactor loop → Review → Ship** - **Design** plans the types and the package layout before code exists. - **Prepare** reshapes the code the change touches, so the feature lands as an addition. - **Implement (TDD) loop** writes one behavior at a time: a failing test, the code that makes it pass, then a refactor. - **Lint-Refactor loop** runs the repository's linter and fixes the mechanical findings. A design finding goes to a refactor guided by the rule that covers it, and the loop lints again until the linter is green. - **Review** is advisory: it runs parallel reviewers, one per rule family, plus a skeptic that rejects extractions that do not earn their keep. - **Ship** writes the docs and commits when the tests and the linter are green. One prompt runs the whole workflow: `/go-ldd-autopilot`, `/py-ldd-autopilot`, `/tsr-ldd-autopilot` or `/ldd-autopilot`. ## How We Know It Works Behavior changes are measured, not judged by eye: - **A bad fixture.** Each language has a small service with planted design violations (go-mini, py-mini, ts-react-mini) and an answer key of what a good run must find and fix. - **Headless runs.** Each case gives a fresh copy of the fixture to `claude -p` with the plugin loaded, and records every tool call and the final report. - **Graders.** Regex checks on the report and on the files, checks on tool order, a post-check script in the tree, and an LLM judge that votes two of three score each run. - **A baseline.** Each baseline is recorded against a named plugin commit. A refactor must keep every case within the noise floor, the graders that flip between runs of the same case. A behavior change names the cases it should flip and runs them again. The cases, the fixtures, the runner and the baselines are in [weka/ldd-evals](https://github.com/weka/ldd-evals). How it fits together: [docs/eval-harness.md](docs/eval-harness.md). ## What's Inside | | Plugin | Version | For | |---|--------|---------|-----| | 🐹 | [`go-linter-driven-development`](go-linter-driven-development/README.md) | 2.17.0 | Go | | 🐍 | [`python-linter-driven-development`](python-linter-driven-development/README.md) | 0.6.0 | Python | | 🧩 | [`linter-driven-development`](linter-driven-development/README.md) | 0.7.0 | Any language without a binding — detects the language at run time | | ⚛️ | [`ts-react-linter-driven-development`](ts-react-linter-driven-development/README.md) | 2.2.0 | TypeScript + React | Plus the coding rules as a single document, for a project that does not use the plugin: - [`coding-rules/go.md`](coding-rules/go.md) — the Go coding rules: the twelve rules with Go examples, the shared house rules H1–H2 and the Go house rules G1–G6, a self-review checklist and the mechanics. - [`coding-rules/python.md`](coding-rules/python.md) — the same twelve rules with Python examples and the Python binding's positions, the shared house rules and the Python house rules P1–P5, a self-review checklist and the mechanics. - [`coding-rules/ts-react.md`](coding-rules/ts-react.md) — the same twelve rules with TypeScript and React examples and the ts-react binding's positions, the shared house rules and the TypeScript house rules T1–T5, a self-review checklist and the mechanics. - [`coding-rules/generic.md`](coding-rules/generic.md) — the same twelve rules for any other language: pseudocode examples, each with a note on how the language spells it, the shared house rules and the two any-language house rules A1–A2, a self-review checklist and the mechanics. All four are generated from the same sources as the plugins, so they never drift from them; import one from your `CLAUDE.md` or `AGENTS.md`, or read it before your first PR. How they are built: [docs/handbook.md](docs/handbook.md). ### Go plugin The organising idea: **the rule is the unit, not the phase.** Each design principle lives exactly once, as data: - **`rules/` R1–R12** — single source of truth: primitive obsession, self-validating types, storifying, helper placement, vertical slices, test-only interfaces, test placement, no globals, repo-brain documentation, concurrency safety, conditional dispatch (Anti-IF), mutation discipline (Fowler's Mutable Data). - **`skills/`** — six thin directional views that sequence and route into the rules (orchestrator, design, testing, refactoring, review, documentation). - **`agents/`** — payload-fed isolated workers: parallel single-obsession `rule-hunter`s, an `overabstraction-skeptic` that tries to kill proposed extractions, a `comment-critic` that makes every comment prove it earns its lines (Comment Value Toolbox), and a `lint-fixer` that keeps the lint loop out of your conversation. - **`commands/`** — `/go-ldd-autopilot`, `/go-ldd-quickfix`, `/go-ldd-prepare`, `/go-ldd-analyze`, `/go-ldd-review`, `/go-ldd-status`, `/wire-repo-brain`. Full architecture, workflow, and usage: [plugin README](go-linter-driven-development/README.md) · what changed between versions: [CHANGELOG](go-linter-driven-development/CHANGELOG.md). ### Python plugin The same core rendered with Python knowledge: every canonical example is Python, every detection command greps `.py` files, the linter routing is keyed by ruff codes and ty, and the testing skill speaks pytest. Where a Go idiom has no Python twin the plugin takes a position — `None` as declared absence, Null Object constants, frozen dataclasses, `match` closed by `assert_never`, `Event.wait` over `time.sleep` — recorded in [docs/language-residue.md](docs/language-residue.md). Details and the opinionated stances: [plugin README](python-linter-driven-development/README.md). ### Generic plugin The same core rendered for repositories without a language binding. It detects the language from the repository's marker file, runs the linter the repository already configures, and routes findings by what they are about; the rules, review and refactoring moves run in full. Details and what it does not know: [plugin README](linter-driven-development/README.md). ### TS/React plugin The same core rendered for a React single-page application in TypeScript: every canonical example is TypeScript or TSX, every detect line runs over `.ts` and `.tsx` files, the linter routing is keyed by ESLint rule ids (SonarJS, react-hooks, typescript-eslint), and the testing skill speaks Vitest, React Testing Library and MSW. Where a Go idiom has no TypeScript twin the plugin takes a position — `undefined` as declared absence, parse at the API boundary, discriminated unions closed by `assertNever`, effects that return their cleanup, context providers over module singletons, MSW over `vi.mock` — recorded in [docs/language-residue.md](docs/language-residue.md). Details: [plugin README](ts-react-linter-driven-development/README.md). ## Installation **Step 1: Add the marketplace** ``` /plugin marketplace add weka/linter-driven-development ``` **Step 2: Install a plugin** ``` /plugin install go-linter-driven-development@weka-ldd /plugin install python-linter-driven-development@weka-ldd /plugin install linter-driven-development@weka-ldd /plugin install ts-react-linter-driven-development@weka-ldd ``` **Verify:** `/plugin list` should show the plugin as `enabled`. **First steps:** [docs/quick-start.md](docs/quick-start.md) — from the one-line prompt that runs the whole workflow to a repository shared by two language plugins. **Update later:** ``` /plugin update go-linter-driven-development@weka-ldd ``` ## Team Setup Add the marketplace and the plugin to your project's `.claude/settings.json`. Claude Code then offers the plugin to each team member who opens the project: ```json { "extraKnownMarketplaces": { "weka-ldd": { "source": { "source": "github", "repo": "weka/linter-driven-development" } } }, "enabledPlugins": { "go-linter-driven-development@weka-ldd": true } } ``` Use the key of the plugin for your language in `enabledPlugins`. ## Developing the Plugins 1. Clone the repo. All four plugin directories are generated, and so are `coding-rules/go.md`, `coding-rules/python.md`, `coding-rules/ts-react.md` and `coding-rules/generic.md`: edit the sources under `core/` (language-neutral text, with the neutral defaults under `core/includes/`) and `lang/go/`, `lang/python/`, `lang/ts-react/` or `lang/generic/` (the bindings), then run `task generate`, `task generate BINDING=python`, `task generate BINDING=ts-react` and `task generate BINDING=generic` and commit all of them. `task check` fails when a plugin directory or a handbook drifts from its sources. How the pieces fit: [core/README.md](core/README.md), [docs/generator.md](docs/generator.md) and [docs/handbook.md](docs/handbook.md). 2. Test a change on the spot: start a session that loads the plugin straight from your checkout. ``` claude --plugin-dir ./linter-driven-development/go-linter-driven-development ``` To use your checkout in every session, add it as the marketplace and install the plugin from it: ``` /plugin marketplace add ./linter-driven-development /plugin install go-linter-driven-development@weka-ldd ``` Claude Code installs a copy of each plugin, so run `/plugin update <plugin>@weka-ldd` and restart after a change. 3. For the generated plugins, follow the architecture contract — each fact lives once: rule content goes in `core/rules/`, language-neutral defaults for a binding slot in `core/includes/`, Go material in `lang/go/`, Python material in `lang/python/`, TypeScript and React material in `lang/ts-react/`, the case studies' doctrine in `core/examples/` and their code sections in `lang/<lang>/examples/`, skills only sequence and route. See the [plugin README](go-linter-driven-development/README.md#architecture-rules-as-data). 4. Behavior changes to the Go, Python and TypeScript + React plugins are measured, not eyeballed: behavioral evals run them on a deliberately bad fixture project (go-mini, py-mini, ts-react-mini) and compare against a recorded baseline. Start at [docs/index.md](docs/index.md) — the harness, the fixture, how to write a case, the runner, and how to read a baseline. The cases, fixture, runner and baselines live in [weka/ldd-evals](https://github.com/weka/ldd-evals); `scripts/evals.sh` runs them against this checkout. 5. Open a PR; releases are tagged per plugin (e.g. [`go-ldd-v2.0.0`](https://github.com/weka/linter-driven-development/releases/tag/go-ldd-v2.0.0)). ## License Apache-2.0, copyright WekaIO Ltd. Use it anywhere, for any code, commercial or not. The code you write with these plugins is yours. See [LICENSE](LICENSE). Created by [Dan Mordechay](https://github.com/buzzdan) at WEKA.

Loading the repository README…

Skills in this repository

classification pending

skill

occupation

description

updated

testing

unclassified

Use when creating leaf types, after refactoring, during implementation, or when testing advice is needed. Automatically invoked to write tests for new types, or use as testing expert advisor. Covers the composition ladder from rung-0 unit tests to…

2026-10-28

documentation

unclassified

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…

2026-10-26

pre-commit-review

unclassified

unclassified

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…

2026-10-18

unclassified

2026-10-06

code-designing

unclassified

FORWARD view over rules/ — domain type design and architectural planning for code BEFORE it exists, in whatever language the repository uses. Use when planning new features, designing self-validating types, preventing primitive obsession, or when refactoring…

2026-10-06

Showing 32 of 32 collected skills.