dependency-tool-substitution

Maps current dependencies and tools to target platform equivalents with version compatibility analysis.

1|1|Updated May 16, 2026
One-click install
npx skills add https://github.com/vanduc2514/hackathon-lablab-ibm-bob --skill dependency-tool-substitution-vanduc2514
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dependency-tool-substitution
Source: https://github.com/vanduc2514/hackathon-lablab-ibm-bob/tree/main/.bob/skills/dependency-tool-substitution
Command: npx skills add https://github.com/vanduc2514/hackathon-lablab-ibm-bob --skill dependency-tool-substitution-vanduc2514

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? During platform migrations, teams struggle to determine which libraries, frameworks, and tools need updates, replacements, or removal, risking broken builds and incompatible versions. ## Core Features & Use Cases - Dependency Inventory & Substitution Matrix: Parses dependency manifests (pom.xml, package.json, requirements.txt) and produces a mapping table with current versions, target versions, and change types. - Breaking Change Detection: Identifies incompatible APIs, deprecated libraries, and version conflicts with concrete remediation actions. - Tooling Updates: Documents build tool, CI/CD, and testing framework changes required by the target platform. - Use Case: Migrating a Java Spring Boot 2.7 application on Java 11 to Spring Boot 3.2 on Java 21, generating a design_dependency_mapping.md that captures the javax to jakarta namespace migration, Hibernate upgrades, and Maven plugin updates. ## Quick Start Analyze my project's dependency manifests against the target architecture and generate a dependency mapping document with substitutions and breaking changes.

Frequently Asked Questions about dependency-tool-substitution

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I map dependencies when migrating to a new platform?▼

Extract all dependencies from manifests like pom.xml or package.json, check each against target platform compatibility, and document substitutions in a matrix with exact versions. Classify each change as direct update, equivalent replacement, platform native, removal, or addition.

How to handle javax to jakarta namespace migration in Spring Boot?▼

Spring Boot 3.x requires replacing javax.* imports with jakarta.* equivalents, such as swapping javax.validation for jakarta.validation. The API remains mostly unchanged, so the work is primarily updating imports across the codebase.

What inputs are needed for dependency substitution analysis?▼

The analysis requires a target architecture document, component migration strategies, current dependency manifests, and a target platform compatibility matrix. These inputs drive the inventory, compatibility checks, and substitution decisions.

How do I resolve version conflicts between dependencies?▼

Resolve conflicts by converging on the highest compatible version, excluding conflicting transitive dependencies, or using a Bill of Materials to manage related versions consistently. Validate resolved versions through integration testing.

Should dependency versions be specified as ranges during migration?▼

No, always specify exact versions such as 3.2.0 rather than ranges like 3.2.x. Exact versions ensure reproducible builds and let you verify compatibility and check for known vulnerabilities against specific releases.