Pull Request Lint Comment Summarization Prompt Template

This prompt is designed for code review bots, CI/CD pipelines, and developer tools that post automated lint feedback on pull requests. Its primary job is to transform a noisy, repetitive list of raw lint findings into a single, well-structured, and developer-actionable review comment. The ideal user is a platform engineer, DevSecOps lead, or developer building an AI-assisted code review harness. The prompt expects a structured input containing multiple lint findings, each with a file path, line number, rule ID, severity, and message. It produces a grouped summary that deduplicates identical violations, clusters related issues by file and category, and maintains a constructive, non-blaming tone that respects the developer's time.

Use this prompt when you have a batch of lint findings from one or more tools (ESLint, Pylint, RuboCop, Checkstyle, etc.) and need a single, coherent PR comment. It is appropriate when the findings are already deduplicated at the tool level or when you want the model to handle cross-tool deduplication. The prompt is not suitable for real-time IDE feedback where individual, immediate squiggles are more useful than a summary. It is also not a replacement for a security triage workflow: if the findings include critical SAST results that require immediate human review, route those through a dedicated security escalation path before summarization. The prompt assumes the input findings are already parsed into a consistent schema—it does not handle raw, unstructured linter output.

Before wiring this into a production PR workflow, ensure you have a clear contract for the input schema and a validation step that checks the output comment for length limits, markdown validity, and the presence of required sections. The prompt works best when combined with a post-generation evaluation that verifies no finding was dropped, severity levels are preserved, and the tone remains constructive. For high-risk repositories (compliance, safety-critical systems), always require human review of the summarized comment before it is posted to the PR. The next section provides the copy-ready prompt template you can adapt to your specific linter ecosystem and PR platform conventions.

This prompt template is designed to be dropped into a code review bot, CI pipeline, or AI coding agent workflow that receives raw linter output and must produce a single, well-structured review comment for a pull request. The template expects pre-processed lint findings grouped by file and category, and it outputs a deduplicated summary that a developer can act on without reading through hundreds of raw linter lines. Use this when you have multiple linters posting to the same PR and need a single coherent voice, or when raw lint output is too noisy for meaningful human review.

textCopy
You are a code review assistant summarizing lint findings for a pull request.

## INPUT
[LINT_FINDINGS]

## CONSTRAINTS
- Group findings by file path, then by category (e.g., style, bug-risk, security, performance, type-safety).
- Deduplicate identical findings within the same file. If the same violation appears on multiple lines, mention the line range instead of listing every line.
- For each group, write a single sentence that states the category, the count of occurrences, and the most representative example.
- Do not repeat the same advice across files. If a pattern spans multiple files, note it once under a "Cross-File Patterns" section.
- Use a neutral, non-blaming tone. Frame findings as opportunities, not failures.
- If a finding is likely a false positive based on [FALSE_POSITIVE_RULES], flag it with "[likely FP]" and a one-line justification.
- If the total finding count exceeds [MAX_FINDINGS], add a note: "[TRUNCATION_NOTICE] additional findings omitted. Run locally for full results."

## OUTPUT_SCHEMA
Return a single markdown comment with this structure:
1. A one-line summary: "This PR introduces [N] lint findings across [M] files."
2. A "## Findings by File" section with subsections per file.
3. An optional "## Cross-File Patterns" section if patterns repeat.
4. An optional "## Likely False Positives" section if any findings are flagged.
5. A "## Next Steps" section with one to three concrete actions.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

Adaptation guidance: Replace [LINT_FINDINGS] with pre-grouped JSON or markdown output from your linter aggregation step. [FALSE_POSITIVE_RULES] should be a list of patterns your team has agreed to suppress (e.g., specific rules in test files, generated code directories). [MAX_FINDINGS] prevents comment bloat on large PRs — set this based on your review tool's character limits or team attention budget. [FEW_SHOT_EXAMPLES] should include two to three examples of well-formed summaries from your actual codebase so the model learns your team's tone and grouping conventions. [RISK_LEVEL] controls how conservative the summary is: set to "high" to require explicit false-positive checks and truncation notices, or "low" for internal draft PRs where brevity matters more than auditability. Before shipping, validate the output against your PR comment schema, test with a golden set of known lint outputs, and ensure the truncation behavior triggers correctly when finding counts exceed your threshold.

This prompt is designed to sit inside a code review automation step that runs after linting tools produce their raw output. The typical integration point is a CI pipeline job or a webhook handler that receives lint results, invokes the LLM with this prompt, and posts the summarized comment to the pull request. The harness must handle input assembly, output validation, and fallback behavior when the model produces an unusable summary. Because the output will be posted as a public PR comment visible to the development team, the harness should enforce tone and accuracy checks before publishing.

Input assembly starts by collecting the raw lint findings from one or more tools (ESLint, Pylint, RuboCop, etc.) and grouping them by file path. The [LINT_FINDINGS] placeholder expects a structured list where each finding includes file, line, severity, rule_id, and message. If your lint tools output JSON or SARIF, transform that into the expected format before populating the prompt. The [REPOSITORY_CONTEXT] placeholder should include the PR diff or changed-file list so the model can distinguish new violations from pre-existing ones. The [TEAM_CONVENTIONS] placeholder is optional but valuable: supply a short markdown snippet of your team's style guide or suppression policy to help the model decide what's worth flagging. Model choice matters here. Use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller models that may hallucinate file paths or merge unrelated findings.

Output validation is the critical safety layer. Before posting the summary to the PR, validate the model's output against a schema: it must be valid markdown, must not exceed a configurable character limit (e.g., 2000 characters), must not contain placeholder tokens or unresolved references, and must not fabricate file paths or line numbers not present in the input. Implement a retry loop with up to 2 additional attempts if validation fails, feeding the validation error back to the model as [PREVIOUS_OUTPUT] and [VALIDATION_ERROR] in a retry prompt variant. If all retries fail, fall back to a simple template that lists files with violations and a link to the full lint report. Logging should capture the raw prompt, the model response, validation results, and whether the summary was posted or escalated. This audit trail is essential for debugging prompt drift and for teams that need to demonstrate review process compliance.

Human review gates depend on your risk tolerance. For most teams, auto-posting the summary is acceptable because the underlying lint findings are already visible in CI logs. However, if the summary includes severity classifications or fix suggestions that could mislead reviewers, add a draft comment step: post the summary as a hidden or draft PR comment, require a single reviewer approval, then publish. For security-sensitive repositories, consider routing summaries that flag CRITICAL or HIGH severity findings to a dedicated security review channel instead of the general PR comment thread. Tool integration is straightforward: the prompt expects no external tool calls during generation, but the harness itself may call the GitHub/GitLab/Bitbucket API to post the comment, fetch the diff, or query team membership for reviewer assignment.

What to avoid: Do not use this prompt to generate fix suggestions or code patches—that's a separate workflow with higher risk and requires diff verification. Do not skip output validation even if the model has been reliable in testing; production PR comments are a shared surface and a garbled or misleading summary erodes trust in the automation. Do not run this prompt on every push without diff-aware filtering; summarizing the same pre-existing lint violations on every commit creates noise. Finally, version your prompt template alongside your lint configuration so that changes to rules or severity thresholds are reflected in the summarization behavior.