Context Engineering Kit adds judge agents to Claude Code

NeoLabHQ’s Context Engineering Kit is a marketplace of Claude Code plugins that wraps an agent’s work in reflection loops, judge sub-agents and written specifications, and it puts a token price on each layer. The README in the project’s GitHub repository, as it stood on September 4, compares eight ways of running an agent. Each one gets an accuracy estimate by changeset size and a token overhead.

The kit is built from prompts the company’s developers say they have used daily for a long time, plus plugins drawn from benchmarked papers. Its plugins cover reflexion, spec-driven and subagent-driven development, code review, Git, TDD, domain-driven design, Kaizen root-cause analysis, docs, language rules and MCP server setup.

Accuracy against token cost

The table gives the probability of getting a result that is “fully accurate” with “zero hallucinations”, split by how many files the task changes: 1-3, 4-10, 10-20 and 20+. The authors say the figures come from more than a year of real development on production projects.

• One-shot prompt: 60%-80% for 1-3 files, falling to 1%-20% for 20+ files, no overhead.
• /reflect: 68%-91% for 1-3 files and 1%-30% for 20+, at 1k-3k extra tokens.
• /reflect plus /memorize: 79%-87% and 5%-30%, at 2k-5k tokens.
• /do-and-judge: 90% for 1-3 files and 30% for 20+, at 1.5x-3x the tokens.
• /do-in-steps: 92% and 50%, at 3x-5x.
• /plan-task plus /implement-task: 94% and 70%, at 5x-20x.
• Adding /brainstorm first: 95% and 80%, at 5x-20x.
• /plan-task, human review, then /implement-task: 99% up to 20 files and 95% for 20+, at 5x-35x.

On 1-3 files, the table sets the one-shot prompt’s 60%-80% against 99% for the human-review flow, which costs 5x-35x the tokens. On 20+ files the same pair reads 1%-20% against 95%. The README’s note on the one-shot row explains the drop: “with context growth LLM quality degrades exponentially”. The authors frame the plugins as complementary, so a team can choose its own trade between reliability and token cost for each task.

What the judge sub-agent does

The middle rows of the table come from the Subagent-Driven Development plugin, installed as sadd. Its /do-and-judge command hands the task to an implementation sub-agent and has an independent judge verify the output, retrying until the judge passes it. The README says this counters “context rot” (the slide in model quality as a long session fills its context window), along with bias, hallucinations and missed requirements. /do-in-steps runs the same loop separately for each group of files, decomposing the task automatically and passing context between sequential sub-agents.

The judges score against structured rubrics and want evidence. The same plugin carries /judge-with-debate, where several judges argue toward consensus or report their disagreement, /do-competitively, which generates competing solutions and synthesises the best one, and /tree-of-thoughts for exploring a solution space and pruning weak branches. Since v2.2.0, the plugin also works as a distilled version of the spec-driven workflow: meta-judge and judge sub-agents write the specification on the fly, in parallel with implementation. A later release, v3.6.0, added logic to stop the agents iterating on nitpicks.

Specs as a build step

The top rows belong to the Spec-Driven Development plugin, sdd, which the authors describe as “development as compilation”. In practice that means three commands. /add-task creates a draft task file under .specs/tasks/draft/ from a single prompt. /plan-task refines it into a full specification and moves it to .specs/tasks/todo/. The README then says to restart the Claude Code session to clear context before running /implement-task, which writes the code and moves the task to .specs/tasks/done/. Simple tasks may take 30 minutes; complex ones can run for a few days.

Planning is split across agents in phases. A researcher studies the technology and writes a reusable skill file, a code-explorer maps the existing codebase and its patterns, and a business-analyst writes the acceptance criteria, rubric and test strategy. A software-architect designs the solution, and a tech-lead breaks it into per-step sub-task files grouped into independently verifiable phases, each with its own reviewer model.

During implementation a developer agent takes exactly one step from its sub-task file and must leave the tree building and green. A code-reviewer then checks each phase against its acceptance criteria. Since v3.1.0 the reviewer also runs Muda waste analysis, a Lean technique for finding work that adds no value, here aimed at complexity and duplication, and the developer agent has DDD and SOLID rules embedded.

The specification template follows arc42, a documentation standard for software architecture, cut down to drop the sections the authors found added nothing to implementation quality or degraded it. The plugin also implements MAKER, a pattern from the paper “Solving a Million-Step LLM Task with Zero Errors”, which launches agents with clean state and keeps memory on the filesystem. The README pitches the plugin at large existing codebases, adding a codebase impact analysis to each planning phase that lists the files likely to change and the patterns to follow.

The success claims vary within the README itself. The v2.0.0 note says the rewritten plugin produces working code “in 99% of cases on real-life production projects”, while the plugin’s own section says that in tests on the team’s production projects it “in 100% of cases” generated working code aligned with the initial prompt. The authors add that quality will be sub-optimal without human feedback. Developers can annotate a generated spec with // comments and rerun /plan-task --refine, or pass --human-in-the-loop to verify each phase. For large work they advise splitting tasks and linking them through /add-task arguments, which writes a depends_on section into the task file’s frontmatter. Without that, the README suggests tools like ralph-loop to keep the agent running longer.

Reflection and memory

The cheapest rows come from the Reflexion plugin. /reflect makes the model review its previous output: obvious issues get fixed on the spot, and minor ones come back as suggestions. /memorize pulls resolution strategies out of those reflections and writes them into CLAUDE.md, so the same mistakes are less likely in later tasks. A hook fires /reflect automatically when the word “reflect” appears in the prompt; it needs bun installed, though the command itself does not. The README cites the Self-Refine and Reflexion papers, which report 8–21% quality gains across seven tasks including coding and mathematical reasoning, and the Agentic Context Engineering paper, which it says beats strong baselines by 10.6% in agent applications.

Among the other plugins, Review calls itself an open-source, higher-quality version of CodeRabbit. It runs six specialised agents, including a bug-hunter, a security-auditor and a historical-context-reviewer, filters findings by impact and confidence, and integrates with GitHub Actions. The FPF plugin, built on Anatoly Levenchuk’s First Principles Framework, has the agent generate 3-5 competing hypotheses, check them against project constraints and evidence, and compute trust scores before a human picks one. The core FPF specification runs to about 600k tokens, so the plugin loads it into a subagent on the Sonnet[1m] model, and the README warns that “such an agent can consume your token limit quickly.”

Installing outside Claude Code

In Claude Code, /plugin marketplace add NeoLabHQ/context-engineering-kit makes the plugins available without loading anything into context. Each /plugin install, for example reflexion@NeoLabHQ/context-engineering-kit, then loads only that plugin’s agents, commands and skills. Skills follow the agentskills.io specification. Gemini CLI and Antigravity CLI install the whole kit as one bundle because neither supports per-plugin selection, so unneeded skills have to be deleted by hand. Cursor, Codex, OpenCode and others go through npx skills add, which lets you pick skills but does not support subagents. The README warns that this route “won’t provide the full experience”.

The repository’s release notes show v3.8.1 adding subagent support for Gemini and Antigravity.