Cross-Team Dependency Readiness Assessment Prompt

This prompt is designed for release managers and program coordinators who need to assess whether all dependent teams, services, and external partners are prepared for a coordinated release. It synthesizes status reports, integration test results, and communication threads into a structured dependency readiness matrix. Use this prompt when you have multiple teams contributing to a release train and need a single, defensible view of cross-team readiness before making a go/no-go call. This prompt does not replace direct team communication; it structures the evidence you already have.

The ideal input is a collection of structured and unstructured evidence: team status reports, integration test pass/fail logs, API contract test results, email or chat threads confirming readiness, and any known blocking issues. The prompt expects you to supply this evidence in the [DEPENDENCY_EVIDENCE] block. You must also provide a [DEPENDENCY_MAP] that defines each dependency, the owning team, the consuming team, and the agreed-upon interface or contract. Without a clear dependency map, the model cannot correctly attribute readiness status. The output is a matrix with status per dependency (Ready, At Risk, Not Ready, Unknown), blocking risks, and recommended synchronization actions. This structured output can be consumed by a release dashboard or governance workflow.

Do not use this prompt when you lack concrete evidence for most dependencies. If teams have not submitted status reports or integration tests have not run, the model will produce a matrix full of 'Unknown' statuses, which adds no value and may create a false sense of due diligence. Similarly, do not use this prompt for single-team releases with no cross-team dependencies; a simpler release readiness checklist is more appropriate. For high-risk releases where regulatory or safety-critical systems are involved, always pair this prompt's output with human review and direct confirmation from each dependent team lead before finalizing any go/no-go decision.

The following prompt template is designed to be copied directly into your AI harness, notebook, or orchestration layer. It accepts a dependency list, per-dependency status evidence, a release timeline, and known risks as input. The model is instructed to produce a strict JSON dependency readiness matrix, making it suitable for automated downstream processing in release dashboards or CI/CD pipelines.

textCopy
You are a release coordination analyst. Your task is to assess cross-team dependency readiness for an upcoming coordinated release. You will receive a list of dependencies, status evidence for each, and the release timeline. Produce a structured dependency readiness matrix.

## DEPENDENCY LIST
[DEPENDENCY_LIST]

## STATUS EVIDENCE PER DEPENDENCY
[STATUS_EVIDENCE]

## RELEASE TIMELINE
[RELEASE_TIMELINE]

## KNOWN RISKS AND UNRESOLVED ISSUES
[KNOWN_RISKS]

## INSTRUCTIONS
1. For each dependency, determine a readiness status: READY, AT_RISK, NOT_READY, or UNKNOWN.
2. For each dependency, identify blocking risks that could prevent the coordinated release.
3. For each dependency, recommend synchronization actions to align timelines or resolve blockers.
4. Produce a dependency readiness matrix with the fields specified in the output contract.
5. If evidence is missing or insufficient for a dependency, set status to UNKNOWN and note what evidence is needed.
6. Do not invent status information. If evidence is ambiguous, state the ambiguity explicitly.
7. Flag any dependency where the stated completion date conflicts with the release timeline.

## OUTPUT CONTRACT
Return a JSON object with this structure:
{
  "release_id": "string",
  "assessment_date": "string (ISO 8601)",
  "overall_readiness": "READY | AT_RISK | NOT_READY",
  "dependencies": [
    {
      "dependency_name": "string",
      "dependent_team": "string",
      "dependency_type": "INTERNAL_SERVICE | EXTERNAL_PARTNER | SHARED_LIBRARY | INFRASTRUCTURE | DATA_PIPELINE",
      "status": "READY | AT_RISK | NOT_READY | UNKNOWN",
      "evidence_summary": "string (max 200 chars)",
      "blocking_risks": ["string"],
      "synchronization_actions": ["string"],
      "last_status_update": "string (ISO 8601 or null)",
      "confidence": "HIGH | MEDIUM | LOW"
    }
  ],
  "critical_blockers": ["string"],
  "missing_evidence": ["string"],
  "recommended_escalations": ["string"]
}

To adapt this template, replace the square-bracket placeholders with structured data from your release management system. The [DEPENDENCY_LIST] should be a markdown table or JSON array of dependency names and owning teams. [STATUS_EVIDENCE] must contain the latest completion percentages, test results, or integration sign-offs per dependency. The [RELEASE_TIMELINE] should include the target release date and any hard deadlines for dependency completion. [KNOWN_RISKS] can be populated from your risk register or prior release retrospectives. For high-stakes releases, always route the output through a human review step before the overall_readiness field is used to gate deployment.

When integrating this prompt into an application, validate the output JSON against the schema before acting on it. If the overall_readiness is AT_RISK or NOT_READY, or if any dependency has a LOW confidence score, trigger an escalation workflow rather than automatically blocking the release. The missing_evidence array is your primary signal for data collection gaps—use it to prompt team leads for updates before re-running the assessment.

This prompt is designed to be called via API as part of an automated release gate check, not as a one-off chat interaction. The primary integration point is a release management dashboard or CI/CD pipeline stage that collects structured input from project management tools (Jira, Linear, Asana), service catalogs, and prior incident databases. The application layer is responsible for assembling the [DEPENDENCY_LIST], [TEAM_STATUS_REPORTS], [INCIDENT_HISTORY], and [RELEASE_TIMELINE] placeholders from these systems of record before invoking the model. Do not pass raw, unprocessed data dumps; pre-process inputs into the structured format described in the prompt template to reduce hallucination and improve consistency.

Configure the API call with response_format set to json_schema (or the equivalent structured output mode for your model provider) using the DependencyReadinessMatrix schema defined in the prompt. After receiving the response, run a strict validation pass: check that every dependency in the input list has a corresponding entry in the output matrix, that all status fields match the allowed enum values (ready, at_risk, blocked, unknown), that blocking_risks entries contain non-empty descriptions when status is blocked, and that recommended_actions are present for any dependency not marked ready. If validation fails, construct a retry prompt that appends the specific validation errors to the original prompt context and re-invoke the model exactly once. Do not loop indefinitely; if the retry also fails validation, log the failure and escalate to a human release coordinator.

For high-risk releases—defined by criteria such as multiple blocked dependencies, dependencies on teams with recent incident history, or releases affecting revenue-critical services—route the validated output to a human review queue before the dependency matrix is shared with stakeholders. The review interface should display the full prompt, the model's raw response, the validation result, and a diff against the previous release's dependency matrix if available. Log every invocation with a unique release_id and timestamp, storing the complete prompt, response, validation outcome, and reviewer decision in an audit trail alongside the release decision record. This traceability is essential for post-release reviews and compliance with internal change management policies.