Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

cross-source-correlation

Étoiles85

Forks16

Mis à jour3 mai 2026 à 10:07

Correlate near-in-time events across PR merges, deploys, monitoring (Sentry/NewRelic/Datadog/AppDynamics) and ticket trackers (Jira/Azure DevOps) into confidence-scored clusters that answer "which deploy caused this bug" without manual tab-switching.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

aozyildirim

aozyildirim/Agena

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	cross-source-correlation
description	Correlate near-in-time events across PR merges, deploys, monitoring (Sentry/NewRelic/Datadog/AppDynamics) and ticket trackers (Jira/Azure DevOps) into confidence-scored clusters that answer "which deploy caused this bug" without manual tab-switching.
tags	["observability","incident-response","correlation","ai-agent","devops"]
publisher	agena

Cross-Source Correlation

When a Sentry alert fires, a senior engineer mentally cross-references the last deploy time, recent PRs, NewRelic apdex, and the support tickets opened in the last hour. AGENA's Cross-Source Correlation engine does the same correlation deterministically, producing a single confidence-scored cluster per incident.

How to apply this pattern

Pick a time window (default 60 minutes ending now) and pull every event your platform observed inside it: PR merges, deploys, error imports (Sentry / NewRelic / Datadog / AppDynamics), and work-item imports (Jira / Azure DevOps).
Score candidate clusters using a heuristic that rewards co-location in time + repo:
- PR merge inside the window → +40
- Deploy from the same repo inside the window → +20
- One monitoring signal in the window → +20 (+30 if more than one)
- One work-item opened in the window → +10 (+20 if more than one)
- Bonus +10 when a PR is present alongside any monitoring signal
Surface only clusters ≥ 70. Below that the noise / signal ratio collapses; above it you get the "vay" moment for incident triage.
Persist the cluster with: primary_kind, primary_label, related_events[], confidence, severity, narrative, repo_mapping_id. Keep a fingerprint for idempotency so repeated poller runs don't double-insert the same cluster.
Offer triage actions on each cluster: confirm, false-positive, undo, and (when a PR is the prime suspect) one-click rollback.

Example

🔴 CRITICAL · confidence 94%

PR #4519 (erinc, merged 14:18) in checkout-api correlates with
2 monitoring signal(s) (sentry, newrelic) and 1 work-item opened
in the same window.

Timeline:
  14:18  🔀 PR #4519 merged — payment_service.py, +47/-12
  14:18  🚀 deploy a1b2c3d4 → production
  14:23  🚨 Sentry: TypeError in payment_service.py:88 (47×)
  14:24  📡 NewRelic: apdex 0.92 → 0.41
  14:31  🪐 Jira SUP-128 opened — 12 customers report failed checkout

Notes

Run as a background poller every ~5 minutes on a fresh window — no webhook fan-out needed when you control all the sources.
Sub-70 clusters can still be useful for trending dashboards even if you don't want to surface them as actionable.
Store the cluster's narrative as a one-sentence summary (LLM-generated off the timeline) so it's readable in Slack alerts and post-mortem docs.
Designed to be agnostic to specific monitoring backends — add a new source by writing a single mapper that emits (timestamp, kind, ref, label) rows into the same window query.

Plus depuis ce dépôt

même dépôt

integration-rule-engine

aozyildirim/Agena

A declarative routing engine that turns ticket / error attributes (reporter, label, project, area path, error class, environment) into a tag + AI agent + priority assignment, so cross-source workflows ("security tickets always go to the OWASP reviewer") stay out of code and in user-editable rules.

2026-05-0385

owasp-reviewer-prompt

aozyildirim/Agena

A paranoid OWASP-Top-10-aware system prompt for AI code review that traces data flow, treats every input as malicious, maps each finding to an OWASP category, and outputs a structured Summary / Findings / Severity / Score block reviewers can act on.

2026-05-0385

review-backlog-killer

aozyildirim/Agena

Detect pull requests aging past warn / critical thresholds, score severity, and nudge reviewers via Slack DM, channel, email, or directly as a PR comment — with one-time auto-escalation when a PR hits critical so velocity stops leaking through review queues.

2026-05-0385

stale-ticket-triage

aozyildirim/Agena

Replace the weekly "look at every ticket older than X days" meeting with a scheduled AI scan that picks close / snooze / keep per ticket plus a one-sentence reason, so a PM can bulk-approve in 90 seconds Monday morning.

2026-05-0385

name	cross-source-correlation
description	Correlate near-in-time events across PR merges, deploys, monitoring (Sentry/NewRelic/Datadog/AppDynamics) and ticket trackers (Jira/Azure DevOps) into confidence-scored clusters that answer "which deploy caused this bug" without manual tab-switching.
tags	["observability","incident-response","correlation","ai-agent","devops"]
publisher	agena

Cross-Source Correlation

How to apply this pattern

Pick a time window (default 60 minutes ending now) and pull every event your platform observed inside it: PR merges, deploys, error imports (Sentry / NewRelic / Datadog / AppDynamics), and work-item imports (Jira / Azure DevOps).
Score candidate clusters using a heuristic that rewards co-location in time + repo:
- PR merge inside the window → +40
- Deploy from the same repo inside the window → +20
- One monitoring signal in the window → +20 (+30 if more than one)
- One work-item opened in the window → +10 (+20 if more than one)
- Bonus +10 when a PR is present alongside any monitoring signal
Surface only clusters ≥ 70. Below that the noise / signal ratio collapses; above it you get the "vay" moment for incident triage.
Persist the cluster with: primary_kind, primary_label, related_events[], confidence, severity, narrative, repo_mapping_id. Keep a fingerprint for idempotency so repeated poller runs don't double-insert the same cluster.
Offer triage actions on each cluster: confirm, false-positive, undo, and (when a PR is the prime suspect) one-click rollback.

Example

🔴 CRITICAL · confidence 94%

PR #4519 (erinc, merged 14:18) in checkout-api correlates with
2 monitoring signal(s) (sentry, newrelic) and 1 work-item opened
in the same window.

Timeline:
  14:18  🔀 PR #4519 merged — payment_service.py, +47/-12
  14:18  🚀 deploy a1b2c3d4 → production
  14:23  🚨 Sentry: TypeError in payment_service.py:88 (47×)
  14:24  📡 NewRelic: apdex 0.92 → 0.41
  14:31  🪐 Jira SUP-128 opened — 12 customers report failed checkout

Notes

Run as a background poller every ~5 minutes on a fresh window — no webhook fan-out needed when you control all the sources.
Sub-70 clusters can still be useful for trending dashboards even if you don't want to surface them as actionable.
Store the cluster's narrative as a one-sentence summary (LLM-generated off the timeline) so it's readable in Slack alerts and post-mortem docs.
Designed to be agnostic to specific monitoring backends — add a new source by writing a single mapper that emits (timestamp, kind, ref, label) rows into the same window query.