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 agentmods add skills/pitimon/8-habit-ai-dev/post-mortemnpx skills add pitimon/8-habit-ai-dev --skill post-mortemgit clone --depth 1 https://github.com/pitimon/8-habit-ai-devWrote 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/pitimon/8-habit-ai-dev/post-mortem)<a href="https://agentmods.dev/skills/pitimon/8-habit-ai-dev/post-mortem"><img src="https://agentmods.dev/badge/skills/pitimon/8-habit-ai-dev/post-mortem.svg" alt="Measured on agentmods" 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 | $0.00100 | $0.03086 |
| Opus 5 | $0.00050 | $0.01543 |
| Sonnet 5 | $0.00020 | $0.00617 |
| Haiku 4.5 | $0.00010 | $0.00309 |
Grade B, and why
post-mortem scanned grade B with 1 finding 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.
Reads agent configuration directoriesmediumAgent snooping
.claude/, .codex/, .gemini/ hold keys, settings and other credentials a mod has no legitimate need for.
> **Root cause.** `hooks/session-start.sh:42` wrapped the `cat ~/.claude/habit-profile.md` call in `|| true`. When the file was absent (typical first-run state), `cat` exited 1, `|| true` swallowed it, and the script con How it starts
The opening of the file, as written. The whole thing — 187 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Post-mortem (ชันสูตรบั๊กหลังแก้)
Habit: H4 — Think Win-Win + H7 — Sharpen the Saw | Anti-pattern: Closing a fix with "Fixed in PR #N" and walking away
Canonical engineering record of a bug fix. Written after debugging lands a validated fix, for other engineers (and future-you, who will have forgotten everything in 6 months). Code identifiers are first-class here — this is the artifact that lets the next person grep back to the cause in seconds, not hours.
When to Use
- After a debug session has clearly landed a fix and the fix is validated.
/post-morteminvoked explicitly.- User says "write the post-mortem / postmortem / RCA / root-cause analysis", "document this fix", "close out this bug with a writeup".
- Pair with
/reflectfor a complete loop:/reflectcaptures the lightweight retrospective signal;/post-mortemcaptures the engineering record. They serve different audiences.
When to Skip
- Bug not fixed yet, or fix not validated. A post-mortem of a hypothesis is misleading. Refuse and tell the user what's missing.
- Customer-visible outage / incident. Those need a separate incident report (timeline, blast radius, comms). This skill is bug-fix scope. Flag and confirm before producing one.
- Trivial fix (typo, obvious one-liner). The PR description is the record. Don't manufacture ceremony.
- Auto-generated changes (lint --fix, dependency bumps with no behavior change). Nothing to walk through.
Required Inputs — Refuse to Draft Without These
Before writing a single line, confirm all four. If any are missing, list what's missing and stop:
- Reliable repro — a deterministic or high-rate-flake repro the next person can run. "Happens sometimes" is not enough.
- Root cause is known — the bug mechanism is identified, not a hypothesis.
- Fix is identified — PR / commit / branch pointer exists.
- Fix is validated — the original repro now passes; the failing test / customer workload / scan now succeeds.
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 · 187 lines · 100 tokens per session scan B 7acd58cc9efa
post-mortem is a skill published in the GitHub repository pitimon/8-habit-ai-dev (3 stars, last pushed 1mo ago), licensed MIT. It adds 100 tokens to every session and 3,086 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it B with 1 finding (reads agent configuration directories). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
fix
Use to drive a bug fix from first report through close, with a "why didn't we catch it?" loop at the end. Triggers — "/engineer.fix", "a bug came in", "this is broken", "a user reported X", "there's a defect", "we have a regression", "this needs a fix", "another report", "more issues", "still failing", "validation…
next
Use at the start of a work session, or any time the question is "what should I pick up now" across the whole project. Triggers — "/engineer.next", "what's next", "what should I work on", "what should I do next", "where do I pick up".
crap-analyzer
Use to produce a risk-based refactor + test plan for recently-changed code on a diff/branch/PR by computing CRAP (complexity × untested) on changed methods. Multi-language — TypeScript, JavaScript, Python, Java, Kotlin, Go, Ruby, C#, Rust, PHP — auto-discovers how the repo generates coverage. Triggers …
post-merge
Use immediately after a PR is merged to clean up the local feature branch and resync main. Triggers — "/engineer.post-merge", "did we merge", "did we push", "PR merged", "post-merge cleanup", or right after a gh pr merge succeeds in the same session.
session-summary
Use at the end of a work session on a DAE feature, so the next session picks up cleanly. Triggers — "/engineer.session-summary", "wrap up the session", "write the session log", "I'm stopping for the day".
onboard
Use to bring a project into the DAE methodology, or to check an onboarded project for gaps. Triggers — "/engineer.onboard", "onboard this project", "set up DAE here", "adopt the methodology", or when a DAE skill fails because no manifest exists.