Dependency and Config Skill

Dependency and Config Skill

Purpose

Manage packages, environment configuration, and project config files safely — avoiding unnecessary dependencies, unapproved upgrades, lockfile drift, and risky config changes.

When to Use

• A task seems to require a new package/library.
• Environment variables need to be added/changed (and .env.example or equivalent updated).
• Config files (framework config, tsconfig.json, lint/format config, build config) need changes.
• package.json scripts need to be added/changed.

When Not to Use

• The task can be completed entirely with existing dependencies and config — no changes needed here.
• Routine code changes that don't touch config/dependencies/env.

Required Inputs

• Current package.json (dependencies, devDependencies, scripts), lockfile type.
• Existing config files relevant to the task.
• Existing .env.example or equivalent (without reading actual secret values from .env if avoidable).

Assumptions

• The existing package manager and lockfile are authoritative — never switch package managers.
• New dependencies, major version upgrades, and config changes require approval before being applied.

Step-by-Step Workflow

1. Check existing dependencies first: search package.json and codebase usage for a library that already solves the need, or a native/platform API that does.
2. If a new dependency seems necessary:
   • Identify the specific package, version range, and what it's needed for.
   • Explain briefly why existing tools/native APIs aren't sufficient.
   • Ask for approval before installing (per Safety and Risk rules) unless the user has already explicitly approved adding dependencies for this task.
3. If installing (after approval): use the project's existing package manager (npm/yarn/pnpm/bun per lockfile) and let it update the lockfile naturally — never hand-edit the lockfile.
4. For environment variables:
   • Add new variables to the example env file (e.g. .env.example) with a placeholder value and a short comment on purpose.
   • Reference them via the project's existing config-loading convention (e.g. process.env.X, a typed config module).
   • Never commit real secret values.
5. For config file changes:
   • Confirm the change is required by the task (e.g. a new path alias, a new build target) or explicitly approved.
   • Make the minimal change needed; don't reformat or restructure the whole config file.
   • Note any behavioral impact (e.g. a new alias affecting imports project-wide).
6. For scripts: don't add new package.json scripts unless asked; if asked, follow the naming style of existing scripts.