---
name: kedarrio/dependency-and-config
source: https://app.decimal.ai/s/kedarrio-dependency-and-config@1/SKILL.md
source_sha256: 918cfb9a3fa0
---

# 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.
7. **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.