Implementation

Make the canon enforce itself.

Download the canon as a lint config in your project's language plus a set of rule files for your AI coding agent. Pick both below.

§1

Pick your language

Pick the language of your project. The choice also sets the language used in every code sample and enforcement table on the rest of the site.

§2

Enforcement

One config file per language. Every rule has an inline comment naming the tenet it enforces and a link to the canon entry. Drop it in your repo, install the dependencies, and the rules run.

TypeScript · primary toolchain: ESLint (flat config)

Config file: eslint.config.mjs

eslint.config.mjs219 lines

// =============================================================================
// Prickles canon — TypeScript flat config (eslint.config.mjs) · v1.0
// Source of truth: https://prickles.org/implementation
//
// What this file enforces (21 of 50 tenets):
//   F1 F2 F3 F4 F5 F6      ·  Foundations
//   A1 A2 A3 A6 A11        ·  Architecture (folder + import discipline)
//   S2 S3 S4 S5            ·  Style (caps, params, guards, inline-first)
//   T2                     ·  Types (no escape hatches)
//   P5                     ·  Quality outside QA (React + a11y safety)
//   TA1 TA2                ·  Tooling (linter as law, detect duplication)
//   TS5                    ·  Testing (locate by structure — a11y roles)
//
// What this file CANNOT enforce — the canon ships these on other surfaces:
…

Install steps

Install the dependencies:

npm i -D eslint @eslint/js typescript-eslint eslint-plugin-sonarjs eslint-plugin-unicorn eslint-plugin-import jscpd prettier

Drop the config above into eslint.config.mjs at your repo root.

Run the gate:

npx eslint . && npx jscpd src && npx prettier --check .

Wire the gate into CI: a quality script (or its build-tool equivalent) that fails the build on any rule violation.

§3

AI rules

Nine rule files, one per pillar. The text on each rule matches the tenet entry on the canon.

Claude Code · canonical drop path: .claude/rules/<tenet>.md

Claude Code reads project-level rules from the .claude/rules directory at repo root.

Foundations pillar

What good code looks like before the framework gets a vote. Each line is a UI for the next reader, human or agent — these six tenets are the levers that make it one.

.claude/rules/prickles-foundations.md98 lines

# Prickles canon · Foundations pillar · Claude Code rules · v1.0

# Source of truth: https://prickles.org/implementation
# This bundle covers 6 tenets from the Foundations pillar.
# Each section below begins with a link back to its canonical entry on prickles.org.

<!-- Prickles F1 · Single Responsibility Principle · https://prickles.org/tenet/single-responsibility-principle/F1 -->

## Prickles F1 — Single Responsibility Principle

One obvious job per function, class, or module. When a second concern shows up in the same unit, peel it out so each piece has its own reason to change.

Names should read as a single verb phrase. If you need “and” to describe what the function does, you probably have two responsibilities—extract until the sentence holds without a conjunction.

…

Architecture pillar

Boundaries before patterns. Coupling is the only metric that matters.

.claude/rules/prickles-architecture.md158 lines

# Prickles canon · Architecture pillar · Claude Code rules · v1.0

# Source of truth: https://prickles.org/implementation
# This bundle covers 11 tenets from the Architecture pillar.
# Each section below begins with a link back to its canonical entry on prickles.org.

<!-- Prickles A1 · Screaming Architecture · https://prickles.org/tenet/screaming-architecture/A1 -->

## Prickles A1 — Screaming Architecture

The top-level folder structure is the architecture diagram. Read your `ls` aloud — it should name what the system does, not which framework it runs on.

Top-level folders name domains (orders, billing, identity, scheduling), not framework artefacts (controllers, models, views, services). Framework files live one level down, inside the domain folder they serve.

…

Style pillar

How code reads on the page. The strokes and the rules that hold them in place.

.claude/rules/prickles-style.md60 lines

# Prickles canon · Style pillar · Claude Code rules · v1.0

# Source of truth: https://prickles.org/implementation
# This bundle covers 4 tenets from the Style pillar.
# Each section below begins with a link back to its canonical entry on prickles.org.

<!-- Prickles S2 · Cyclomatic Caps · https://prickles.org/tenet/cyclomatic-caps/S2 -->

## Prickles S2 — Cyclomatic Caps

Cap cyclomatic complexity per function. The number is editorial; pick one and put it in the linter.

Cap function length. Pick a number; the canonical Prickles default is 15 lines. Pair with caps on indentation depth, statement count, parameter count.

…

Types & Schema pillar

Containers that hold what they say they hold. Domain in the types, exceptions called out, casts replaced with proof, and one owner per schema.

.claude/rules/prickles-types.md70 lines

# Prickles canon · Types & Schema pillar · Claude Code rules · v1.0

# Source of truth: https://prickles.org/implementation
# This bundle covers 4 tenets from the Types & Schema pillar.
# Each section below begins with a link back to its canonical entry on prickles.org.

<!-- Prickles T1 · Domain-Driven Types · https://prickles.org/tenet/domain-driven-types/T1 -->

## Prickles T1 — Domain-Driven Types

> Canon: https://prickles.org/tenet/domain-driven-types/T1

Brand the primitives. A user ID is not a string; an email is not a string; a UUID is not a string. Wrap each domain primitive in a typed brand the compiler enforces, so passing a BookingId where a UserId is expected fails at compile time.

…

Process pillar

How good code gets written. The Foundations describe what good code looks like; the Process pillar covers the disciplines that make it the default outcome rather than the lucky one — from spec to merge.

.claude/rules/prickles-process.md102 lines

# Prickles canon · Process pillar · Claude Code rules · v1.0

# Source of truth: https://prickles.org/implementation
# This bundle covers 7 tenets from the Process pillar.
# Each section below begins with a link back to its canonical entry on prickles.org.

<!-- Prickles P1 · Test-First Development · https://prickles.org/tenet/test-first-development/P1 -->

## Prickles P1 — Test-First Development

Write the failing test before the implementation. Watch it fail for the reason you predicted; then write the smallest code that makes it green.

In typed languages, the type is the first test. Define the signature, leave the body as a hole, let the compiler reject the inconsistencies the unit test would have caught, then write the test for the residue.

…

Testing pillar

Probes and proofs. The instruments that keep the canon honest. Eight tenets carry the load — five about what tests prove, three about how they prove it.

.claude/rules/prickles-testing.md116 lines

# Prickles canon · Testing pillar · Claude Code rules · v1.0

# Source of truth: https://prickles.org/implementation
# This bundle covers 8 tenets from the Testing pillar.
# Each section below begins with a link back to its canonical entry on prickles.org.

<!-- Prickles TS1 · Living Documentation · https://prickles.org/tenet/living-documentation/TS1 -->

## Prickles TS1 — Living Documentation

If a behaviour matters, write a test that proves it. The test is the spec; prose docs are a paraphrase.

When the code changes, the test fails or it doesn't. Prose can drift in silence; a test in CI cannot. The first signal is a red build, not a stale paragraph.

…

AI Collaboration pillar

The pair programmer changes. The principles don't.

.claude/rules/prickles-ai.md90 lines

# Prickles canon · AI Collaboration pillar · Claude Code rules · v1.0

# Source of truth: https://prickles.org/implementation
# This bundle covers 6 tenets from the AI Collaboration pillar.
# Each section below begins with a link back to its canonical entry on prickles.org.

<!-- Prickles AI1 · The Intern Pattern · https://prickles.org/tenet/the-intern-pattern/AI1 -->

## Prickles AI1 — The Intern Pattern

Treat the agent as an over-eager intern. Run the loop in four moves: plan, approve, execute, review. Skip a move and you produce plausible wrongness at machine speed.

Plan before you type. Use Plan Mode (Claude Code), spec-first prompts (Cursor), or a written outline checked into the PR description. The plan names files, decisions, and the verification step.

…

Tooling pillar

These tenets enforce what gates can enforce — line counts, complexity caps, duplicate text, type strictness. Everything Prickles is about beyond that boundary is what the rest of the canon teaches.

.claude/rules/prickles-tooling.md32 lines

# Prickles canon · Tooling pillar · Claude Code rules · v1.0

# Source of truth: https://prickles.org/implementation
# This bundle covers 2 tenets from the Tooling pillar.
# Each section below begins with a link back to its canonical entry on prickles.org.

<!-- Prickles TA1 · Linter as Law · https://prickles.org/tenet/linter-as-law/TA1 -->

## Prickles TA1 — Linter as Law

Every quality gate is an error, never a warning. A warning gets ignored within a sprint; an error stops the build.

Encode the limit before the violation. Line count, complexity, parameter count, file size, equality, return annotations, type-file naming, barrel files, import direction — all in `eslint.config.mjs` or its language equivalent.

…

Patterns pillar

Prickles curates; we don't re-author the catalogue. The PT tenets discipline how to use patterns — name them and name their failure modes.

.claude/rules/prickles-patterns.md34 lines

# Prickles canon · Patterns pillar · Claude Code rules · v1.0

# Source of truth: https://prickles.org/implementation
# This bundle covers 2 tenets from the Patterns pillar.
# Each section below begins with a link back to its canonical entry on prickles.org.

<!-- Prickles PT1 · Patterns Are Vocabulary · https://prickles.org/tenet/patterns-are-vocabulary/PT1 -->

## Prickles PT1 — Patterns Are Vocabulary

If a class implements a known pattern, name the pattern in the identifier. A Factory is `*Factory`. A Repository is `*Repository`. An Adapter is `*Adapter`. An Observer is `*Observer`. An abstract base is `Abstract*` or marked `abstract` in the language.

Read GoF, Refactoring Guru, or Fowler's PoEAA once so the names mean the same thing across team and code. Do not paraphrase the catalogue; cite it.

…

§4

Download

Pick a language and an agent surface. The bundle: one lint config, nine rule files, a README.

Step 1. Pick the language

Step 2. Pick the agent surface

Download TypeScript pack for Claude Code