Alerting

Alert design: SLOs, noise reduction, routing, severity. Use when tuning pages or defining on-call policy.

Security Scan

This is a high-level, instruction-only guidance skill for alerting design (SLOs, routing, noise reduction) that requests no installs, credentials, or system access and is internally consistent with its stated purpose.

Purpose & Capability

Name, description, and the SKILL.md all describe the same purpose: a staged, procedural guide for alerting work (SLOs, routing, severity, noise reduction). There are no unrelated requirements (no env vars, binaries, or installs) that would contradict the stated purpose.

Instruction Scope

The instructions are purely procedural: ask context questions, propose stages, provide checklists and verification steps. They do not instruct the agent to read files, access environment variables, call external endpoints, or exfiltrate data. Scope remains focused on advising the user.

Install Mechanism

No install spec and no code files — this is instruction-only, which is the lowest-risk installation model and appropriate for a guidance-style skill.

Credentials

The skill requires no environment variables, credentials, or config paths. That is proportionate for a conversational guidance skill and matches its stated function.

Persistence & Privilege

Flags show default behavior (always: false, user-invocable: true, model invocation allowed). The skill does not request persistent presence, nor does it appear to modify system or other-skill settings.

Assessment

This skill is a benign, high-level advisor for alerting design. It's safe in that it doesn't request credentials, install code, or access files. Before sharing, remember: the agent may ask you for context (logs, configs, or incident details) — avoid pasting sensitive credentials or private data. If you want the agent to act on live systems (apply configs, call APIs), prefer a skill that explicitly requests the needed credentials and review those requirements carefully. Otherwise, using this skill for planning, checklists, and review guidance is appropriate.

Alerting Skill

This skill provides structured guidance for Alerting work. Act as an active guide: confirm triggers, propose the stages below, and adapt if the user wants a lighter pass.

When to Offer This Workflow

Trigger conditions:

• User mentions alerting or closely related work
• They want a structured workflow rather than ad-hoc tips
• They are preparing a review, rollout, or stakeholder communication

Initial offer: Explain the four stages briefly and ask whether to follow this workflow or work freeform. If they decline, continue in their preferred style.

Workflow Stages

Stage 1: Clarify context & goals

Anchor on SLOs and user-visible symptoms. Ask what success looks like, constraints, and what must not break. Capture unknowns early.

Stage 2: Design or plan the approach

Translate goals into a concrete plan around routing, severity, and ownership. Compare alternatives and explicit trade-offs; avoid implicit assumptions.

Stage 3: Implement, validate, and harden

Execute with verification loops tied to noise reduction and tuning. Prefer small steps, measurable checks, and rollback points where risk is high.

Stage 4: Operate, communicate, and iterate

Close the loop with runbook linkage: monitoring, documentation, stakeholder updates, and lessons learned for the next cycle.

Checklist Before Completion

• Goals and constraints are explicit for Alerting Skill
• Risks and trade-offs are stated, not hand-waved
• Verification steps match the change’s impact (tests, canary, peer review)
• Operational follow-through is covered (monitoring, docs, owners)

Tips for Effective Guidance

• Be procedural: stage-by-stage, with clear exit criteria
• Ask for missing context (environment, scale, deadlines) before prescribing
• Prefer checklists and concrete examples over generic platitudes
• If the user declines the workflow, switch to freeform help without lecturing

Handling Deviations

• If the user wants to skip a stage: confirm and continue with what they need.
• If context is missing: ask targeted questions before strong recommendations.
• Prefer concrete examples, trade-offs, and verification steps over generic advice.

Quality Bar

• Each recommendation should be actionable (what to do next).
• Call out failure modes relevant to Alerting (security, scale, UX, or ops).
• Keep tone direct and respectful of the user’s time.