القائمة
Use when conducting a security review, reducing dependency surface, or when dependencies may pose supply-chain, bloat, or maintainability risks.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when building any UI, HTML component, slide, document, or design asset that will represent SBP visually — applies the Schuberg Philis visual brand identity (colors, typography, logo, stylization, grids, photography, iconography) to ensure brand-consistent output without manual reminders.
Use when deploying to production — verifies rollback readiness, monitoring, and change communication against mission-critical criteria and produces a go/no-go decision.
Use when a production incident has occurred — structured blameless post-incident analysis that reconstructs timeline, assesses impact, finds root causes, and produces concrete action items.
Use when verifying monitoring, alerting, and logging coverage — checks the four pillars (metrics, logs, traces, alerts), produces a coverage matrix with gaps, severity ratings, and recommended actions, and applies the 3 AM test to every component.
Use when existing code needs to change shape before a feature, or when code drift is making further work expensive — improves structure and readability without changing observable behavior.
Use when generating operational runbooks from code and infrastructure — produces runbooks that work at 3 AM, covering common failure scenarios with specific diagnosis and resolution steps, copy-pasteable commands, and clear escalation paths.
| name | sbp-dependency-audit |
| description | Use when conducting a security review, reducing dependency surface, or when dependencies may pose supply-chain, bloat, or maintainability risks. |
| metadata | {"domain":"security","lifecycle":"build"} |
Audit project dependencies for bloat, risk, and supply-chain concerns. The goal is a clear picture of what you depend on, why, and whether each dependency is worth the risk it carries.
Work incrementally — one category at a time. Do not try to fix everything at once.
Build a complete inventory of dependencies and actual usage.
List all direct dependencies:
pyproject.toml, requirements.txt, setup.py, setup.cfg.package.json (both dependencies and devDependencies).go.mod.Identify what is actually imported:
Map transitive dependencies:
uv.lock, package-lock.json, go.sum) to count transitive dependencies.Classify each direct dependency into one of five categories:
Large, well-maintained, complex libraries where writing your own would be foolish.
Criteria: actively maintained (commits in last 6 months), multiple maintainers, solves a genuinely hard problem (HTTP server, cryptography, database driver, ML framework), widely used and battle-tested.
Tiny packages that do one simple thing in under 100 lines of code.
Criteria: the functionality is trivial to implement, the package has few or no updates, and depending on it adds supply-chain risk disproportionate to its value. Copy the implementation (respecting the license), add a comment noting the origin, and remove the dependency.
Examples: left-pad-style packages, simple string utilities, single-function math helpers.
Packages that provide functionality now available in the language's standard library or in a dependency you already have.
Criteria: the functionality exists natively in the current language version or in a library already in your dependency tree. Common cases: backport packages for features now in the stdlib, polyfill packages for APIs now widely available.
Narrow-purpose, stable packages where you want to lock the exact code but the package is too complex to inline.
Criteria: the package is stable (no updates needed), you use it for a specific purpose, and you want to decouple from the package registry. Copy the package into a vendor/ or 3rdparty/ directory, preserving its license.
Packages that are not imported anywhere, or that are imported but the functionality is unused (dead code paths).
Criteria: no import found in the codebase, or the import exists but the code path is never reached. Remove the dependency and run the test suite to confirm nothing breaks.
For each dependency classified as "keep," evaluate supply-chain risk:
Maintenance status:
Known vulnerabilities:
Trust indicators:
Attack surface analysis for mission-critical systems:
pip install or npm install.Flag any dependency that is: unmaintained (no updates in 12+ months), single-maintainer, has known vulnerabilities, or has install-time code execution.
Produce a prioritized list of actions. Work through these one category at a time, running the full test suite after each change.
Priority 1 — Remove (lowest effort, immediate risk reduction):
Priority 2 — Replace with native (low effort, reduces surface area):
Priority 3 — Inline (moderate effort, meaningful risk reduction):
Priority 4 — Vendor (moderate effort, supply-chain protection):
Priority 5 — Address vulnerabilities (effort varies):
Priority 6 — Monitor (ongoing):
Produce two artifacts:
| Package | Version | Category | Risk | Action | Effort | Notes |
|---|---|---|---|---|---|---|
| requests | 2.31.0 | Keep | Low | None | - | Well-maintained, widely used |
| left-pad | 1.0.0 | Inline | Medium | Copy 3-line implementation | 15 min | Single maintainer, trivial function |
| typing-extensions | 4.8.0 | Replace | Low | Remove (Python 3.11+) | 5 min | Backport no longer needed |
For each action item, provide: