done-ops
Skill2 starsChanged 6 months agoMITView on GitHub
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.
In this repository8 other files it gives its agents.
- ai-changeSkill
- change-requestSkill
- commsSkill
- incidentSkill
- itilSkill
- postmortemSkill
- problemSkill
- statuspageSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
If the service has not been verified as operational in this session, the task cannot be claimed as complete.
- Distinctive: line 31
Before claiming any operational task is complete:
- Distinctive: line 85
After resolution, observe before final closure:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Operations Verification Gate
Core principle: Evidence before claims, always.
The Iron Law
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCEIf 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 |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.