Linter Output Triage and Prioritization Prompt Template

This prompt is designed for DevSecOps engineers, platform teams, and technical leads who receive raw, high-volume linter or static analysis output and need to turn it into an actionable work queue. The core job is triage and prioritization, not remediation. Use it when you have a dump of findings from one or more tools—ESLint, Pylint, Semgrep, Checkstyle, or similar—and you need a deduplicated, severity-ranked, and categorized list that a team can actually act on. The prompt expects you to provide the raw lint output, your team's severity taxonomy, and any known false-positive patterns or suppression rules. It does not assume a specific language or tool, but it does assume the findings are already in a parseable text format.

Do not use this prompt when you need a code fix, a security exploit proof-of-concept, or a deep root-cause analysis of a single finding. Those are separate workflows covered by sibling playbooks like Context-Aware Lint Fix Suggestion or Security Linter Finding Remediation. This prompt is also not a replacement for a linting dashboard or a CI quality gate; it is a human-readable prioritization aid that should feed into your backlog, not make automated pass/fail decisions. If you need a machine-readable decision, use the Code Quality Gate Pass/Fail Decision prompt instead. The output here is structured for human review and sprint planning, not for direct CI integration.

Before using this prompt, gather the raw linter output, your team's agreed severity definitions (what constitutes Critical, High, Medium, Low), any known false-positive signatures or file paths to suppress, and the target audience for the triage report (e.g., a specific squad, a security team, or a cross-functional review board). The prompt works best when you include these as explicit [CONSTRAINTS] and [CONTEXT] blocks. After running the prompt, validate the output against the eval checks described in the full playbook: correct severity mapping, deduplication accuracy, false-positive flagging, and owner assignment reasonableness. If the output will drive sprint commitments, have a human reviewer spot-check at least 10% of the prioritized findings before accepting the triage.

The following template is designed to be dropped into your AI harness, whether you're building a CI bot, a PR review assistant, or an internal DevSecOps dashboard. It takes raw, often noisy linter output and transforms it into a structured JSON payload that your application can consume directly. The prompt uses square-bracket placeholders for all dynamic inputs, making it straightforward to wire into a pipeline where [LINTER_OUTPUT] is piped from a tool like ESLint, Pylint, or Semgrep, and [REPOSITORY_CONTEXT] is assembled from file paths, recent commits, or a CODEBUDDY.md.

codeCopy
You are a senior DevSecOps engineer triaging raw linter output for a production codebase.

Your task is to process the provided linter output and produce a prioritized, deduplicated, and categorized list of findings. Your output will be used by an automated system to assign tickets and notify code owners, so strict schema adherence is critical.

## INPUT
[LINTER_OUTPUT]

## REPOSITORY CONTEXT
[REPOSITORY_CONTEXT]

## CONSTRAINTS
- Deduplicate findings that share the same root cause, file, and line range. Keep the highest severity instance and note the count of duplicates in the `duplicate_count` field.
- Map all tool-specific severities to a standard scale: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW`, `INFO`.
- Estimate remediation effort as `TRIVIAL` (<15 min), `SMALL` (<1 hr), `MEDIUM` (<4 hrs), or `LARGE` (>4 hrs).
- Suggest a likely owner team based on file path patterns in [REPOSITORY_CONTEXT] (e.g., `**/*.spec.ts` -> `QA-Team`).
- Flag any finding that appears to be a false positive based on common patterns (e.g., a lint rule conflicting with a documented team convention in [REPOSITORY_CONTEXT]). Provide a brief justification in `false_positive_reason`.
- Do not invent or assume file paths, code snippets, or fixes not present in the input.

## OUTPUT_SCHEMA
Return a single JSON object with a `findings` array. Each object in the array must conform to this schema:
{
  "finding_id": "string (unique slug, e.g., 'no-unused-vars-src-utils-helper-ts-L12')",
  "category": "string (e.g., 'security', 'bug-risk', 'style', 'performance', 'maintainability')",
  "severity": "CRITICAL | HIGH | MEDIUM | LOW | INFO",
  "file_path": "string",
  "line_range": "string (e.g., 'L12-L15')",
  "rule_id": "string (original linter rule identifier)",
  "message": "string (original, unaltered linter message)",
  "duplicate_count": "number (1 if unique)",
  "effort_estimate": "TRIVIAL | SMALL | MEDIUM | LARGE",
  "suggested_owner": "string (team or 'unknown')",
  "is_false_positive": "boolean",
  "false_positive_reason": "string | null"
}

## PRIORITY SORT ORDER
Sort the `findings` array by:
1. Severity (CRITICAL first)
2. Category (security before style)
3. File path (alphabetical)
4. Line number (ascending)

Return only the JSON object. Do not include any text outside the JSON.

To adapt this template, start by replacing [LINTER_OUTPUT] with the raw stdout or JSON report from your linter. The [REPOSITORY_CONTEXT] placeholder should be filled with a concise map of file ownership patterns, a CODEOWNERS file excerpt, or a summary of team conventions that might justify suppressing a rule. If you're using a model with a small context window, consider pre-filtering the linter output to only include errors and warnings before passing it in. For high-risk repositories, add a [RISK_LEVEL] constraint that adjusts the severity mapping for security rules, ensuring no CRITICAL finding is ever auto-suppressed without human review.

Before deploying this prompt, validate its output against your application's schema. A common failure mode is the model collapsing multiple findings into a single object or inventing a suggested_owner when no ownership data is provided. Implement a post-processing validator that checks for unique finding_id values, rejects any finding with a file_path not present in the original linter output, and escalates findings flagged as is_false_positive: true to a human review queue. Wire the validated JSON directly into your ticketing system, using the suggested_owner field to route the issue.

This prompt is designed to sit behind an API endpoint or a CI job that receives raw, multi-tool linter output. The application layer is responsible for collecting the raw findings, normalizing them into the [LINT_OUTPUT] format expected by the prompt, and handling the structured response. Do not pass raw, unprocessed tool stdout directly to the model; always pre-parse it into a consistent JSON or Markdown list of findings with at least file, line, rule_id, and message fields. This pre-processing step is critical because the model's triage quality depends on receiving clean, deduplicated input with consistent field names across tools like ESLint, Pylint, and Semgrep.

After the model returns the prioritized JSON payload, validate it against the expected [OUTPUT_SCHEMA] before any downstream action. A lightweight validation layer should check that every finding in the response maps back to a finding in the original input (no hallucinated violations), that severity levels are within the allowed enum, and that the deduplicated_group_id references are internally consistent. If validation fails, retry once with the validation errors appended to the prompt as additional [CONSTRAINTS]. Log every triage response, including the raw model output, validation result, and any retries, to an observability store for later audit and prompt regression testing. For high-risk security findings where a false negative could mean a missed vulnerability, route CRITICAL severity items to a human review queue before auto-closing or suppressing them.

Model choice matters here. Use a model with strong JSON mode and long-context handling, such as gpt-4o or claude-3.5-sonnet, because the input payload can be large and the output schema is deeply nested. Set temperature to 0 or a very low value to maximize deterministic severity mapping and deduplication. If you are processing findings from a monorepo with thousands of violations, chunk the input by directory or rule category and run parallel triage calls, then merge the results with a final deduplication pass. Avoid wiring this prompt directly into an auto-fix pipeline without human approval for any finding above LOW severity; the triage output is a prioritization artifact, not a remediation command.