Reverse-engineered business-process diagram

Points an agent at the artifacts of a process — Slack threads, ticket history, call transcripts, doc folders, code paths — and asks for a Mermaid diagram of how the process actually runs, not how the wiki says it runs. Surfaces invisible handoffs, parallel forks, dead branches.

Replaces a 1–2-week consultant interview round. Most teams discover their real process diverges sharply from the documented one. This is the cheapest way to find that delta.

1. Identify the process (e.g. "customer onboarding," "release," "incident response").
2. Pull every artifact it touches: relevant repo paths, Linear/Jira project, Slack channel, transcripts of related meetings, the existing wiki page.
3. Prompt the agent: "Read these sources. Produce a Mermaid flowchart of what actually happens end-to-end. Mark each step with the evidence (timestamp, message link, file path). Flag steps documented in the wiki but not present in the evidence, and vice versa."
4. Render the Mermaid in Obsidian / GitHub for review.
5. Review with the team — every gap is a useful conversation.
6. Update the wiki from the agent's output; archive the old diagram.

Read every message in #onboarding, every ticket tagged "onboarding" in the last 90 days, every transcript in transcripts/ tagged onboarding, and the wiki page at docs/onboarding.md. Build a Mermaid flowchart of the actual process. For each node cite ≥1 piece of evidence ([timestamp] or [file:line]). At the bottom list: (a) steps in the wiki absent from evidence, (b) steps in evidence absent from the wiki.

• The first pass is often too detailed. Ask for a 7–12-node version, then a detailed sub-diagram per node.
• Require citations on every node or the agent invents steps that "feel" right but aren't.