Matteo Collina's skills are a curated prompt library for Node.js work

Eleven skills, each with a declared speciality

The README describes the repository as a collection of skills for AI-assisted development, and the table lists what is in it.

| Skill | Description | |-------|-------------| | `documentation` | Technical writer specializing in the Diátaxis documentation framework | | `fastify` | Comprehensive best practices for Fastify development | | `init` | Creates and maintains high-signal AGENTS.md guidance for repositories | | `linting-neostandard-eslint9` | Linting workflows with neostandard and ESLint v9 flat config | | `node` | Best practices for Node.js development | | `nodejs-core` | Deep Node.js internals expertise including C++ addons, V8, libuv, and build systems | | `oauth` | OAuth 2.0/2.1 specification expert with deep RFC knowledge and Fastify integration patterns | | `octocat` | Git and GitHub wizard using gh CLI for all git operations and GitHub interactions | | `skill-optimizer` | Improves skill activation, benchmark outcomes, and regression resistance across models | | `snipgrapher` | Configure and use snipgrapher to generate polished code snippet images | | `typescript-magician` | TypeScript wizard specializing in advanced type systems, complex generics, and eliminating any types |

Reading the descriptions tells you what the author thinks an assistant is bad at. The node and nodejs-core pair covers the ordinary case and the internals case, where a model asked about a native addon or a libuv behaviour would otherwise guess. The typescript-magician entry names two specific things, advanced type systems and complex generics, and its third clause, eliminating any types, is the giveaway that this is aimed at a codebase that has accumulated them. The octocat entry is scoped to the gh CLI, so the instruction is about the commands rather than about GitHub.

The `init` skill is different in kind from the rest. It creates and maintains high-signal AGENTS.md guidance for repositories, so it is the skill that bootstraps the others, since an assistant following an AGENTS.md file needs that file to exist and to be worth reading.

The two most project-specific entries are `snipgrapher`, which is about configuring a specific tool to generate polished code snippet images, and `linting-neostandard-eslint9`, which is a workflow rather than a general topic.

Skills are reviewed files, not a runtime dependency

The Usage section is short and the wording matters. This package contains best practices and skills for AI-assisted development.

There is no installation step, no import, and no API. The package metadata confirms it, with private set to true and version 1.0.0. So this is not a library that anything consumes at runtime, it is a body of written instructions that an assistant reads, and the package manifest exists so that the repository can be linted, type checked and tested like any other TypeScript project.

The scripts show that.

"scripts": {
  "typecheck": "tsc --noEmit",
  "lint": "eslint .",
  "test": "node --test"
}

Type checking with tsc --noEmit, linting with eslint, and tests with the Node.js built-in test runner. The repository top level listing shows the matching configuration files, an eslint.config.mjs, a tsconfig.json, an AGENTS.md, a src/ directory, a skills/ directory and a docs/ directory.

The two directories are the interesting ones and they are separate. skills/ holds the skill definitions, and src/ holds the TypeScript that the project type checks and lints. The skills are the product, the src/ directory is the machinery that keeps the repository honest.

The dev dependencies are current and match the flat config era of the linter. @eslint/js at ^10.0.1, eslint at ^10.0.3, globals at ^17.4.0, typescript at ^5.7.0, typescript-eslint at ^8.57.0 and @types/node at ^22.0.0, plus close-with-grace at ^2.5.0, which is the graceful shutdown library.

There is a small inconsistency worth noting between the repository and the skills it contains. One of the skills is named linting-neostandard-eslint9 and describes ESLint v9 flat config, while this repository's own dev dependency is eslint at ^10.0.3. That is not a contradiction, the skill is a workflow document for a specific toolchain and the repository has moved on, but it is the kind of thing that tells you the skill descriptions are not automatically in sync with the tooling they describe.

The skills are benchmarked, and the benchmarks are committed

The Benchmarking section is the part that distinguishes this from a folder of prompt files, because it links two documents.

- Cross-model skill benchmarking workflow (docs/skill-benchmarking.md) - Benchmark run history (docs/skill-benchmark-runs.md)

The workflow is a procedure and the run history is the record of what happened when it was run. Committing the run history next to the workflow is the part that matters, because it means the results are reviewable in the same pull request as the change that produced them.

The skill-optimizer entry describes what this machinery is for. It improves skill activation, benchmark outcomes, and regression resistance across models.

Those three phrases describe three distinct failure modes. Activation is whether a skill gets loaded at all, and a skill that never activates is dead weight no matter how good it is. Benchmark outcomes are whether the assistant's output improves when the skill is present, which is the measurement that matters. And regression resistance across models is the hard one, because a skill tuned against one model's behaviour can degrade when the model changes, and the only way to catch that is to run the benchmark against several models and keep the history.

So the collection has a feedback loop on itself. The skill-optimizer is a skill about improving skills, and the mechanism for knowing whether it helped is the benchmark workflow, whose results are committed.

The docs/ directory at the top level holds both documents, and they sit alongside the skills/ directory rather than inside it, which suggests the benchmarking machinery is considered part of the project's documentation rather than part of the payload.

An AGENTS.md that is itself a maintained artefact

The AGENTS.md file at the top of the repository and the `init` skill are related, and the relationship is worth spelling out because it is a pattern more projects are converging on.

An AGENTS.md file is the instruction set an AI coding assistant reads when it works in a repository. It is the place where a project says how to build it, how to test it, what the conventions are and what not to touch. The quality of an assistant's work on a codebase is bounded by the quality of that file, and a generic one produced once and never updated is worse than none, because it asserts things that are no longer true.

The `init` skill exists to address that. It creates and maintains high-signal AGENTS.md guidance for repositories. The word maintain is the important one, since creating such a file is a solved problem and keeping it accurate is not. A skill that regenerates the file from the repository's actual state, its build commands, its test layout and its conventions, keeps it from rotting.

The repository has both the file and the skill, which is a good sign that the author dogfoods the approach. The skill is listed among the others rather than being the main entry, which suggests the AGENTS.md is the primary artefact and the skill is a tool for producing it.

The remaining entry point to the collection is the description itself, best practices and skills for AI-assisted development, and the fact that the skills are scoped to a single stack. The entries cover Node.js and Fastify practice, Node internals, TypeScript, OAuth with Fastify patterns, GitHub, documentation, linting, the optimiser and snippet images. The stack focus is deliberate, and it is the same focus as the author who wrote them.

Where this collection is the wrong thing to reach for

The first wrong case is a team that does not use an AI coding assistant. There is no library to import, no configuration to enable and no runtime behaviour to change. The value is entirely in text that a model reads, and if your workflow does not involve one, the repository is a set of Markdown files.

The second wrong case is a stack other than Node.js. The collection is explicitly described as a collection of skills for modern Node.js development, and the majority of the entries assume that context. The typescript-magician and documentation skills transfer, but the Node.js, Fastify, nodejs-core and OAuth entries do not, and the OAuth one even names Fastify integration patterns.

The third wrong case is a team that treats an assistant's output as authoritative. A skill is guidance written by one person about how they want things done, and it is not the same as a specification. Where a skill says best practices, it is a set of opinions with a specific author's taste, and adopting the collection means adopting those opinions. A team that has already settled its conventions has nothing to gain from a foreign set, and one that has not should be careful about taking a whole library of opinions from a single source without reviewing each.

The fourth wrong case is a team expecting maintenance guarantees. The package is marked private, so it is not published to a registry, and the repository has no GitHub releases. The skills change in place, with the last push on 2026-10-18, and a skill file that changes under you is a change in how your assistant behaves. There is no version pinning story here in the way there would be for a published dependency, so if a skill needs to be frozen for a release, that is a fork you have to make.

How it differs from writing the guidance yourself

The comparison worth making is with the alternative every team reaches for, which is writing the same guidance into a wiki page, a contributing document, or a paragraph in every prompt, and the difference in approach is where the text lives and what shape it has.

A wiki page is prose written for humans. It is good at explaining why and bad at being applied consistently, because a model reading a page of narrative has to infer which paragraph is an instruction. A skill is written to be applied, and the difference in shape shows in the descriptions, which are all one-line statements of scope rather than explanations.

The second difference is reuse across projects. Guidance in a wiki lives with one repository. A skill file is a portable unit that can be read by any assistant working in any repository, which is why a collection of them is a different artefact from a documentation site.

The third difference is measurement. A wiki page has no way of telling you whether following it improves anything, because there is no counterfactual. A skill can be benchmarked, and this repository does that, with a documented workflow and a committed run history, and a skill-optimizer whose purpose is to improve activation and outcomes. That closes a loop that most guidance never closes, and it is the strongest argument for the collection being a project rather than a folder.

The fourth difference is the maintenance burden, and here the comparison narrows. Writing guidance for an assistant is not free, and the skills that are most valuable are the ones that encode something a model would otherwise get wrong, the OAuth flow, the Node internals, the ESLint flat config migration, the TypeScript generics. A model will produce plausible output for most of those, and plausible is the failure mode, so having the specific version written down is worth the effort. A skill that only restates what a competent developer would say anyway is not worth maintaining.

Editorial conclusion

This collection fits a Node.js developer who uses an AI coding assistant and wants domain guidance that is written down once, in a form that can be reviewed, diffed and benchmarked, rather than rediscovered in every prompt. It does not fit a team on a stack other than Node.js, since most of the skills assume Node.js, and it does not fit a team that expects a maintained library, since the package is marked private and never published. Before adopting a skill, read its own file rather than the table, run the documented benchmarking workflow to see whether it activates on your prompts, and note that the package is private, the licence is MIT, and the last push was on 2026-10-18.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mcollina/skills on GitHub
4. README