dt-sdlc-evidence-gates

Validate design, delivery, and release decisions with DQL queries against Dynatrace runtime baselines and SLOs.

Updated Dec 12, 2025
One-click install
npx skills add https://github.com/ricardojjulia/ESACompanion --skill dt-sdlc-evidence-gates-ricardojjulia
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dt-sdlc-evidence-gates
Source: https://github.com/ricardojjulia/ESACompanion/tree/main/.github/skills/dt-sdlc-evidence-gates
Command: npx skills add https://github.com/ricardojjulia/ESACompanion --skill dt-sdlc-evidence-gates-ricardojjulia

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Delivery and release decisions are often made on assumptions rather than evidence. This Skill replaces manual checklists and guesswork with grounded verdicts based on Dynatrace runtime telemetry, error budgets, SLOs, and deployment health data. ## Core Features & Use Cases - Three Gate Types: Design, Delivery, and Runtime gates, each with a defined verdict set (PASS, FAIL, ROLLBACK, LANE A/B/C) backed by DQL evidence queries. - Baseline Discovery: Ready-to-use DQL queries for service latency baselines, error budget status, deployment events, and host saturation. - Risk Tiering: A Tier 0/1/2 assessment framework that matches lifecycle depth to change risk, so low-risk changes skip unnecessary gates. - Post-Deploy Verification: Pre/post latency comparison, new-problem detection, feature flag checks, and dtctl wait query rollout assertions. - Use Case: Before shipping a hot-path change, run the design gate to collect baselines and map dependencies, then after deployment compare p90 latency against the pre-deploy baseline and classify any regression into infra, code, or design lanes. ## Quick Start Ask the assistant to run an evidence-based delivery gate for a service by collecting its Dynatrace baseline and evaluating whether the change is safe to ship.

Frequently Asked Questions about dt-sdlc-evidence-gates

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I validate a release with Dynatrace runtime data?▼

Run the delivery gate procedure: collect a latency and error-rate baseline with DQL, compare staging metrics against it, and check SLO compliance via dtctl and runtime SLI proxy queries. The gate returns PASS, PASS WITH NOTES, FAIL, or FAIL AND RE-DESIGN based on the evidence.

How to compare pre and post deployment latency with DQL?▼

Use a timeseries query computing p90 response time for the last hour and append a shifted baseline query for the prior hour, then calculate degradation percentage. A regression beyond your threshold triggers the ROLLBACK verdict in the runtime gate.

What risk tier does my change need for delivery gates?▼

Tier 0 covers docs and zero-behavior refactors needing only local validation. Tier 1 covers non-hot-path changes requiring design enrichment and a delivery gate. Tier 2 covers hot-path, dependency, timeout, retry, or security changes requiring the full lifecycle including a runtime gate.

How do I check SLO error budget status with dtctl?▼

Run dtctl get slos --plain to list configured SLOs, then dtctl describe slo <slo-id> --plain to inspect status and remaining error budget. Complement this with a DQL runtime SLI proxy query for availability, error rate, and p90 latency on the target service.

When should I not use the full evidence gate lifecycle?▼

Skip the full lifecycle for Tier 0 changes such as documentation, naming, formatting, or verified zero-behavior refactors, which need only local validation. Applying full gates to low-risk changes wastes query quota and review effort.

How are production issues classified after a failed runtime gate?▼

Issues are routed into three lanes: Lane A for infrastructure causes like CPU saturation or pod eviction, Lane B for code issues correlated with a recent deployment, and Lane C for persistent design-level degradation requiring architectural review.