本文へ移動
cccskills
無料GitHub で公開

premortem

Find how a rollout plan could fail before committing to it. Use when: asked what could go wrong or to poke holes in a plan.

インストール方法を見る

含まれるファイル(6)

  • SKILL.md7.0 KB
  • references/derivation-diff.md1.5 KB
  • references/premortem.feature689 B
  • schemas/premortem-plan-review.v1.schema.json1.3 KB
  • scripts/validate-output.sh2.2 KB
  • scripts/validate.sh821 B

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Premortem

Premortem is an optional plan-challenge strategy. It asks one fresh context to identify concrete ways the resolved bead or caller intent could fail before implementation. It is not part of the required RPI sequence and does not authorize readiness. Plan's shared challenge method owns optional exchange, independence and stopping rules; Premortem owns the three checks below. Neighbours: general advice is Review, acceptance of a finished change is Validate, and several independent views are Council.

Run the checks in this order; they outrank any single technical risk.

The first check: who verifies, and are they fresh?

Test the plan's evidence shape before any technical risk: for every unit of work, who verifies it, and is the verifying context distinct from the one that authored it? A plan whose closure step is "the implementer runs its own tests and closes" contains no independent judgment anywhere. Self-graded green is the classic false-done, and it ranks first because it silently converts every other failure into a shipped one.

The second check: which steps are one-way doors?

Walk the steps and mark each two-way (the plan can back out of it) or one-way (it cannot). For every one-way step name the exact undo cost, the point of no return, and who holds the handle when it is crossed: the caller, or an agent deciding inside a batch. A two-way failure costs a retry; a one-way failure costs the thing itself. Watch for nineteen reversible steps followed by an irreversible one, where the reflex trained by the first nineteen answers the twentieth.

The named failure mode is reversibility asserted, not traced: a rollback section that says "fully reversible" while one step revokes a credential, force-pushes or publishes. A material irreversible action outside existing caller authority is a finding; trace actual undo cost and authorization with Plan. Prior authorization remains valid: do not demand repeated approval at the crossing or call every uncertain detail irreversible. Stop condition: every step carries a mark, and every one-way mark carries its undo cost.

The third check: construct the failure

For every candidate failure, attempt a concrete defeat: write the input, command sequence or repository state that would make the plan fail, and run or cite the check that shows whether the plan survives it. When execution is not available, the constructed input or sequence plus a cited fact (file and line, documented behavior, an observed output) counts as the attempt. A failure you could not construct is reported as attempted-and-blocked with the obstacle named, which is itself evidence for the plan. The named failure mode is armchair pessimism: imagined risks with no construction, which reads as diligence while testing nothing. A finding with neither a construction nor a blocking fact is deleted, not softened.

Workflow

  1. Resolve the existing intent source and inspect its acceptance, non-goals, evidence requirements and declared write scope. Its digest is the SHA-256 of the exact intent text as supplied (for example shasum -a 256 plan.md).
  2. Judge from a context that did not write the plan, following the shared challenge method for identity, model selection, authorization and bounds. A plan the caller wrote can be judged here, with the caller as author. If this context wrote the plan and no fresh context can be started, run the checks anyway, state that the independence leg is missing, and return inline findings; never describe them as independent.
  3. Run the three checks, then test acceptance completeness, edge behavior, scope and dependencies against cited repository facts. For integration or extension plans where anchoring on the working design is the risk, add the derivation-diff challenge.
  4. Return one complete, bounded set of concrete findings with checked and not-checked scope.
  5. Stop. The caller decides whether to revise the plan or invoke RPI.

Council or Dueling Idea Genies may be caller-supplied evidence, but Premortem requires neither and cannot turn consensus into approval.

Prompt

Premortem this plan before I implement: bead ag-4f21 proposes rewriting
`scripts/regen-all.sh` to call `ao gate check` instead of shelling out to
the Python generators, touching cli/internal/gates/regen.go. Plan and
acceptance are in the bead. Find concrete ways it fails.

It's working if

Observable in the trace, without reading the prose, and the rubric a fresh independent judge scores this skill against:

  • Every unit of work carries a named verifier, and any unit verified by the context that authored it comes back as a finding.
  • Every step carries a two-way or one-way mark, and each one-way mark names its undo cost and its point of no return.
  • Every reported finding cites a defeat attempt (the input, command or repository state constructed) or the fact that blocked the construction.
  • The finding set is bounded: a review that flags every step has reported nothing.

Boundary

  • Emit advisory findings, no verdict of any version, readiness, admission, or permission.
  • Do not implement, validate the candidate, retry, repair, schedule, claim, change acceptance, operate Git, close work, release, or deliver.
  • Any plan edit creates a new subject for a later caller-initiated Premortem.

Output

Return findings inline by default:

Findings (most consequential first)
1. <step> - <how it fails> - <construction, or the fact that blocked it> - <consequence>
Verifiers: <unit>: <who verifies>; self-verified units are findings
One-way steps: <step> - <undo cost> - <point of no return> - <who holds the handle>
Checked: <what was examined>. Not checked: <what was not>.
Independence: <judge context, distinct from author> or "missing: <reason>"

When the caller requests a durable review, return premortem-plan-review.v1 with the intent digest, author and judge context IDs, findings, evidence references, checked, and not_checked, and check it with this skill's scripts/validate-output.sh. The schema requires distinct author and judge IDs, so a review without an independent judge stays inline. An empty finding set means only that this optional challenge found no concrete defect; it is never a lifecycle gate.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Use AtomLane to compile and execute safe atomic parallel plans on macOS and native Windows Preview for worthwhile independent argv tasks, dependency DAGs, supported platform entrypoints, or Apple-silicon operators. Use at task start or an execution boundary when structured local work may contain two or more worthwhile units; skip plain answers, one quick command, and work whose effects cannot be safely bounded.

日本語の概要は準備中です。原文の説明を表示しています。

hashgraph-online/awesome-codex-plugins1,2732026年10月10日 更新

add

無料

Register a deferred decision in the debt registry. Trigger by judgment, not a marker scan, whenever a future reader would ask "why this way?": an unmade decision, stub, loosened type, bypassed check, swallowed error, a default picked "for now", or a TODO/FIXME/HACK/XXX marker. Trigger immediately whenever you defer work, or when the user invokes $add. Over-register freely; the developer drops with "drop A", "drop A,C", or "drop all".

日本語の概要は準備中です。原文の説明を表示しています。

hashgraph-online/awesome-codex-plugins1,2732026年10月10日 更新

ADK 框架适配层。为 LangChain / EINO / AutoGen / AgentScope / CrewAI 提供框架特定的 代码模板、惯用模式、API 映射和项目结构,供 agent-dev-workshop Phase 5 代码生成使用。 每个框架 reference 文件标注 verified_date 用于版本锁定。

日本語の概要は準備中です。原文の説明を表示しています。

hashgraph-online/awesome-codex-plugins1,2732026年10月10日 更新

中文调试修复技能。用于报错、测试失败、页面异常、功能不符合预期、需要定位根因并做最小修复时。触发语包括"进入调试模式""帮我修问题""报错了""测试失败""页面坏了""找根因"。

日本語の概要は準備中です。原文の説明を表示しています。

hashgraph-online/awesome-codex-plugins1,2732026年10月10日 更新

交互式 AI Agent 开发工作坊:通过 6 阶段深度协作对话,引导用户完成 Agent 需求分析、架构设计、 工具定义、Prompt 与编排设计、代码生成、验证迭代,产出可直接运行的 Agent 项目。 框架无关设计优先,支持 LangChain / EINO / AutoGen / AgentScope / CrewAI 等 ADK 框架。

日本語の概要は準備中です。原文の説明を表示しています。

hashgraph-online/awesome-codex-plugins1,2732026年10月10日 更新

中文漂移审计技能。用于项目或学习过程变乱、上下文漂移、任务分叉、多个方案冲突、命名不一致、Codex 可能顺手改多了时。触发语包括"漂移检查""感觉跑偏了""项目变乱了""检查是否失控""分叉太多""上下文漂移"。

日本語の概要は準備中です。原文の説明を表示しています。

hashgraph-online/awesome-codex-plugins1,2732026年10月10日 更新

hashgraph-online のスキルをすべて見る

このスキルの問題を報告する