Lists concrete actions: analyze upgrade impact, find safest version that fixes vulnerabilities, uses pre-computed Endor Labs data. Also specifies what it does NOT do (checking vulnerabilities, applying fixes), which adds clarity.

Clearly answers both 'what' (analyze dependency upgrade impact, find safest version fixing vulnerabilities) and 'when' (explicit 'Use when' clause with multiple trigger examples, plus 'Do NOT use' negative boundaries).

Excellent coverage of natural trigger phrases: 'should I upgrade lodash', 'what breaks if I update express', 'upgrade impact', 'endor upgrade', 'breaking changes from upgrading'. These are realistic phrases users would actually say.

Highly distinctive with explicit negative boundaries distinguishing it from /endor-check and /endor-fix. The focus on pre-upgrade impact analysis creates a clear niche that is unlikely to conflict with vulnerability scanning or fix-application skills.

The content is lean and efficient. It doesn't explain what dependencies are, what vulnerabilities are, or how Endor Labs works conceptually. Every section serves a direct purpose with no padding or unnecessary context.

Provides fully executable bash commands with specific flags, filters, and field masks. The output template is copy-paste ready with clear placeholder variables. The table format for presenting results is concrete and specific.

Clear 4-step sequence with explicit checkpoints: stop if project not found, filter based on user intent, escalate CIA details only on request. The conditional logic (specific package vs general, high-risk on demand only) is well-defined with clear decision points.

The main workflow is concise and self-contained. Advanced details (install commands, data source policy, authentication recovery) are referenced as one-level-deep links to separate files. CIA details are deferred to Step 4 only when needed.