Done ops

Skill bouob/sysadmin-skills/skills/done-ops

Operations task verification gate before claiming work is complete. This skill should be used before closing incidents, finalizing change requests, sending resolution notifications, or when asking "is this resolved?", "can we close this?", "is the change complete?", or verifying SLO compliance after an incident. Evidence before claims — verify operational status first.From its SKILL.md

Install

npx -y skills add bouob/sysadmin-skills --skill done-ops

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.8 KB, as published. Nobody here has run it

Operations Verification Gate

Core principle: Evidence before claims, always.

The Iron Law

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

If the service has not been verified as operational in this session, the task cannot be claimed as complete.

Related Skills

/incident — loads this skill before closing an incident
/change-request — loads this skill before finalizing a change
itil — provides the process framework for closure criteria

This skill is loaded as a gate by /incident and /change-request. It does not need to be invoked directly when using those workflows.

The Gate

Before claiming any operational task is complete:

IDENTIFY — what evidence proves resolution/completion?
VERIFY — confirm the evidence is current (not from memory or earlier checks)
DOCUMENT — record the verification in the output document
CONFIRM — does the evidence satisfy the closure criteria?
- NO → state actual status with evidence, identify remaining actions
- YES → state claim WITH evidence

Verification Requirements by Task Type

Incident Closure

Check	Required Evidence
Service restored	Service is accessible and functioning (confirmed by monitoring or manual test)
User confirmation	Affected user/team confirms the issue is resolved
Monitoring stable	No recurring alerts for the affected component within the observation period
Documentation complete	Timeline, actions taken, resolution, and follow-up items recorded
Problem record	Created if root cause is unknown or incident is recurring
Communication sent	Resolution notification sent to all parties who received the initial alert
SLO compliance checked	(Optional) Error budget impact estimated; note if budget is now < 10%

Change Request Closure

Check	Required Evidence
Implementation complete	All steps in the implementation plan executed
Validation passed	Post-implementation checks confirm expected behavior
No regression	Related services unaffected (checked, not assumed)
Rollback not triggered	No rollback criteria were met during implementation
PIR scheduled	Post-Implementation Review scheduled within required timeframe
Users notified	Affected users informed of completion (if applicable)

Status Page Update

Check	Required Evidence
All components operational	Each affected component verified and set to Operational
Resolved update posted	Final status update published with summary
Duration recorded	Accurate start and end times documented
Subscribers notified	Status page notification delivered

Red Flags — Stop and Verify

Using "should be fine", "probably resolved", "seems stable"
Closing an incident without contacting the reporter
Marking a change as complete without running the validation plan
Resolving a status page incident while components are still degraded
Relying on "it was working earlier" instead of checking now
Closing without documenting — if it is not written down, it did not happen

Observation Periods

After resolution, observe before final closure:

Priority	Observation Period
P1	1-2 hours of stability
P2	2-4 hours of stability
P3	Confirm at next check-in
P4	Immediate closure acceptable