Multi-Repo Consolidated Changelog Prompt Template

This prompt is for platform teams, release managers, and technical writers who need to produce a single, unified changelog from commits, PRs, and issues across multiple repositories. It is designed for environments with microservices, shared libraries, and infrastructure-as-code repos that release on a coordinated cadence. Use this prompt when you have raw change data from several sources and need a structured, categorized, and deduplicated release note with service-level breakdowns and cross-service impact notes.

The prompt assumes you have already collected the raw input from each repository and can provide it in a structured format. Each input entry should include the source repository, change type, description, linked issues, and any breaking-change flags. The model will deduplicate entries that appear across multiple sources, categorize changes by impact (breaking, feature, fix, maintenance), and produce a consolidated output with per-service sections and cross-service impact annotations. You must supply version alignment metadata so the model can flag repositories that are missing from the release or running mismatched versions.

Do not use this prompt for single-repo changelogs; a simpler commit-to-changelog prompt is more appropriate for that scope. Avoid this prompt when your repositories lack consistent tagging or versioning conventions, because the deduplication and cross-service logic depends on aligned version identifiers. If your raw data is incomplete or you cannot provide structured inputs per repository, invest in data collection before running this prompt. For regulated environments, always include a human review step after generation to verify breaking-change classifications and migration guidance before publication.

This prompt template is designed to be copied directly into your AI harness, IDE, or orchestration layer. It accepts raw changelog data from multiple repositories, a target release version and date, and any known cross-service dependencies. The model is instructed to parse, categorize, deduplicate, and restructure the input into a unified release note with service-level breakdowns, cross-cutting change sections, and missing-repository flags. The output is a complete Markdown document ready for review and publication.

markdownCopy
You are a release manager for a platform engineering team. Your task is to consolidate raw changelog entries from multiple repositories into a single, structured, and deduplicated release note.

## Input Data
Below are the raw changelog entries grouped by repository. Each entry includes a category, description, and optional linked issues or PRs.

[RAW_CHANGELOG_DATA]

## Target Release
- Release Version: [TARGET_VERSION]
- Release Date: [RELEASE_DATE]

## Known Cross-Service Dependencies
[KNOWN_DEPENDENCIES]

## Instructions
1. Parse all entries from the input data.
2. Categorize every change into one of: Breaking Changes, Features, Fixes, Deprecations, Security, Dependencies, Documentation, or Internal/Refactor.
3. Deduplicate entries that appear in multiple repositories. If a change affects multiple services, list it once under a "Cross-Cutting Changes" section and note the affected services.
4. For each entry, preserve links to original issues, PRs, and contributors from the raw data.
5. Generate a "Service-Level Breakdown" section that lists changes specific to each repository.
6. Generate a "Cross-Service Impact Notes" section that flags changes in one service that require action from consumers of another service.
7. If a repository is missing from the input or has a version that does not align with the target release, flag it in a "Missing or Misaligned Repositories" section at the top of the report.
8. Do not invent changes, contributors, or links that are not present in the raw input.

## Output Format
Return the consolidated changelog in Markdown using the structure below. Do not wrap the output in a code block.

# Release [TARGET_VERSION] - [RELEASE_DATE]

## Missing or Misaligned Repositories
[Flag any missing repos or version mismatches here. If none, write "All expected repositories are present and aligned."]

## Highlights
[A 3-5 bullet summary of the most impactful changes across all services]

## Breaking Changes
[Table: Change | Affected Services | Migration Notes]

## Cross-Cutting Changes
[Changes that span multiple services]

## Service-Level Breakdown
### [Service Name] ([Version])
- **Features**
  - ...
- **Fixes**
  - ...
[Repeat for each service]

## Cross-Service Impact Notes
[Flag changes in one service that require action from consumers of another]

## Contributors
[Deduplicated list of contributors with links to their contributions]

To adapt this template, replace the three square-bracket placeholders with your actual data. [RAW_CHANGELOG_DATA] should contain the full set of changelog entries, grouped by repository and including categories, descriptions, and issue/PR links. [TARGET_VERSION] and [RELEASE_DATE] define the release you are documenting. [KNOWN_DEPENDENCIES] should list any known cross-service dependencies that might affect how changes are interpreted—for example, a shared protocol buffer definition or a database schema consumed by multiple services. If no dependencies are known, replace this placeholder with "None."

Before integrating this prompt into a production release pipeline, add a validation step after the model responds. Check that every entry in the input appears in the output under the correct service and category. Verify that no contributor names, issue links, or PR references were fabricated by comparing the output against the raw input. For high-stakes releases, route the generated changelog to a human reviewer for final approval before publication. This prompt works best with models that have strong instruction-following and structured output capabilities, such as Claude 3.5 Sonnet or GPT-4o.

Common failure modes include: the model merging distinct changes that share similar descriptions, misclassifying a breaking change as a feature, or omitting a repository entirely if the input format is inconsistent. To mitigate these, ensure your raw changelog data uses a consistent structure across all repositories before passing it to the prompt. If you encounter persistent categorization errors, add a few-shot example section showing correct categorization for your domain's typical changes.

This prompt is designed to be the final aggregation step in a multi-repo release documentation pipeline. It should be executed only after all per-repository changelogs have been generated by sibling prompts—such as 'Commit History to Structured Changelog' or 'PR Description to Release Note Extraction'—and their outputs have been collected. The primary input, [RAW_CHANGELOG_DATA], is a pre-formatted string that concatenates these individual structured changelogs, typically as a series of Markdown sections. The job of this prompt is not to re-summarize individual commits, but to synthesize a unified, cross-service narrative, identify missing repositories, and flag breaking changes that span multiple components.

To integrate this into an automated release pipeline, use a script—such as a Python or Bash script in a CI/CD workflow—to gather the outputs of upstream changelog prompts and inject them into the [RAW_CHANGELOG_DATA] variable. When calling the LLM, set the response_format to text or omit it entirely, as the expected output is a Markdown document, not a structured JSON object. After receiving the model's response, immediately run a validation step. The most critical check is to parse the 'Missing or Misaligned Repositories' section of the generated Markdown and compare the listed repositories against your expected list of all repositories that should have been included in the release. A mismatch here indicates a failure in the upstream data collection or a hallucination by the model.

For robust production use, implement a retry mechanism. If the initial output fails the repository-list validation, retry the prompt once with a more explicit instruction prepended to the [RAW_CHANGELOG_DATA], such as: 'CRITICAL: The previous output failed validation because the list of missing repositories was incorrect. The expected repositories are: [EXPECTED_REPO_LIST]. Please re-evaluate the input and ensure the missing repository list is accurate.' Log the prompt template version, a hash of the input data, the full model output, and the validation result for each run. This audit trail is essential for debugging discrepancies between releases. Finally, never publish the consolidated changelog without a human review step. A release manager or technical lead must manually verify all entries in the 'Breaking Changes and Cross-Service Impact' section, as these carry the highest risk of customer-facing disruption.