Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add anatolykoptev/dozor --skill post-mortemgit clone --depth 1 https://github.com/anatolykoptev/dozorWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/anatolykoptev/dozor/post-mortem)<a href="https://agentmods.dev/skills/anatolykoptev/dozor/post-mortem"><img src="https://agentmods.dev/badge/skills/anatolykoptev/dozor/post-mortem/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/anatolykoptev/dozor/post-mortem"><img src="https://agentmods.dev/badge/skills/anatolykoptev/dozor/post-mortem.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00053 | $0.00820 |
| Opus 5.5 | $0.00021 | $0.00328 |
| Sonnet 5.5 | $0.00011 | $0.00164 |
| Haiku 4.5 | $0.00005 | $0.00082 |
Grade A, and why
post-mortem scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 119 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Post-Mortem
After every significant incident, build a structured record for future reference.
When to Run
- After any P0 incident is resolved
- After any P1 incident that required 3+ tool calls to resolve
- After any cascading failure (2+ services affected)
- When user asks "what happened?" about a past event
- After a failed deployment that needed rollback or manual intervention
Data Collection
Gather these before writing the post-mortem:
1. Timeline
server_inspect(mode: "logs", service: NAME, lines: 200)
Look for: first error timestamp, escalation points, recovery timestamp.
2. Current state
server_triage()
server_inspect(mode: "health")
Confirm the incident is actually resolved.
3. Impact scope
server_inspect(mode: "health")
Which services were affected? Which stayed healthy?
4. Root cause evidence
server_inspect(mode: "analyze", service: NAME)
server_inspect(mode: "overview")
Error patterns, resource state at time of incident.
Post-Mortem Template
Write to memory using update_memory:
Title: [P0/P1] [Service] [Issue] — [YYYY-MM-DD]
## Timeline
- [HH:MM] First error detected: [what]
- [HH:MM] Triage triggered / alert received
- [HH:MM] Diagnosis: [finding]
- [HH:MM] Fix applied: [action]
- [HH:MM] Verified: [confirmation]
- Duration: [X min from detection to resolution]
## Impact
- Services affected: [list]
- Services unaffected: [list]
- User-facing impact: [yes/no, what]
## Root Cause
[One paragraph: what actually went wrong and why]
## Resolution
[What was done to fix it]
## What Worked
- [Things that helped: quick detection, right tool, etc.]
## What Didn't Work
- [Things that slowed down: wrong diagnosis, unnecessary restarts, etc.]
## Prevention
- [ ] [Concrete action to prevent recurrence]
- [ ] [Monitoring improvement]
- [ ] [Configuration change]
Root Cause Categories
| Category | Example | Prevention |
|---|---|---|
| Resource exhaustion | Disk full, OOM | Capacity monitoring, cleanup cron |
| Configuration | Wrong env var, bad port | Config validation in deploy skill |
| Dependency | Upstream service down | Health checks, circuit breakers |
| Code bug | Crash loop, memory leak | Escalate to devops for code fix |
| Infrastructure | Host reboot, network | Redundancy, monitoring |
| Human error | Wrong deploy, deleted data | Approval gates, backups |
| Development collision | Rebuild during watch | Dev mode exclusions |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 119 lines · 53 tokens per session scan A 4d66d38525c6
post-mortem is a skill published in the GitHub repository anatolykoptev/dozor (6 stars, last pushed yesterday), licensed MIT. It adds 53 tokens to every session and 820 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
fastgpt-docker-deploy
FastGPT Docker Compose self-hosting deployment workflow. Use when a user asks an AI agent to deploy FastGPT with Docker by referencing /deploy/SKILL.md, including creating an empty fastgpt directory, running the install script in non-interactive mode, starting Docker Compose, monitoring service health, troubleshooting…
latex-rescue
Diagnose and repair LaTeX build failures in local projects or supplied logs. Make minimal source fixes, preserve scientific content and reference keys, and report actual build evidence and unresolved errors.
代码调试
A debugging workflow that reproduces a problem with a failing test, collects evidence, finds the underlying cause, applies a fix, and runs regression checks. Regression checks verify that the fix does not break behavior that already worked.
files-search-and-read
Find and read the documents an agent has been granted access to, using pinchyls and pinchyread. Use whenever a question is about the content of a file in the agent's document folders. Covers discovering files before reading them, which formats can actually be extracted, how to point a reader back at a passage, and…
document-comparison
Evaluate several documents against a shared set of criteria — proposals against requirements, contracts against each other, policies against a standard, candidates against a role. Use whenever the answer is a comparison, a ranking, a scoring, or a gap analysis. Covers fixing the criteria before reading, keeping the…
odoo-attach
Attach files (receipts, delivery notes, contracts, supporting documents) to Odoo records with odooattachfile using the pinchyref token. Use whenever the user sends a document that belongs on an Odoo record. Explains the ref-flow contract so you pass a real pinchyref instead of fabricating a " , " string.