Synthesis
AuraScore 79/100

Cross-Service Technical Debt and Observability Synthesis Spec

Synthesize distributed trace logs, error budget consumption, and static debt reports into an infrastructure-wide platform hardening spec.

Use this template when runtime fragility, high defect churn, and observability blind spots span across multiple services. It synthesizes cross-repo metrics into an engineering platform hardening and telemetry specification.

Template

Role: Lead Platform Engineer specializing in observability pipelines, runtime profiling, and engineering standards.

Context

  • Runtime Platform & Cluster: {{runtime_platform}}
  • Target Infrastructure Environment: {{target_cluster_env}}
  • Distributed Trace Samples & Profiling Data: {{distributed_trace_samples}}
  • Flaky Test & Build Reports: {{flaky_test_reports}}
  • Service Error Budget Metrics: {{error_budget_metrics}}
  • Aggregated Technical Debt Backlog: {{tech_debt_backlog}}

Task

Synthesize cross-cutting runtime logs, APM traces, and debt backlogs into an actionable engineering platform hardening specification that standardizes observability, eliminates systemic instability, and restores error budgets.

Method

  1. Correlate items in {{tech_debt_backlog}} against recurring latency outliers present in {{distributed_trace_samples}}.
  2. Map service failure rates and SLA burn in {{error_budget_metrics}} to missing trace context and logging discrepancies.
  3. Analyze {{flaky_test_reports}} to distinguish between non-deterministic test assertions, concurrency races, and infrastructure timeouts.
  4. Synthesize common antipatterns discovered across services running on {{runtime_platform}} in {{target_cluster_env}}.
  5. Specify uniform OpenTelemetry standards, including required trace propagation headers, span attributes, and metric naming conventions.
  6. Design centralized middleware and SDK guardrails to enforce standardized timeout budgets, pool limits, and structured logs.
  7. Define explicit criteria for deprecating legacy libraries and refactoring high-risk modules.
  8. Formulate a technical debt governance rubric to prioritize remediations by error budget impact.

Constraints

  • MUST adhere strictly to standard OpenTelemetry (OTel) conventions for all metric and trace schema definitions.
  • MUST NOT recommend total service rewrites; focus entirely on incremental hardening, middleware injection, and configuration standards.
  • All telemetry specifications MUST include exact semantic attribute keys and expected value types.
  • Keep platform configuration examples tailored specifically to {{runtime_platform}}.

Output format

  1. Platform Fragility & Debt Correlation Matrix
  2. Standardized Observability & Telemetry Schema Specification
  3. Runtime Resiliency Middleware Configuration Spec (Timeouts, Pools, Retries)
  4. CI/CD Flake Remediation & Test Quality Gate Specification
  5. Prioritized Engineering Hardening Backlog (Ranked by error budget recovery)

Self-review

  • Ensure all proposed span attributes conform to vendor-neutral OpenTelemetry standards.
  • Confirm that every hardening item directly mitigates a recorded metric in {{error_budget_metrics}}.
  • Verify that middleware configurations are compatible with {{runtime_platform}} and {{target_cluster_env}}.
AuraScore breakdown
79/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 engineering10/12 · Adequate

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
platform-engineering
observability
opentelemetry