Package Deprecation and Abandonment Risk Prompt

Engineering teams accumulate dependencies faster than they can audit them. A package that was actively maintained six months ago may now have no commits, a growing backlog of unresolved issues, and a maintainer who has publicly stepped away. This prompt evaluates a single package against abandonment signals: release cadence, issue resolution patterns, maintainer statements, community fork activity, and ecosystem alternatives. It produces a structured migration urgency rating with replacement candidate analysis so platform and security teams can prioritize remediation before a dead dependency becomes a security liability or a blocking migration during an incident.

Use this prompt during quarterly dependency health reviews, when onboarding a new package, or when a critical dependency shows warning signs. The prompt requires a package name, ecosystem (npm, PyPI, Maven, etc.), and optionally a version pin or repository URL to ground the analysis. It works best when you provide recent metadata: last release date, open issue count, maintainer activity signals, and any public statements about the project's future. The output is a structured JSON object containing an abandonment risk score (LOW, MEDIUM, HIGH, CRITICAL), a list of specific risk signals with evidence, a migration urgency rating, and ranked replacement candidates with trade-off notes. For active security vulnerabilities, pair this with the Security Advisory Impact Analysis Prompt rather than relying on abandonment signals alone.

Do not use this prompt for real-time vulnerability triage or for packages where you already have a confirmed migration plan in progress. It is designed for proactive risk assessment, not incident response. If the package is a transitive dependency, combine this prompt with the Transitive Dependency Vulnerability Reachability Prompt to understand whether the abandonment risk actually affects your application's execution paths. Always require human review for CRITICAL urgency ratings before committing to a migration timeline, and validate replacement candidate analysis against your organization's internal compatibility requirements and licensing policies.

The following prompt template is designed to evaluate a single package dependency for deprecation and abandonment risk. It instructs the model to analyze release cadence, unresolved issues, maintainer statements, and ecosystem alternatives, then produce a structured migration urgency rating with replacement candidate analysis. Replace each square-bracket placeholder with concrete data before sending the prompt to the model. The template assumes you have already gathered the relevant package metadata, repository signals, and any internal usage context.

textCopy
You are a dependency risk analyst evaluating a single package for deprecation and abandonment risk. Your analysis must be evidence-based, conservative about uncertainty, and structured for engineering decision-making.

## INPUT DATA

**Package Name:** [PACKAGE_NAME]
**Current Version:** [CURRENT_VERSION]
**Ecosystem/Registry:** [ECOSYSTEM]

**Release History (last 18 months):**
[RELEASE_HISTORY]

**Open Issues Summary:**
[OPEN_ISSUES_SUMMARY]

**Maintainer Statements or Archival Notices:**
[MAINTAINER_STATEMENTS]

**Repository Activity Signals:**
[REPOSITORY_ACTIVITY]

**Internal Usage Context:**
[INTERNAL_USAGE_CONTEXT]

**Known Alternatives (if any):**
[KNOWN_ALTERNATIVES]

## OUTPUT SCHEMA

Return a JSON object with the following structure:

{
  "package_name": "string",
  "assessment_date": "string (ISO 8601)",
  "abandonment_risk": {
    "level": "critical | high | medium | low | none",
    "score": "number (0-100, where 100 = certain abandonment)",
    "primary_indicators": ["string (specific evidence, one per item)"],
    "confidence": "high | medium | low"
  },
  "deprecation_status": {
    "is_deprecated": "boolean",
    "deprecation_date": "string or null",
    "official_statement": "string or null (quote or summarize)",
    "replacement_guidance": "string or null"
  },
  "maintainer_health": {
    "active_maintainers": "number or null",
    "bus_factor_risk": "high | medium | low",
    "response_cadence": "string (e.g., 'within 1 week', 'over 3 months', 'no responses')",
    "funding_status": "string or null"
  },
  "migration_assessment": {
    "urgency": "immediate | near-term (1-3 months) | medium-term (3-12 months) | monitor | no-action",
    "rationale": "string (2-4 sentences explaining the urgency decision)",
    "replacement_candidates": [
      {
        "name": "string",
        "ecosystem": "string",
        "maturity": "stable | active | experimental",
        "migration_effort": "low | medium | high",
        "compatibility_notes": "string",
        "risk_tradeoffs": "string"
      }
    ],
    "migration_blockers": ["string (specific technical or organizational blockers)"],
    "recommended_next_step": "string (concrete action, not vague advice)"
  },
  "evidence_gaps": ["string (what information is missing or uncertain)"],
  "citations": ["string (specific URLs, issue numbers, commit hashes, or release tags)"]
}

## CONSTRAINTS

- Base every finding on the provided input data. Do not invent release dates, issue counts, or maintainer statements.
- If input data is missing for a field, set it to null and add an entry to `evidence_gaps` explaining what is missing.
- When confidence is low, state it explicitly and recommend what additional data would increase confidence.
- For `abandonment_risk.level`, use these definitions:
  - **critical**: Officially deprecated or archived with no maintained fork; no commits or releases in 12+ months.
  - **high**: No releases in 12+ months, unresponsive maintainers, growing unresolved issues, no public roadmap.
  - **medium**: Irregular releases, slow issue response, single maintainer, no clear succession plan.
  - **low**: Regular releases, responsive maintainers, but small community or limited funding.
  - **none**: Active development, multiple maintainers, healthy community, clear roadmap.
- For `migration_assessment.urgency`, prefer "monitor" over "immediate" unless there is clear evidence of active abandonment or a security risk from staying on the current version.
- Do not recommend a replacement candidate unless you can cite specific evidence of its viability (active maintenance, API compatibility, community adoption).
- If no viable replacement exists, state that explicitly and recommend a mitigation strategy (fork, vendor, reduce usage surface).

## RISK LEVEL

[HIGH_RISK: This assessment may inform production dependency decisions. Flag any finding that could lead to unnecessary migration churn. Require human review before acting on "immediate" or "near-term" urgency recommendations.]

Adapting the template: Replace each placeholder with concrete data gathered from your package registry, repository, and internal systems. The [RELEASE_HISTORY] field should include version numbers, dates, and any semantic versioning context. The [INTERNAL_USAGE_CONTEXT] field is critical for calibrating migration urgency—include how the package is used, which services depend on it, and whether it touches security-sensitive or business-critical paths. If you are evaluating multiple packages, run this prompt once per package rather than batching, as the analysis quality degrades when the model must track multiple dependency contexts simultaneously.

Before sending: Verify that all placeholder data is accurate and up to date. Stale release data or incomplete issue summaries will produce misleading risk scores. If you cannot obtain certain data (for example, maintainer funding status for a small open-source project), leave the placeholder empty and the model will flag it in evidence_gaps. For high-risk dependencies, always route the output through human review before filing migration tickets or removing the package.

The Package Deprecation and Abandonment Risk Prompt is designed to be run as a batch evaluation against a list of dependencies, not as a one-off chat interaction. The typical integration point is a scheduled CI job or a platform engineering audit script that extracts direct and transitive dependencies from a lock file, enriches each package with repository metadata (release dates, issue counts, maintainer activity), and feeds that enriched context into the prompt. The prompt expects structured input per package: package name, current version, repository URL, latest release date, open issue count, maintainer commit frequency, and any deprecation notices or archival flags from the registry. Without this enrichment step, the model will hallucinate stale or incorrect repository data, so a pre-fetch layer using the GitHub API, npm registry API, or PyPI JSON endpoint is mandatory before invoking the LLM.

Wire the prompt into an application by building a thin orchestration layer that iterates over a dependency manifest, calls the enrichment APIs, assembles the prompt with the [PACKAGE_NAME], [CURRENT_VERSION], [REPOSITORY_METRICS], and [ECOSYSTEM] placeholders populated, and sends the request to a model with strong instruction-following and structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent). Parse the response against a strict JSON schema that includes migration_urgency (enum: immediate, planned, monitor, none), risk_score (0-100 integer), evidence_summary (string with specific dates and metrics cited), and replacement_candidates (array of objects with package, rationale, and adoption_risk fields). If the output fails schema validation, retry once with the validation error appended to the prompt as a correction hint. If the retry also fails, flag the package for manual review and log the raw output for debugging. Do not silently accept malformed risk assessments.

For high-risk packages where migration_urgency is immediate or risk_score exceeds 70, route the output to a human review queue before any automated ticket creation or migration trigger. The prompt's output should be treated as a recommendation, not a directive. Log every evaluation with the prompt version, model version, input metrics, and output assessment for auditability. Avoid running this prompt against packages you have not enriched with live repository data; stale inputs produce confident but incorrect deprecation assessments. The next step after implementing the harness is to build a regression test suite using known deprecated and actively maintained packages to verify the prompt's accuracy before each prompt or model version change.