postmortem

# Blameless postmortem

Stop what you were doing. This is an explicit reflection ritual — not a task to resume. Produce a structured postmortem report about what went wrong in this conversation, then write it to the vault, then stop.

If `$ARGUMENTS` is set (the user supplied a focus), narrow the analysis to that topic. Otherwise analyze whatever is most salient across the conversation so far.

## What this is and isn't

- It *is* a blameless, systems-level analysis: what broke, why, and what minimal change would prevent a recurrence.
- It *isn't* an apology, a retry, or a pivot back into the original task.

**Forbidden phrasing** — do not use "I apologize", "I'm sorry", "I should have", "my mistake", "my fault", or any first-person self-flagellation. Frame anomalies systemically: "the agent did X", "the tool description lacked Y", "the instruction was ambiguous about Z".

## Report structure

Produce the report with these five sections, in order, as H2 headings. Keep each section tight — a few sentences or a short list, not paragraphs.

### `## Anomaly`

One or two sentences stating concretely what went wrong. Reference specific turns, tool calls, or outputs where possible.

### `## Root cause hypotheses`

A ranked list (most likely first). Each hypothesis must name a category:

- **Ambiguous instruction** — the user or system prompt underspecified a requirement.
- **Missing guardrail** — no rule existed to prevent the failure mode.
- **Tool-description gap** — a tool's description was unclear, missing a constraint, or actively misleading.
- **Skill-body issue** — a skill's SKILL.md produced unintended behavior.
- **LLM quirk** — model-level tendency (over-eagerness, sycophancy, context loss, pattern-matching a wrong template).
- **Missing capability** — the agent lacked a needed tool, data source, or skill.
- **User-facing ambiguity** — the UI or command surface let the user form a wrong mental model.

Each hypothesis: one line naming the category, then one line of evidence from the conversation.

### `## Proposed patches`

Specific, minimal, testable changes. Each patch must name the artifact being changed (file path, tool name, AGENT.md line, skill name) and what exactly to change. Examples of acceptable specificity:

- "Add a line to AGENT.md under 'Tool use' saying: …"
- "Tighten the `web_fetch` tool description: add 'Prefer workspace_read when the URL is a local path.'"
- "Create a new `foo` skill that …"

Not acceptable: "the agent should be more careful", "improve the prompt", "rewrite the tool".

### `## Systemic vs session-specific`

For each proposed patch, tag it as:

- **Systemic** — a change to the codebase (code, SKILL.md, AGENT.md, tool description, docs).
- **Session-specific** — already handled in this conversation; no codebase change needed.

### `## Next steps`

A short bulleted list of decisions the user needs to make: accept/reject each proposed patch, file an issue, add an eval case, etc. Do not act on any of them — just surface them.

## Persistence

After producing the report (and only after), write it to the vault so it can be consolidated later by the dream/garden processes.

1. Call `current_time` to get the current timestamp.
2. Derive a short kebab-case slug from the anomaly (3–5 words).
3. Call `vault_write` with:
   - **page**: `agent/pages/postmortems/{YYYY-MM-DD-HHMM}-{slug}` (no `.md` extension — the tool adds it)
   - **content**: the report, prefixed with YAML frontmatter:

     ```yaml
     ---
     tags: [postmortem]
     importance: 0.6
     summary: <one-sentence anomaly summary>
     ---
     ```

   - Append a `## Sources` section to the bottom referencing the conversation (ID if available, else a brief description of the session).

## Delivery and stop

1. Deliver the report text in the assistant response (the vault page is for archival; the user still reads the report inline).
2. End the turn. Do not re-engage with the original task. If the user wants to act on a proposed patch, they will ask in the next turn.