tdg-personal/unified-notifications-ops
Operate notifications as one ECC-native workflow across GitHub, Linear, desktop alerts, hooks, and connected communication surfaces. Use when the real problem is alert routing, deduplication, escalation, or inbox collapse.
74
74%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
Discovery
75%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description has a solid structure with an explicit 'Use when' clause and a distinctive niche in cross-platform notification management. Its main weaknesses are the use of jargon ('ECC-native workflow') and somewhat abstract action descriptions that could be more concrete. The trigger terms cover the domain reasonably but miss some natural user language variations.
Suggestions
Replace 'ECC-native workflow' with plain language or explain what ECC means, as users won't naturally use this term when seeking help with notifications.
Add more concrete actions like 'create routing rules', 'merge duplicate alerts', 'configure escalation chains', 'triage notification inbox' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (notifications/alerts) and some actions (routing, deduplication, escalation, inbox collapse), but these are somewhat abstract concepts rather than concrete step-by-step actions. It doesn't specify what concrete operations are performed (e.g., 'create notification rules', 'merge duplicate alerts', 'configure escalation policies'). | 2 / 3 |
Completeness | Clearly answers both 'what' (operate notifications across GitHub, Linear, desktop alerts, hooks, and communication surfaces) and 'when' (explicit 'Use when' clause covering alert routing, deduplication, escalation, or inbox collapse). | 3 / 3 |
Trigger Term Quality | Includes some relevant keywords like 'notifications', 'GitHub', 'Linear', 'alert routing', 'deduplication', 'escalation', and 'inbox collapse'. However, 'ECC-native workflow' is jargon that users wouldn't naturally say, and common terms like 'notification noise', 'alert fatigue', 'mute', 'snooze', or 'notification settings' are missing. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of notification management across specific platforms (GitHub, Linear) with specific concerns (deduplication, escalation, inbox collapse) creates a clear niche that is unlikely to conflict with other skills. The focus on cross-platform notification orchestration is quite distinctive. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-organized process/policy skill with a clear workflow and good severity classification model. Its main weakness is the lack of concrete, executable implementation artifacts—no webhook configs, no CLI commands, no code snippets for actual notification routing. The content is moderately concise but has some redundancy between sections.
Suggestions
Add concrete, executable examples: a sample webhook configuration, a script snippet for event classification/routing, or a specific CLI command for setting up notification hooks in the ECC ecosystem.
Reduce redundancy between the opening description, 'When to Use', and 'Good Use Cases' sections—these overlap significantly and could be consolidated.
Consider splitting the severity model table and output format template into a referenced file (e.g., NOTIFICATION-REFERENCE.md) to keep the main skill leaner and improve progressive disclosure.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably well-structured but includes some unnecessary verbosity—e.g., the 'When to Use' section overlaps with the opening description, and the 'Good Use Cases' section restates what's already implied. Some sections like 'Preferred Surface' list things Claude already knows about (GitHub, Linear, etc.) without adding operational value. | 2 / 3 |
Actionability | The skill provides a clear conceptual framework and structured workflow steps, but lacks concrete executable code, commands, or specific API calls. Everything is described at the process/policy level—no webhook configuration snippets, no CLI commands, no concrete automation examples. For a skill about notification ops, there are no actual implementation artifacts. | 2 / 3 |
Workflow Clarity | The 5-step workflow is clearly sequenced (inventory → decide interruption → collapse duplicates → design workflow → return action-biased design), with each step containing specific sub-questions and decision criteria. The event pipeline (capture → classify → route → collapse → attach) provides a clear mental model. The severity model table adds explicit validation criteria for classification decisions. | 3 / 3 |
Progressive Disclosure | The skill references related skills at the end (workspace-surface-audit, project-flow-ops, etc.) which is good navigation, but the main content is a long monolithic document that could benefit from splitting detailed sections (e.g., severity model, output format templates) into separate reference files. The output format template is inline rather than referenced. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents