Model or dataset
NeoLabHQ/context-engineering-kit avatar
NeoLabHQ/context-engineering-kit

Context Engineering Kit: a plugin marketplace of Claude Code Skills, and what it costs you to install it

Hand-crafted Claude Code Skills focused on improving agent results quality. Compatible with OpenCode, Cursor, Antigravity, Gemini CLI, and others. Includes CodeRabbit open-source alternative.

1,700 stars159 forksTypeScriptGPL-3.0

At a glance

What is it?
Context Engineering Kit packages hand-written agent skills into installable plugins for Claude Code and several other agent CLIs. The interesting part is the per-plugin loading model and the spec-driven development plugin; the awkward part is how unevenly that model survives on non-Claude providers.
Who is it for?
Adopt it if you already run Claude Code and want granular, per-plugin skills rather than one large prompt bundle, and if you are willing to read each plugin's prompt files before trusting them. Do not adopt it if you need identical behaviour across Claude Code, Gemini CLI and Cursor, because the README states that only Claude Code supports per-plugin selection and that npx skills drops subagents.
Can I use it commercially?
Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
Is it still maintained?
Yes. The repository last received commits 20 days ago.
What is it written in?
Mainly TypeScript, 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

The problem: agent context fills up with instructions you did not ask for

Most prompt collections for coding agents are shipped as one archive. You install the whole thing, and every command, skill and agent definition becomes eligible for loading. Context Engineering Kit takes the opposite position. The README describes it as a collection of advanced context engineering techniques and patterns with minimal token footprint, and the granularity claim is explicit: each plugin loads only its specific agents, commands, and skills, without overlap or redundant skills. Installing the marketplace itself, via /plugin marketplace add NeoLabHQ/context-engineering-kit, does not load anything. The README states that this step makes all plugins available for installation but does not load any agents or skills into your context. Loading happens per plugin.

That is the actual product decision. The kit is not a model, a runtime or a code generator. It is a set of prompt artifacts plus an installation mechanism that tries to keep the artifacts out of your context window until you ask for them. The audience is developers who already use an agent CLI daily and have noticed that quality degrades as the instruction set grows. The README also notes the marketplace is based on prompts the company's own developers used daily, supplemented by plugins from benchmarked papers and other projects. Treat that as provenance, not as validation.

What a plugin actually contains, and why command-oriented skills are preferred

The README's key features list gives the design rule: the project prefers command-oriented skills with sub-agents over general information skills when possible, to minimize populating context with unnecessary information. Read that carefully, because it is a trade-off rather than a free win. An information skill loads reference material into the model's context and lets the model decide when to apply it. A command-oriented skill with a sub-agent instead runs a defined procedure in a separate context and returns a result. The second approach keeps the main conversation smaller, but it also means the model has less room to improvise. You get predictability at the cost of flexibility.

The reflexion plugin is the clearest example in the README. You ask the agent to implement something, then run /reflect. According to the README, it analyses results and suggests improvements, fixes obvious issues immediately, and for minor issues suggests improvements you can respond to. There is also a hook path: if you include the word reflect in the initial prompt, the README states the hook automatically runs /reflect afterwards. A third command, /memorize, extracts resolution strategies and saves the insights to project memory so the same class of issue does not reappear. That is a coherent loop: generate, critique, persist. Whether the critique is any good depends entirely on the prompt text in the plugin, which the README does not reproduce.

Installation differs sharply by provider, and the README says so

For Claude Code, the sequence is two commands. First /plugin marketplace add NeoLabHQ/context-engineering-kit, then /plugin install reflexion@NeoLabHQ/context-engineering-kit. The plugin name is qualified with the marketplace, so you can install several plugins side by side.

For Gemini CLI, the README gives gemini extensions install https://github.com/NeoLabHQ/context-engineering-kit, with an explicit warning: this installs every plugin's skills and agents as a single bundle, there is no per-plugin selection, and the README states Gemini CLI does not support it. The suggested workaround is to delete skills and agents you do not need after installation. Antigravity CLI has the same shape, using agy plugin install https://github.com/NeoLabHQ/context-engineering-kit/antigravity, pointing at the repository's antigravity folder, and the same bundle warning.

For Cursor, Codex, OpenCode and others, the route is the vercel-labs/skills command: npx skills add NeoLabHQ/context-engineering-kit, which lets you pick skills. The README adds a caveat that matters more than it looks: each provider uses its own agent format, and npx skills does not support subagents, so this installation method will not provide the full experience. An alternative is given as npx openskills install NeoLabHQ/context-engineering-kit followed by npx openskills sync. The honest reading is that the granular loading model, which is the project's main argument, is a Claude Code feature. Everywhere else you are either accepting a bundle or losing subagents.

The SDD plugin and the Arc42 dependency

Spec-Driven Development is the plugin the release notes spend the most words on. The README states it is based on the Arc42 specification standard for software development documentation. That is a real constraint, not a marketing line: Arc42 prescribes a section structure for architecture documentation, so the plugin's generated artifacts will follow that structure whether or not it matches how your team already writes specs.

The changelog in the README traces an evolution. v2.0.0 rewrote the plugin from scratch, and the README claims it is now able to produce working code in 99% of cases on real-life production projects. That number is the project's own claim with no methodology attached, so it should not be repeated as a finding. v2.1.0 added code quality guidelines from the DDD plugin into the SDD agents. v3.1.0 embedded DDD and SOLID rules in the developer agent and added a dedicated code-reviewer agent that applies functional and OOP best-practices rules together with Muda waste analysis to reduce code complexity and duplication. Muda is the lean-manufacturing term for waste, and using it as a review criterion is unusual enough to be worth reading the reviewer prompt directly before you rely on it.

A related plugin, Subagent-Driven Development, is described as a distilled version of SDD that uses meta-judge and judge sub-agents to generate specifications on the fly and in parallel with implementation. That is a different bet: SDD front-loads specification work, SADD interleaves it. Which one fits depends on whether your team can pause implementation to agree on a spec.

Limitations the README states, and one it does not

The stated limitations are all about portability. Per-plugin selection exists only on Claude Code. Gemini CLI and Antigravity CLI install everything as one bundle, and the recommended cleanup is manual deletion of files. The npx skills path loses subagents, which the README says means it will not provide the full experience. If your team standardises on Cursor, you are installing a reduced version of the kit and should expect the command-oriented skills to behave differently.

The unstated limitation is verification. The README describes plugins as scientifically proven and based on techniques validated by reputable benchmarks and studies, but it does not name a single benchmark, sample size or evaluation method in the material available here. The 99% figure in the v2.0.0 note has no stated measurement procedure. That does not make the prompts bad. It means the quality claim is not something you can check from the repository description, and the only way to evaluate it is to read the prompt files and run them against your own codebase.

There is also a structural cost to the design. Because plugins are granular and command-oriented, you accumulate a set of commands to remember: /reflect, /memorize, and whatever the SDD and DDD plugins add. The kit reduces context pollution but increases the surface area of things a developer has to know exists. On a small project with one developer, that overhead may exceed the benefit.

How this differs from a review bot such as CodeRabbit

The repository description mentions it includes a CodeRabbit open-source alternative, which invites a comparison. CodeRabbit is a hosted review service: you connect a repository, it comments on pull requests, and the review happens outside your machine on its infrastructure. The kit's review capability, as described in the release notes, is a code-reviewer agent inside the SDD plugin that applies functional and OOP best-practices rules plus Muda waste analysis. That runs inside your agent session, on your machine, against whatever context the agent has loaded.

The difference in approach is where the judgement lives. A hosted bot reviews a diff with a fixed ruleset and posts comments. The kit's reviewer is a prompt that a coding agent invokes, which means the review is shaped by the surrounding session, and you can edit the rules. You cannot edit CodeRabbit's ruleset in the same way, but you also do not have to maintain it. The kit's version has no dashboard, no PR integration of its own, and no historical record beyond what your agent writes into project memory via /memorize. There is also a CI integration guide referenced at neolab.gitbook.io/cek/guides/ci-integration, which the README links but does not reproduce, so the CI story cannot be assessed from this material.

Licence and maintenance: GPL-3.0 and a fast release cadence

The repository is licensed GPL-3.0. That matters more than usual for a prompt collection, because GPL-3.0 is a copyleft licence, and the artifacts here are text files that get embedded into your development workflow. How copyleft applies to prompt files that you modify and redistribute, or to tooling you ship that bundles them, is a question for your own legal review. This article does not give legal advice, and the repository description alone is not enough to determine the answer. If you plan to vendor the skills into a product you distribute, read the LICENSE file rather than the badge.

The maintenance picture visible here is active. The last push is dated 2026-08-26, and the release notes show v3.10.0 on the same day, v3.9.1 a week earlier on 2026-08-19, and v3.9.0 on 2026-08-18. That is a tight cadence, which cuts both ways. Fixes arrive quickly, and so do changes to prompt text that may alter agent behaviour between versions. Because the plugins are installed by name from a marketplace, an upgrade can change what /reflect does without any change on your side. Pinning to a specific release, or reading the diff between versions before upgrading, is the practical mitigation. The README does not describe a version-pinning mechanism, so verify that one exists in your provider's plugin tooling before you depend on it.

Editorial conclusion

Adopt it if you already run Claude Code and want granular, per-plugin skills rather than one large prompt bundle, and if you are willing to read each plugin's prompt files before trusting them. Do not adopt it if you need identical behaviour across Claude Code, Gemini CLI and Cursor, because the README states that only Claude Code supports per-plugin selection and that npx skills drops subagents. Before installing anything, check the GPL-3.0 terms against how you distribute your own tooling, and inspect the reflexion and SDD plugin directories to see exactly which agents and commands get loaded into your context.

Official sources

  1. License: GPL-3.0
  2. NeoLabHQ/context-engineering-kit on GitHub
  3. Project website
  4. README
  5. Releases
Community notes

Community notes