Prepare evidence-backed incident postmortems

Create a production-ready AgentUse workflow that prepares an evidence-backed postmortem draft for one explicitly resolved incident by reading Sentry, GitHub, Slack, and Linear. It must not modify operational systems or declare root cause without human review.

Run `npx agentuse@latest skills get core --full` and `npx agentuse@latest skills get creator --full`. Inspect the installed AgentUse version, model catalog, project conventions, and live tool inventories. Use https://docs.sentry.io/api/, https://docs.sentry.io/api/events/list-an-organizations-issues/, https://docs.sentry.io/api/events/retrieve-an-issue/, https://docs.sentry.io/api/events/list-an-issues-events/, https://docs.sentry.io/api/permissions/, https://github.com/github/github-mcp-server, https://docs.github.com/en/rest/deployments/deployments, https://docs.github.com/en/rest/deployments/statuses, https://docs.slack.dev/ai/slack-mcp-server, https://linear.app/docs/mcp, and https://docs.agentuse.io/reference/builtin-tools#artifact-tools as implementation references. Report unavailable evidence as a blocker rather than inventing a connector or asking for manual exports.

Create `agents/incident-postmortems/incident-postmortem-preparer.agentuse`. Give it a narrow Sentry read wrapper for the documented organization-issues, issue-detail, and issue-events GET endpoints; the official GitHub MCP server in read-only mode with only required toolsets; a separate GitHub wrapper limited to GET /repos/{owner}/{repo}/deployments and GET /repos/{owner}/{repo}/deployments/{deployment_id}/statuses with Deployments: read; Slack MCP search and retrieval for the approved incident conversation; Linear's read-only MCP endpoint; and AgentUse artifact tools. Expose no write operation for Sentry, GitHub, Slack, or Linear.

The input is an incident_envelope containing incident ID, owner, UTC start and end, affected services, severity definition, Sentry organization, region, projects, environments and issue scope, GitHub repositories and release or deployment conventions, Slack workspace and incident channel, Linear incident issue and engineering teams, source ceilings, fact and inference labels, postmortem template, artifact group, retention policy, and review owner. Refuse to run without an explicit incident ID, owner, time window, and source boundaries.

Paginate every source to completion and emit a source_receipt for each connector with status, counts, pages or cursors, denied items, skipped formats, errors, and collection time. For Sentry, preserve issue IDs, permalinks, event counts, observed user measures, first and last seen, releases, tags, and event timestamps without recasting observed users as customers. Use the issue-events endpoint with the incident start and end, approved environments, and full event bodies only when required; account for its smaller page size when full is true. For GitHub, retrieve only explicitly linked or time-bounded commits, pull requests, releases, deployments, deployment statuses, and Actions evidence. Previous deployment statuses older than GitHub's 90-day retention are an explicit evidence gap, not proof that a status did not exist. For Slack, retrieve the approved incident channel and threads inside the window. For Linear, read the incident record and search existing follow-up work.

Normalize timestamps to UTC while retaining the original value. Emit an ordered event ledger with timestamp, event class, actor or system, concise fact, stable source ID, URL, and evidence class. Evidence class is verified_fact, supported_inference, hypothesis, contradiction, or unknown. Link events only through stable IDs, explicit references, or corroborated system evidence. Temporal proximity may create a hypothesis but never proves cause.

Draft impact, detection, response, timeline, mitigation, recovery, contributing factors, lessons, and action proposals. Every nontrivial statement needs a source or an explicit inference label. Include supporting evidence, counterevidence, confidence, and open questions for each contributing-factor hypothesis. Do not name a root cause as confirmed until the incident owner reviews it. Reconcile each action proposal against Linear and label it covered, possible duplicate, no match, or unavailable. Include problem, evidence, proposed owner, measurable completion, and priority input, but create no issue.

Save one Markdown artifact through artifact_save containing the incident envelope, source receipts, evidence manifest, full event ledger, postmortem draft, action coverage, unresolved contradictions, review checklist, and terminal receipt. If any required source is incomplete, preserve partial evidence, mark the artifact incomplete or blocked, withhold unsupported conclusions, and do not claim full coverage.

Use a supervised historical incident first. Later trigger the agent only after an explicit resolution event or operator invocation with the incident envelope. Deduplicate collection by source system plus stable item ID and output by incident ID plus source-scope fingerprint. Create a new artifact revision when evidence changes rather than overwriting a reviewed draft.

Create fixtures for linked deployment, coincidental deployment, missing Sentry events, Slack pagination failure, conflicting timestamps, unsupported impact claim, existing Linear action, ambiguous duplicate, unconfirmed root cause, and unavailable source. Run doctor, a complete mock test, deterministic timestamp and ordering tests, and one supervised read-only reconstruction before operational use.

At handoff provide the agent path, connector identities and exact read operations, source and privacy matrix, evidence schema, exact supervised command, fixture and session evidence, example postmortem artifact, known coverage limits, trigger recommendation, and incident-owner review checklist. Never request, print, or store credentials in agent files.