AI Coding Rules

A Claude Code plugin marketplace for linter-driven development — workflows where quality gates (tests, linters, design review) guide your design instead of slowing you down.

What's Inside

	Plugin	Version	For
🐹	go-linter-driven-development	2.15.0	Go
🐍	python-linter-driven-development	0.4.0	Python
🧩	linter-driven-development	0.4.0	Any language without a binding — detects the language at run time
⚛️	ts-react-linter-driven-development	2.0.0	TypeScript + React

Plus the coding rules as a single document, for a project that does not use the plugin:

• 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 — 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 — 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 — 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.

Go plugin (v2 — rules as data)

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-hunters, 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 · what changed between versions: CHANGELOG.

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. Details and the opinionated stances: plugin README.

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.

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. Version 2 replaces the hand-written six-skill plugin; the upgrade notes are in the plugin README.

Installation

Step 1: Add the marketplace

/plugin marketplace add buzzdan/ai-coding-rules

Step 2: Install a plugin

/plugin install go-linter-driven-development@ai-coding-rules
/plugin install python-linter-driven-development@ai-coding-rules
/plugin install linter-driven-development@ai-coding-rules
/plugin install ts-react-linter-driven-development@ai-coding-rules

Verify: /plugin list should show the plugin as enabled.

First steps: 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@ai-coding-rules

Team Setup

Add the marketplace to your project's .claude/settings.json so it's known team-wide:

{
  "extraKnownMarketplaces": [
    "buzzdan/ai-coding-rules"
  ]
}

Team members then install with the same /plugin install commands above.

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, docs/generator.md and docs/handbook.md.
2. Test locally by adding the checkout as a marketplace:

   /plugin marketplace add ./ai-coding-rules
   /plugin install go-linter-driven-development@ai-coding-rules
   

   After changes, uninstall/reinstall the plugin to pick them up.
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.
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 — 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 buzzdan/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).

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.