conventionsHouse style for C4 workspaces on top of valid Structurizr DSL — camelCase identifiers and Title Case names, mandatory descriptions and canonical technology on every element, explicit view keys, present-tense relationship verbs with a technology on process boundaries, the External tag for third-party
exportRender a C4 workspace to PlantUML, Mermaid, WebSequenceDiagrams, workspace JSON, a theme file, or a browsable static HTML site. Use whenever the user wants diagram source or files out of the model — "export the diagrams", Mermaid for a README, PlantUML for a wiki or Confluence, the workspace JSON fo
previewStart or stop a live browser preview of the C4 workspace at http://localhost:8080, re-rendering as the DSL is edited. Use whenever the user wants to look at the diagrams rather than get files out of them — "preview", "open the diagrams", "render this in a browser", "start the local server", "let me
structurizeScaffold a new C4 architecture workspace from scratch — workspace.dsl, ADRs, docs, and a preview script — either at the repo root or in an architecture/ subdirectory of an existing project. Use when the user wants to start architecture documentation where none exists yet: "set up C4 here", "add a C4
updateEdit an existing C4 workspace — add or change elements (server, service, container, component, database, queue, actor), relationships, views, styles, deployment environments, ADRs, and docs. Use when the user describes a new or missing server/service, adds a dependency between systems, records an ar
validateCheck a C4 workspace.dsl for syntax and semantic errors by running the Structurizr CLI in Docker, and explain any failure. Use when the user asks to validate, lint, or check the DSL, asks "is the workspace valid?", or wants a quality gate before committing or merging — and after any hand-edit made o