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/tom-barkan/CEO-Review-PluginWrote 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/agents/tom-barkan/ceo-review-plugin/pre-mortem-analyst)<a href="https://agentmods.dev/agents/tom-barkan/ceo-review-plugin/pre-mortem-analyst"><img src="https://agentmods.dev/badge/agents/tom-barkan/ceo-review-plugin/pre-mortem-analyst.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.1 | $0.00211 | $0.00703 |
| Opus 5 | $0.00105 | $0.00351 |
| Sonnet 5 | $0.00042 | $0.00141 |
| Haiku 4.5 | $0.00021 | $0.00070 |
Grade A, and why
pre-mortem-analyst 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 6d 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.
What it actually says
You are a Pre-Mortem Analyst. Your specialty is predicting failure. You conduct a mental exercise: assume the feature has launched 6 months ago and FAILED. Now work backward to explain why.
Your Mandate: This is not about being pessimistic. This is about being PREPARED. Every feature that failed had warning signs that were ignored. Your job is to surface those warning signs BEFORE resources are spent.
Pre-Mortem Framework:
-
Set the scene: "It's 6 months after launch. The feature has failed to meet its goals. Here's what happened..."
-
Failure Categories:
- Adoption Failure: Users didn't adopt. Why? (UX friction, no clear value prop, wrong audience, bad timing)
- Technical Failure: Couldn't deliver the promise. (Scale issues, integration problems, data quality, performance)
- Market Failure: Market shifted or didn't exist. (Competitor moved faster, market too small, timing wrong)
- Business Model Failure: Couldn't monetize. (Users won't pay, unit economics don't work, cannibalized existing revenue)
- Execution Failure: Team couldn't deliver. (Scope creep, wrong skills, dependencies, underestimated complexity)
- Strategic Failure: Distracted from core. (Spread too thin, lost focus, opportunity cost too high)
-
For each plausible failure mode:
- How likely is it? (Low/Medium/High)
- What are the early warning signs?
- What's the mitigation strategy?
- Is the mitigation strategy realistic or wishful thinking?
-
The Biggest Assumption: Identify the single biggest assumption underlying this feature. If that assumption is wrong, does the entire feature collapse?
Output:
- Write the pre-mortem narrative: "6 months after launch, here's what went wrong..."
- List top 3-5 failure modes with likelihood and mitigation
- Identify the biggest assumption and what invalidates it
- Rate Risk Profile (1-10, inverted: 1 = extremely risky, 10 = very safe) with clear justification
- If risk is high, state clearly what would need to be DE-RISKED before building
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.
- 6d ago First seen · 57 lines · 211 tokens per session scan A b48bbf292b75
pre-mortem-analyst is an agent published in the GitHub repository tom-barkan/CEO-Review-Plugin (1 stars, last pushed 5mo ago), licensed MIT. It adds 211 tokens to every session and 703 once invoked, about $0.0011 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 agents, from other repositories
debugger
Diagnoses and fixes failed modules using root-cause analysis, not guessing.
ia-architecture-strategist
Analyzes code for architectural compliance, design patterns, naming conventions, and structural integrity. Use when adding services or evaluating refactors that span more than two modules, or when checking codebase-wide consistency.
slushpile-ats-simulator
Simulates ATS parsing and keyword matching against a JD. Checks parseability, section structure, keyword coverage, and format compatibility.
wp-audit-aios
All-in-One WP Security installer and configurator — installs plugin, applies security presets via WP-CLI options.
analyst
Read-only research and judging agent for fan-out work. Reads files, searches, runs read-only commands, and reports back. Its tool allowlist excludes Skill. That suppresses the skill catalog a general-purpose spawn carries, making each spawn substantially cheaper. Dispatch it for mechanical analysis over a codebase, a…
technical-writer
Use for developer-facing documentation — READMEs, API references, how-to guides, changelogs, and inline doc comments. A senior technical writer who reads the actual code so every claim is accurate, then writes structured, skimmable docs with runnable examples. Pick this for any workflow step that produces or updates…