claude-code-skills: A Small Marketplace of Bounded Engineering Skills for Claude Code and Codex
Standalone engineering skills for Claude Code and Codex: review, audit, optimization, testing, product discovery, architecture, and safe publishing.
At a glance
- What is it?
- The repository ships 24 standalone skills across seven plugins, each capped at 200 lines and required to track its checklist items with evidence. It is a good fit if you want narrow, auditable agent instructions rather than an orchestration framework, and a poor fit if you need cross-skill state or bundled tooling.
- Who is it for?
- Adopt it if you want a specific auditor or reviewer skill you can read end to end before trusting it, and if your team already works inside Claude Code or Codex. Skip it if you expect a pipeline that carries state between planning, implementation, and delivery, because the README states the repository contains no orchestration hierarchy and no MCP servers.
- 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 4 days ago.
- What is it written in?
- Mainly PowerShell, 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 the Repository Actually Ships
This is a catalog of agent instructions, not a tool. The README describes it as a compact marketplace of standalone engineering skills for Claude Code and Codex, distributed through two host-specific marketplace catalogs. The stated contents are the skills themselves, minimal plugin manifests, documentation, and a static catalog site. The README is explicit about what is absent: no MCP servers, no orchestration hierarchy, no distributed shared resources, no generated skill copies, and no evaluation harness. That list of omissions is the most useful thing in the README, because it tells you the shape of the dependency you are taking on. You are adding text files that a coding agent reads, plus manifests that tell the host where to find them. The primary language listed for the repository is PowerShell, which matters for anyone expecting a Node or Python install path. The audience is engineers already working in Claude Code or Codex who want a bounded procedure for a specific job: review a plan before execution, audit a test suite, upgrade dependencies in reversible batches, record an architecture decision. Each skill is meant to cover one outcome, not a workflow spanning several.
The 200-Line Ceiling and the Evidence Rule
Two authoring constraints define how these skills behave. The first is length: the README states skills have a 200-line ceiling and no minimum. A ceiling with no floor is an unusual choice, and it means a skill can be very short if the domain does not need more. The second is accountability. Skills track every domain checklist item with evidence or an explicit applicability reason, and a final self-check reconciles evidence, scope, omissions, and verdict. Reports follow a fixed order: result, scope, evidence, verification, completion, with skill-specific decisions and evidence added where relevant. The practical effect is that when a skill reports on your repository, it is supposed to say which checklist item it checked, what it found, and why any item was skipped rather than silently dropping it. That is the part worth evaluating in practice. An explicit applicability reason can still be a weak reason, and the format does not force the agent to be right, only to be explicit. Supporting references live inside the skill and load only for the relevant workflow branch. The delivery review panel is named as one such branch, which suggests the heavier review machinery is opt-in within a skill rather than always loaded.
The Seven Suites and What Each One Covers
The review suite has two skills: index 11 validates an implementation plan against repository evidence before execution, and index 12 reviews scoped delivery acceptance, regressions, and release risks. The codebase audit suite has five: documentation trust and factual accuracy (21), cross-cutting code health, security, delivery, and maintainability (22), test value, coverage, isolation, and oracle strength (23), system boundaries, ownership, contracts, and dependency topology (24), and queries, transactions, consistency, and resource lifecycle (25). The optimization suite has five more: profiling and keeping only measured improvements (31), dependency upgrades in reversible verified batches (32), replacing bounded capabilities when net value is proven (33), comparing alternatives under a frozen reproducible experiment contract (34), and implementing a bounded change through the smallest complete root-cause fix (35). Testing splits into strategy planning without changing code (41) and building, updating, consolidating, or retiring acceptance evidence without repairing product code (42). Product discovery has a single skill, 51, for comparing opportunities using current evidence and a low-cost validation path. Architecture has six, numbered 71 through 76, covering baseline drivers and constraints, documenting implemented architecture from repository evidence, target design proposals, single-decision records with alternatives and consequences, diagram building, and migration planning. The README states these architecture workflows operate independently and communicate only through optional repository documents. The maintainer suite (61 through 64) handles reviewing skill repositories, publishing a Git repository with remote verification, publishing tagged GitHub releases, and drafting fact-checked Discussions announcements. The README says users who only consume the engineering skills do not need it.
Installing Only the Plugins You Need
The README gives one installation instruction: browse the skills catalog or install only the plugins you need. It does not reproduce host-specific install commands in the portion available here, so the exact invocation for adding a marketplace or enabling a plugin has to come from the catalog site or the host's own documentation. What the material does establish is the layout you will be pointing at. Skills live under plugins/<suite>/skills/<index>-<name>/SKILL.md, for example plugins/review-suite/skills/ln-11-plan-reviewer/SKILL.md and plugins/codebase-audit-suite/skills/ln-22-codebase-auditor/SKILL.md. The repository supports the portable Agent Plugins v1 standard while retaining native Claude Code and Codex distribution compatibility, and ships two host-specific marketplace catalogs. If your host is neither Claude Code nor Codex, the Agent Plugins v1 path is the one to check first, and the specification is linked from the README rather than summarized in it. The authoring format itself is defined in SKILL_TEMPLATE.md at the repository root, which is the file to read if you intend to write a skill in the same style or judge whether an existing one follows the house rules. Because there is no evaluation harness, nothing in the repository verifies that a skill produces good output on your codebase. The first run is the test.
Where the Standalone Design Breaks Down
The same property that makes these skills auditable makes them unable to carry context. The README states there is no orchestration hierarchy and no distributed shared resources, and the architecture suite section says each workflow operates independently and communicates only through optional repository documents. So if you want a plan produced by skill 11 to be the input that skill 35 implements against, the handoff is a document you place in the repository and a human or agent decision to read it. Nothing enforces that the document is current, that the implementing run read it, or that the two agree on scope. The 200-line ceiling has a second cost: a bounded skill can only encode so much domain knowledge, and the README's own framing is that instructions not supporting the single bounded outcome are removed. Depth that would not fit is pushed into supporting references loaded per branch, which means the agent must correctly decide which branch applies. If it picks the wrong branch, the relevant reference never loads, and the evidence format will still produce a tidy report. The maintainer suite's skill 61 is described as distinguishing static review from authorized behavioral validation, which reads as an acknowledgment that reviewing skill text is not the same as confirming a skill behaves correctly. That distinction applies to every skill here, not just the ones under review.
Compared With a General-Purpose Review Agent
The obvious alternative is a single review or audit agent configured with broad instructions and left to decide its own procedure. The difference is not quality of model but structure of output. A general agent typically returns prose findings in whatever order it prefers. These skills return result, scope, evidence, verification, completion, with each checklist item either evidenced or marked inapplicable. That makes the output diffable across runs and makes it possible to see what was skipped. The trade is coverage: a general agent can wander into an area no checklist anticipated, while a skill with a fixed checklist will mark that area out of scope or miss it. The audit suite's split into five separate auditors (documentation, codebase, tests, architecture, persistence) is the clearest expression of this. You get a narrower, more repeatable pass per run, and you have to run several to cover a repository. The optimization suite applies the same logic to change: skill 31 keeps only measured improvements and skill 34 requires a frozen reproducible experiment contract before comparing alternatives. If your team's problem is that performance work proceeds on intuition, that constraint is the reason to look at this repository. If your problem is that nobody knows where to start, a checklist-driven skill will not tell you.
Maintenance, Versioning, and Licence
Releases are dated rather than semantic: v2026.04.21, v2026.05.06, and v2026.07.12, with the most recent push to master on 2026-09-05. The gaps between those three releases are roughly two weeks, two months, and two months, so the cadence is irregular and you should not plan around a fixed schedule. Because the artifacts are markdown and manifests, an upgrade is mostly a matter of pulling the new skill text and re-reading the skills you depend on. The README's promise that there are no generated skill copies means there is no build step that could drift from source, which simplifies upgrades. It also means any local edits you make to a skill will conflict with the next pull, so if you adapt a skill to your repository, track that adaptation. The licence is MIT, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are preserved. That is a summary of the identifier, not legal advice; if you vendor these skills into a product, have someone confirm the notice requirements. The maintainer suite adds a maintenance surface of its own: skills 62 through 64 can commit, push, publish releases, and post Discussions announcements. Those are write actions against a live repository, and the README frames them as operating on approved changes, so the approval step is where your control lives.
Editorial conclusion
Adopt it if you want a specific auditor or reviewer skill you can read end to end before trusting it, and if your team already works inside Claude Code or Codex. Skip it if you expect a pipeline that carries state between planning, implementation, and delivery, because the README states the repository contains no orchestration hierarchy and no MCP servers. Before installing anything, open the SKILL.md for the index you actually want, confirm its checklist matches the artifact you will hand it, and check whether your host supports the Agent Plugins v1 standard or only the native marketplace catalogs.
Community notes