预验尸技能 (pre-mortem) - AI驱动的软件开发计划审查与风险评估工具 | 提升项目成功率

pre-mortem by boshu2/agentops

288 周安装量

220 GitHub Stars

GitHub

安装命令

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 开发者，精准高效

联系我们

步骤 1：查找计划/规格说明

如果提供了路径： 直接使用它。

如果没有路径： 查找最近的计划：

ls -lt .agents/plans/ 2>/dev/null | head -3
ls -lt .agents/specs/ 2>/dev/null | head -3

使用最新的文件。如果没找到任何文件，询问用户。

步骤 1.4：首先加载已编译的预防措施（强制）

在进行快速或深度审查之前，当存在时，从 .agents/pre-mortem-checks/*.md 加载已编译的检查。这与飞轮搜索是分开的，并且不会被 --quick 跳过。

使用 docs/contracts/finding-compiler.md 和 docs/contracts/finding-registry.md 中跟踪的合约：

优先使用已编译的预验尸检查
按严重性、applicable_when 重叠度、语言重叠度和字面计划文本重叠度进行排序
限制为前 5 个发现项 / 检查文件
如果已编译的检查缺失、不完整或少于匹配的发现集，则回退到 .agents/findings/registry.jsonl
故障开放原则：
- 缺少已编译目录或注册表 -> 静默跳过
- 空的已编译目录或注册表 -> 静默跳过
- 格式错误的行 -> 警告并忽略该行
- 不可读的文件 -> 警告一次，并在没有发现项的情况下继续

将匹配的条目作为 known_risks 包含在评审团数据包中，包含以下字段：

id
pattern
detection_question
checklist_item

步骤 1.5：快速路径（--quick 模式）

默认情况下，预验尸以内联方式运行（--quick） —— 单代理结构化审查，不生成代理。这能以约 10% 的完整评审团成本捕获实际的实施问题（在 ag-nsx 中已验证：内联发现了 3 个可操作的错误，这些错误会导致运行时故障）。

在 --quick 模式下，跳过步骤 1a 和 1b（知识搜索、产品上下文），除非设置了 --deep、--mixed、--debate 或 --explorers。这些预处理步骤仅用于多评审员评审团数据包。

要升级到完整的多评审员评审团，请使用 --deep（4 位评审员）或 --mixed（跨供应商）。

步骤 1a：搜索知识飞轮

如果设置了 --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 不可用或没有返回结果，则静默跳过。

步骤 1b：检查产品上下文

如果设置了 --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 以启用产品感知的计划验证。

步骤 2：运行评审团验证

默认（内联，不生成代理）：

/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 文档。

步骤 3：解读评审团裁决

评审团裁决	预验尸结果	行动
PASS	准备实施	继续
WARN	审查关注点	解决警告或接受风险
FAIL	未准备好	在实施前修复问题

步骤 4：撰写预验尸报告

写入位置： .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

步骤 4.5：持久化可复用的发现项

如果裁决是 WARN 或 FAIL，仅将可复用的计划/规格说明失败项持久化到 .agents/findings/registry.jsonl。

使用发现注册表合约：

必填字段：dedup_key、provenance、pattern、detection_question、checklist_item、applicable_when、confidence
applicable_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 仍然是幂等的最后保障。

步骤 5：记录棘轮进度

ao ratchet record pre-mortem 2>/dev/null || true

步骤 6：向用户报告

评审团裁决（PASS/WARN/FAIL）
关键关注点（如果有）
建议
预验尸报告的位置

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>（内联，不生成代理）
单代理结构化审查发现缺少令牌过期的错误处理
评审团裁决：WARN
输出写入到 .agents/council/2026-02-13-pre-mortem-auth-system.md

结果： 带有可操作关注点的快速预验尸报告。对于需要多评审员共识的高风险计划，请使用 --deep。

跨供应商计划验证

用户说： /pre-mortem --mixed .agents/plans/2026-02-05-auth-system.md

发生的情况：

代理运行混合供应商评审团（3 个 Claude + 3 个 Codex）
跨供应商视角捕获平台特定问题
裁决：PASS，附带 2 个警告

结果： 在投入资源之前，通过跨供应商验证获得更高的信心。

自动查找最近计划

用户说： /pre-mortem

发生的情况：

代理扫描 .agents/plans/ 查找最近的计划
找到 2026-02-13-add-caching-layer.md
运行内联评审团验证（不生成代理，约 10% 的完整评审团成本）
记录棘轮进度

结果： 对最近的规划工作进行无摩擦验证。

高风险计划的深度审查

用户说： /pre-mortem --deep .agents/plans/2026-02-05-migration-plan.md

发生的情况：

代理读取迁移计划
在知识飞轮中搜索先前的迁移经验教训
检查 PRODUCT.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 — 实施后验证代码

2026 年 2 月 2 日

🇺🇸English

Pre-Mortem Skill

Purpose: Is this plan/spec good enough to implement?

Mandatory for 3+ issue epics. Pre-mortem is enforced by hook when /crank is invoked on epics with 3+ child issues. 6/6 consecutive positive ROI. Bypass: --skip-pre-mortem flag or AGENTOPS_SKIP_PRE_MORTEM_GATE=1.

Run /council validate on a plan or spec to get multi-model judgment before committing to implementation.

Quick Start

/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

Execution Steps

Step 1: Find the Plan/Spec

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.

Step 1.4: Load Compiled Prevention First (Mandatory)

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:

prefer compiled pre-mortem checks first
rank by severity, applicable_when overlap, language overlap, and literal plan-text overlap
cap at top 5 findings / check files
if compiled checks are missing, incomplete, or fewer than the matched finding set, fall back to .agents/findings/registry.jsonl
fail open:
- missing compiled directory or registry -> skip silently
- empty compiled directory or registry -> skip silently
- malformed line -> warn and ignore that line
- unreadable file -> warn once and continue without findings

Include matched entries in the council packet as known_risks with:

id
pattern
detection_question
checklist_item

Step 1.5: Fast Path (--quick mode)

By 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).

Step 1a: Search Knowledge Flywheel

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.

Step 1b: Check for Product Context

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.md from docs/PRODUCT-TEMPLATE.md to enable product-aware plan validation.

Step 2: Run Council 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.

Step 3: Interpret Council Verdict

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

Step 4: Write Pre-Mortem Report

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

Step 4.5: Persist Reusable Findings

If the verdict is WARN or FAIL, persist only the reusable plan/spec failures to .agents/findings/registry.jsonl.

Use the finding-registry contract:

required fields: dedup_key, provenance, pattern, detection_question, checklist_item, applicable_when, confidence
applicable_when must use the controlled vocabulary from the contract
append or merge by dedup_key
use the contract's temp-file-plus-rename atomic write rule

Do 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.

Step 5: Record Ratchet Progress

ao ratchet record pre-mortem 2>/dev/null || true

Step 6: Report to User

Tell the user:

Council verdict (PASS/WARN/FAIL)
Key concerns (if any)
Recommendation
Location of pre-mortem report

Integration with Workflow

/plan epic-123
    │
    ▼
/pre-mortem                    ← You are here
    │
    ├── PASS → /implement
    ├── WARN → Review, then /implement or fix
    └── FAIL → Fix plan, re-run /pre-mortem

Examples

Validate a Plan (Default — Inline)

User says: /pre-mortem .agents/plans/2026-02-05-auth-system.md

What happens:

Agent reads the auth system plan
Runs /council --quick validate <plan-path> (inline, no spawning)
Single-agent structured review finds missing error handling for token expiry
Council verdict: WARN
Output written to .agents/council/2026-02-13-pre-mortem-auth-system.md

Result: Fast pre-mortem report with actionable concerns. Use --deep for high-stakes plans needing multi-judge consensus.

Cross-Vendor Plan Validation

User says: /pre-mortem --mixed .agents/plans/2026-02-05-auth-system.md

What happens:

Agent runs mixed-vendor council (3 Claude + 3 Codex)
Cross-vendor perspectives catch platform-specific issues
Verdict: PASS with 2 warnings

Result: Higher confidence from cross-vendor validation before committing resources.

Auto-Find Recent Plan

User says: /pre-mortem

What happens:

Agent scans .agents/plans/ for most recent plan
Finds 2026-02-13-add-caching-layer.md
Runs inline council validation (no spawning, ~10% of full council cost)
Records ratchet progress

Result: Frictionless validation of most recent planning work.

Deep Review for High-Stakes Plan

User says: /pre-mortem --deep .agents/plans/2026-02-05-migration-plan.md

What happens:

Agent reads the migration plan
Searches knowledge flywheel for prior migration learnings
Checks PRODUCT.md for product context
Runs /council --deep --preset=plan-review validate <plan-path> (4 judges)
Council verdict with multi-perspective consensus

Result: Thorough multi-judge review for plans where the stakes justify spawning agents.

Troubleshooting

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)

Reference Documents

Weekly Installs

233

Repository

boshu2/agentops

GitHub Stars

197

First Seen

Feb 2, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykPass

Installed on

opencode229

codex227

gemini-cli225

github-copilot225

cursor221

amp218

通过 LiteLLM 代理让 Claude Code 对接 GitHub Copilot 运行 | 高级变通方案指南

27,600 周安装

预验尸技能 (pre-mortem) - AI驱动的软件开发计划审查与风险评估工具 | 提升项目成功率

🇨🇳中文介绍

预验尸技能

快速开始

相关 Skills

执行步骤

步骤 1：查找计划/规格说明

步骤 1.4：首先加载已编译的预防措施（强制）

步骤 1.5：快速路径（--quick 模式）

步骤 1a：搜索知识飞轮

步骤 1b：检查产品上下文

步骤 2：运行评审团验证

步骤 3：解读评审团裁决

步骤 4：撰写预验尸报告

步骤 4.5：持久化可复用的发现项

步骤 5：记录棘轮进度

步骤 6：向用户报告

与工作流集成

示例

验证一个计划（默认 — 内联）

跨供应商计划验证

自动查找最近计划

高风险计划的深度审查

故障排除

另请参阅

参考文档

🇺🇸English

Pre-Mortem Skill

Quick Start

Execution Steps

Step 1: Find the Plan/Spec

Step 1.4: Load Compiled Prevention First (Mandatory)

Step 1.5: Fast Path (--quick mode)

Step 1a: Search Knowledge Flywheel

Step 1b: Check for Product Context

Step 2: Run Council Validation

Step 3: Interpret Council Verdict

Step 4: Write Pre-Mortem Report

Step 4.5: Persist Reusable Findings

Step 5: Record Ratchet Progress

Step 6: Report to User

Integration with Workflow

Examples

Validate a Plan (Default — Inline)

Cross-Vendor Plan Validation

Auto-Find Recent Plan

Deep Review for High-Stakes Plan

Troubleshooting

See Also

Reference Documents

最新 Skills