authoring-workflow-postmortem

Verify the trigger event in state.json, archive runlogs and spend data into a dated folder, build a UTC timeline from runlog.jsonl, identify the mechanism-based root cause, and draft the document from the postmortem template with owned action items.

Four triggers require a postmortem within 48 hours: a failed stage with more than $1 spent, a rejected implement gate, a spend-cap overrun where total cost meets the cap, and a sandbox egress test failure. Multiple triggers are covered in one document.

Check state.json with jq filters: look for stages with status failed and cost over $1, an implement status of rejected, or total_cost_usd greater than or equal to spend_cap_usd. If verification fails, stop and ask the user rather than drafting on a phantom trigger.

A good root cause names the mechanism and system gap, not the agent. Instead of "the model hallucinated", state what allowed it, such as a plan-stage prompt that predates the citation rule. Apply at least three whys before declaring the cause.

Do not write one for successful-workflow retrospectives, architecture decisions (use ADRs), or when no trigger event fired. If the approval chain fails verification or real PII appears in logs, escalate as a security incident first.

No. It only authors action items as PR targets with owners and due dates, then hands off to sibling skills like drafting-stage-prompt or authoring-scaffold-profile. The action owner runs the sibling skill so the PR has the right author.