Open Source Maintainer Health Evaluation Prompt

This prompt is designed for platform engineering, security, and architecture teams who need to evaluate the long-term viability of an open source dependency before adopting it or as part of a periodic supply chain health audit. The job-to-be-done is turning unstructured repository signals—commit frequency, issue resolution time, maintainer responsiveness, funding status, and community activity—into a structured sustainability score with clear adoption risk flags. The ideal user is a technical decision-maker who can provide a repository URL and needs an evidence-backed assessment, not a generic popularity metric.

Use this prompt when you are performing due diligence on a new dependency, comparing multiple libraries that solve the same problem, or auditing existing dependencies for abandonment risk. It requires access to live repository metadata, which means it should be wired into a tool-calling harness that can fetch data from GitHub, GitLab, or similar APIs. The prompt expects [REPOSITORY_URL] and [PACKAGE_NAME] as inputs, along with optional [ADOPTION_CONTEXT] describing how the dependency would be used in your system. The output is a structured JSON object containing a composite health score, individual dimension scores, risk flags, and a summary of evidence.

Do not use this prompt for real-time incident response, for evaluating proprietary or closed-source software, or as a substitute for a full security audit. It assesses maintainer health and community sustainability, not code quality, vulnerability presence, or license compliance—those require separate, specialized prompts. The prompt is also not suitable for repositories with fewer than 50 commits or less than six months of history, as the signal is too sparse for reliable evaluation. For high-risk production dependencies, always pair this automated assessment with human review of the flagged dimensions before making an adoption or replacement decision.

This prompt template is designed to be copied directly into your prompt library or AI harness. It accepts a repository identifier and optional context about your usage to produce a structured sustainability assessment. The square-bracket placeholders are the only parts you need to replace before execution. The template is self-contained: it defines the role, the evaluation dimensions, the output schema, and the constraints the model must follow. You can adapt the [EVALUATION_DIMENSIONS] list to emphasize specific risks relevant to your organization, such as security response time or funding diversity.

textCopy
You are an open source dependency risk analyst. Your task is to evaluate the health and long-term sustainability of an open source project based on the provided repository data.

## Repository to Evaluate
[REPOSITORY_IDENTIFIER]

## Our Usage Context
[DEPENDENCY_USAGE_CONTEXT]

## Evaluation Dimensions
Analyze the repository across the following dimensions. For each, provide a finding, a confidence level (High, Medium, Low), and cite the specific evidence you relied on.

[EVALUATION_DIMENSIONS]

## Output Schema
Return a valid JSON object matching this structure exactly:
{
  "project_name": "string",
  "assessment_date": "YYYY-MM-DD",
  "overall_sustainability_score": number (0-100),
  "overall_confidence": "High|Medium|Low",
  "dimensions": [
    {
      "name": "string",
      "finding": "string",
      "risk_level": "Critical|High|Medium|Low",
      "confidence": "High|Medium|Low",
      "evidence": ["string"]
    }
  ],
  "adoption_risk_flags": [
    {
      "flag": "string",
      "severity": "Critical|High|Medium|Low",
      "explanation": "string"
    }
  ],
  "recommendation": "Adopt|Adopt with Monitoring|Neutral|Avoid|Replace",
  "recommendation_rationale": "string",
  "data_quality_notes": ["string"]
}

## Constraints
- Base every finding on evidence present in the provided repository data. If evidence is missing for a dimension, set confidence to "Low" and note the gap in `data_quality_notes`.
- Do not invent commit counts, issue resolution times, or funding amounts. If data is unavailable, state that explicitly.
- If the repository appears abandoned (no commits in 12+ months, no maintainer response to issues), flag it as Critical risk regardless of other scores.
- The `overall_sustainability_score` must reflect a weighted concern for bus factor, maintenance activity, and security responsiveness.
- If our `[DEPENDENCY_USAGE_CONTEXT]` indicates deep integration or security-sensitive use, apply a stricter risk threshold.

To adapt this template, start by replacing [REPOSITORY_IDENTIFIER] with the GitHub owner/repo string or an internal package registry identifier. The [DEPENDENCY_USAGE_CONTEXT] should describe how your application consumes the package—for example, "core authentication middleware" or "development-only linting tool." This context is critical because it changes the risk calculus. The [EVALUATION_DIMENSIONS] placeholder should be replaced with a bulleted list of the specific factors you want assessed, such as "Maintainer bus factor," "Issue resolution time (median over last 90 days)," "Release cadence," "Security advisory history," and "Funding and sponsorship status." After running the prompt, validate the output JSON against the schema before ingesting it into your dependency risk dashboard. For high-risk dependencies, route the output to a human reviewer before accepting an "Adopt" or "Avoid" recommendation.

This prompt is designed to be called programmatically as part of a dependency risk assessment pipeline, not as a one-off chat interaction. The typical integration point is a CI/CD check, a periodic dependency audit job, or a pull-request review bot that evaluates new dependencies before they are merged. The application layer is responsible for gathering the required inputs—repository metadata, recent activity data, issue/PR statistics, funding information, and community signals—before assembling the prompt. The model's output should be treated as a structured risk signal that feeds into a larger decision record, not as the sole gate for blocking or approving a dependency.

Input assembly: Before calling the model, collect data from the GitHub/GitLab API, OpenCollective or GitHub Sponsors API, and package registry metadata. Normalize this into the [REPOSITORY_DATA] placeholder as a structured JSON or markdown table containing: repository name, stars, forks, open issues count, closed issues count, average issue response time (days), average PR merge time (days), number of unique contributors in the last 6 and 12 months, number of maintainers with merge rights, date of last release, date of last commit to default branch, funding platform links and active sponsor count, and any recent security advisory history. Validation layer: Before sending the prompt, validate that required fields are populated and that timestamps are within expected ranges. If the repository has fewer than 10 commits total or was created in the last 30 days, prepend a [CONSTRAINTS] note that the model should flag insufficient history for reliable assessment. Model choice: Use a model with strong structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set response_format to json_schema with the expected output schema. Temperature should be set low (0.0–0.2) to maximize consistency across evaluations.

Retry and fallback logic: If the model response fails schema validation, retry once with the validation errors appended to the prompt as additional [CONSTRAINTS]. If the second attempt also fails, log the failure, emit a partial result with an assessment_incomplete flag set to true, and route the dependency for manual review. Logging and audit trail: Store the full prompt, model response, parsed scores, and any validation errors in an audit log tied to the dependency name and version. This is critical for supply chain governance because decisions about dependency adoption must be reproducible and explainable to security auditors. Human review gates: Any dependency that scores below 40 on overall sustainability or has a bus factor of 1 should automatically trigger a human review ticket with the full evaluation report attached. Do not auto-block dependencies based solely on the model's score—use the score to prioritize human review queues. Scheduling: For existing dependencies, run this evaluation on a quarterly cadence and whenever a major version bump is proposed. For new dependencies, run it as a blocking informational check in the PR workflow, not as a merge gate unless your organization's policy explicitly requires it.