home / skills / yelmuratoff / agent_sync / dependencies

dependencies skill

safe

This skill helps manage pub.dev dependencies for Flutter/Dart projects by validating necessity, evaluating candidates, and documenting decisions to preserve

npx playbooks add skill yelmuratoff/agent_sync --skill dependencies

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.5 KB

---
name: dependencies
description: When evaluating, adding, updating, or removing pub.dev packages while preserving existing architecture and project conventions.
---

# Dependency Management

## When to use

- Adding a package for a new feature.
- Replacing an existing package.
- Adding/removing dev tooling dependencies.
- Investigating whether a package should be removed.

## Steps

### 1) Validate necessity first

- Confirm the problem cannot be solved with current project dependencies or Dart/Flutter SDK APIs.
- If a package is still needed, define the exact capability gap it fills.

### 2) Evaluate candidate quality

Check package fitness before adding:

- maintenance signal (recent stable releases, issue activity)
- documentation quality and usage examples
- compatibility with current architecture and target platforms
- risk of overlap with existing stack (state management, DI, logging, serialization)

### 3) Add dependency with correct scope

Use the standard commands:

```bash
flutter pub add <package>
flutter pub add dev:<package>
flutter pub add override:<package>:<version>
dart pub remove <package>
```

Only use overrides when strictly required and time-bound.

### 4) Verify the integration

- run `dart analyze`
- run targeted `flutter test` for changed areas
- remove imports/usages of replaced packages to avoid dead dependencies

### 5) Document the decision briefly

When introducing a new package, state:

- why current stack was insufficient
- why this package was selected over alternatives
- rollback/removal condition if the package is temporary

Overview

This skill helps evaluate, add, update, or remove pub.dev packages while preserving existing architecture and project conventions. It focuses on validating necessity, assessing package quality, applying correct dependency scope, verifying integration, and documenting decisions. The goal is safe, minimal-risk dependency changes that align with project standards.

How this skill works

The skill inspects the project for capability gaps and verifies whether existing SDK APIs or current dependencies can solve the problem. It evaluates candidate packages for maintenance signals, documentation, compatibility, and overlap with the current stack. It then applies changes with correct pub commands, runs static analysis and targeted tests, and records a brief decision note including rollback criteria.

When to use it

Adding a package to implement a new feature when SDK or existing deps are insufficient
Replacing or upgrading a package that no longer fits project needs
Adding or removing dev tooling (linters, test runners, codegen)
Investigating and removing unused or risky dependencies
Applying a time‑boxed override to resolve urgent compatibility issues

Best practices

Confirm the problem can’t be solved with current SDK or dependencies before adding a package
Assess maintenance, release cadence, issues, docs, and platform compatibility
Avoid overlapping functionality with existing state management, DI, logging, or serialization stacks
Use flutter pub add / dart pub remove and only use overrides sparingly and with an expiry plan
Run dart analyze and targeted flutter test suites after changes
Record a short rationale and rollback/removal condition in project docs or PR description

Example use cases

Add JSON serialization package when current serializers lack required features and compare alternatives
Introduce a dev tool (formatter/linter plugin) for CI while documenting scope and removal criteria
Replace an outdated HTTP client with a maintained alternative and remove the old package imports
Temporarily override a transitive dependency for a critical bugfix with a clear expiration and follow-up plan
Audit project dependencies to identify dead packages and safely remove them after verification

FAQ

When should I prefer SDK APIs over adding a package?

Prefer SDK APIs when they meet the requirement without adding third‑party maintenance or compatibility risk. Validate by prototyping with existing APIs first.

How do I decide between package alternatives?

Compare maintenance signals, docs, platform compatibility, API ergonomics, and overlap with your architecture. Pick the option with the best long‑term support and minimal integration friction.