Triage Web Incidents Skill

CANDIDATE CANDIDATE NEW BOUNDED TASK · Operations Web Function 0.1.0. Turn a web observation into a defensible classification, severity, owner, service-level target, preservation decision, next safe action, and incident receipt. Use when a monitor alerts, a site appears down or blocked, crawler and human views differ, spam or compromise is suspected, a deploy regresses, or a website problem needs diagnosis and handoff without premature remediation.

Canonical owner: operations-web-function:triage-web-incidents · Task registration: TASK_LIBRARY_REGISTRATION_PENDING

Broader definitive hub · Exact Task Library page: TASK_LIBRARY_REGISTRATION_PENDING

Download the complete plugin · Source skill SHA-256: 4b76055db3f0784915361e465702d8ff9d0ad91181ed29a0ff563d8c5bad7ced

Candidate source: dennisyu/blitzmetrics-skills · commit: PENDING_MERGE · path: skills/triage-web-incidents/SKILL.md

Triage determines what is known, what remains unknown, how urgent the finding is, who owns the next action, and whether changing the system would destroy evidence.

Triage flow

Verify the target identity, environment, lifecycle, source receipt, and observation time.
Re-run known controls and reproduce the minimum signal from a second permitted vantage.
Separate observer failure from target failure. BLOCKED and UNREACHABLE require investigation; they are not infection verdicts.
Classify the failing layer: DNS, TLS, network, edge/WAF, web server, application/runtime, dependency, content, analytics, access, or security/persistence.
Check for crawler identity split and impossible-path interception before diagnosing an ordinary application outage.
Assign target health, classification, evidence tier, severity under the organization’s policy, owner, due time, and next check.
If compromise or volatile evidence is plausible, invoke $preserve-web-incident before any repair.
Produce a bounded next action: preserve, contain, request approval, repair, re-probe, hand off, or monitor.
Create or update the incident record and link the source receipt. Draft communication separately; do not post or send without the required approval.

SUSPECT versus INFECTED

Use SUSPECT for one hostile-looking signal, two symptoms derived from the same response, or a finding not yet reproduced with passing controls. Use INFECTED only when controls pass and either:

a second permitted vantage independently reproduces hostile behavior; or
two structurally independent signal families agree, such as crawler-only hostile content plus hostile interception of a separately requested impossible path.

A casino title and casino words in the same Googlebot response are one signal family, not two. Classification can be upgraded or downgraded as evidence changes; preserve the earlier receipt.

Stability and communication

Every incident declares whether a stability window is required, its duration, required automatic checks, and completed checks. The organization sets these values by incident class; do not invent them at runtime. A recurrence-prone compromise cannot move to RESOLVED before the declared window passes.

Communications are separate approved jobs. A resolution claim requires a linked verification receipt; otherwise state what is confirmed, what remains unknown, the owner, and the next update time.

Required distinctions

Root cause is why the failure occurred; root correction is what prevents recurrence.
Containment stops damage; repair restores function; eradication removes persistence; recovery proves stability.
A homepage 200 does not close a security incident.
A WAF block against the probe does not prove the site is healthy or down.
A status-code split alone may be an edge challenge; inspect titles, bodies, content types, and controls.
A novel unexplained signal stays SUSPECT or UNKNOWN; do not inflate certainty.

Handoff contract

Every open incident has: stable ID; target; exact evidence; observed and reproduced times; current lifecycle; owner and backup; due time; permission required; preservation status; next action; next automatic check; communication state; stability window; prior-attempt state; and closure criteria. From the plugin root, use schemas/incident.schema.json.

Do not accept “working on it,” “agent running,” or “will update” as a handoff. Use $verify-web-outcome before resolution and $document-web-lessons after it.

This is a generated candidate implementation page, not automatically a definitive article or accepted Task Library task. It delegates to the named canonical owner until reviewed registration and merge receipts exist.