Best agent skills for a JavaScript/TypeScript monorepo

A monorepo is where an agent's general knowledge goes stale fastest. The conventions move, and when they move the failures are silent: config written to a file the tool stopped reading, a task key from an older generation, a release-age policy set in the wrong unit. Nothing throws. You find out when a cache never hits, or an override never applies, or a build ships output nobody asked for. Installing a skill is how you stop your agent writing remembered config — provided the skill itself is current.

That last clause is the whole problem. Two skills for the same build tool can disagree about the top-level key in turbo.json: Vercel's own writes tasks in every example, two others write pipeline in every example, and one of those also pins turbo: ^1.10.0 in the root manifest it hands your agent. Nothing on the outside of either skill tells you they disagree. Everything you need is on the first screen inside them, which is where this piece spends its time.

Top picks

Turborepo: install Vercel's own, not a copy of it

vercel/turborepo/turborepo opens with a rule rather than a tutorial: scripts live in each package, get registered in root turbo.json, and the root package.json does nothing but call turbo run. Most of its length is anti-patterns, and they are the ones that actually cost cache hits — Turborepo does not read .env files, so the file has to be listed in inputs or edits invalidate nothing; a prebuild script that builds siblings by hand is a missing workspace:* declaration wearing a disguise; and transit nodes exist for the lint and typecheck case where you want parallel execution and correct invalidation at the same time. Most rivals sharing the name are that same document frozen earlier — module-federation/core/turborepo is stamped 2.8.14-canary.8 and predates the futureFlags.globalConfiguration section that lets a task keep a global file out of its hash — while the independent ones vary wildly in depth: Mindrally/skills/turborepo is a tidy bullet list of structure, caching and dependsOn advice with no anti-patterns in it at all. Two independents write pipeline throughout instead of tasks — wshobson/agents/turborepo-caching and bobmatnyc/claude-mpm-skills/turborepo — and wshobson's root manifest template pins turbo: ^1.10.0 alongside it. Install wshobson's anyway if you self-host a cache: it is the only one that sketches the server side of the protocol — GET, PUT and HEAD on /v8/artifacts/:hash, plus the --api, --token and --team flags that aim the CLI at your own endpoint — and its filter cookbook is the clearest around. Sketch is the operative word, since its HEAD handler calls fs.access while the file only imports createReadStream, createWriteStream and mkdir; let it teach you the cache and let Vercel's skill write your turbo.json.

pnpm: antfu's, because it is the one that knows where config lives now

antfu/skills/pnpm leads with the thing that breaks agents: pnpm settings now live in pnpm-workspace.yaml in camelCase, .npmrc is for authentication and registry credentials only, and the pnpm field in package.json is no longer read. The body itself is a routing table — catalogs, overrides, patches, hooks, peer-dependency rules, config dependencies, the global virtual store, and a supply-chain row covering allowBuilds, minimumReleaseAge and trustPolicy — with the detail behind reference files, which is the right shape for something an agent loads mid-task. sanity-io/next-sanity/pnpm and hairyf/skills/pnpm are earlier cuts of the same generator, sharing the opening paragraph but still pointing configuration at .npmrc and package.json fields; hairyf's has the widest reference surface of the three (Docker, Podman, changesets, git-branch lockfiles), so take it knowingly if you want those. The one to watch is Mindrally/skills/pnpm, which is hand-written rather than generated and teaches overrides in the package.json pnpm field and peer settings in .npmrc — precisely the two locations the current model abandons. It is also the friendliest explanation of filter syntax in the set, including the difference between ...pkg and pkg..., so it is a good read and a bad writer.

Workspace links: the shortest pick here prevents the most common agent mistake

nrwl/nx-ai-agents-config/link-workspace-packages exists for one moment: your agent hits Cannot find module @org/ui or TS2307 and reaches for a tsconfig path alias. Its trigger text names those errors and tells the agent not to patch around them, then gives the four real fixes — pnpm add @org/ui --filter @org/app --workspace, yarn workspace @org/app add @org/ui, npm install @org/ui --workspace @org/app, and bun's workspace: protocol — with what each writes into package.json, which differs per manager. The closing notes are the part worth keeping: npm and bun hoist shared dependencies to the root, pnpm does not, yarn berry has no node_modules at all under Plug'n'Play, and the root manifest should be private: true. It is published by the Nx team but nothing in it is Nx-specific; the Nx-only material sits in nrwl/nx-ai-agents-config/nx-import, which documents that nx import adds the imported directory itself to pnpm-workspace.yaml rather than a glob for the packages inside it, so cross-package imports break until you fix the pattern by hand.

Publishing: the tsdown migration skill is the one to install first

rolldown/tsdown/tsdown-migrate carries a finding you would not guess: do not migrate a tsup config straight to the current tsdown. Version 0.23 removed the tsup-compatibility options — bundle, outExtension, publicDir and the rest — and ignores them silently at runtime, so a single missed mapping produces wrong output with no error anywhere. The skill routes you through 0.22.14, the last version that still accepts them and emits a deprecation warning for each, and treats a warning-free build as the completeness check before you upgrade. Around that it has the unglamorous material that makes a migration finish: property renames, default-value differences, plugin import transforms, dependency namespace moves, and a checklist. It is also the only one of these that pins the build-time Node floor precisely — 22.18+, 24.11+ or 26+, with odd-numbered and end-of-life lines excluded — where rolldown/tsdown/tsdown, the everyday config reference, says only 22.18.0 or higher, and both note that output can still target older runtimes. antfu/skills/tsdown matches that looser wording; sanity-io/next-sanity/tsdown is an earlier cut with no runtime section at all, opening straight into when to use it.

Supply chain: grafana's check-npm is an audit, not advice

grafana/skills/check-npm is read-only by construction and says so in its first line. It detects the manager from packageManager then the lockfile, then runs four checks with thresholds instead of opinions: tool version (npm 11.15.0, yarn 4.14.0, pnpm 11.0.0), lifecycle scripts disabled, dependency protocols, and minimum release age. The protocol check is the one worth having — anything that is not a semver range, workspace:, patch: or an npm: alias gets flagged with its path, name and value, which catches the git URL somebody added in a hurry two years ago. It also encodes a unit trap you will otherwise hit: the same three-day release-age policy is written 3 for npm and 4320 for yarn and pnpm, because one counts days and the others count minutes. Output is a PASS/FAIL table with a paste-ready fix per failure, and it knows pnpm 11 stops reading script policy from .npmrc and package.json#pnpm entirely.

Dependency reduction: grafana's audit, with its scope read first

grafana/skills/audit-and-reduce-dependencies runs check-npm as step zero and refuses to weaken any hardening it finds while cleaning up, which is a discipline most upgrade skills do not have. Its best idea is measuring rather than guessing: to rank a direct dependency by transitive cost it removes it from the manifest, reinstalls, measures the lockfile delta, then reverts both the manifest and the lockfile before testing the next one — giving you exclusive closure, not just total. Before adding or upgrading any named version it checks the registry's publish time and stops if the version is under 72 hours old, and every mutation runs with --ignore-scripts, including the workaround for pnpm dlx not accepting that flag directly. Two caveats matter: it is pnpm-only and will stop rather than migrate you, and @grafana/* packages are exempt from its freshness gate, which is a Grafana-shaped hole in an otherwise general skill. If you are on npm or bun instead, jamditis/claude-skills-journalism/supply-chain-hardening covers the same cooldown idea with a third unit — days for npm, seconds for bun — plus a sandboxed pre-install scan under bwrap or firejail for the times you have to bypass the wait.

How to tell same-name skills apart

Skills are community-published and their names are not namespaced. Anyone can publish one called turborepo, and many people have — some are the official document vendored at different moments, some are independent work of very different depth, and occasionally a name covers a different tool altogether. The name only tells you the topic; the publisher and the body tell you what you are actually installing. So read the first screen and look for a tell, not a summary.

• The turbo.json key splits the field. Vercel's document and its copies write tasks; wshobson's and bobmatnyc's write pipeline. It is the first config block in all of them, so this costs you ten seconds.
• pnpm dates itself by where it puts settings. Does configuration go in pnpm-workspace.yaml with camelCase keys, or into .npmrc and the package.json pnpm field? The second answer marks the older model, and stale pnpm advice fails quietly rather than loudly — your overrides simply stop applying.
• The version stamp, where there is one. The Turborepo family tells your agent to write a $schema URL with the version inside it, and each copy inherits the version it was taken at: antfu/skills/turborepo stamps 2.9.19-canary.9, saffron-health/libretto/turborepo 2.9.7-canary.14, sanity-io/next-sanity/turborepo 2.9.15-canary.3. That single line dates a file better than anything else in it. The tell does not invert, though: bklit/bklit-ui/turborepo and secondsky/claude-skills/turborepo write an unversioned schema URL, as do the hand-written skills, so no stamp means you cannot date it — not that it is current.
• Stars measure the repo, not the skill. langfuse/langfuse/turborepo has the largest star count of anything here named turborepo, ahead of Vercel's own repo. It is a copy of Vercel's document stamped 2.8.21-canary.9, and its repo declares no usable license. Those stars belong to Langfuse.
• Length cuts both ways. aj-geddes/useful-ai-prompts/monorepo-management is short because it is a table of contents; the substance is all behind reference files, and its quick-start root manifest declares npm workspaces while its scripts pass -r, which is pnpm's recursive flag. wshobson/agents/monorepo-management is a good orientation tour — tool tradeoffs, package exports maps, a changesets release flow — and it also writes pipeline, so it orients well and configures badly.

What the frontmatter tells you that the prose does not

The pnpm skills are the only ones in this space that admit where they came from. antfu's, sanity-io's and hairyf's all credit Anthony Fu as author and name both the upstream generator and a generation date in their metadata: June, January and February respectively. Read that date first — it is the entire difference between the current config model and the abandoned one, and it also tells you that the org in the id is who vendored a file, not who wrote it. The Turborepo copies are less forthcoming; their metadata carries a version and nothing else, which is why the $schema line matters there.

License is the other line to read before a skill goes into a repo you do not own. shipshitdev/skills/turborepo is a real condensation of the Vercel material rather than a copy of it — it keeps the anti-patterns and the transit-node pattern, writes tasks, and fits in a fraction of the length — and it ships with no license file, which is a problem for vendoring and not for reading. Langfuse's copy has the same gap with far more visibility. Both are fine to learn from and awkward to commit.

Last, read the description for scope you did not ask for. grafana's two skills are shaped around Grafana plugins and assume pnpm; jamditis's hardening skill is framed for a journalism toolchain. Both are good, both carry that assumption in their defaults, and both are trivially usable elsewhere once you have seen the assumption written down.

The short version

Install Vercel's own turborepo skill and let it write turbo.json; keep wshobson's turborepo-caching for the remote cache and the filter cookbook, and for nothing else. Take antfu's pnpm, because it is the one that knows where configuration lives now. Add link-workspace-packages, which is a page long and buys back every hour your agent would spend inventing path aliases. When you publish, tsdown-migrate is the skill that gets a tsup config across intact. For hygiene, check-npm audits without touching anything, and audit-and-reduce-dependencies measures instead of guessing.

What that buys you is mostly absence. No turbo.json written against the wrong key. No pnpm overrides parked in a file the current release ignores. No migration that produces wrong output and no error. No skill in your repo that you cannot actually license. None of those failures announce themselves, and none of them are visible from outside a skill — but all four are visible on its first screen, in the key it writes, the location it points at, the version it was frozen at, and the license line. Open that screen before you install. It is the cheapest check in the whole setup.