Task Close Postmortem

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 /STATUS.md` — the task being closed

• workflow/contexts/.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//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.

1. 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/--.md

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

Naming rule: ` 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  postmortem complete.
    answers captured (frontmatter + body)
    proposals written to work/_learning/proposals/
     •   [] 
     •   [] 
   → 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,

skipphrases as above, cutdownafter_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.

1. 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//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)

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: bks-lab
• Source: bks-lab/open-bridge
• License: MIT
• Homepage: https://bks-lab.github.io/open-bridge/

Install and usage instructions live in the source repository linked above.