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 commands/sigistry/marketplace/postmortemgit clone --depth 1 https://github.com/sigistry/marketplaceWhat 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.00011 | $0.00587 |
| Opus 5 | $0.00005 | $0.00293 |
| Sonnet 5 | $0.00002 | $0.00117 |
| Haiku 4.5 | $0.00001 | $0.00059 |
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 2d 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 — 35 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Draft a blameless postmortem from raw incident evidence, pasted timeline, logs, alerts, and chat. Use this after an incident is resolved, while memory is fresh. $ARGUMENTS holds the incident notes (or a path to a notes file); gather whatever timeline, alert, and chat material the user has.
Process
Step 1: Assemble the evidence
- Read the notes in
$ARGUMENTS(inline text or a file path). Collect timestamps, alert names, deploy/rollback events, log excerpts, and who-did-what, but for attribution use roles ("the on-call engineer"), never names for blame. - Normalize every timestamp to UTC. If a source timezone is ambiguous, note the assumption rather than guessing silently.
Step 2: Draft the document
- Launch the postmortem-writer agent to stitch the UTC timeline, identify contributing factors, and write owner-assigned action items. The agent writes the finished document to
postmortems/YYYY-MM-DD-<slug>.md. - Apply the incident-response skill for the template structure and the severity model (
severity-levels.md).
Step 3: Structure (exact headings)
The postmortem must contain, in order:
- Summary: 2-3 sentences: what broke, blast radius, how long.
- Impact: users affected, duration, severity (SEV1-SEV4), SLO/error-budget burn if known.
- Timeline (UTC): detection → mitigation → resolution, one row per event with a source citation.
- Root Cause: contributing factors as a system-level analysis; multiple factors, never a single scapegoat.
- What went well / What went poorly: honest, specific.
- Action items: table of
Owner | Due date | Item | Type (preventive / detective). - Lessons learned: durable takeaways.
Important Notes
- Blameless, always. Analyze systems, processes, and missing guardrails, never assign fault to an individual. Replace "X deployed the bad change" with "the change passed CI because there was no integration test for Y."
- Ground every timeline entry in a real piece of evidence (a log line, an alert, a chat timestamp) and cite it. Never invent times, metrics, or events.
- If the evidence is thin, mark gaps explicitly as
[unknown, needs follow-up]rather than filling them in. - Every action item needs an owner (role or named team) and a due date; classify each as preventive (stops recurrence) or detective (catches it faster next time).
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.
- 2d ago First seen · 35 lines · 11 tokens per session scan A 6809317acf13
postmortem is a command published in the GitHub repository sigistry/marketplace (3 stars, last pushed 4d ago), licensed MIT. It adds 11 tokens to every session and 587 once invoked, about $0.0001 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-08-31.
Other commands, from other repositories
reviews-plans
Review all active architecture plans relevant to the current task.
derive-tests
Turn documented intent into a test-coverage map — inventory the tests that exist today, derive use-case cases from the system docs, separate existing coverage from proposed tests and unverified gaps, mark each unit / guarded-live / manual, and recommend a green-before-merge CI gate.
ship-check
Turn a vibe-coded repo into a reviewer-ready shipping packet — document the app, wire agent context, run security and performance audits, map test coverage, and compile the results.
battlecard
Create a sales-ready competitive battlecard — positioning, feature comparison, objection handling, and win strategies.
plan-launch
Create a full go-to-market strategy — beachhead segment, ICP, messaging, channels, and launch plan.
ship
Autonomous spec-to-PR pipeline with zero approval gates.