Task Close Postmortem

---
name: task-close-postmortem
description: 'Postmortem capture + bridge-improvement scan at task close. Surfaces six optional questions (time invested, estimate vs actual, what went well, what burned time, where the bridge fell short, concrete improvement proposal), writes structured frontmatter back to STATUS.md, and generates proposal files under work/_learning/proposals/ for later review via /bridge-learn. Invoked automatically by protocols/standing-orders/task-sync.md Phase 3b at task close, and directly user-invokable for ad-hoc reflection. Trigger: "task done", "document everything", "wrap up", "wrap-up", "task complete", "post-mortem", "/postmortem the last hour", "reflect on the piece just finished", "review the last block", "what did we learn from X".'
allowed-tools:
  - Read
  - Write
  - Edit
  - Glob
  - Grep
  - Bash
metadata:
  scope: core
---

# Task-Close Postmortem

Captures a short reflection at task close, maps any surfaced gaps to concrete
Bridge-File-Improvement-Proposals, and writes both back as structured artifacts.

The skill is **always optional and always interruptible** — every question is
skippable, and skipping all six leaves the task unchanged from today's behavior.
Default-on (per `bridge-config.yaml.learning.postmortem.enabled`) but cost-light:
fast-path through all six skips is <20 seconds.

## When this skill runs

1. **Auto, via `task-sync.md` Phase 3b** — every time a task closes, after the
   dual_doku self-check passes and before the 3-step move.
2. **Manual** — when the user says any of: "/postmortem the last hour",
   "reflect on the piece just finished", "post-mortem this", "what did we
   learn from X". In manual mode the scope is **not bound to a task folder** —
   the skill reflects on the recent activity (last log.md entries, recent
   commits, recent file edits). No frontmatter writes happen in manual mode;
   output is only the proposals.

## Inputs

**Auto mode:**
- `work/tasks/<slug>/STATUS.md` — the task being closed
- `workflow/contexts/<context>.yaml` if STATUS references a context
- recent entries from `work/log.md` (last 24h or all entries since task `created`)

**Manual mode:**
- last N log.md entries (N defaults to last 10, or "the last hour")
- recent uncommitted git diff in this Bridge repo and any other repos touched

## The six questions

(Full script in [`references/postmortem-questions.md`](references/postmortem-questions.md).)

Surface them one at a time. Accept skip-phrases from
`bridge-config.yaml.learning.postmortem.skip_phrases` — default
`["skip", "next", "—", "no", "next", "."]`. If
`cutdown_after_skips` (default 3) consecutive skips occur, switch
to **Cutdown mode** for the remaining questions: ask only the single
catch-all "anything else worth noting?". Empty answer → done.

| # | Question (EN) | Writes to |
|---|---|---|
| 1 | Time invested? | frontmatter `time_invested` |
| 2 | Estimate vs actual? | frontmatter `estimate_vs_actual` |
| 3 | What went well? | body `## Postmortem` → "What went well" |
| 4 | What burned time? | body `## Postmortem` → "What did not go well" |
| 5 | Did the bridge fail you? | frontmatter `bridge_gaps[]` + body |
| 6 | Concrete improvement? | proposal file + body |

Use the conversation language from `bridge-config.yaml.language.conversation`
(default `en`). EN fallback if missing.

## Frontmatter write rules

Use the Edit tool against `work/tasks/<slug>/STATUS.md`. All four fields
(`time_invested`, `estimate_vs_actual`, `lessons`, `bridge_gaps`) are
**optional** in the schema (`work/templates/_schema.status.yaml`) — omit
the line entirely when the user skipped that question. Never write empty
strings or `null`.

Q1 → `time_invested:` — accept any of the schema-allowed forms
(`~12h`, `P3D`, `PT4H`, `—`, `unknown`). Loose parsing OK; if user types
"about 12 hours over 3 days", record as `"~12h"` and add the prose to body.

Q2 → `estimate_vs_actual:` — match to nearest enum value: ok / 1.5x / 2x /
3x / >3x / re-scoped / —. If user says "estimate was 4h, so 3x" record
`"3x"` and add the math to body for human readability.

Q3+Q4 → body `## Postmortem` subsections. Free-form prose. Bullet each line.

Q5 → `bridge_gaps[]` array. Each entry is one of:
`{skill: NAME, why: TEXT}` / `{standing_order: NAME, why: TEXT}` /
`{rule: NAME, why: TEXT}` / `{doc: NAME, why: TEXT}` /
`{protocol: NAME, why: TEXT}` / `{memory: NAME, why: TEXT}`.
A single user answer can yield multiple `bridge_gaps` entries.

Q6 → free-text improvement. Add to body "Concrete Bridge improvements proposed"
sub-section. Each bullet there will be examined in the proposal-writing phase.

## Improvement-Scan phase

After all six questions are answered (or skipped), scan for proposal-worthy
candidates from THREE sources, in order:

1. **`bridge_gaps[]`** (Q5 structured answers) — one proposal per entry.
2. **Free-text Q6 answer** — try to map to a structured proposal; if it
   doesn't fit cleanly, write a `proposal_type: needs-triage` proposal.
3. **Touched files during this task** — `git log --diff-filter=AM --name-only`
   in the relevant repos since task `created` date. If any file changed in
   this Bridge repo (skills/, protocols/, rules/, docs/) that wasn't a planned
   edit, flag as potential trigger-or-routing miss for the postmortem.

For each candidate, write one file to:

```
work/_learning/proposals/<YYYY-MM-DD>-<task-slug>-<topic-slug>.md
```

Following the schema in
[`references/_schema.proposal.yaml`](references/_schema.proposal.yaml).

**Naming rule:** `<topic-slug>` is the gap-id from `bridge_gaps[]` if
structured, or a 3-4-word kebab-case summary if from free-text. Disambiguate
collisions with a `-2`, `-3` suffix.

## Proposal-writing rules

Use the template in
[`references/proposal-writing.md`](references/proposal-writing.md).

Default `severity: P2` for postmortem-sourced proposals. P0/P1 only when the
gap is in an actively-used path (existing skill, common standing-order) AND
the user explicitly described impact.

Default `scope: user` for postmortem-sourced proposals unless the target is
clearly a CORE file (a generic skill, a CORE standing-order, the schema).
The /bridge-learn skill (Phase 2) and /bridge-sync handle promotion to
your org overlay / open-bridge later — getting the scope right at
proposal-write time saves an audit later.

Default `status: pending`. Never write `accepted` or `implemented` from
this skill — those are /bridge-learn states.

## Output to user

After all phases complete, return a single block:

```
✅ Task <slug> postmortem complete.
   <X> answers captured (frontmatter + body)
   <N> proposals written to work/_learning/proposals/
     • <file-1>  [<severity>] <one-line summary>
     • <file-2>  [<severity>] <one-line summary>
   → review per /bridge-learn (Phase 2) — or open the files directly.
```

If all six questions skipped:

```
✅ Postmortem skipped — STATUS.md unchanged.
```

Hand control back to `task-sync.md` Phase 3c (3-step move).

## Edge cases

- **Task has no `context:` field** → skip context.yaml read, proceed.
- **Task has no `mandant:` field** → no impact on postmortem.
- **STATUS.md is malformed** → log warning, ask user to fix, exit
  gracefully (do not mv files yet).
- **Skip-phrase ambiguity** ("no" could mean "no, nothing" or "no
  I'll answer in a moment"): treat as skip; user can backfill manually.
- **User says "wait" / "hold on" / "stop"** mid-flow → suspend, do NOT
  write partial frontmatter, hand control back. User can resume by
  saying "continue postmortem" / "postmortem continue".
- **Proposals folder doesn't exist** → create on first write
  (`mkdir -p work/_learning/proposals/`).
- **Bridge-config.yaml not present** → assume defaults (postmortem enabled,
  skip_phrases as above, cutdown_after_skips=3).

## Testing the skill

Two ways to dry-run without closing a real task:

1. **Manual mode** — say "reflect on the last hour", skill runs without
   binding to a STATUS.md, just emits a sample proposal-set.
2. **Test fixture** — `work/_learning/_test/sample-task/STATUS.md` (create
   on demand) — skill runs against the fixture, writes proposals to
   `work/_learning/_test/proposals/`, asserts schema validity.

## What this skill deliberately does NOT do

- ❌ Mutate any file outside `work/tasks/<slug>/STATUS.md` and
  `work/_learning/proposals/`. The 3-step move is done by `task-sync.md`
  Phase 3c, not here.
- ❌ Auto-apply any proposal. Every proposal-file is `status: pending` —
  accept/reject is the /bridge-learn skill's job.
- ❌ Probe other repositories (customer-x, partner-project, ...). Only this Bridge repo
  + git-stats for the task duration period.
- ❌ Write to MEMORY.md. The auto-memory system is separate; a postmortem
  may *suggest* a memory entry via `bridge_gaps[].memory:` but the actual
  write happens later, human-approved.
- ❌ Decide when proposals get implemented. That's /bridge-learn.
- ❌ Run if `bridge-config.yaml.learning.postmortem.enabled: false`.

## Related

- `protocols/standing-orders/task-sync.md` § Phase 3b (invokes this skill)
- `work/templates/_schema.status.yaml` (schema for the frontmatter fields)
- `work/templates/STATUS.md` (template `## Postmortem` section)
- `work/_learning/README.md` (the aggregation layer this writes into)
- `skills/bridge-learn/SKILL.md` (Phase 2 — reviews proposals)
- `bridge-config.yaml.learning.postmortem` (config block)
- CLAUDE.md § Auto Memory (the parallel system this does NOT touch)