pre-mortem by boshu2/agentops
npx skills add https://github.com/boshu2/agentops --skill pre-mortem目的: 这个计划/规格说明是否足够好,可以实施?
对于包含 3 个以上子任务的史诗级任务是强制性的。 当在包含 3 个以上子任务的史诗级任务上调用
/crank时,预验尸会通过钩子强制执行。连续 6/6 次获得正向投资回报率。绕过方法:使用--skip-pre-mortem标志或设置AGENTOPS_SKIP_PRE_MORTEM_GATE=1。
在计划或规格说明上运行 /council validate,以便在承诺实施之前获得多模型判断。
/pre-mortem # 验证最近的计划(内联,不生成代理)
/pre-mortem path/to/PLAN.md # 验证特定计划(内联)
/pre-mortem --deep path/to/SPEC.md # 4 位评审员(彻底审查,生成代理)
/pre-mortem --mixed path/to/PLAN.md # 跨供应商(Claude + Codex)
/pre-mortem --preset=architecture path/to/PLAN.md # 以架构为重点的审查
/pre-mortem --explorers=3 path/to/SPEC.md # 对计划进行深度调查
/pre-mortem --debate path/to/PLAN.md # 两轮对抗性审查
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
如果提供了路径: 直接使用它。
如果没有路径: 查找最近的计划:
ls -lt .agents/plans/ 2>/dev/null | head -3
ls -lt .agents/specs/ 2>/dev/null | head -3
使用最新的文件。如果没找到任何文件,询问用户。
在进行快速或深度审查之前,当存在时,从 .agents/pre-mortem-checks/*.md 加载已编译的检查。这与飞轮搜索是分开的,并且不会被 --quick 跳过。
使用 docs/contracts/finding-compiler.md 和 docs/contracts/finding-registry.md 中跟踪的合约:
applicable_when 重叠度、语言重叠度和字面计划文本重叠度进行排序.agents/findings/registry.jsonl将匹配的条目作为 known_risks 包含在评审团数据包中,包含以下字段:
idpatterndetection_questionchecklist_item默认情况下,预验尸以内联方式运行(--quick) —— 单代理结构化审查,不生成代理。这能以约 10% 的完整评审团成本捕获实际的实施问题(在 ag-nsx 中已验证:内联发现了 3 个可操作的错误,这些错误会导致运行时故障)。
在 --quick 模式下,跳过步骤 1a 和 1b(知识搜索、产品上下文),除非设置了 --deep、--mixed、--debate 或 --explorers。这些预处理步骤仅用于多评审员评审团数据包。
要升级到完整的多评审员评审团,请使用 --deep(4 位评审员)或 --mixed(跨供应商)。
如果设置了 --quick 则跳过。 仅当设置了 --deep、--mixed 或 --debate 时运行此步骤。
if command -v ao &>/dev/null; then
ao search "plan validation lessons <goal>" 2>/dev/null | head -10
fi
如果 ao 返回了先前的计划审查发现项,则将它们作为评审团数据包的上下文包含进来。如果 ao 不可用或没有返回结果,则静默跳过。
如果设置了 --quick 则跳过。 仅当设置了 --deep、--mixed 或 --debate 时运行此步骤。
if [ -f PRODUCT.md ]; then
# PRODUCT.md 存在 — 在计划审查的同时包含产品视角
fi
当项目根目录中存在 PRODUCT.md 且用户没有传递显式的 --preset 覆盖时:
读取 PRODUCT.md 内容,并通过 context.files 将其包含在评审团数据包中
向评审团调用添加一个统一的 product 视角:
/council --preset=plan-review --perspectives="product" validate <plan-path>
这将总共产生 3 位评审员(2 位计划审查 + 1 位产品)。产品评审员在一次审查中涵盖用户价值、采用障碍和竞争地位。
使用 --deep 时:5 位评审员(4 位计划审查 + 1 位产品)。
当 PRODUCT.md 存在但用户传递了显式的 --preset 时:跳过产品自动包含(用户的显式预设优先)。
当 PRODUCT.md 不存在时:继续执行步骤 2,不做更改。
提示: 从
docs/PRODUCT-TEMPLATE.md创建PRODUCT.md以启用产品感知的计划验证。
默认(内联,不生成代理):
/council --quick validate <plan-path>
单代理结构化审查。以约 10% 的完整评审团成本捕获实际的实施问题。对于大多数计划来说已经足够(在 6 个以上的史诗级任务中得到验证)。
当您有意运行非快速评审团模式时,默认(2 位具有计划审查视角的评审员)适用。
使用 --deep(4 位具有计划审查视角的评审员):
/council --deep --preset=plan-review validate <plan-path>
生成 4 位评审员:
missing-requirements:规格说明中缺少什么?哪些问题还没有被问到?feasibility:技术上哪些地方困难或不可能?哪些地方会花费比估计多 3 倍的时间?scope:哪些是不必要的?缺少了什么?范围会在哪里蔓延?spec-completeness:边界是否已定义?一致性检查是否涵盖了所有验收标准?计划是否在机械上可验证?对于高风险计划(迁移、安全、多服务、7 个以上任务),使用 --deep。
使用 --mixed(跨供应商):
/council --mixed --preset=plan-review validate <plan-path>
3 个 Claude + 3 个 Codex 代理,用于具有计划审查视角的跨供应商计划验证。
使用显式预设覆盖:
/pre-mortem --preset=architecture path/to/PLAN.md
显式的 --preset 会覆盖自动的计划审查预设。改为使用以架构为重点的角色。
使用探索者:
/council --deep --preset=plan-review --explorers=3 validate <plan-path>
每位评审员生成 3 个探索者,以根据代码库调查计划可行性的各个方面。对于复杂的迁移或重构计划很有用。
使用辩论模式:
/pre-mortem --debate
为计划验证启用对抗性两轮审查。用于存在多种有效方法的高风险计划。有关完整的 --debate 详细信息,请参阅 /council 文档。
| 评审团裁决 | 预验尸结果 | 行动 |
|---|---|---|
| PASS | 准备实施 | 继续 |
| WARN | 审查关注点 | 解决警告或接受风险 |
| FAIL | 未准备好 | 在实施前修复问题 |
写入位置: .agents/council/YYYY-MM-DD-pre-mortem-<topic>.md
---
id: pre-mortem-YYYY-MM-DD-<topic-slug>
type: pre-mortem
date: YYYY-MM-DD
source: "[[.agents/plans/YYYY-MM-DD-<plan-slug>]]"
---
# Pre-Mortem: <Topic>
## Council Verdict: PASS / WARN / FAIL
| Judge | Verdict | Key Finding |
|-------|---------|-------------|
| Missing-Requirements | ... | ... |
| Feasibility | ... | ... |
| Scope | ... | ... |
## Shared Findings
- ...
## Known Risks Applied
- `<finding-id>` — `<why it matched this plan>`
## Concerns Raised
- ...
## Recommendation
<council recommendation>
## Decision Gate
[ ] PROCEED - Council passed, ready to implement
[ ] ADDRESS - Fix concerns before implementing
[ ] RETHINK - Fundamental issues, needs redesign
如果裁决是 WARN 或 FAIL,仅将可复用的计划/规格说明失败项持久化到 .agents/findings/registry.jsonl。
使用发现注册表合约:
dedup_key、provenance、pattern、detection_question、checklist_item、applicable_when、confidenceapplicable_when 必须使用合约中的受控词汇表dedup_key 追加或合并不要写入每条评论。仅持久化那些应该改变未来规划或审查行为的发现项。
更新注册表后,如果 hooks/finding-compiler.sh 存在,则运行:
bash hooks/finding-compiler.sh --quiet 2>/dev/null || true
这将刷新 .agents/findings/*.md、.agents/planning-rules/*.md、.agents/pre-mortem-checks/*.md 以及同一会话中的草稿约束元数据。session-end-maintenance.sh 仍然是幂等的最后保障。
ao ratchet record pre-mortem 2>/dev/null || true
告知用户:
graph TD
A[/plan epic-123/] --> B[/pre-mortem/];
B --> C{裁决};
C -- PASS --> D[/implement/];
C -- WARN --> E[Review];
E --> F{决定};
F -- Accept --> D;
F -- Fix --> G[Fix plan];
G --> B;
C -- FAIL --> G;
style B stroke:#f9f,stroke-width:2px;
用户说: /pre-mortem .agents/plans/2026-02-05-auth-system.md
发生的情况:
/council --quick validate <plan-path>(内联,不生成代理).agents/council/2026-02-13-pre-mortem-auth-system.md结果: 带有可操作关注点的快速预验尸报告。对于需要多评审员共识的高风险计划,请使用 --deep。
用户说: /pre-mortem --mixed .agents/plans/2026-02-05-auth-system.md
发生的情况:
结果: 在投入资源之前,通过跨供应商验证获得更高的信心。
用户说: /pre-mortem
发生的情况:
.agents/plans/ 查找最近的计划2026-02-13-add-caching-layer.md结果: 对最近的规划工作进行无摩擦验证。
用户说: /pre-mortem --deep .agents/plans/2026-02-05-migration-plan.md
发生的情况:
/council --deep --preset=plan-review validate <plan-path>(4 位评审员)结果: 对风险足以证明生成代理合理的计划进行彻底的多评审员审查。
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 评审团超时 | 计划太大或太复杂,评审员无法在分配时间内审查 | 将计划拆分为更小的史诗级任务,或通过评审团配置增加超时时间 |
| 有效计划上出现 FAIL 裁决 | 评审员误解了领域特定的约束 | 通过带有领域解释的 --perspectives-file 添加上下文 |
| 缺少产品视角 | PRODUCT.md 存在但未包含在评审团数据包中 | 验证 PRODUCT.md 是否在项目根目录中,并且没有传递显式的 --preset 覆盖 |
| 预验尸门禁阻止 /crank | 史诗级任务有 3 个以上任务且未运行预验尸 | 在 /crank 之前运行 /pre-mortem,或使用 --skip-pre-mortem 标志(不推荐) |
| Spec-completeness 评审员警告 | 计划缺少 Boundaries 或 Conformance Checks 部分 | 添加 SDD 部分或接受 WARN(向后兼容 — 不是失败) |
| 史诗级任务强制执行的强制性 | 钩子在未进行预验尸的 3 个以上任务史诗级任务上阻止 /crank | 首先运行 /pre-mortem,或设置 AGENTOPS_SKIP_PRE_MORTEM_GATE=1 以绕过 |
skills/council/SKILL.md — 多模型验证评审团skills/plan/SKILL.md — 创建实施计划skills/vibe/SKILL.md — 实施后验证代码每周安装次数
233
仓库
GitHub 星标数
197
首次出现
2026 年 2 月 2 日
安全审计
安装在
opencode229
codex227
gemini-cli225
github-copilot225
cursor221
amp218
Purpose: Is this plan/spec good enough to implement?
Mandatory for 3+ issue epics. Pre-mortem is enforced by hook when
/crankis invoked on epics with 3+ child issues. 6/6 consecutive positive ROI. Bypass:--skip-pre-mortemflag orAGENTOPS_SKIP_PRE_MORTEM_GATE=1.
Run /council validate on a plan or spec to get multi-model judgment before committing to implementation.
/pre-mortem # validates most recent plan (inline, no spawning)
/pre-mortem path/to/PLAN.md # validates specific plan (inline)
/pre-mortem --deep path/to/SPEC.md # 4 judges (thorough review, spawns agents)
/pre-mortem --mixed path/to/PLAN.md # cross-vendor (Claude + Codex)
/pre-mortem --preset=architecture path/to/PLAN.md # architecture-focused review
/pre-mortem --explorers=3 path/to/SPEC.md # deep investigation of plan
/pre-mortem --debate path/to/PLAN.md # two-round adversarial review
If path provided: Use it directly.
If no path: Find most recent plan:
ls -lt .agents/plans/ 2>/dev/null | head -3
ls -lt .agents/specs/ 2>/dev/null | head -3
Use the most recent file. If nothing found, ask user.
Before quick or deep review, load compiled checks from .agents/pre-mortem-checks/*.md when they exist. This is separate from flywheel search and does NOT get skipped by --quick.
Use the tracked contracts in docs/contracts/finding-compiler.md and docs/contracts/finding-registry.md:
applicable_when overlap, language overlap, and literal plan-text overlap.agents/findings/registry.jsonlInclude matched entries in the council packet as known_risks with:
idpatterndetection_questionchecklist_itemBy default, pre-mortem runs inline (--quick) — single-agent structured review, no spawning. This catches real implementation issues at ~10% of full council cost (proven in ag-nsx: 3 actionable bugs found inline that would have caused runtime failures).
In --quick mode, skip Steps 1a and 1b (knowledge search, product context) unless --deep, --mixed, --debate, or --explorers is set. These pre-processing steps are for multi-judge council packets only.
To escalate to full multi-judge council, use --deep (4 judges) or --mixed (cross-vendor).
Skip if--quick. Only run this step for --deep, --mixed, or --debate.
if command -v ao &>/dev/null; then
ao search "plan validation lessons <goal>" 2>/dev/null | head -10
fi
If ao returns prior plan review findings, include them as context for the council packet. Skip silently if ao is unavailable or returns no results.
Skip if--quick. Only run this step for --deep, --mixed, or --debate.
if [ -f PRODUCT.md ]; then
# PRODUCT.md exists — include product perspectives alongside plan-review
fi
When PRODUCT.md exists in the project root AND the user did NOT pass an explicit --preset override:
Read PRODUCT.md content and include in the council packet via context.files
Add a single consolidated product perspective to the council invocation:
/council --preset=plan-review --perspectives="product" validate <plan-path>
This yields 3 judges total (2 plan-review + 1 product). The product judge covers user-value, adoption-barriers, and competitive-position in a single review.
3. With --deep: 5 judges (4 plan-review + 1 product).
When PRODUCT.md exists BUT the user passed an explicit --preset: skip product auto-include (user's explicit preset takes precedence).
When PRODUCT.md does not exist: proceed to Step 2 unchanged.
Tip: Create
PRODUCT.mdfromdocs/PRODUCT-TEMPLATE.mdto enable product-aware plan validation.
Default (inline, no spawning):
/council --quick validate <plan-path>
Single-agent structured review. Catches real implementation issues at ~10% of full council cost. Sufficient for most plans (proven across 6+ epics).
Default (2 judges with plan-review perspectives) applies when you intentionally run non-quick council mode.
With --deep (4 judges with plan-review perspectives):
/council --deep --preset=plan-review validate <plan-path>
Spawns 4 judges:
missing-requirements: What's not in the spec that should be? What questions haven't been asked?feasibility: What's technically hard or impossible here? What will take 3x longer than estimated?scope: What's unnecessary? What's missing? Where will scope creep?spec-completeness: Are boundaries defined? Do conformance checks cover all acceptance criteria? Is the plan mechanically verifiable?Use --deep for high-stakes plans (migrations, security, multi-service, 7+ issues).
With --mixed (cross-vendor):
/council --mixed --preset=plan-review validate <plan-path>
3 Claude + 3 Codex agents for cross-vendor plan validation with plan-review perspectives.
With explicit preset override:
/pre-mortem --preset=architecture path/to/PLAN.md
Explicit --preset overrides the automatic plan-review preset. Uses architecture-focused personas instead.
With explorers:
/council --deep --preset=plan-review --explorers=3 validate <plan-path>
Each judge spawns 3 explorers to investigate aspects of the plan's feasibility against the codebase. Useful for complex migration or refactoring plans.
With debate mode:
/pre-mortem --debate
Enables adversarial two-round review for plan validation. Use for high-stakes plans where multiple valid approaches exist. See /council docs for full --debate details.
| Council Verdict | Pre-Mortem Result | Action |
|---|---|---|
| PASS | Ready to implement | Proceed |
| WARN | Review concerns | Address warnings or accept risk |
| FAIL | Not ready | Fix issues before implementing |
Write to: .agents/council/YYYY-MM-DD-pre-mortem-<topic>.md
---
id: pre-mortem-YYYY-MM-DD-<topic-slug>
type: pre-mortem
date: YYYY-MM-DD
source: "[[.agents/plans/YYYY-MM-DD-<plan-slug>]]"
---
# Pre-Mortem: <Topic>
## Council Verdict: PASS / WARN / FAIL
| Judge | Verdict | Key Finding |
|-------|---------|-------------|
| Missing-Requirements | ... | ... |
| Feasibility | ... | ... |
| Scope | ... | ... |
## Shared Findings
- ...
## Known Risks Applied
- `<finding-id>` — `<why it matched this plan>`
## Concerns Raised
- ...
## Recommendation
<council recommendation>
## Decision Gate
[ ] PROCEED - Council passed, ready to implement
[ ] ADDRESS - Fix concerns before implementing
[ ] RETHINK - Fundamental issues, needs redesign
If the verdict is WARN or FAIL, persist only the reusable plan/spec failures to .agents/findings/registry.jsonl.
Use the finding-registry contract:
dedup_key, provenance, pattern, detection_question, checklist_item, applicable_when, confidenceapplicable_when must use the controlled vocabulary from the contractdedup_keyDo NOT write every comment. Persist only findings that should change future planning or review behavior.
After the registry update, if hooks/finding-compiler.sh exists, run:
bash hooks/finding-compiler.sh --quiet 2>/dev/null || true
This refreshes .agents/findings/*.md, .agents/planning-rules/*.md, .agents/pre-mortem-checks/*.md, and draft constraint metadata in the same session. session-end-maintenance.sh remains the idempotent backstop.
ao ratchet record pre-mortem 2>/dev/null || true
Tell the user:
/plan epic-123
│
▼
/pre-mortem ← You are here
│
├── PASS → /implement
├── WARN → Review, then /implement or fix
└── FAIL → Fix plan, re-run /pre-mortem
User says: /pre-mortem .agents/plans/2026-02-05-auth-system.md
What happens:
/council --quick validate <plan-path> (inline, no spawning).agents/council/2026-02-13-pre-mortem-auth-system.mdResult: Fast pre-mortem report with actionable concerns. Use --deep for high-stakes plans needing multi-judge consensus.
User says: /pre-mortem --mixed .agents/plans/2026-02-05-auth-system.md
What happens:
Result: Higher confidence from cross-vendor validation before committing resources.
User says: /pre-mortem
What happens:
.agents/plans/ for most recent plan2026-02-13-add-caching-layer.mdResult: Frictionless validation of most recent planning work.
User says: /pre-mortem --deep .agents/plans/2026-02-05-migration-plan.md
What happens:
/council --deep --preset=plan-review validate <plan-path> (4 judges)Result: Thorough multi-judge review for plans where the stakes justify spawning agents.
| Problem | Cause | Solution |
|---|---|---|
| Council times out | Plan too large or complex for judges to review in allocated time | Split plan into smaller epics or increase timeout via council config |
| FAIL verdict on valid plan | Judges misunderstand domain-specific constraints | Add context via --perspectives-file with domain explanations |
| Product perspectives missing | PRODUCT.md exists but not included in council packet | Verify PRODUCT.md is in project root and no explicit --preset override was passed |
| Pre-mortem gate blocks /crank | Epic has 3+ issues and no pre-mortem ran | Run /pre-mortem before /crank, or use --skip-pre-mortem flag (not recommended) |
skills/council/SKILL.md — Multi-model validation councilskills/plan/SKILL.md — Create implementation plansskills/vibe/SKILL.md — Validate code after implementationWeekly Installs
233
Repository
GitHub Stars
197
First Seen
Feb 2, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
opencode229
codex227
gemini-cli225
github-copilot225
cursor221
amp218
通过 LiteLLM 代理让 Claude Code 对接 GitHub Copilot 运行 | 高级变通方案指南
27,600 周安装
| Spec-completeness judge warns | Plan lacks Boundaries or Conformance Checks sections | Add SDD sections or accept WARN (backward compatibility — not a failure) |
| Mandatory for epics enforcement | Hook blocks /crank on 3+ issue epic without pre-mortem | Run /pre-mortem first, or set AGENTOPS_SKIP_PRE_MORTEM_GATE=1 to bypass |