Synthesis
AuraScore 81/100

Multi-Repository Code Health and Vulnerability Remediation Blueprint

Synthesize static analysis, dependency CVEs, and test metrics across multiple repositories into a technical debt burndown plan.

Use this template when planning engineering-wide technical debt sprints or security remediation cycles. It synthesizes vulnerability scans, code smell audits, and pipeline telemetry into an actionable debt burndown plan.

Template

Role: Staff Software Quality Architect with extensive background in static code analysis, CI/CD security tooling, and large-scale refactoring.

Context

  • Multi-repository static analysis findings: {{static_analysis_reports}}
  • Triaged security vulnerabilities: {{cve_vulnerability_list}}
  • Test suite performance and failure data: {{flaky_test_telemetry}}
  • Target runtime and framework versions: {{framework_upgrade_targets}}
  • Engineering productivity bottlenecks: {{developer_velocity_blockers}}
  • Total allocated engineering capacity: {{allocated_sprint_budget}}

Task

Synthesize security vulnerabilities, code maintainability issues, and testing bottlenecks into a prioritized, multi-sprint Technical Debt Remediation Plan that maximizes code health without stalling active feature delivery.

Method

  1. Ingest {{static_analysis_reports}} and {{cve_vulnerability_list}} to establish a unified threat and maintainability index across all repositories.
  2. Correlate hot-spot repositories with {{flaky_test_telemetry}} to pinpoint test harness liabilities that slow CI/CD verification.
  3. Map runtime dependencies against {{framework_upgrade_targets}} to flag breaking upstream changes and deprecated APIs.
  4. Score each debt item using a combined index of security severity (CVSS), churn rate, and developer friction from {{developer_velocity_blockers}}.
  5. Consolidate interdependent package updates into unified dependency bump waves to prevent diamond dependency conflicts.
  6. Group remediation tasks into modular work packages sized precisely to fit {{allocated_sprint_budget}}.
  7. Define automated guardrails (linter rules, CI pipeline blocks, SAST gates) to prevent re-introduction of resolved anti-patterns.

Constraints

  • MUST remediate all Critical and High CVEs within the first implementation wave.
  • MUST NOT recommend manual testing where automated regression suites or contract tests can be introduced.
  • Every work package must include an estimated story point weight and clear acceptance criteria.
  • Upgrades must not introduce breaking changes to public-facing API contracts.

Output format

Deliver a unified code health and remediation plan containing:

  1. Cross-Repository Debt Synthesis (250 words outlining top systemic risk factors).
  2. Severity-Weighted Debt Matrix (Table: Repository, Issue Category, CVSS/Maintainability Score, Velocity Impact, Sprint Allocation).
  3. Phased Burndown Schedule (Detailed roadmap partitioned across sprints adhering to capacity limits).
  4. Automated CI/CD Gate Definition (Specific linting, coverage, and security rules to implement in the build pipeline).
  5. Key Metric Success Targets (Clear before-and-after benchmarks for test pass rate, build duration, and open vulnerability counts).

Self-review

  • Ensure all CVEs from {{cve_vulnerability_list}} are directly accounted for in early sprint waves.
  • Confirm the total task workload strictly adheres to {{allocated_sprint_budget}}.
  • Check that fixes addressing {{developer_velocity_blockers}} have measurable CI/CD metric improvements.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

research-analysis
research-synthesis
software-engineering-debugging
code-quality
technical-debt
security-remediation