agentleFS
ldaumeldaume/agentic-engineering-harness/skills/engineering/pnpm/SKILL.md

pnpm

Skill3 starsChanged 3 months agoMITView on GitHub

Handles pnpm package management, workspaces, lockfiles, scripts, catalogs, overrides, patches, Corepack, and dependency troubleshooting. Use when running pnpm commands, configuring pnpm workspaces, fixing strict dependency resolution, managing packageManager versions, or updating dependencies in Node.js projects.

  • Installs packages

30 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use antfu-design, xsai and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • wltn7810-dotcomSkill

    antfu-design

    antfu-style design conventions, broadened. UnoCSS-first, class-based semantic tokens with dual light/dark for tooling and devtools UIs, plus design-read, anti-slop, and micro-interaction polish for landing pages and product surfaces. Use when building or refactoring any interface with UnoCSS.

    Also in 3 projects that use this

  • alint-devSkill

    xsai

    Use this skill when the user is building with `xsai` or any `@xsai/*` package, or is evaluating xsAI for a small OpenAI-compatible workflow with text generation, streaming, tool calling, structured output, embeddings, image generation, speech synthesis, or transcription.

    Also in 3 projects that use this

  • SentrySkill

    nitro

    Build and deploy universal JavaScript servers with Nitro v3. Use when working with nitro.config.ts, defineNitroConfig, defineHandler, defineConfig, server.ts entry, filesystem routing, route rules, useStorage, defineCachedHandler, useDatabase, definePlugin, runtime hooks, Vercel/Cloudflare deployment, or migrating from Nitro v2/nitropack.

    Also in 3 projects that use this

  • MicrosoftSkill

    simple-english

    Write or rewrite text in plain, layman-readable English in the spirit of ASD-STE100 Simplified Technical English: short sentences, active voice, simple tenses, one word one meaning, condition before command, every technical term defined at first use, no AI slop. Default mode is Plain. Strict mode applies full STE vocabulary compliance when the user names STE, ASD-STE100, or compliance. Use for documentation, READMEs, runbooks, procedures, error messages, release notes, incident reports, API guides, and explanations for readers outside the field. Also use when the user says "STE", "Simplified Technical English", "ASD-STE100", "plain English", "layman's terms", "explain it simply", "no jargon", "de-slop", "make this readable", "write for non-native readers", or asks for docs that translate well. The same rules govern the reply: answer first, prose only.

    Also in 3 projects that use this

  • MicrosoftSkill

    typescript

    TypeScript best practices for this monorepo. Use this skill when: (1) writing new TypeScript code, (2) reviewing TypeScript code, (3) working with API responses, fetch calls, or JSON parsing, (4) adding or modifying types and interfaces.

    Also in 3 projects that use this

  • GoogleSkill

    setup-matt-pocock-skills

    Configure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.

    Also in 3 projects that use this

  • +1 more from microsoft

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 0 are common, 8 are distinctive, and 7 are very specific to this project.

  • 0

    Common

    Most of the 19 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use this for Node.js package management with pnpm's strict dependency model.

    line 8
  2. Very specific:

    Read package.json, pnpm-workspace.yaml, pnpm-lock.yaml, .npmrc, engines, packageManager, and toolchain files.

    line 14
  3. Distinctive:

    Use the repo's pinned pnpm version through Corepack, mise, Volta, or the documented path.

    line 16
  4. Distinctive:

    Run commands from the workspace root unless a package-level command is explicitly needed.

    line 18
  5. Very specific:

    Do not replace npm/yarn/bun with pnpm unless the user asked.

    line 20
  6. Distinctive:

    Treat lockfile changes as intentional and review them.

    line 21
  7. Very specific:

    Use --filter for targeted work.

    line 36
  8. Distinctive:

    Keep root scripts as orchestration.

    line 37
  9. Very specific:

    Prefer workspace:* for internal package dependencies.

    line 38
  10. Distinctive:

    Use catalogs only when the repo already uses or wants centralized versions.

    line 39
  11. Very specific:

    Use overrides sparingly and document why.

    line 40
  12. Distinctive:

    Add dependencies to the package that imports them.

    line 44
  13. Distinctive:

    Keep dev tools in the narrowest sensible workspace.

    line 45
  14. Distinctive:

    Do not bypass peer dependency warnings without understanding runtime impact.

    line 46
  15. Very specific:

    Use pnpm why before deleting or deduplicating dependencies.

    line 47

“Common” is measured: kept by at least 6 in 10 of the 19 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

pnpm

Use this for Node.js package management with pnpm's strict dependency model.

Project Fit Check

Before running pnpm:

  1. Read package.json, pnpm-workspace.yaml, pnpm-lock.yaml, .npmrc, engines, packageManager, and toolchain files.
  2. Use the repo's pinned pnpm version through Corepack, mise, Volta, or the documented path.
  3. Run commands from the workspace root unless a package-level command is explicitly needed.
  4. Do not replace npm/yarn/bun with pnpm unless the user asked.
  5. Treat lockfile changes as intentional and review them.

Commands

pnpm install
pnpm --filter <package> <script>
pnpm exec <tool>
pnpm why <package>
pnpm update <package>
pnpm patch <package>

Workspace Rules

  • Use --filter for targeted work.
  • Keep root scripts as orchestration; package scripts do package-local work.
  • Prefer workspace:* for internal package dependencies.
  • Use catalogs only when the repo already uses or wants centralized versions.
  • Use overrides sparingly and document why.

Dependency Rules

  • Add dependencies to the package that imports them.
  • Keep dev tools in the narrowest sensible workspace.
  • Do not bypass peer dependency warnings without understanding runtime impact.
  • Use pnpm why before deleting or deduplicating dependencies.

Red Flags

  • running install from the wrong directory
  • changing package manager version without aligning docs and CI
  • lockfile churn unrelated to the task
  • adding dependency at root because it is convenient
  • using --force or --shamefully-hoist as a first move

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.