FradSer/dotclaude: 22 Claude Code plugins in one MIT marketplace
A comprehensive development environment with specialized AI agents for code review, security analysis, and technical leadership.
At a glance
- What is it?
- dotclaude is a plugin collection for Claude Code that bundles 22 separately installable plugins, from Git automation to KiCad and OpenSCAD drivers. The interesting question is not what it contains but what you inherit when you install one of them.
- Who is it for?
- dotclaude is worth adopting piecemeal if you already run Claude Code and want one narrow capability, such as the git-agent health scan or the memory consolidation validator, installed as a plugin rather than vendored by hand.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 35 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What dotclaude actually is: a marketplace, not a tool
The README opens by describing dotclaude as a curated collection of 22 plugins for Claude Code, providing specialized agents, skills, and automation tools for development and productivity workflows. The badge at the top says 23 plugins while the prose says 22, which is the first thing you notice and a fair signal of how tightly the catalogue is maintained. The repository is written primarily in JavaScript, carries an MIT licence, and its most recent release in the supplied material is v1.13.0 from June 2026, with v1.12.2 and v1.12.1 before it. The last push is dated August 2026, so the project is active rather than archived. None of that makes it a product. It is a distribution channel: you add a marketplace, then install individual plugins from it by name. The unit of adoption is the plugin, not the repository. That distinction matters because the plugins have wildly different dependencies, different upstreams and different levels of completeness, and the README treats them all with the same one-paragraph treatment. If you are looking for a single coherent development environment with a unified configuration story, this is not it. If you want a menu of Claude Code extensions maintained by one person and installable with one command each, it is.
The problem it solves for Claude Code users
Claude Code supports plugins, and the practical problem for anyone using it daily is that specialised behaviour (conventional commits, PR review loops, refactoring patterns, a memory consolidation routine) has to be written, versioned and updated somewhere. dotclaude answers that by packaging each behaviour as its own installable unit under a shared marketplace namespace, frad-dotclaude. The audience is narrow and specific: people already running Claude Code who want to add capability without maintaining their own skill files. The breadth of the catalogue tells you the author is solving their own problems first. There is a git plugin for conventional commits and GitFlow branches, a github plugin whose /github:review-pr command watches CI and triages reviewer comments, a swiftui reviewer for iOS and macOS Clean Architecture, a hardware plugin that drives kicad-cli and openscad, and an office plugin covering patent applications, PRDs, video generation and writing trope detection. Those do not belong to one job function. A working developer might want three of them and have no use for the other nineteen, which is fine, because installation is per plugin.
The install path and what each plugin pulls in
Every plugin in the README follows the same installation shape. You install from the marketplace namespace, for example claude plugin install git@frad-dotclaude, or claude plugin install github@frad-dotclaude, or claude plugin install hardware@frad-dotclaude. There is no repository-wide install command documented, and no configuration file schema is given in the material. Some plugins declare prerequisites in their blurb, and those are the ones to read carefully. The antigravity plugin requires GEMINI_API_KEY and uv, and it delegates to Google Gemini Managed Agents in a remote sandbox, polling for completion through the Monitor tool. The generate-image plugin offers two backends, Google Gemini via gemini-3-pro-image or any OpenAI-compatible endpoint using gpt-image-2 or dall-e-3, which means you supply credentials for whichever you pick. The git-agent plugin is backed by a separate git-agent CLI, and its @git-agent entry point runs a health scan covering gitignore completeness, commit scope freshness, secret leaks via trufflehog, and co-change index health. That is a real external binary dependency, not a prompt. The pattern across the catalogue is that the interesting plugins are thin wrappers around something you have to install and configure yourself, and the README states the requirement without walking through setup.
Mirrors, forks and the licence question nobody asks
Several plugins are not original work. The mattpocock plugin is described as BDD-first engineering skills forked from mattpocock/skills v1.2.3. The lark plugin is mirrored from larksuite/cli. The marketing plugin is mirrored from coreyhaines31/marketingskills. The hyperframes plugin is mirrored from heygen-com/hyperframes. The storm plugin is a Claude-native port of Stanford STORM's two-stage research-to-article pipeline. The autoresearch plugin is inspired by karpathy/autoresearch. The repository as a whole is MIT, but the README does not state the licence of each mirrored or forked upstream, and a fork does not automatically inherit the parent's terms in a way you can assume. If you plan to use dotclaude inside a commercial product or redistribute it internally, the thing to check is the LICENSE file inside each plugin directory you install, not the badge at the top of the README. This is not legal advice; it is a statement about what the supplied material does and does not tell you. The material tells you the repository licence. It does not tell you the per-plugin licence for the six entries above.
Memory consolidation is the most opinionated plugin in the set
The memory plugin is where the design choices are sharpest and therefore the most useful to examine. It writes memory actively during conversation and exposes a manual /memory:consolidate command. The README is explicit that there is no auto-consolidation. It keeps harness memory at ~/.claude/projects/<escaped-cwd>/memory and a repo-local .memory/ directory idempotent with respect to each other. The consolidation routine is described as fail-closed and runs theme clustering, a practical-expiry prune, a ground-truth verify, an adversarial second pass, and finally a machine validator, validate-consolidate.py, which checks cluster coverage, report path rows and a privacy scrub. That is a lot of machinery for a memory feature, and the fail-closed posture is a deliberate trade. You get a pipeline that refuses to write when validation fails, and in exchange you get a manual step and a Python script in the loop. Anyone who wants memory to just work in the background should look elsewhere, because this plugin is designed around the assumption that unsupervised memory writes are a liability. Whether that assumption holds for your workflow is a judgement call the README leaves to you.
Where the documentation runs out
The README is a catalogue with install lines. It is not a manual. For most plugins there is no description of what files get written, what hooks are registered, or how to uninstall cleanly. The pi plugin entry is truncated mid-sentence in the supplied material, describing a bridge to pi (dev/pi), a minimal terminal coding harness, with /pi:delegate sending coding tasks with file, and the sentence stops there, so the delegation semantics cannot be confirmed from what is available. The plugin-optimizer plugin validates and optimizes Claude Code plugins against official best practices with agent-based fixes, but the README does not say which best-practice version it targets. The code-context plugin lists five retrieval methods (DeepWiki, Context7, Exa, git clone, web search) without explaining when to prefer one. This is the main limitation of the repository as a whole: the README tells you a plugin exists and how to install it, and stops before telling you what it does to your environment. For a plugin that only adds slash commands, that is survivable. For one that runs trufflehog across your repository or writes to ~/.claude/projects, you are installing on trust.
Alternatives and the difference in approach
The closest alternative is writing your own Claude Code skills and commands in a personal or team repository. That gives you full control over behaviour, no third-party update cadence, and no ambiguity about what a plugin does, at the cost of maintaining it yourself. The second alternative is installing the upstream projects directly where they exist as standalone tools: karpathy/autoresearch for the research loop, mattpocock/skills for the BDD engineering skills, larksuite/cli for Feishu and Lark operations. dotclaude's contribution in those cases is packaging and a naming convention, not new logic. The difference in approach is that dotclaude centralises distribution and lets you install a Claude Code plugin with one command, while going upstream means you track each project's own release process and integration instructions. If you use exactly one of the mirrored projects, going direct is simpler and you get the upstream documentation. If you want four or five of them behind a single marketplace and a consistent install command, dotclaude saves you the wiring. Neither approach gives you a support contract, and the README does not claim one.
Maintenance cost and version churn
The release history in the supplied material shows v1.12.1 in March 2026, v1.12.2 in June, and v1.13.0 later in June, with the last push in August. That is a steady patch cadence across a catalogue of 22 plugins, which means any given plugin changes less often than the repository as a whole. The maintenance question is not whether dotclaude is maintained but whether the plugin you depend on is. Mirrored plugins have a second clock: the upstream project moves, and the mirror has to be re-synced, and the README does not state a sync policy or a pinned upstream version for the mirrors beyond the mattpocock fork, which is pinned at mattpocock/skills v1.2.3. If you adopt a mirrored plugin, you are depending on someone else's release schedule filtered through this repository. The MIT licence means you can fork and self-maintain, which is the realistic escape hatch for a single-author collection. Budget for reading the plugin directory before you upgrade, not for reading a changelog, because the material does not indicate that per-plugin changelogs exist.
Editorial conclusion
dotclaude is worth adopting piecemeal if you already run Claude Code and want one narrow capability, such as the git-agent health scan or the memory consolidation validator, installed as a plugin rather than vendored by hand. It is the wrong choice if you need a stable, documented API surface, a single supported product, or anything with a written compatibility guarantee: the README is a catalogue of 22 entries with install lines and short blurbs, and several entries are explicitly mirrors of other people's repositories. Before installing anything, check the plugin directory you intend to use for a LICENSE file and for the upstream project it was forked or mirrored from, because the repository-level MIT badge does not tell you what the individual plugin contains.
Community notes