operational-statelisted

Classify operational findings before action: Watch, Fix Candidate, Active Incident, Resolved, Handoff, Known Accepted Issue, False Positive, or Self-Resolved. Use when an infra/app/alert finding is not simply "fix" or "done", especially when recovered-but-recurring signals, Running-but-unhealthy workloads, ownership handoffs, or accepted known issues need explicit evidence and closure criteria. Read-only guidance; maps state to required evidence, allowed/prohibited actions, approval gates, artifacts, escalation criteria, and next action without executing mutations. Maps to H1 (Be Proactive) + H5 (Seek First to Understand) + H8 (Find Your Voice).
pitimon/8-habit-ai-dev · ★ 3 · Code & Development · score 77

Install: claude install-skill pitimon/8-habit-ai-dev

# Operational State **Habits**: H1 (Be Proactive) + H5 (Seek First to Understand) + H8 (Find Your Voice) | **Anti-pattern**: treating every operational signal as either "fix now" or "close" ## When to Use - An alert, daily-fix item, health check, or ops finding needs classification before action. - The system is currently healthy but the signal recurs or could become noisy. - A pod/service says Running, but a mount path, dependency, endpoint, or user-visible check is unhealthy. - Ownership is unclear and the next step may be AppDev, Registry, vendor, or another team handoff. - A known issue should stay visible without counting as an active incident. - You need to distinguish report hygiene from a cluster/service mutation. Use this before `/deploy-guide` for operational mutations, before `/post-mortem` for fixed incidents, and before `/management-talk` when leadership needs state wording. ## When to Skip - The finding already has a validated root cause, approved fix, rollback plan, and current impact; go to `/deploy-guide` or `/post-mortem`. - The work is only a wording/status update with no operational ambiguity. - The user explicitly asks for an incident RCA after a validated fix; use `/post-mortem`. - The problem is a hard unknown-root-cause bug; use `/diagnose` first. ## State Decision Process 1. **Capture the signal**: symptom, source, timestamp, environment, owner candidate, and user/customer impact if any. 2. **Check current reality**: fresh status, logs/events/