---
title: "skill by agenticluke · skilld"
canonical_url: "https://skilld.dev/gh/agenticluke/alert-router-plus"
meta:
  description: "Run notifications as one ECC-native flow across GitHub, Linear, desktop alerts, hooks, and connected message tools. Use when the real problem is alert routing,… From agenticluke/alert-router-plus."
  "og:description": "Run notifications as one ECC-native flow across GitHub, Linear, desktop alerts, hooks, and connected message tools. Use when the real problem is alert routing,… From agenticluke/alert-router-plus."
  "og:title": "skill by agenticluke"
  "twitter:description": "Run notifications as one ECC-native flow across GitHub, Linear, desktop alerts, hooks, and connected message tools. Use when the real problem is alert routing,… From agenticluke/alert-router-plus."
  "twitter:title": "skill by agenticluke"
---

`

[All skills](https://skilld.dev/skills)

[![agenticluke avatar](https://skilld.dev/_img/avatar?url=https%3A%2F%2Fgithub.com%2Fagenticluke.png%3Fsize%3D96)](https://skilld.dev/gh/agenticluke)

# **/skill**

[@e0ca508](https://github.com/agenticluke/alert-router-plus/commit/e0ca508e51d2e0f7c70bd7e4f8e049f2b819817b "Your agent reads SKILL.md at commit e0ca508")

by [agenticluke](https://skilld.dev/gh/agenticluke)· [agenticluke](https://skilld.dev/gh/agenticluke)/ [alert-router-plus](https://skilld.dev/gh/agenticluke/alert-router-plus)

Run notifications as one ECC-native flow across GitHub, Linear, desktop alerts, hooks, and connected message tools. Use when the real problem is alert routing, duplicate alerts, missed handoffs, escalation, or inbox overload.

- 1 file
- 9.3 KB
- Updated last week
- [GitHub](https://github.com/agenticluke/alert-router-plus/blob/e0ca508e51d2e0f7c70bd7e4f8e049f2b819817b/skill/SKILL.md "View SKILL.md on GitHub")

## SKILL.md

9.3 KB

**≈58** tokens always: the name and description. **≈2.3k** when used: this file.

## Unified Notification Ops

Use this skill when alerts are spread across many tools.

The goal is not to send more alerts. The goal is to send fewer, better alerts. Each alert must have:

- A clear level
- A clear owner
- A clear route
- A clear next step

### When to Use

Use this skill when:

- The user wants one alert flow for GitHub, Linear, local hooks, desktop alerts, chat, or email.
- CI failures, review asks, issue changes, or system events are spread across many tools.
- The current setup makes noise but does not lead to action.
- The same event sends more than one alert.
- Important alerts get lost in a busy inbox.
- Hooks or linked tools exist, but there is no clear alert plan.
- An alert has no owner or next step.

Do not use this skill when the user only needs one simple alert from one source.

### Start With Tools That Already Exist

Check these first:

- GitHub issues, pull requests, reviews, comments, and CI
- Linear issues and project state changes
- Local hooks and session events
- Desktop alerts
- Linked chat or email tools that are already in use

Do not add a new alert service unless the current tools cannot meet the need.

### Hard Rules

- Never show tokens, keys, webhook secrets, private links, or hidden IDs.
- Do not make outside calls unless the user asks for them.
- Do not turn on alerts or change live routes without clear approval.
- Keep these parts separate:
  - Event source
  - Alert level
  - Alert route
  - Owner
  - Next step
- If the cost of an alert is not clear, use a summary first.
- Do not send every event to every channel.
- If the real fix is better issue work, hooks, or project flow, say so.
- Give each event one main route and one backup route at most.
- Make sure a backup route does not send the same alert twice.

### Event Flow

Handle each event in this order:

1. **Capture:** Get the event.
2. **Classify:** Set its level and owner.
3. **Filter:** Drop test events and known noise.
4. **Merge:** Join copies of the same event.
5. **Route:** Send it to the right place.
6. **Act:** Add one clear next step.
7. **Close:** Mark it done, mute it, or raise its level.

The goal is fewer alerts with clear action.

### Default Alert Levels

| Level | Examples | Default action |
| --- | --- | --- |
| Critical | CI is broken on the main branch, a security issue, a blocked release, a failed deploy | Alert now |
| High | A review ask, a failed pull request, a blocked handoff | Alert the same day |
| Medium | An issue state change, an important comment, a backlog change | Add to a summary or queue |
| Low | Repeat success, normal status noise, extra life-cycle tags | Hide, merge, or log only |

If the team has no alert levels, define them before adding rules.

### Workflow

#### 1. List the Current Alert Paths

For each source, record:

- Event name
- Current channel
- Current owner
- Hook or script that sends it
- Other paths that send the same event
- Cases where a key event is missed
- Cases where an alert has no next step

Reuse what ECC already has.

#### 2. Set the Alert Level

For each event type, answer:

- Who must know?
- How fast must they know?
- What harm happens if no one acts?
- Should it alert now, go into a batch, or only be logged?
- What action will close the alert?

Use these defaults:

- Alert now for release, CI, security, deploy, and blocked-owner events.
- Use a summary for useful updates that can wait.
- Log repeat success and low-value status events.

#### 3. Set the Owner

Each alert needs one owner.

Use these rules:

- Use the code owner for a failed check when one is known.
- Use the issue owner for a Linear issue event.
- Use the on-call owner for live system faults.
- If no owner is known, route to one triage queue.
- Do not alert a whole team when one role can own the event.

If ownership is unclear, mark it as a gap. Do not guess a person.

#### 4. Merge Copies Before Adding Channels

Check for:

- One pull request event shown in GitHub, Linear, chat, and local logs
- Two hooks that report the same failure
- Many comments that should be one summary
- Many state changes that do not change the next action
- Retry events that create a new alert each time
- Reopened alerts that have no link to the first alert

Prefer:

- One main summary
- One owner
- One main channel
- One backup path

Use a stable event key when possible. A good key may include the source, repo or project, item number, event type, and failure run.

#### 5. Handle Edge Cases

Plan for these cases:

- **Flapping alerts:** Wait for a short set time or require repeat failure before alerting.
- **Retries:** Update the first alert instead of making a new one.
- **Recovery:** Close the open alert and note that the service is healthy.
- **Owner away:** Send to the backup owner or triage queue.
- **Tool outage:** Use the backup route only when the main route fails.
- **Rate limits:** Queue events and send one summary when the tool is back.
- **Late events:** Keep the event time. Do not make an old event look new.
- **Out-of-order events:** Use the newest known state.
- **Test data:** Mark and drop test events before they reach users.
- **Private data:** Remove secrets and private text from alert bodies.
- **No action:** Do not send an alert if no useful action exists.
- **Many linked failures:** Send one main alert with a count and links.
- **Time zones:** Use the owner's work hours for high alerts. Critical alerts may break quiet hours.

#### 6. Design the ECC-Native Flow

For each real alert need, define:

- **Source:** Where the event starts
- **Rule:** What must be true before it is sent
- **Level:** Critical, high, medium, or low
- **Format:** Alert now, summary, queue, dashboard, or log
- **Channel:** Where it goes
- **Owner:** Who acts
- **Action:** What the owner must do
- **Close rule:** What ends the alert
- **Backup:** What happens if the main route fails

Use ECC parts that already exist:

- An operator skill for triage
- A hook for a clear event rule
- An agent for a task that needs review and routing
- An MCP or connector only when a needed link is missing

#### 7. Check the Plan Before Use

Before turning on a live flow, test:

- One critical event
- One normal event
- One duplicate event
- One retry
- One recovery event
- One event with no owner
- One failed main route

Confirm that each test creates the right result and no extra alerts.

#### 8. Return an Action Plan

The final result must state:

- What to keep
- What to hide
- What to merge
- What route to use
- Who owns each alert
- What ECC should add next

### Output Format

```
Current paths
- Source:
- Event:
- Channel:
- Owner:
- Copies:
- Gaps:

Event model
- Critical:
- High:
- Medium:
- Low:

Route plan
- Source -> rule -> channel
- Level:
- Owner:
- Next step:
- Close rule:
- Backup:

Merge plan
- Hide:
- Merge:
- Main summary:
- Event key:

Next ECC action
- Skill, hook, agent, or MCP:
- Exact flow to build:
- Tests to run:
- Approval needed:
```

### Concrete Example

User request:

```
GitHub and Linear both send CI alerts to chat. Failed retries make more alerts.
Please make a cleaner plan.
```

Good result:

```
Current paths
- Source: GitHub Actions
- Event: Main branch CI failure
- Channel: Team chat
- Owner: Repo code owner
- Copies: Linear also sends the same failure
- Gaps: Retry and recovery events are not linked

Event model
- Critical: Main branch CI fails twice in 10 minutes
- High: Pull request CI fails after the last retry
- Medium: First pull request CI failure
- Low: Passed retry and repeat success

Route plan
- GitHub Actions -> fail twice in 10 minutes -> team chat
- Level: Critical
- Owner: Repo code owner
- Next step: Open the failed run and assign the fix
- Close rule: CI passes on the same branch
- Backup: Triage queue if chat send fails

Merge plan
- Hide: Repeat success alerts
- Merge: Retry alerts into the first failure
- Main summary: One daily list of open pull request failures
- Event key: repo + branch + workflow name

Next ECC action
- Hook: Merge CI retries and close the alert on recovery
- Exact flow to build: GitHub event -> level rule -> merge -> chat or summary
- Tests to run: Failure, retry, recovery, duplicate, and failed chat send
- Approval needed: Yes, before the live hook is turned on
```

### Choice Rules

- Pick one strong channel over many weak channels.
- Put medium and low events in summaries.
- Use a hook for a clear event rule.
- Use an operator skill when a person must review, route, or decide.
- Use `project-flow-ops` when the root issue is backlog or pull request work.
- Use `workspace-surface-audit` when the alert sources are not yet known.
- Use a desktop alert when it is enough.
- Do not build an outside bridge without a clear need.

### Good Use Cases

- "We have GitHub, Linear, and local hook alerts, but no single flow."
- "People ignore CI alerts because there are too many."
- "We need one alert plan across Claude, OpenCode, and Codex."
- "Tell us what should alert now and what should go in a summary."
- "Merge our duplicate pull request alerts into one ECC channel."

### Related Skills

- `workspace-surface-audit`
- `project-flow-ops`
- `github-ops`
- `knowledge-ops`
- `customer-billing-ops`, when the alert problem is about billing or customer work

Source: [SKILL.md on GitHub](https://github.com/agenticluke/alert-router-plus/blob/e0ca508e51d2e0f7c70bd7e4f8e049f2b819817b/skill/SKILL.md)

## Third-party checks

No third-party reports yet.

## Provenance

[Signed by skilld at e0ca508.](https://github.com/agenticluke/alert-router-plus/commit/e0ca508e51d2e0f7c70bd7e4f8e049f2b819817b "e0ca508e51d2e0f7c70bd7e4f8e049f2b819817b") This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub last week.

Activeupdated last week

## Capability

<dl>

<dt>origin</dt>
<dd>ECC</dd>

</dl>

## README badge

![README badge for agenticluke/alert-router-plus](https://skilld.dev/b/agenticluke/alert-router-plus?theme=light&label=0)

## Related skills

-
-
-
-
-
-