ClaudeCodeAgents: review and verification agents for Claude Code

What an agent definition actually is here

The repository contains a collection of specialized agent definitions for Claude Code, which the README describes as configurations that give Claude Code specific expertise and behaviours for particular tasks. When invoked, these agents help with focused areas like code review, testing, verification and quality assessment.

The important thing to understand is that these are Markdown files, not programs. The repository's top level is seven agent definitions plus a README and a licence, and there is no source directory, no build step and no test suite. Each agent is a document that Claude Code reads and follows.

The consequence is worth being precise about, because it determines what you can expect. An agent definition shapes how the model approaches a task: what it looks at, what it checks, what it concludes and how it reports. It does not add a capability the model lacks, and it does not run anything on its own. The UI testing agent, for example, is described as automatically selecting appropriate testing tools, Puppeteer, Playwright or Mobile MCP, which means the definition instructs the model to drive those tools, and the tools still have to be installed and configured.

The format is what the contributing section describes: each agent definition follows a specific format that Claude Code can interpret and use. That is the whole authoring contract, and it means these files are effectively prompts written for one particular agent runtime.

The agents and what each one is for

Six agents are described in the README, with a seventh file, ultrathink-debugger.md, present in the repository but not listed in the documentation.

Jenny is the implementation verification agent. Jenny verifies that implemented code actually matches project specifications, and the listed uses are verifying that authentication systems match security requirements, ensuring that database schemas implement multi-tenant specifications correctly, validating that implementations fulfil stated requirements, and getting an independent assessment of feature completeness. The framing is comparison against a written specification, not a judgement about code quality.

The Claude MD compliance checker ensures that code changes adhere to project-specific guidelines defined in CLAUDE.md files. It verifies that new implementations follow project standards, checks that modifications comply with coding guidelines, ensures consistency with documented project principles, and validates adherence to team conventions.

The code quality pragmatist reviews code for over-engineering, unnecessary complexity and poor developer experience. It identifies over-engineered solutions, finds unnecessary abstractions, spots premature optimisations, and ensures code remains simple and maintainable. The name is the point: the agent is an argument against speculative generality.

Karen, the reality check agent, provides a realistic assessment of project completion and creates actionable plans. It assesses actual against claimed project completion, cuts through incomplete implementations, creates realistic plans to finish the work, and validates functional completeness without over-engineering.

The task completion validator verifies that claimed task completions are actually functional, validating that authentication systems work end to end, ensuring database integrations are functional, verifying features work as intended and not just stubbed, and confirming implementations meet underlying goals.

The UI comprehensive tester performs thorough UI testing across web and mobile platforms, testing user flows and edge cases and validating functionality across different platforms with systematic UI validation.

The pattern the six agents share

Read together, the agents describe a review process rather than six unrelated tools, and the order in which the documentation suggests using them is the order of a development cycle.

After implementing a feature, use the task completion validator to ensure it is truly complete. Before committing code, run the code quality pragmatist to check for over-engineering. When requirements seem met, use Jenny to verify the implementation matches the specifications. For UI changes, deploy the UI comprehensive tester for thorough validation. To assess project status, use Karen for a realistic completion assessment. After making changes, run the Claude MD compliance checker to ensure guideline compliance.

The two ideas that recur are verification against a written source and a deliberate hostility to claims. Jenny compares code to a specification, the compliance checker compares code to a CLAUDE.md, the completion validator compares a claim of finished work to the actual behaviour, and Karen compares a stated project status to reality. Three of the six agents are variations on the same move, which is to take what has been said and check it.

The other idea is restraint. The pragmatist looks for over-engineering, unnecessary abstractions and premature optimisations, and Karen explicitly validates completeness without over-engineering. Both agents exist to stop a model from producing more work, which is an unusual thing to want from a coding assistant and probably reflects how these definitions were written in practice rather than as a design exercise.

The remaining two agents are the only ones that leave the editor. The completion validator asks whether an authentication system works end to end and whether a database integration is functional, and the UI tester drives Puppeteer, Playwright or Mobile MCP. Those are the two that need tools installed and configured on the machine.

The licence is unusually permissive for prompts

The licence field on the repository records MIT, and the README states it in a way that goes beyond the standard grant. You are free to use, copy, modify and redistribute these agent definitions for any purpose, including commercial use, with any tool or platform, naming Claude Code, Cursor, OpenCode, or anything else.

That last clause is the one to notice. These are prompts written for a particular runtime, and prompts are unusually portable: the format is a document, and the reasoning in it is not tied to a specific API. The author is effectively saying that the definitions work in other coding agents too, which is a strong statement for content that was written for one tool.

The MIT terms themselves are the standard ones, so the obligations are to keep the copyright notice and the licence text with copies and to disclaim warranty. For a set of Markdown files that is a light requirement, and it makes the collection a reasonable thing to vendor into an internal repository alongside your own agent definitions.

The repository is not archived and the last push was on 2026-08-14, and the recent releases section says there are no GitHub releases, so the commit history is the version record.

Where the collection is the wrong choice

The first limitation is that these agents verify, they do not test. A definition that tells a model to check whether an authentication system works end to end is a model running the check, which means the tool, the credentials and the environment all have to be in place, and the result is a model's account of what it did rather than a recorded pass or fail. A CI pipeline that runs a real test suite gives a stronger guarantee than an agent that reviews the code and reports a verdict.

The second is that the compliance agent needs something to comply with. Its whole value is checking changes against project-specific guidelines defined in CLAUDE.md files, and a project without those files gets a check against nothing. The definitions raise the ceiling of what your project can check, and the ceiling is still set by how well you have written down your standards.

The third is that there is no evidence here that any of this works. The repository has no tests, no issue tracker activity documented in the README, no benchmark and no record of which of the six agents people actually use. The definitions are plausible and specific, and that is as far as the public documentation goes. Anyone adopting them should treat the first agent as a hypothesis to test on their own codebase rather than as a known quantity.

The fourth is the undocumented file. ultrathink-debugger.md is in the repository but not in the README's list of available agents, so a reader cannot tell what it does or why it is not documented. That is a small signal about the curation of the collection.

The fifth is the vendor dependency in practice. Even though the definitions are licensed for any tool, the way an agent is invoked, what a subagent can see, and what the model is allowed to do differ between runtimes, so a definition tuned for one may behave differently in another.

How this compares with writing your own subagent and with a lint rule

The comparison with writing your own agent definition is the first one, and the difference in approach is entirely about who pays the setup cost. A definition of your own is a prompt you wrote, tuned to your codebase, your conventions and the way you talk about problems, and it costs an afternoon. A shared collection costs nothing and gives you a starting point, and the risk is that the author's assumptions about what a good review looks like are not yours.

The second comparison is with a linter or a static analysis rule, and here the difference in kind matters. A linter is deterministic, it runs in CI, it fails the build, and it costs nothing per run. An agent is probabilistic, it runs when someone asks, and it produces an argument rather than a verdict. The right question for any check is whether you want a gate or a second opinion, and for a gate the linter wins, and for a second opinion the agent is more useful because it can read the intent behind a change rather than only the syntax of it.

The third comparison is with a code review by a colleague, and the honest point is that an agent definition is a partial substitute rather than a real one. It never reads the ticket, it does not know what the change is for beyond what the diff shows, and it has no stake in the outcome. That is a reason to use it as a supplement and a reason not to trust it as the only review a change gets.

The fourth is a comparison with the process of writing the review criteria down. The compliance agent only does something a project has already thought about, and for many teams that act, writing a short set of conventions and a checklist in a CLAUDE.md is a better investment than any agent.

What to do before you copy these into a project

Four things to check.

Read the agent definition files themselves rather than the summary. The README lists what each agent is for, and the behaviour is in the Markdown. A definition is a prompt, and you cannot evaluate a prompt from its summary, and the version in the repository may differ from what the README describes.

Decide which of the six you actually need. They overlap, and the task completion validator and Jenny are close enough that using both on the same change is likely to produce two reviews of the same thing. The pragmatic set for most people is the quality pragmatist before a commit and the compliance checker afterwards, with the others reserved for the specific situations the documentation lists.

Check that your project has a CLAUDE.md worth checking against, if you intend to use the compliance agent, and that the guidelines in it are the ones you would actually want enforced rather than a wish list.

And take the licence at face value. The MIT terms allow you to copy, modify and redistribute these definitions for any purpose, including commercial use, with any tool or platform, so vendoring them into an internal repository and adapting the wording to your own codebase is expressly permitted, and the only obligations are to keep the notice and to disclaim warranty.

Editorial conclusion

ClaudeCodeAgents suits someone who uses Claude Code regularly and has noticed that the model reports work as complete when it is not, and who wants a second opinion that is scoped to verification rather than to writing more code. It is the wrong tool for a team that has not yet settled how its own standards are written down, because the compliance agent can only check guidelines that exist in a CLAUDE.md file, and the wrong choice if you need automated checks in CI, since these are prompt definitions rather than tests. Before using them, read the agent definition files themselves, because the README summarises their intent rather than the behaviour they produce, and the MIT licence explicitly allows copying them into another tool.

Frequently asked questions

Official sources

1. darcyegb/ClaudeCodeAgents on GitHub
2. Issues
3. License: MIT
4. README