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.

1. 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.
2. 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.

1. 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).

1. For scripts: don't add new package.json scripts unless asked; if asked, follow the naming style of existing scripts.
2. Major version upgrades: never perform without explicit approval; if a task seems to require one, flag it and explain the impact (breaking changes, migration effort) instead of proceeding.

Rules and Best Practices

• Check existing dependencies and native APIs before suggesting anything new.
• Don't add a dependency just because it's popular or familiar — justify the need.
• Preserve the existing package manager and script conventions.
• Never hand-edit lockfiles.
• Don't change config files beyond what the task requires or what's approved.
• Keep .env.example (or equivalent) in sync with actual required environment variables, without real secret values.
• Explain dependency/config changes before making them, including the impact.

Safety Checks

• Treat new dependencies, major version upgrades, package manager changes, and broad config changes as requiring explicit approval — do not proceed without it.
• Never commit real secrets, API keys, or credentials into code or example env files.
• Don't change build/deploy config in ways that could break other environments without flagging the risk.

Validation Checks

• Confirm any new dependency is actually used and necessary.
• Confirm the lockfile is consistent with package.json after any approved install (regenerated by the package manager, not hand-edited).
• Confirm .env.example/equivalent reflects any new required environment variables.
• Confirm config changes are minimal and scoped to the task's need.

Common Mistakes to Avoid

• Installing a new dependency without checking if an existing one or a native API already solves the problem.
• Hand-editing lockfiles.
• Switching package managers or frameworks mid-task.
• Performing major version upgrades without approval.
• Committing real secret values in example env files or config.
• Reformatting or restructuring entire config files for a small change.
• Adding new npm scripts without being asked.

Output Rule

Do not invent a custom final response format for this skill. Follow the Global Agent Output and Reporting Skill. Only include skill-specific reporting details when necessary for understanding the completed work.