--- id: hairyf/skills/hairy version: "c05708d1" license: MIT install: manual updated: 2026-06-10 --- # hairy — Hairy packages a handpicked set of agent skills reflecting Hairyf's approach to contemporary web development. Built on proven foundations and extended with specialized capabilities, this collection captures real-world tooling choices and architectural patterns for developers seeking a focused, opinionated stack. Publisher: hairyf · Stars: 24 · Updated: 2026-06-10 Install (manual): `git clone https://github.com/hairyf/skills` ## SKILL.md # Hairyf's Preferences This skill covers Hairyf's preferred tooling, configurations, and best practices for web development. This skill is opinionated. ## Quick Summary | Category | Preference | |----------|------------| | Package Manager | pnpm | | Language | TypeScript (strict mode) | | Module System | ESM (`"type": "module"`) | | Linting & Formatting | @antfu/eslint-config (no Prettier) | | Testing | Vitest | | Git Hooks | simple-git-hooks + lint-staged | | Documentation | VitePress (in `docs/`) | --- ## Global Preferences High-level cross-cutting preferences that should be respected whenever possible: ### "specify" keyword When a task is marked with **"specify"** (for example: "specify this repo according to hairy"): - Treat it as a request to **inspect the current project** and **optimize it until it matches these preferences as much as reasonably possible**. - Concretely, this should trigger: - Architecture detection and upgrade planning via `@skills/arch-upkeep` and the relevant `arch-*` skills. - Preference-aware stack choices (prefer unjs ecosystem via `@skills/unjs`). - Dependency freshness checks and upgrades via `@skills/taze`. - A final pass of `lint` + `typecheck` (and tests if present) before considering the "specify" task done. ### Prefer unjs ecosystem frameworks - When choosing frameworks or runtimes (SSR, API, tooling, dev server, etc.), **prefer unjs ecosystem projects** first (for example Nuxt, Nitro, h3, unstorage, unplugin, unocss, ofetch, and other unjs-maintained tools). - Only fall back to non-unjs options when there is a clear, justified reason (missing feature, ecosystem constraint, or legacy requirements). - For concrete choices, recipes, and defaults, **delegate to `@skills/unjs`** and follow its recommendations. ### Architecture must map to `arch-*` skills - A project’s architecture should always map to one of the canonical `arch-*` stacks (tsdown library, CLI, monorepo, unplugin, webext, vscode, etc.). - When the current shape does not match any target cleanly, **treat it as an upgrade opportunity** and plan a migration instead of adding more ad‑hoc structure. - Use **`@skills/arch-upkeep`** to: - Detect the current architecture. - Choose the best target `arch-*` skill(s). - Orchestrate an incremental migration to that architecture. ### Keep dependencies fresh with `taze` - Dependencies should be kept **continuously fresh**, not only during big refactors. - Prefer using **`taze`** (see `@skills/taze`) to: - Audit outdated dependencies. - Perform controlled upgrades (minor/patch regularly; majors with explicit review). - Align versions across a monorepo using pnpm workspaces and catalogs. - Avoid hand-editing versions in `package.json` unless there is a specific reason not to follow `taze`’s suggestions. ### Always finish with lint + typecheck - After implementing any non-trivial change (feature, refactor, config change, dependency upgrade, CI change, etc.), **always run lint and typecheck** before considering the task done. - Standard scripts: - `nr lint` → ESLint via `@antfu/eslint-config`. - `nr typecheck` → TypeScript in strict mode (project-wide). - For CI and Git hooks: - Ensure pre-commit hooks at least run `lint` on staged files. - Ensure GitHub Actions (or other CI) run both `lint` and `typecheck` on PRs and `main` pushes. --- ## Core Stack ### Package Manager (pnpm) Use pnpm as the package manager. For monorepo setups, use pnpm workspaces: ```yaml # pnpm-workspace.yaml packages: - 'packages/*' ``` Use pnpm named catalogs in `pnpm-workspace.yaml` to manage dependency versions: | Catalog | Purpose | |---------|---------| | `prod` | Production dependencies | | `inlined` | Dependencies inlined by bundler | | `dev` | Development tools (linter, bundler, testing, dev-server) | | `frontend` | Frontend libraries bundled into frontend | Catalog names are not limited to the above and can be adjusted based on needs. Avoid using default catalog. #### @antfu/ni Use `@antfu/ni` for unified package manager commands. It auto-detects the package manager (pnpm/npm/yarn/bun) based on lockfile. | Command | Description | |---------|-------------| | `ni` | Install dependencies | | `ni ` | Add dependency | | `ni -D ` | Add dev dependency | | `nr