giuseppe-trisciuoglio/developer-kit: A Claude Code Plugin Marketplace for Java, TypeScript, Python, PHP and AWS

What Developer Kit actually is, and who it is aimed at

Developer Kit is a plugin marketplace for Claude Code and other agentic CLIs. The README describes it as teaching Claude "how to perform development tasks in a repeatable, high-quality way" instead of returning generic answers. The unit of distribution is a plugin named after a language or domain: developer-kit-java, developer-kit-typescript, developer-kit-python, developer-kit-php, developer-kit-aws, developer-kit-ai, developer-kit-devops, developer-kit-tools, developer-kit-core and github-spec-kit.

The intended user is a working developer who already drives an agentic CLI and wants stack-specific behaviour without writing the prompts themselves. The Java plugin ships 9 agents, 11 commands, 51 skills and 4 rules covering Spring Boot, LangChain4J, AWS SDK and GraalVM. The TypeScript plugin is the largest by component count with 13 agents, 3 commands, 25 skills and 17 rules, aimed at NestJS, React, Next.js, Drizzle ORM and monorepos. Python is comparatively thin at 4 agents and 4 rules for Django, Flask, FastAPI and AWS Lambda. That imbalance is worth noting before you commit: the depth you get depends entirely on which plugin you install.

This is not a runtime, a library you import, or a service. Nothing executes in your build. What you install is a set of Markdown files that the CLI reads.

The four layers: skills, agents, rules and commands

The README organises capability into four layers. Skills are described as reusable capabilities loaded on demand, and the usage example shows the CLI surfacing an activation line such as a spring-boot-crud-patterns skill becoming active. Agents are specialised sub-agents invoked either through natural language or through commands like /devkit.java.code-review and /devkit.typescript.code-review. Commands are slash commands. Rules are path-scoped instructions that activate on file globs.

The rules layer is the one with a real design constraint. The README states plainly that plugins do not automatically install rules into your project, and that you must copy them manually or use a Makefile target. The example rule shown in the README targets Java files and instructs the model to always use constructor injection and never use field injection with @Autowired. That is a sensible default for Spring code, but it only reaches your project if you copy it.

Each plugin is self-contained, with its own manifest at .claude-plugin/plugin.json alongside agents/, commands/, skills/ and rules/ directories. The repository root also carries .skills-validator-check/, scripts/, docs/ and a Makefile. The plugin.json manifest is the boundary: it declares what a plugin contributes, and the Makefile reads those manifests to decide what to copy where.

Installing Developer Kit and running a first refactor

For Claude Code, the README gives a marketplace install. The /plugin command is issued inside the CLI, not in your shell.

/plugin marketplace add giuseppe-trisciuoglio/developer-kit

If you prefer a clone, the Makefile auto-detects which CLIs are present and installs for all of them. The README also lists per-CLI targets.

cd developer-kit
make install

To target one CLI only, use the corresponding target: make install-claude, make install-opencode, make install-copilot or make install-codex. The Makefile header notes that Copilot CLI receives agents and skills but no commands, Codex CLI receives skills only with no agents, and Kimi and Kiro are also supported. That asymmetry is a property of the host tools, not a bug in the installer, but it means the same repository gives you a different surface depending on which CLI you use.

After installation, the README's quick start is to launch the CLI and check what is available.

claude
/help

Then invoke a Developer Kit command such as /devkit.refactor. The example prompts in the README include generating a CRUD module for a User entity with NestJS and Drizzle ORM, reviewing a Spring Boot service for security issues, and creating a CloudFormation template for ECS with auto-scaling. If you want the rules layer, remember the extra step from the README.

make copy-rules PLUGIN=developer-kit-java

The README notes that copied rules activate automatically based on the globs: patterns in each file's header, so after the copy you should see .claude/rules/ populated with the plugin's .md files.

Where the installation story breaks down

The rules gap is the most concrete limitation and the README does not hide it. You install a plugin, and the part of it that governs how the model writes your code every day is left on the shelf until you run a second command. Anyone who installs developer-kit-java through /plugin and then wonders why field injection is still being suggested has hit exactly this.

The second limitation is coverage. Skills and agents are concentrated in Java and TypeScript. If your stack is Go, Rust, C# or Kotlin, the plugin table offers nothing, and the 150+ figure is a total across all plugins rather than a per-language guarantee. Python, at 4 agents and 4 rules, is a much thinner proposition than the headline number suggests.

The third is that this is prompt content, not verified code. The README describes skills as providing patterns, templates and best practices, but nothing in the project's own documentation indicates the generated output is compiled, tested or linted. The validation that exists, the .skills-validator-check/ directory and the plugin-validation workflow, checks the components themselves, not the code your agent produces with them. Treat the output as a draft from a knowledgeable colleague, which is what it is.

The Python validator is a separate, smaller tool

The pyproject.toml at the repository root does not describe Developer Kit. It describes a package named claude-validator, version 1.0.0, with the description "Pre-commit validation system for Claude Code components (Skills, Agents, Commands)". It requires Python 3.8 or later, depends only on PyYAML, and exposes a console script entry point named claude-validator that maps to validators.cli:main. The package sources live under .skills-validator-check/ and tests are configured to run from .skills-validator-check/tests with pytest.

The classifier in that file reads "Development Status :: 4 - Beta", which is a more honest signal than the README's framing. If you are writing your own skills or agents for a plugin, this validator is the piece you would run before submitting, and the plugin-validation GitHub Actions workflow referenced in the README badges suggests the project runs it on itself. The security-scan workflow is a second badge in the same row.

For a user who only wants to install plugins, the validator is irrelevant. It matters if you intend to contribute a skill, because it defines what a well-formed component looks like in this repository's terms.

An alternative approach: writing your own project instructions

The obvious alternative is not another plugin marketplace but the built-in mechanism every one of these CLIs already provides: a project-level instruction file, such as CLAUDE.md in Claude Code, that you write yourself. The difference in approach is authorship and scope. Developer Kit ships pre-written, path-scoped rule files and skill definitions maintained by one author across ten plugins; a hand-written instruction file is smaller, tailored to your codebase, and under your control from day one.

The trade-off is real in both directions. Developer Kit gives you breadth immediately, including conventions you may not have thought to encode, such as the constructor-injection rule. A hand-written file gives you nothing out of the box but never drifts from your actual conventions and never needs a copy step. Teams with unusual architecture or a strong internal style guide will likely get more from a short custom file than from 51 Java skills. Teams starting a greenfield Spring Boot or NestJS project, where the framework defaults are the conventions, are the better fit for the plugin route. You can also combine them: install developer-kit-core plus one language plugin, then layer your own rules on top.

Maintenance, licensing and the upgrade path

The repository is not archived and the last push was on 2026-09-10, the same day as the v4.0.1 release. The two prior releases, v4.0.0 and v3.2.0, are both dated 2026-08-18, which suggests the versioning has moved quickly and that a major bump can land within days of a minor one. There is a CHANGELOG.md at the root, and the README links to it, so upgrade notes are at least a documented destination rather than something you infer from diffs.

The upgrade cost depends on how you installed. With the /plugin marketplace route, updates flow through the CLI's plugin mechanism. With a clone plus Makefile, you are pulling the repository and re-running make install, which will overwrite the component files it manages. That is where the rules copy step becomes a maintenance consideration: if you copied rules into .claude/rules/ and then edited them to match your codebase, a later make copy-rules or manual copy will clobber those edits unless you keep them elsewhere. The README does not document a merge strategy for locally modified rules, and the Makefile offers make backup for current configs, which is the closest thing to a safety net described.

The project is MIT licensed. That is permissive and, as far as the repository states, applies to the plugin content and the validator package alike, which the pyproject.toml also marks as MIT. This is not legal advice; if you redistribute the skill content inside a commercial product, read the LICENSE file at the root rather than relying on the badge.

Editorial conclusion

Adopt it if you already work inside Claude Code or a supported agentic CLI and want domain-specific skill files for Spring Boot, NestJS, Django or CloudFormation rather than writing your own. Skip it if you need a hosted service, a stable API surface, or tooling for a language outside the plugin list; this is a collection of Markdown components, and the rules folder in particular is not installed for you. Before relying on it, run `make list-plugins` and `make status` against your clone to see which plugins and components the Makefile actually discovers, then open the plugin.json of the one plugin you intend to use and confirm its declared components match what you expect.

Frequently asked questions

Official sources

1. giuseppe-trisciuoglio/developer-kit on GitHub
2. Issues
3. License: MIT
4. README
5. Releases