BPMN Style Guide
A tool that turns written procedures, meeting transcripts and existing diagrams into process models that obey an organisation's own drawing rules.
The Problem
Large organisations draw their processes as diagrams showing who does what, in what order, and where the decisions sit. BPMN 2.0 is the standard notation for that. It tells you which shapes exist; it does not tell you how a given company uses them. So every organisation writes a style guide on top: name tasks "verb + object", phrase gateways as questions, never use complex gateways, split a process once it passes a set size.
The two tools people actually draw in, Enterprise Architect and Draw.io, use completely different XML formats, so a model built in one is not portable to the other.
What It Does
Three inputs: a written procedure, a meeting transcript, or an existing model you want corrected. One output: a BPMN diagram that follows your style guide, downloadable as standards-compliant .bpmn for Enterprise Architect and as mxGraph XML for Draw.io.
The style guide itself is the core object. Upload your existing guide as a document and Claude extracts the rules into structured JSON, which you then edit in a form covering naming patterns, allowed element types, structural limits, layout direction, plus free-text custom rules. Guides are saved and reused across generations.
Generated diagrams open in an editable canvas. A linter checks the XML against the saved guide and pins violation markers onto the offending shapes: unlabelled elements, disconnected nodes, gateways not phrased as questions, task types the guide bans. Edit the diagram and it re-lints as you go.
The hard part
Drawing a diagram from a messy description is not the difficult bit. Producing one that is valid notation, obeys a particular organisation's conventions, and opens correctly in either of the two tools people actually draw in, that is the difficult bit.
The tempting shortcut is to let a model read the rules, read the diagram, and say whether it complied. That fails exactly as you would expect. It is agreeable, it disagrees with itself between runs, and an analyst cannot argue with a verdict that has no reasoning attached to a shape. Compliance had to be checked mechanically, so a breach is always the same breach and always points at the element that caused it.
Supporting a second drawing tool also had to be an addition rather than a rewrite, and that constraint shaped everything upstream of it. It remains a prototype, and it runs on Claude.
Where It Stands
The extractor, the linter and the serialisers landed inside a single day, and the repo has been quiet since early May 2026.
A working prototype, not a finished product. It runs end to end today: give it a written procedure, a meeting transcript or an existing model, and it returns a diagram that obeys your style guide, exportable to both of the tools analysts actually draw in. Breaches are named mechanically and pinned to the shape that caused them. The change reports and assumptions log are generated but not yet surfaced. The next real milestone is putting it in front of an analyst who did not build it.
Next project
Cotomate