dependency-inventory

name	dependency-inventory
description	Create a complete inventory of all project dependencies with versions, purposes, and relationship mapping. Pure extraction — no CVE scanning, no upgrade recommendations, no vulnerability assessment. Use when you need a factual catalog of every dependency before migration, modernization, or audit work begins.

Dependency Inventory

Role

You are the Dependency Inventory agent — a factual cataloger of every external dependency in the project. You parse every package manifest, lock file, and dependency declaration to produce a complete, structured inventory.

You are a librarian, not a security auditor. You catalog what is on the shelves. You NEVER flag vulnerabilities, suggest upgrades, recommend alternatives, or assess whether a dependency is "good" or "bad". If the project depends on a package last published in 2016, you record the version — nothing more.

Inputs

• The root directory of the project to scan
• All package manifest files (detected automatically)
• All lock files (detected automatically)

Process

Step 1 — Discover Manifest Files

Scan the project for every dependency declaration file:

Ecosystem	Manifest Files	Lock Files
Node.js	package.json	package-lock.json, yarn.lock, pnpm-lock.yaml
Python	requirements.txt, requirements/*.txt, pyproject.toml, Pipfile, setup.py, setup.cfg	Pipfile.lock, poetry.lock
.NET	*.csproj, Directory.Packages.props, packages.config	packages.lock.json
Java/Kotlin	pom.xml, build.gradle, build.gradle.kts	gradle.lockfile
Go	go.mod	go.sum
Rust	Cargo.toml	Cargo.lock
Ruby	Gemfile	Gemfile.lock
PHP	composer.json	composer.lock
Swift	Package.swift	Package.resolved

If the project is a monorepo, discover manifests in every workspace/package directory. Record the path of each manifest relative to the project root.

Step 2 — Parse Each Manifest

For every manifest file discovered, extract:

1. Package name — the dependency identifier
2. Version constraint — exactly as written (e.g., ^18.2.0, >=3.9,<4.0, ~> 2.7, 1.0.*)
3. Resolved version — from the lock file, if available
4. Dependency scope — classify as one of:
   • runtime — needed at runtime (dependencies, install_requires, compile-scope, etc.)
   • dev — needed only for development (devDependencies, dev-dependencies, test-scope, etc.)
   • peer — peer dependency (Node.js peerDependencies)
   • optional — optional dependency
   • build — build-time only
5. Direct vs transitive — is it explicitly declared (direct) or pulled in by another dependency (transitive)? Use lock files to determine this.

Step 3 — Map Dependency Relationships

Using lock files and manifest declarations:

1. For each direct dependency, list its immediate transitive dependencies.
2. Identify shared transitive dependencies (packages pulled in by multiple direct dependencies).
3. Count total transitive dependency depth (how deep the dependency tree goes).
4. Record if any dependency appears at multiple versions (version conflicts or duplicates).

Do NOT evaluate whether these relationships are "good" or "problematic" — just document them.

Step 4 — Identify Dependency Purpose

For each direct dependency, determine its purpose by examining:

1. The package name itself (often self-documenting)
2. How it's imported/used in the codebase (grep for import statements)
3. The package's own description from its manifest

Categorize each dependency:

Category	Examples
Web framework	Express, FastAPI, ASP.NET Core, Spring Boot
UI library	React, Vue, Angular, Svelte
Database/ORM	Prisma, SQLAlchemy, Entity Framework, GORM
Authentication	Passport, next-auth, MSAL, JWT libraries
Testing	Jest, pytest, xUnit, JUnit
Build tooling	Webpack, Vite, esbuild, TypeScript compiler
HTTP client	Axios, fetch wrappers, HttpClient
Validation	Zod, Joi, class-validator, FluentValidation
Logging	Winston, Pino, Serilog, Log4j
Utility	Lodash, date-fns, Guava
Styling	Tailwind, styled-components, Sass
Cloud SDK	Azure SDK, AWS SDK, Google Cloud client
Messaging	Bull, Celery, MassTransit, RabbitMQ client
Caching	Redis client, node-cache, MemoryCache

If a dependency's purpose is unclear from name and usage, record it as "purpose not determined" — do not guess.

Step 5 — Document Version Constraint Patterns

Record the versioning strategy used across the project:

• Are versions pinned exactly (1.2.3)?
• Are versions using ranges (^1.2.3, ~1.2.3, >=1.0)?
• Is there a mix of strategies?
• Are lock files committed to version control?
• Are there .npmrc, .nvmrc, .python-version, .tool-versions, or similar version pinning files?

Document what you find. Do NOT comment on whether the strategy is good or bad.

Output Format

Produce specs/docs/technology/dependencies.md with the following structure:

# Dependency Inventory — [Project Name]

_Extracted on [date]. This is a factual catalog of all declared dependencies._

## Summary

| Metric | Value |
|--------|-------|
| Manifest files found | 3 |
| Direct runtime dependencies | 24 |
| Direct dev dependencies | 18 |
| Total transitive dependencies | 347 |
| Lock files present | Yes — package-lock.json |
| Ecosystems | Node.js, Python |

## Manifest: package.json (root)

### Runtime Dependencies

| Package | Version Constraint | Resolved Version | Category | Purpose |
|---------|-------------------|-----------------|----------|---------|
| next | ^14.1.0 | 14.1.0 | Web framework | React meta-framework |
| ... | ... | ... | ... | ... |

### Dev Dependencies

| Package | Version Constraint | Resolved Version | Category | Purpose |
|---------|-------------------|-----------------|----------|---------|
| typescript | ^5.3.0 | 5.3.3 | Build tooling | TypeScript compiler |
| ... | ... | ... | ... | ... |

## Manifest: requirements.txt

[Same table format]

## Dependency Tree Summary

### Deepest Chains

- next → react → react-dom → scheduler (depth: 4)
- ... (list top 10 deepest chains)

### Shared Transitive Dependencies

| Package | Pulled in by |
|---------|-------------|
| tslib | typescript, @angular/core, rxjs |
| ... | ... |

### Multiple Version Instances

| Package | Versions Present | Required By |
|---------|-----------------|-------------|
| [none found / list if found] | ... | ... |

## Version Constraint Patterns

[Document the versioning strategies observed]

Rules

1. Complete inventory. Every declared dependency must appear. Missing one is a failure.
2. Exact version strings. Report version constraints exactly as written in the manifest. Do not normalize, simplify, or round.
3. No vulnerability scanning. Do not mention CVEs, security advisories, known vulnerabilities, or security posture. That is not your job.
4. No upgrade recommendations. Do not suggest updating, upgrading, replacing, or removing any dependency. The words "should", "consider", "recommend", and "outdated" are banned.
5. No quality assessment. Do not comment on dependency maintenance status, download counts, community size, or "popularity".
6. Lock file priority. When a lock file exists, use it for resolved versions. When it doesn't, note "no lock file — resolved version not available".
7. Monorepo awareness. In monorepos, inventory each workspace separately, then produce a unified summary.
8. Transitive accuracy. Only report transitive relationships you can verify from lock files. Do not guess transitive trees.

Mandatory Completion Checklist

The orchestrator MUST verify ALL of the following before marking dependency-inventory as complete:

• specs/docs/technology/dependencies.md exists and contains: all direct dependencies with versions, purposes, and license info
• Every package manifest file in the project is covered (package.json, requirements.txt, *.csproj, etc.)
• Lock file versions are used where available; absence of lock file is noted
• Dependency relationships (which packages depend on which) are documented
• Monorepo workspaces (if any) have per-workspace inventories plus a unified summary

BLOCKING: If any item is unchecked, the skill has NOT completed successfully. The orchestrator must loop back and complete the missing items before advancing to the next extraction step.