agentleFS
KIMJINWOO4KIMJINWOO4/vue-skills/skills/antfu/SKILL.md

antfu

Skill28 starsChanged 30 days agoMITView on GitHub

Anthony Fu's opinionated tooling and conventions for JavaScript/TypeScript projects. Use when setting up new projects, configuring ESLint/Prettier alternatives, monorepos, library publishing, or when the user mentions Anthony Fu's preferences.

  • Installs packages

11 other projects use a version of this, 9 of them edited; 1 new project in the last 4 weeks, against 1 the 4 before.

Adopted by

Steady: 1 new project took it in the last 4 weeks, 1× the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 1 new projectWeek of Oct 11: 1 new projectWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 2 in all, so this is a hint, not a trend.

Most recently taken up by

Used with

Projects with it also use antfu-design, nitro and 6 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

  • 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

  • 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

  • GoogleSkill

    improve-codebase-architecture

    Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

    Also in 4 projects that use this

  • MicrosoftSkill

    caveman

    Ultra-compressed response style that reduces output token count while preserving technical accuracy, with intensity levels and auto-clarity safety rules

    Also in 3 projects that use this

  • MicrosoftSkill

    grill-with-docs

    Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.

    Also in 3 projects that use this

  • +1 more from google

The file

Show its rules and text

We split this skill into the rules it gives an agent

18 rules. 3 are common, 1 is distinctive, and 14 are very specific to this project.

  • 3

    Common

    Most of the 9 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 14

    Very specific

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

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

    Type separation: Always separate types and interfaces into types.ts or types/*.ts

    line 17
  2. Common:

    Prefer isomorphic code: Write runtime-agnostic code that works in Node, browser, and workers whenever possible

    line 22
  3. Common:

    Clear runtime indicators: When code is environment-specific, add a comment at the top of the file:

    line 23
  4. Very specific:

    Explicit imports: Prefer explicit import statements.

    line 39
  5. Very specific:

    No path aliases by default: Use relative imports (./foo, ../bar).

    line 40
  6. Very specific:

    Test files: foo.ts → foo.test.ts (same directory)

    line 49
  7. Very specific:

    Use describe/it API (not test)

    line 50
  8. Very specific:

    Use toMatchSnapshot for complex outputs

    line 51
  9. Very specific:

    Use toMatchFileSnapshot with explicit path for language-specific snapshots

    line 52
  10. Very specific:

    Use fast-npm-meta to look up the latest version of a package — it queries a small metadata endpoint instead of downloading the full …

    line 72
  11. Very specific:

    Prefer this over npm view <pkg> version when you only need the latest version, and over reading package.json from the registry directly.

    line 82
  12. Very specific:

    Always enable antislop: true.

    line 115
  13. Distinctive:

    Use Knip to catch unused files, exports and dependencies — the linter only sees one file at a time.

    line 121
  14. Very specific:

    Every project exposes a ci script that runs all checks in one command:

    line 136
  15. Very specific:

    Add .githooks to .gitignore and simple-git-hooks: true under allowBuilds in pnpm-workspace.yaml.

    line 171
  16. Very specific:

    Prefer npm Trusted Publishing (OIDC) over NPM_TOKEN secrets: releases run on CI from a v* tag via release.yml with id-token: write, and nr …

    line 179
  17. Very specific:

    Use named catalogs in pnpm-workspace.yaml for version management:

    line 183
  18. Common:

    Avoid the default catalog.

    line 192

“Common” is measured: kept by at least 6 in 10 of the 9 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

Reference template: antfu/starter-ts. When scaffolding a new TypeScript project, mirror its package.json scripts, eslint.config.js, knip.json, tsdown.config.ts and workflows rather than inventing a new layout.

Coding Practices

Code Organization

  • Single responsibility: Each source file should have a clear, focused scope/purpose
  • Split large files: Break files when they become large or handle too many concerns
  • Type separation: Always separate types and interfaces into types.ts or types/*.ts
  • Constants extraction: Move constants to a dedicated constants.ts file

Runtime Environment

  • Prefer isomorphic code: Write runtime-agnostic code that works in Node, browser, and workers whenever possible
  • Clear runtime indicators: When code is environment-specific, add a comment at the top of the file:
// @env node
// @env browser

TypeScript

  • Explicit return types: Declare return types explicitly when possible
  • Avoid complex inline types: Extract complex types into dedicated type or interface declarations

Explicitness

Favor explicit, traceable code over implicit "magic". A reader (human or agent) should be able to follow where every name comes from without running tooling.

  • Explicit imports: Prefer explicit import statements. Avoid auto-imports — when a framework provides them (e.g. Nuxt/Nitro), turn them off for new projects (see app-development).
  • No path aliases by default: Use relative imports (./foo, ../bar). Only use path aliases (@/, ~/, #imports, etc.) when they are already configured in the project; don't introduce new ones for greenfield code.

Comments

  • Avoid unnecessary comments: Code should be self-explanatory
  • Explain "why" not "how": Comments should describe the reasoning or intent, not what the code does

Testing (Vitest)

  • Test files: foo.ts → foo.test.ts (same directory)
  • Use describe/it API (not test)
  • Use toMatchSnapshot for complex outputs
  • Use toMatchFileSnapshot with explicit path for language-specific snapshots

Tooling Choices

@antfu/ni Commands

CommandDescription
niInstall dependencies
ni <pkg> / ni -D <pkg>Add dependency / dev dependency
nr <script>Run script
nuUpgrade dependencies
nun <pkg>Uninstall dependency
nciClean install (pnpm i --frozen-lockfile)
nlx <pkg>Execute package (npx)

Checking npm Package Versions

Use fast-npm-meta to look up the latest version of a package — it queries a small metadata endpoint instead of downloading the full registry payload (which can be megabytes per package).

nlx fast-npm-meta version vite              # 7.3.1
nlx fast-npm-meta version "nuxt@^3.5"       # 3.5.22 — range-aware
nlx fast-npm-meta version vite nuxt vue     # multiple at once
nlx fast-npm-meta version vite --json       # JSON for scripting
nlx fast-npm-meta full vite                 # full version list + dist-tags

Prefer this over npm view <pkg> version when you only need the latest version, and over reading package.json from the registry directly.

TypeScript Config

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "moduleResolution": "bundler",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true
  }
}

ESLint Setup

// eslint.config.js
import antfu from '@antfu/eslint-config'

export default antfu({
  type: 'lib', // or 'app' (default)
  pnpm: true, // enforce pnpm catalogs in package.json
  antislop: true, // flag redundant/duplicated AI-style code, ban explicit `any`
})

Always enable antislop: true. It requires eslint-plugin-slop and eslint-plugin-sonarjs as dev dependencies.

For detailed configuration options: antfu-eslint-config

Knip

Use Knip to catch unused files, exports and dependencies — the linter only sees one file at a time.

// knip.json
{
  "$schema": "https://unpkg.com/knip@6/schema.json",
  "project": ["src/**/*.ts"],
  "ignoreDependencies": []
}

Fix what Knip reports by deleting; only add to ignoreDependencies for tools invoked outside package.json scripts (e.g. taze).

Scripts and the ci Gate

Every project exposes a ci script that runs all checks in one command:

{
  "scripts": {
    "build": "tsdown",
    "lint": "eslint --cache",
    "typecheck": "tsc",
    "knip": "knip",
    "test": "pnpm run build && vitest",
    "ci": "pnpm run lint && pnpm run typecheck && pnpm run knip && pnpm run test --run"
  }
}

Before every commit, run nr lint --fix to format, then nr ci and make sure it passes. Do not commit with a failing ci; fix the root cause instead of silencing rules or adding ignores.

Git Hooks

simple-git-hooks + nano-staged. The pre-commit hook runs the full ci gate; prepare also installs agent skills via skills-npm:

{
  "scripts": {
    "prepare": "git config core.hooksPath .githooks && simple-git-hooks && skills-npm"
  },
  "simple-git-hooks": {
    "pre-commit": "pnpm i --frozen-lockfile --ignore-scripts --offline && pnpm run ci && pnpx nano-staged"
  },
  "nano-staged": {
    "*": "eslint --fix --no-warn-ignored"
  }
}

Add .githooks to .gitignore and simple-git-hooks: true under allowBuilds in pnpm-workspace.yaml.

skills-npm

skills-npm symlinks agent skills shipped inside installed npm packages (and fetches those declared in a skills field) into the agent's skills directory on every install. Install as a dev dependency and wire it into prepare as above; add skills/npm-* to .gitignore. Commit the generated skills-npm-lock.json.

Publishing

Prefer npm Trusted Publishing (OIDC) over NPM_TOKEN secrets: releases run on CI from a v* tag via release.yml with id-token: write, and nr release (bumpp) only bumps, tags and pushes. Details: setting-up.

pnpm Catalogs

Use named catalogs in pnpm-workspace.yaml for version management:

CatalogPurpose
prodProduction dependencies
inlinedBundler-inlined dependencies
devDev tools (linter, bundler, testing)
frontendFrontend libraries

Avoid the default catalog. Catalog names can be adjusted per project needs.


References

TopicDescriptionReference
ESLint ConfigFramework support, antislop, formatters, rule overrides, VS Code settingsantfu-eslint-config
Project Setup.gitignore, GitHub Actions, OIDC trusted publishing, VS Code extensionssetting-up
App DevelopmentVue/Nuxt/UnoCSS conventions, auto-import control, Storybook component testingapp-development
Library Developmenttsdown bundling, pure ESM publishing, publint, API snapshotslibrary-development
Monorepopnpm workspaces, centralized alias, Turborepomonorepo

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.