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 flonat/flonat-research --skill postmortemgit clone --depth 1 https://github.com/flonat/flonat-researchWrote 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/flonat/flonat-research/postmortem)<a href="https://agentmods.dev/skills/flonat/flonat-research/postmortem"><img src="https://agentmods.dev/badge/skills/flonat/flonat-research/postmortem.svg" alt="Measured on agentmods" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 183 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
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.00040 | $0.01557 |
| Opus 5 | $0.00020 | $0.00779 |
| Sonnet 5 | $0.00008 | $0.00311 |
| Haiku 4.5 | $0.00004 | $0.00156 |
Grade A, and why
postmortem 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 4d 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 — 202 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Lessons Learned: Structured Retrospective
Analyse incidents using a structured framework, identify root causes, and encode preventive measures directly into skills, guards, or documentation. The goal is systematic improvement, not blame.
When to Use
- After incidents, mistakes, rollbacks, or near-misses
- When the user says "what went wrong", "lessons learned", "post-mortem", "retrospective", or "how do we prevent this"
- After a stuck session where significant time was lost
- After a wrong-approach event (plan existed but execution diverged)
Process
Phase 1: Incident Definition
Capture the facts first, analysis later.
## Incident Summary
**What happened:** [Factual description]
**When:** [Date/time]
**Impact:** [What was affected, scope]
**Resolution:** [How it was fixed/rolled back]
**Time to resolution:** [How long to fix]
Phase 2: Timeline Reconstruction
Build a chronological sequence of events:
| Time | Action | Actor | Outcome |
|---|---|---|---|
| HH:MM | [What was done] | [Claude/User] | [Result] |
Key questions:
- What was the trigger?
- Where did the sequence diverge from expected?
- What was the point of no return?
Phase 3: Root Cause Analysis (5 Whys)
1. Why did [incident] happen?
→ Because [immediate cause]
2. Why did [immediate cause] happen?
→ Because [deeper cause]
3. Why did [deeper cause] happen?
→ Because [systemic issue]
4. Why did [systemic issue] exist?
→ Because [process gap]
5. Why did [process gap] exist?
→ Because [root cause]
Stop when you reach a cause that can be addressed by a concrete change to the system (skill, rule, hook, doc).
Phase 4: Contributing Factors
Identify all factors, not just the root cause:
| Category | Factor | Contribution |
|---|---|---|
| Process | Missing checkpoint, unclear workflow | [How it contributed] |
| Communication | Ambiguous instructions, assumed consent | [How it contributed] |
| Technical | Missing guard, no validation | [How it contributed] |
| Context | Session continuation, prior assumptions | [How it contributed] |
| Human | Fatigue, time pressure, overconfidence | [How it contributed] |
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.
- 4d ago First seen · 202 lines · 40 tokens per session scan A b5d596654160
postmortem is a skill published in the GitHub repository flonat/flonat-research (132 stars, last pushed 13d ago), licensed MIT. It adds 40 tokens to every session and 1,557 once invoked, about $0.0002 per session on Opus 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-09-03.
Other skills, from other repositories
check-pipeline
Check that a code and its Pipeline/ .md are still compatible — that every symbol, cell number, data file, and data-flow claim in the pipeline doc still matches the current code (drift detection). Use after editing a documented notebook/engine/script, before trusting a pipeline doc, or on request ("does the pipeline…
reality-check
Re-derive a contested or pushed-back claim in isolation from the definitions, to catch sycophantic capitulation. Use when a result is disputed or you suspect you changed an answer only because the user pushed back.
apply-pipeline
The write-side inverse of /check-pipeline and the pipeline-auditor — read a Pipeline/ doc (and/or an audit report) and EDIT the code accordingly: apply an optimization the pipeline describes, correct code the pipeline (backed by your authoritative notes) shows is wrong, or bring the code in line with the documented…
incident-postmortem
Build a blameless incident report and release follow-up tasks.
github-issues
Create, inspect, triage, label, and update GitHub issues using native GitHub CLI/API paths when configured, with evidence and approval boundaries.
linear-update
Update Linear issues with debugging findings. Add comments, change status, update labels, set priority. Use after completing investigations.