@windyroad/itil 3.0.0 → 3.0.1

package/.claude-plugin/plugin.json

@@ -486,5 +486,5 @@
     }
   },
   "name": "wr-itil",
-  "version": "3.0.0"
+  "version": "3.0.1"
 }

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "wr-itil",
-  "version": "3.0.0",
+  "version": "3.0.1",
   "description": "ITIL problem-management workflows for AI coding agents",
   "author": {
     "name": "Windy Road Technology",

package/README.md

@@ -17,7 +17,7 @@ Bugs recur. Incidents repeat. Without a disciplined process, you fix symptoms in
 
 **Incident management** — restore service fast with an audit trail:
 
-- **Declare incidents** when production is actively broken
+- **Declare incidents** when an existing service is interrupted or degrades from an established prior working baseline. Track missing, incomplete or initially deficient features as problems; an unknown baseline calls for problem investigation.
 - **Evidence-first discipline** — hypotheses must cite evidence before any mitigation
 - **Reversible mitigations first** — rollback, feature flag, restart, route away
 - **Automatic handoff** to problem management once service is restored

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@windyroad/itil",
-  "version": "3.0.0",
+  "version": "3.0.1",
   "description": "ITIL-aligned IT service management for Claude Code and Codex",
   "bin": {
     "windyroad-itil": "./bin/install.mjs"

package/skills/manage-incident/SKILL.md

@@ -9,7 +9,19 @@ deprecated-arguments: true
 
 Declare, triage, mitigate, and close an incident using an evidence-first, cool-headed workflow. This skill's primary goal is **restoring service**. Once service is restored, the skill hands off to `wr-itil:manage-problem` so the underlying cause is tracked.
 
-Incidents are time-bound events. Problems are persistent root causes. One problem can cause many incidents; one incident may (or may not) link to a problem.
+Incidents are observed interruptions or degradations of an existing service with an established prior working baseline to restore. Problems include missing, incomplete or deficient capabilities as well as persistent underlying causes. One problem can cause many incidents; one incident may (or may not) link to a problem.
+
+## Eligibility before declaration
+
+Classify the report before incident duplicate lookup, ID allocation, severity rating or mitigation. This classification is agent-owned from the available evidence; do not ask permission to use the applicable workflow.
+
+| Evidence | Route |
+|----------|-------|
+| Missing or incomplete feature, deficiency present from the outset, or performance that has always been slow | Use `wr-itil:manage-problem`. There is no prior service to restore; do not declare an incident or run restoration ceremony. |
+| Slow or deficient behavior with no established prior working baseline | Investigate through `wr-itil:manage-problem`, measuring the current behavior and seeking evidence of the baseline. Do not invent a regression or declare an incident from unmet expectations alone. |
+| Previously working service becomes unavailable, or previously fast service becomes slower, with an observed change from its baseline | Use incident management to restore that affected existing service. |
+
+Being deployed, customer-visible or called a failure does not turn a capability gap into an incident. Being part of an unfinished product does not exempt a real regression of an existing service from incident handling. If problem investigation establishes an actual interruption or degradation of existing service, switch to incident management and record the baseline and observed change. Keep unrelated incomplete features in problem management.
 
 ## Operations
 
@@ -80,7 +92,7 @@ Determine the operation from `$ARGUMENTS`:
 - If arguments match `<I###> close` → **delegate to `/wr-itil:close-incident <I###>`** via the Skill tool. See "Deprecated-argument forwarders" below.
 - If arguments match `<I###> link P<MMM>` → **delegate to `/wr-itil:link-incident <I###> P<MMM>`** via the Skill tool. See "Deprecated-argument forwarders" below.
 - If arguments start with `I<NNN>` or a bare number → this is an update
-- Otherwise → declare a new incident
+- Otherwise → apply **Eligibility before declaration**. Only an eligible report proceeds as a new incident; route initial deficiencies or an unknown baseline to `wr-itil:manage-problem` before any incident creation.
 
 #### Deprecated-argument forwarders (the "Rename `wr-problem` Plugin to `wr-itil`" architecture rule amended + the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem)
 

package/skills-codex/manage-incident/SKILL.md

@@ -20,7 +20,19 @@ deprecated-arguments: true
 
 Declare, triage, mitigate, and close an incident using an evidence-first, cool-headed workflow. This skill's primary goal is **restoring service**. Once service is restored, the skill hands off to `wr-itil:manage-problem` so the underlying cause is tracked.
 
-Incidents are time-bound events. Problems are persistent root causes. One problem can cause many incidents; one incident may (or may not) link to a problem.
+Incidents are observed interruptions or degradations of an existing service with an established prior working baseline to restore. Problems include missing, incomplete or deficient capabilities as well as persistent underlying causes. One problem can cause many incidents; one incident may (or may not) link to a problem.
+
+## Eligibility before declaration
+
+Classify the report before incident duplicate lookup, ID allocation, severity rating or mitigation. This classification is agent-owned from the available evidence; do not ask permission to use the applicable workflow.
+
+| Evidence | Route |
+|----------|-------|
+| Missing or incomplete feature, deficiency present from the outset, or performance that has always been slow | Use `wr-itil:manage-problem`. There is no prior service to restore; do not declare an incident or run restoration ceremony. |
+| Slow or deficient behavior with no established prior working baseline | Investigate through `wr-itil:manage-problem`, measuring the current behavior and seeking evidence of the baseline. Do not invent a regression or declare an incident from unmet expectations alone. |
+| Previously working service becomes unavailable, or previously fast service becomes slower, with an observed change from its baseline | Use incident management to restore that affected existing service. |
+
+Being deployed, customer-visible or called a failure does not turn a capability gap into an incident. Being part of an unfinished product does not exempt a real regression of an existing service from incident handling. If problem investigation establishes an actual interruption or degradation of existing service, switch to incident management and record the baseline and observed change. Keep unrelated incomplete features in problem management.
 
 ## Operations
 
@@ -91,7 +103,7 @@ Determine the operation from `$ARGUMENTS`:
 - If arguments match `<I###> close` → **delegate to `/wr-itil:close-incident <I###>`** via the installed skill invocation. See "Deprecated-argument forwarders" below.
 - If arguments match `<I###> link P<MMM>` → **delegate to `/wr-itil:link-incident <I###> P<MMM>`** via the installed skill invocation. See "Deprecated-argument forwarders" below.
 - If arguments start with `I<NNN>` or a bare number → this is an update
-- Otherwise → declare a new incident
+- Otherwise → apply **Eligibility before declaration**. Only an eligible report proceeds as a new incident; route initial deficiencies or an unknown baseline to `wr-itil:manage-problem` before any incident creation.
 
 #### Deprecated-argument forwarders (the "Rename `wr-problem` Plugin to `wr-itil`" architecture rule amended + the "Problem 071: Argument-based skill subcommands are not discoverable in Codex autocomplete" problem)