Python dependency and environment management for multi-service or monorepo python backends. Use when: (1) adding, upgrading, or removing a Python package, (2) responding to Dependabot or security vulnerability alerts (GHSA/CVE), (3) creating a new service that needs its own requirements files, (4) debugging pip install failures or Docker build issues related to dependencies, (5) reviewing or auditing the dependency tree, (6) running pip-compile. Enforces the pip-compile locked-file workflow and tiered dependency hierarchy.
From dependency-managementnpx claudepluginhub richfrem/agent-plugins-skills --plugin dependency-managementThis skill is limited to using the following tools:
acceptance-criteria.mdevals/evals.jsonevals/results.tsvfallback-tree.mdreferences/DEPENDENCY_MANAGEMENT.mdreferences/DEPENDENCY_MANIFEST.mdreferences/acceptance-criteria.mdreferences/fallback-tree.mdreferences/policy_details.mdreferences/python_dependency_workflow.mmdrequirements.txtEnables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Sorts ECC skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using repo evidence like file extensions and configs. Creates trimmed install plan for project-specific needs.
Implements structured self-debugging workflow for AI agent failures: capture errors, diagnose patterns like loops or context overflow, apply contained recoveries, and generate introspection reports.
This skill requires Python 3.8+ and standard library only. No external packages needed.
To install this skill's dependencies:
pip-compile ./requirements.in
pip install -r ./requirements.txt
See ./requirements.txt for the dependency lockfile (currently empty — standard library only).
./requirements.txt lockfile.plugins/<plugin-name>/scripts/. Skills that need it use a file-level symlink in their own scripts/ directory pointing back to the root (ln -s ../../../scripts/foo.py).bridge_installer.py) only resolves individual file-level symlinks. Directory-level symlinks are silently dropped by binary packaging tools.bridge_installer.py) resolves all symlinks to physical copies when deploying to .agents/. This ensures every skill is independently runnable regardless of the source mono-repo's presence.plugin_installer.py uses a 3-tier strategy for Windows:
python ../../other-plugin/scripts/foo.py. If a cross-plugin capability is needed, use Agent Skill Delegation: instruct the Agent to invoke the target skill via the conversation layer. In the mono-repo source, cross-plugin file-level symlinks are acceptable for shared logic that the installer will then resolve.src/
├── requirements-core.in # Tier 1: shared baseline (fastapi, pydantic…)
├── requirements-core.txt # Lockfile for core
├── services/
│ ├── auth_service/
│ │ ├── requirements.in # Tier 2: inherits core + auth deps
│ │ └── ./requirements.txt
│ ├── payments_service/
│ │ ├── requirements.in
│ │ └── ./requirements.txt
│ └── database_service/
│ ├── requirements.in
│ └── ./requirements.txt
| Tier | Scope | File | Examples |
|---|---|---|---|
| 1 – Core | Shared by >80% of services | requirements-core.in | fastapi, pydantic, httpx |
| 2 – Specialized | Service-specific heavyweights | <service>/requirements.in | stripe, redis, asyncpg |
| 3 – Dev tools | Never in production containers | requirements-dev.in | pytest, black, ruff |
Each service .in file usually begins with -r ../../requirements-core.in to inherit the core dependencies.
Declare — Add or update the version constraint in the correct .in file.
requirements-core.in.in>= syntax: cryptography>=46.0.5Lock — Compile the lockfile:
# Core
pip-compile src/requirements-core.in \
--output-file src/requirements-core.txt
# Individual service (example: auth)
pip-compile src/services/auth_service/requirements.in \
--output-file src/services/auth_service/./requirements.txt
Because services inherit core via -r, recompiling a service also picks up core changes.
Sync — Install locally to verify:
pip install -r src/services/<service>/./requirements.txt
Verify — Rebuild the affected Docker/Podman container to confirm stable builds.
Commit — Stage and commit both .in and .txt files together.
Identify the affected package and fixed version from the advisory (GHSA/CVE).
Determine tier placement:
.in file)..txt files, it's transitive — pinned by something upstream.For direct dependencies: Bump the version floor in the relevant .in file.
# SECURITY PATCHES (Mon YYYY)
package-name>=X.Y.Z
For transitive dependencies: Add a version floor pin in the appropriate .in file
to force the resolver to pull the patched version, even though it's not a direct dependency.
Recompile all affected lockfiles. Since services inherit core, a core change means recompiling every service lockfile. Use this compilation order:
# 1. Core first
pip-compile src/requirements-core.in \
--output-file src/requirements-core.txt
# 2. Then each service
for svc in auth_service payments_service database_service; do
pip-compile "src/services/${svc}/requirements.in" \
--output-file "src/services/${svc}/./requirements.txt"
done
Verify the patched version appears in all affected .txt files:
grep -i "package-name" src/requirements-core.txt \
src/services/*/./requirements.txt
If no newer version exists (e.g., inherent design risk like pickle deserialization),
document the advisory acknowledgement as a comment in the .in file and note mitigations.
COPY ./requirements.txt + RUN pip install -r ./requirements.txt.RUN pip install <pkg> commands. No manual installs../requirements.txt before source code to preserve Docker layer caching..in change.== instead of >= for security floors — use >= so pip-compile can resolve freely..in files — keep pytest, ruff, etc. in requirements-dev.in..txt without .in — always commit them as a pair.