luciq-alert-noise

Find the alert rules that fire too often to be useful, and fix them at the source. Noise isn't "an alert fired a lot" — it's "an alert fired a lot and the firings weren't individually worth a notification." The skill's job is to cut fatigue without cutting coverage, and every recommendation is grounded in Luciq MCP data rather than guessed from a rule's title.

Use this skill when

• The user says their alerts are too noisy. "My alerts are too noisy", "I get too many alert emails/notifications".
• The user wants their alert setup cleaned up. "Clean up / tune / audit my alerts".
• The user asks which alerts are spammy or fire constantly. "Which alerts are spammy?", "stop paging me so much".
• The user asks which alert rules fire too often in general.

Not for: adding missing alerts or checking monitoring coverage (use luciq-alert-gaps), creating, changing, or managing one specific alert the user describes (use luciq-alert-config), investigating why something crashed or hung (use luciq-debug), or first-time SDK install (use luciq-setup). Resolving or acknowledging a single firing (an incident) rather than changing the rule itself is a direct one-call action, not a noise audit.

What the agent does

• Trigger-count triage. Pulls the full alert inventory sorted by how often each rule's conditions were met, and partitions rules into quiet (leave alone) and loud (investigate) using the product's own noise signal.
• Root-cause diagnosis. For each loud rule, figures out why it's loud — a trivially low threshold, an overly broad scope, correct detection but excessive paging, an exact duplicate of another rule, or a fully redundant rule — before picking a fix.
• Safety-critical protection. Never weakens detection or disables alerts that are supposed to fire loudly because each firing is a real emergency (a crash hitting real users, crash-free or ANR rate dropping below a safety floor). At most, it throttles the notification.
• Least-destructive remediation. Prefers raising a threshold, narrowing scope, or adding a throttle before recommending disabling a rule, and disabling before deleting.
• Approval before writing. Presents a per-rule remediation plan, with safety-critical rules called out separately, and only applies changes the user approves.

Install

The fastest path is the plugin install. Add the marketplace and install:

/plugin marketplace add luciqai/agent-skills
/plugin install [email protected]

Works in Claude Code and Cursor. The plugin install also wires up the Luciq MCP server in one step.

After install, the skill is available as /luciq-skills:luciq-alert-noise.

For other agents, install via npm:

npx luciq-skills install            # project-local
npx luciq-skills install --global   # all projects

Or copy SKILL.md from the public repo to ~/.claude/skills/luciq-alert-noise/SKILL.md (user-global) or .claude/skills/luciq-alert-noise/SKILL.md (project-local). The full SKILL.md is reproduced in the expandable below.

📋 Click to expand the full SKILL.md

---
name: luciq-alert-noise
description: Use when the user wants to reduce noisy, chatty, or spammy Luciq alerts, cut alert fatigue, or stop being over-notified. Triggers include "my alerts are too noisy", "I get too many alert emails/notifications", "alerts are firing constantly", "clean up / tune / audit my alerts", "which alerts are spammy", "stop paging me so much", or asking which alert rules fire too often. Inspects each alert's trigger frequency via the Luciq MCP and recommends targeted fixes (raise threshold, narrow scope, throttle, merge, or disable) — never blindly silencing a safety-critical alert.
---

# Luciq Alert Noise Reduction

Find the alert rules that fire too often to be useful, and fix them at the source. Noise is not "an alert fired a lot" — it is "an alert fired a lot **and the firings were not individually worth a notification**." The job is to cut fatigue without cutting coverage. Every recommendation is grounded in MCP data; never guess which alerts are noisy.

## When NOT to use this skill

- The user wants to **add** missing alerts or check monitoring coverage — use `luciq-alert-gaps`.
- The user wants to **create, change, or manage one specific alert** they describe — use `luciq-alert-config`.
- The user is investigating *why* something crashed/hung — use `luciq-debug`.
- First-time SDK install or wiring `Luciq.start(...)` — use `luciq-setup`.
- The user wants to resolve/acknowledge a specific firing (incident), not change the rule. That is a one-call `write_incidents` action, not a noise audit — just do it directly.

If the request fits one of the above, STOP and route there.

## Prerequisites

The Luciq MCP server must be configured and authenticated. If the alert tools are not available, STOP and direct the user to set up the MCP server (or run `luciq-setup`).

Tools this skill uses (verbatim names):

| Tool | Action | Purpose |
| --- | --- | --- |
| `read_alerts` | `list` | All alert rules + their `conditions_met_count` (the rolling trigger count) and current `status`. Sort by `highest_triggered_count` to surface the worst first. |
| `read_alerts` | `details` | Full payload of one rule. Call before updating, to mirror the existing shape. |
| `read_alerts` | `init` | Per-app catalog of valid types/triggers/conditions/actions/operators and lookup IDs. Call before any update. |
| `read_incidents` | `list` | Actual firing history with `status` (open / resolved), `type`, `count`, and timestamps. Use to judge whether firings were actionable. |
| `write_alerts` | `update` | Apply a remediation to a rule. State-changing — confirm first. |
| `write_alerts` | `delete` | Remove a fully redundant rule. State-changing — confirm first. |
| `write_incidents` | `resolve` | Clear stale open firings as a side cleanup. |

You MUST base every "this alert is noisy" claim on a value the MCP returned. Do not infer noise from a rule's title or your priors.

## What "noisy" means

Luciq tracks how often each rule's conditions are met on a rolling 8-day window and exposes it as `conditions_met_count` on the `read_alerts` list response. That counter is the product's own noise signal: the dashboard treats a rule that crosses **4** matches in the window as a candidate for noise. Use `> 4` as the entry filter for "look closer", not as the verdict.

A rule is genuinely noisy when both hold:
1. It fires frequently (`conditions_met_count` is high relative to the others, and well above 4), AND
2. The firings are not individually worth a separate notification — because the threshold is trivially low, the scope is too broad (no conditions), it duplicates another rule, or it pages on a non-actionable signal.

A rule that fires often **and every firing matters** (a real incident stream) is not noise. The fix there is throttling the *notification*, not weakening the *detection*.

## Workflow

### Step 1. Pull the alert inventory

Call `read_alerts(action: "list", sort_by: "highest_triggered_count", sort_direction: "desc")`. This is the spine of the audit. Note for each rule: `ulid`, `type`, `trigger`, `conditions`, `actions` (and any `frequency` throttle), `status`, and `conditions_met_count`.

Drop disabled rules from consideration — a disabled rule is already silent. Say so if the user asked about one.

### Step 2. Triage by trigger count

Partition the enabled rules:

- **Quiet** (`conditions_met_count` ≤ 4): leave alone. Do not recommend changes to a rule that isn't firing much, even if it looks imperfect. Surface that they are healthy.
- **Loud** (`conditions_met_count` > 4): candidates. Continue to Step 3 for each.

If nothing is loud, report that plainly — "no noisy alerts, here's what you have" — and stop. Do not invent problems.

### Step 3. Diagnose each loud rule

For each candidate, decide *why* it is loud before deciding the fix. When the count alone is ambiguous, call `read_incidents(action: "list", filters: { ... }, sort_by: "count")` to see whether the firings were distinct real events or the same thing over and over.

Map the cause to the right remediation:

| Diagnosis | Signal in the data | Remediation |
| --- | --- | --- |
| Threshold trivially low | e.g. `occurrences_count > 1`, `crash_free_session < 99.9`, p95 just above normal | **raise_threshold** to a meaningful level |
| Scope too broad | no `conditions`, fires on every crash/request/version | **narrow_conditions** (add app_version, key_metric, endpoint, etc.) |
| Detection is right, paging is too frequent | threshold sound, firings are real, but notified on every match | **add/lengthen throttle** (set `frequency` on the action) |
| Exact duplicate of another rule | same `type` + `trigger` + `conditions` as a sibling | **merge** (keep one, delete the other) |
| Fully redundant / obsolete | superseded by a broader rule, or watches a retired metric | **disable** or **delete** |

### Step 4. Protect safety-critical alerts

Some alerts are *supposed* to fire loudly because each firing is an emergency. Never weaken detection or disable these — at most, throttle the notification. Treat as safety-critical:

- `crash_affecting_percentage_of_users`, `configurable_velocity_alert` (a crash hitting real users)
- `crash_free_session` / `crash_free_users_overall` below ~95%
- `anr_free_users_overall` / `anr_free_sessions_overall`
- `affected_users_in_time` with a large user count

If one of these is loud, the recommendation is **add_throttle** or a small **raise_threshold**, with an explicit note that you are keeping detection intact. If you find yourself about to recommend disabling one, STOP — that is removing a safety net.

### Step 5. Present the plan before touching anything

Output a per-rule table the user can approve: rule title, why it's noisy (cite `conditions_met_count` and the diagnosis), and the proposed remediation. Group safety-critical rules separately so the user sees they're handled conservatively. Do not write yet.

### Step 6. Apply approved remediations

For each rule the user approves:

1. Call `read_alerts(action: "init", slug, mode)` to get valid fields/IDs, and `read_alerts(action: "details", ulid)` to mirror the rule's current payload.
2. Build the updated payload — change only the field the remediation targets (threshold value, an added condition, a `frequency` on the action, or `status`). Keep everything else identical.
3. Call `write_alerts(action: "update", ...)` (or `delete` for a confirmed merge/redundant rule).
4. Confirm each change back to the user with the new effective behavior.

Respect the payload rules the `write_alerts` tool documents — most importantly: Overall-app/Release-rollout apdex thresholds are 0–1 decimals (send `0.9`, not `90`); all other percentages are literal; operators are stringified integers; and you may only use types/triggers/conditions that `init` exposes for this app.

### Step 7. Optional — clear stale firings

If the audit surfaced open triggered alerts that are clearly stale (resolved in reality but still `open`), offer to clear them via `write_incidents(action: "resolve", ulid)`. This is cleanup, not noise reduction — keep it separate and only on request.

## Authoring changes correctly (read before any write_alerts call)

Every remediation you apply goes through `write_alerts`. Produce a valid payload:

1. Call `read_alerts(action: "init", slug, mode)` first and `read_alerts(action: "details", ulid)` to mirror the rule's existing shape. Build only from what init exposes for this app; if a field isn't in init, don't send it. Never invent a tracking-tool / developer / team id — take it from init's lookup tables.
2. Wire encoding the tool expects:
   - Operators are **stringified integers**: `"1"`=equals, `"4"`=less than, `"5"`=greater than, `"8"`=is one of, `"3"`=contains. Send `>` as `"5"`, `<` as `"4"`.
   - `trigger_options.time` is the **integer key** from init's time options for that trigger — not hours/minutes. Read the key from init; never send `"1h"` or `24`.
   - Apdex (Overall app) thresholds are **0–1 decimals** (`0.8` for 80%, never `80`). Other percentages (crash-free, failure_rate, velocity) are literal numbers.
   - p95/p50 thresholds are in **seconds** (`0.5` = half a second), not milliseconds.
   - Crashes use `app_version_v2`, not the deprecated `app_version`.
3. Value ranges: apdex 0–1; crash-free / ANR / velocity / percentage 0–100. Never raise a threshold past these bounds.
4. Change only the field the remediation targets; keep everything else identical to the existing rule.

## Style

- Quantify every claim: "fired 47 times in 8 days" beats "fires a lot".
- Prefer the least destructive fix that works: raise/narrow/throttle before disable; disable before delete.
- One change per rule per pass. Don't stack five edits and lose the thread.
- Never present a write as done before it returns success.

## Red Flags — STOP and surface to the user

- "This alert fires constantly, so disable it" — check first whether each firing is a real incident. If so, throttle, don't silence.
- "It's a crash-affecting-users alert firing 40 times, let's turn it off." Never. That's the alert doing its job. Throttle the notification.
- "I'll guess the threshold should be ~50." Base it on the metric's normal range from the data, or ask. Don't pull numbers from nowhere.
- "I'll update the rule without calling init." Don't — you'll send IDs/triggers the app may not support and the write will fail or silently corrupt the rule.
- "The user said clean up, so I'll batch-disable everything loud." Get per-rule approval. Bulk-disabling is how coverage quietly disappears.
- "conditions_met_count is 3 but the title sounds spammy, I'll flag it." 3 is below the signal. Leave it.

Prerequisites

The Luciq MCP server must be configured and authenticated. If the alert tools aren't available, the skill stops and directs the user to set up the MCP server, or run luciq-setup.

The skill uses these tools:

Tool	Action	Purpose
read_alerts	list	All alert rules with their conditions_met_count (rolling trigger count) and current status. Sorted by trigger count to surface the worst first.
read_alerts	details	Full payload of one rule, read before updating to mirror its existing shape.
read_alerts	init	Per-app catalog of valid types, triggers, conditions, actions, operators, and lookup IDs — read before any update.
read_incidents	list	Actual firing history, used to judge whether firings were distinct real events or repeats of the same thing.
write_alerts	update	Applies a remediation to a rule. State-changing — the agent confirms first.
write_alerts	delete	Removes a fully redundant rule. State-changing — the agent confirms first.
write_incidents	resolve	Clears stale open firings as an optional side cleanup.

Every "this alert is noisy" claim is based on a value the MCP actually returned — never inferred from a rule's title.

If the alert tools aren't available, the skill stops and points the user to the Luciq MCP server setup, or to run luciq-setup.

What "noisy" means

Luciq tracks how often each rule's conditions are met over a rolling 8-day window and exposes it as conditions_met_count. The dashboard treats a rule crossing 4 matches in that window as a candidate for noise — the skill uses that same threshold as an entry filter for "look closer," not as the final verdict.

A rule only counts as genuinely noisy when both are true: it fires frequently, well above the entry threshold, and the individual firings aren't worth a separate notification — because the threshold is trivially low, the scope is too broad, it duplicates another rule, or it pages on a non-actionable signal. A rule that fires often but where every firing is a real incident isn't noise; the fix there is throttling the notification, not weakening detection.

How the agent reduces alert noise

Step 1. Pull the alert inventory

The agent calls read_alerts with action: list, sorted by trigger count descending, and records each rule's id, type, trigger, conditions, actions, status, and conditions_met_count. Disabled rules are dropped from consideration, since a disabled rule is already silent.

Step 2. Triage by trigger count

The agent partitions the enabled rules into quiet (at or below the 4-match threshold, left alone) and loud (candidates for further diagnosis). If nothing is loud, it reports that plainly and stops rather than inventing problems.

Step 3. Diagnose each loud rule

For each candidate, the agent determines why it's loud before deciding on a fix, pulling firing history via read_incidents when the count alone doesn't make the cause obvious. It maps the cause to a remediation:

Diagnosis	Signal in the data	Remediation
Threshold trivially low	e.g. an occurrence count over 1, or a p95 just above normal	Raise the threshold to a meaningful level
Scope too broad	no conditions set, fires on every crash/request/version	Narrow the conditions (app version, key metric, endpoint)
Detection is right, paging is too frequent	threshold is sound and firings are real, but every match notifies	Add or lengthen a throttle on the action
Exact duplicate of another rule	same type, trigger, and conditions as a sibling rule	Merge — keep one, delete the other
Fully redundant or obsolete	superseded by a broader rule, or watches a retired metric	Disable or delete

Step 4. Protect safety-critical alerts

Some alerts are supposed to fire loudly because every firing is an emergency — a crash hitting a real percentage of users, or crash-free/ANR rate dropping below a safety floor. The agent never weakens detection or disables these; at most it adds a throttle or a small threshold raise, with an explicit note that detection stays intact.

Step 5. Present the plan before touching anything

The agent presents a per-rule table for approval — the rule, why it's noisy (citing the actual trigger count and diagnosis), and the proposed remediation — with safety-critical rules called out separately so the user can see they're being handled conservatively. Nothing is written yet.

Step 6. Apply approved remediations

For each approved rule, the agent reads the app's init catalog and the rule's current details, changes only the field the remediation targets, and calls write_alerts with update (or delete for a confirmed merge or redundant rule). It confirms each change back to the user with the new effective behavior.

Step 7. Optional — clear stale firings

If the audit surfaces open triggered alerts that are clearly stale, the agent offers to clear them via write_incidents with resolve, kept as a separate, on-request cleanup rather than part of the noise-reduction recommendation itself.