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.
git clone --depth 1 https://github.com/unixcrh/phuryn-pm-skillsWrote 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/commands/unixcrh/phuryn-pm-skills/pre-mortem)<a href="https://agentmods.dev/commands/unixcrh/phuryn-pm-skills/pre-mortem"><img src="https://agentmods.dev/badge/commands/unixcrh/phuryn-pm-skills/pre-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/commands/unixcrh/phuryn-pm-skills/pre-mortem"><img src="https://agentmods.dev/badge/commands/unixcrh/phuryn-pm-skills/pre-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.00027 | $0.00864 |
| Opus 5 | $0.00014 | $0.00432 |
| Sonnet 5 | $0.00005 | $0.00173 |
| Haiku 4.5 | $0.00003 | $0.00086 |
Grade A, and why
pre-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 12d 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.
This is a copy
100% identical to pre-mortem — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 105 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/pre-mortem -- Pre-Launch Risk Analysis
Imagine your launch has failed. Now work backward to figure out why. This command applies the Tigers/Paper Tigers/Elephants framework to surface real risks and create mitigation plans.
Invocation
/pre-mortem [paste or upload a PRD, launch plan, or feature spec]
/pre-mortem We're launching a self-serve billing portal next month
Workflow
Step 1: Accept the Plan
Accept in any format: PRD, feature spec, launch plan, project brief, or verbal description. The more detail provided, the sharper the risk analysis.
Step 2: Risk Identification
Apply the pre-mortem skill:
Imagine the product has launched and failed. Generate risks across categories:
- Technical: Performance, scalability, integration failures, data issues
- User: Adoption barriers, usability problems, unmet expectations
- Business: Revenue impact, competitive response, market timing
- Operational: Support load, documentation gaps, training needs
- Dependencies: Third-party services, cross-team handoffs, regulatory
Step 3: Classify Risks
Categorize each risk:
Tigers — Real, substantive risks that could cause failure
- Assess severity: Launch-blocking / Fast-follow / Track
- For launch-blocking Tigers: immediate mitigation required
- For fast-follow Tigers: plan to address within first sprint post-launch
- For track Tigers: monitor but don't delay launch
Paper Tigers — Risks that feel scary but are overblown
- Explain why the concern is manageable
- Note what would need to change for this to become a real Tiger
Elephants — Unspoken risks the team knows about but avoids discussing
- Surface political, organizational, or uncomfortable risks
- Frame constructively with suggested conversation starters
Step 4: Generate Pre-Mortem Report
## Pre-Mortem: [Feature/Launch]
**Date**: [today]
**Status**: [Draft / Reviewed]
### Risk Summary
- **Tigers**: [count] ([launch-blocking], [fast-follow], [track])
- **Paper Tigers**: [count]
- **Elephants**: [count]
### Launch-Blocking Tigers
| # | Risk | Likelihood | Impact | Mitigation | Owner | Deadline |
|---|------|-----------|--------|-----------|-------|----------|
### Fast-Follow Tigers
| # | Risk | Likelihood | Impact | Planned Response | Owner |
|---|------|-----------|--------|-----------------|-------|
### Track Tigers
[Risks to monitor post-launch with trigger conditions]
### Paper Tigers
[Concerns that seem big but are manageable — with reasoning]
### Elephants in the Room
[Uncomfortable truths the team should discuss]
### Go/No-Go Checklist
- [ ] All launch-blocking Tigers mitigated
- [ ] Fast-follow plan documented and assigned
- [ ] Monitoring in place for Track Tigers
- [ ] Rollback plan defined
- [ ] Support team briefed
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.
- 12d ago First seen · 105 lines · 27 tokens per session scan A 48bd6de2d7c4
pre-mortem is a command published in the GitHub repository unixcrh/phuryn-pm-skills (2 stars, last pushed 6mo ago), licensed MIT. It adds 27 tokens to every session and 864 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to pre-mortem, differing in 0 lines, and is treated as a copy.
Other commands, from other repositories
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.
implement
Execute the implementation plan by processing and executing all tasks defined in tasks.md.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.