Claude Code plugins that bring Extreme Programming and Clean Code discipline to AI-assisted development: one for how code gets built, one for validating that a pull request lives up to it.
At Hivemind Technologies, we build scalabe data platforms and machine learning systems for finance, energy and mobility sectors. Our engineering culture is rooted in the belief that software quality is not a trade-off against delivery speed — it is what makes sustained delivery possible. We practice test-first development, design through small increments, and treat code clarity as a first-class concern. This skill is a direct expression of those values, made available for AI coding agents.
AI coding agents are remarkably capable, but left unconstrained they tend toward the same failure modes as a talented developer working without discipline: skipping tests, over-engineering, and conflating building with cleaning. This skill gives Claude Code a concrete methodology to follow — one that engineers have used to ship reliable software for decades.
It encodes eight principles:
- Test First — the RED → GREEN → CLEAN cycle, enforced strictly. No production code without a failing test.
- BDD Scenarios as Success Criteria — Given/When/Then scenarios are written before tests, making intent explicit and verifiable before a line of implementation exists.
- One Step at a Time — one failing test at a time, one scenario per commit. No speculative work, no big-bang implementations.
- Clean Code Invariants — names that reveal intent, functions that do one thing, comments that explain why rather than what, no surprise side effects.
- Refactor as a Separate Phase — structural improvements are always made after green, never mixed with feature work.
- Domain-Driven Design — code speaks the language of the domain. Bounded contexts enforce explicit boundaries. Value objects replace primitives. Domain events model facts as immutable values. Repositories abstract persistence from domain logic.
- Functional Core — pure functions as the default, referential transparency as the goal. Side effects are pushed to the edges. Errors are modelled as
Either/Resulttypes, not exceptions. Absent values areOption, not null. State changes return new values; nothing mutates in place. Where the language supports it, function composition (including monadic chains) builds complex behaviour from simple, testable parts. - Total Types and Explicit Outcomes — the decision rule for which type carries an outcome.
Optiononly where absence needs no explanation;Either/Resultwhere the caller may need to distinguish, report, recover from, or test the failure. Null never enters the typed core — nullable values are normalised at the boundary. Optionals that depend on each other become a sum type, so invalid combinations cannot be constructed. Closed types are eliminated exhaustively, with no default branch and no forced unwrap. Exceptions keep a defined role: broken invariants and defects, not outcomes.
As a Claude Code plugin (recommended — applies across all projects):
Add the repo as a plugin source in ~/.claude/settings.json:
{
"extraKnownMarketplaces": {
"xp-clean-code": {
"source": {
"source": "github",
"repo": "HivemindTechnologies/xp-clean-code"
}
}
}
}Then open Claude Code and run /plugin to browse and install.
Per-project (append to an existing CLAUDE.md):
echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/HivemindTechnologies/xp-clean-code/main/plugins/xp-clean-code/skills/xp-clean-code/SKILL.md >> CLAUDE.mdplugins/xp-clean-code/ # how to build
├── .claude-plugin/
│ └── plugin.json # Plugin manifest
└── skills/
└── xp-clean-code/
├── SKILL.md # Core principles — loaded by Claude Code
└── references/
├── testing-patterns.md # Framework examples: Scala, Java, Python, PySpark,
│ # TypeScript, Rust, Gherkin
├── total-types.md # Option/Either/ADT idioms per language; result-type
│ # conformance properties
└── scenario-examples.md # Worked BDD scenarios across common problem types
plugins/pr-validation/ # verifying what was built
├── .claude-plugin/
│ └── plugin.json
├── commands/
│ └── pr-validate.md # /pr-validate — runs the check against a GitHub PR
└── skills/
└── pr-validation/
├── SKILL.md # The four analyses — loaded by Claude Code
└── references/
├── purity-checklist.md # Impurity signals + absence-vs-failure signals:
│ # Python, Scala, Java, TypeScript, Rust
├── gap-patterns.md # Eleven coverage gap patterns, with before/after scenarios
└── claim-verification.md # Mutation catalogue for the removal check
The reference files are loaded on demand. SKILL.md stays lean in context; the detail is there when Claude needs it.
Where xp-clean-code governs how to build, pr-validation checks that what was built holds up. Run /pr-validate on a PR — or ask Claude to review one — and it produces a structured report across four analyses:
- Purity — every changed function classified as Pure, Impure–boundary, or Impure–violation.
- Idempotency — every state transition checked for
f(f(x)) = f(x), and for a double-application scenario. - BDD coverage — a coverage matrix mapping changed functions to scenarios: happy path, each failure mode, each branch, each boundary.
- Protection claims — for every assertion the PR body makes about what a check protects against, the mapped test is run with that protection removed. If it still passes, the claim is unsubstantiated: the guard is untested, unreachable, or the test passes for an unrelated reason. A protection claim nobody can break is a promise the suite does not keep.
This skill focuses on how to build. If you also want to constrain how to reason — surface assumptions, avoid over-complication, make surgical changes — it pairs naturally with andrej-karpathy-skills. The two address different failure modes and do not overlap.
MIT