Skills for Real Engineers

Why it's ranked here

The licensing is unambiguous: MIT, declared consistently in three places, so there is no doubt about forking or adapting it. It is released rather than dumped, with a real release process and a check that keeps the plugin manifest's version in step. Distribution runs through Claude Code's official marketplace, a channel with a review step. And the problem it addresses costs real hours, while the answer is a set of small documents you can read, adapt and delete individually rather than a process framework you must adopt whole.

What's good

The collection applies its own doctrine to itself. One document names the levers of writing for machine readers, keeping context small, revealing detail progressively, cutting filler words, avoiding negation, and the other documents visibly use them. They work as gates rather than advice: the debugging guide refuses to let the assistant guess at causes until it can name one command it has already run and show the output, and the testing guide forbids writing a test at a boundary the user has not confirmed. The included vocabulary file is a worked example of the artifact the documents ask you to produce.

Tradeoffs

Two of the top-level guidance files are byte-identical copies, exactly the duplication the writing guide argues against. Nothing here executes, so nothing verifies that a document still behaves as written: there is no test step, and whether a gate actually holds depends on the model reading it. The set is large and mostly human-invoked, so the human carries the index of what exists; the repository says this outright and ships a router document to compensate. A few instructions assume the author's own machine, pointing the assistant at a personal wiki under a home directory. And the code review flow is inert until a one-time setup step has run.

How to use it well

Pick one install route and commit to it: taking both leaves every document duplicated. The routes differ in ownership rather than content; the plugin updates itself but cannot be edited, while the copy route hands you files you own to adapt, which is the stated design intent. Run the setup document once per repository before anything else, because the review and triage flows read the configuration it writes, and write the project vocabulary file early since the testing and debugging guides consult it. Then start with two documents, not twenty-five: a grilling session before a change and the testing reference during it.

Observed

License

MIT, declared in LICENSE, package.json and .claude-plugin/plugin.json

Contents

.claude-plugin/plugin.json lists 25 skill directories: 18 engineering, 7 productivity

Install surface

Two mutually exclusive routes: a read-only Claude Code plugin, or an installer that copies editable files into your repo

Tests

package.json defines no test script; the documents are prose with no executable verification

Executable code

The only shell script among the files read is scripts/link-skills.sh, marked dev-only and not a supported installer