Connecting design and data

Domain Canvas Skill: connect screens, domain concepts and ER diagrams

A screen shows a contract. A business specification distinguishes it from an application. A database connects it to a customer and a property. All describe the same service, yet the connections become hard to follow across documents. Domain Canvas Skill gives Claude Code a workflow for bringing these perspectives into one model.

It is useful when reviewing a feature change or taking over a system and asking: what does this screen represent, and where does its information live? Start by switching views in the public demo to decide whether the approach fits your project.

Published and source checked: 2026-09-15

Open the public demo View the source on GitHub

Give updates one starting point

Domain Canvas Skill packages instructions and a Python generator. The workflow examines project code and specifications, organizes screens, business objects and data structures in model.json, then generates an HTML canvas. It is distributed as a project-local Claude Code skill, rather than a hosted application.

The central idea is to maintain a shared model instead of three independent diagrams. After editing model.json and regenerating the HTML, each view reads the updated data. Screen connections live in bindings; domain and database relationships live in relationships. Related entries still need to be checked for consistency.

README: overview and distribution

Read the same subject through three questions

A domain is the set of meaningful business objects and rules, such as customers, applications and contracts. An entity–relationship (ER) diagram describes data attributes and relationships. Switching views changes the level of detail used to inspect the same subject.

View	What it shows	A contract review question
Design	Screens and the business objects they use	How does contract detail use customer, property and document information?
Concept	Object meanings and named relationships	Who contracts for what, and which documents belong to it?
ER	Attributes, primary keys (PK), foreign keys (FK) and cardinalities	Which keys connect a contract to a customer and property?

Design does not automatically design a finished interface. It can reference a screen image or local HTML prototype; otherwise it shows a placeholder. Concept displays descriptions and relationships, while ER adds attributes and key markers. The current ER view excludes edges marked kind: domain, which represent business-only relationships.

Generator: rendering and validation

Follow the real-estate CRM example

The bundled model contains five objects—customer, property, application, contract and document—three detail screens, and five relationships. Contract detail binds the contract as its primary object, customer and property as context, and documents as a collection. A screen can therefore connect to several objects according to their roles.

Suppose you want to display missing documents on contract detail. You could check the screen binding in Design, read the meaning of the contract–document relationship in Concept, then inspect fields such as document.contract_id in ER. This is an illustrative review scenario; the demo does not detect missing documents.

In the demo, switch between Design, Concept and ER at the top. Drag to pan, use the wheel or +/− to zoom, and select Fit to return to an overview. The sample screen previews are placeholders, not screenshots of a working CRM.

Real-estate CRM sample model

Separate supported relationships from inference

When AI organizes a system, the evidence for an edge matters more than how plausible it looks. The skill directs the agent to use sources appropriate to each claim: schemas, migrations and ORM models for tables and foreign keys; specifications for business meaning; routes and components for screens.

Relationships carry confidence: confirmed or inferred. Concept and ER display inferred relationships as dashed lines. The extraction rules explicitly reject treating two concepts appearing together in a UI as sufficient proof of a database relationship.

However, confirmed is a judgment recorded in the model. The generator does not read the evidence and prove it correct. Source notes and unresolved assumptions belong in the README accompanying the output.

Extraction and evidence rules

Install it and begin with a small scope

No installation is needed to view the public demo. For your project, copy .claude/skills/domain-canvas/ from the repository into the same location in the target project. Invoke it in Claude Code:

/domain-canvas contracts

Here, contracts is an example scope. You can also ask for the contract screens, conceptual model and ER diagram to be brought into one canvas. Starting with one feature makes comparison with source documents easier.

.domain-canvas/model.json: The canonical model; make model changes here.
.domain-canvas/index.html: The generated canvas for viewing.
.domain-canvas/README.md: Sources, unresolved assumptions and the refresh command.

python .claude/skills/domain-canvas/scripts/generate_canvas.py \
  --model .domain-canvas/model.json \
  --out .domain-canvas/index.html

The generator needs Python 3 and no external Python packages. Run the command, then open the HTML in a browser. To try the bundled sample, use example/model.json as input and example/index.html as output.

For ongoing use, include model updates, regeneration and review in the feature-change workflow. Edit the model: direct edits to generated HTML disappear on regeneration. The HTML embeds the model, so check who may receive the internal structure and any referenced screen assets before sharing it.

Skill definition: project workflow

Check business correctness separately from diagram consistency

The current generator checks required root fields, duplicate entity and screen IDs, relationship endpoints, and screen references. It does not automatically validate every database constraint or business rule.

For example, the sample declares document.contract_id nullable: true while giving the contract side of the contract–document relationship a cardinality of 1. You need to establish whether a document can exist without a contract, or whether the relationship describes only attached documents. Successful generation does not settle that semantic question.

The HTML viewer also does not edit or save the model, write changes back to code or a database, or continuously watch for changes. Simplifying technical join tables in the conceptual model requires modeling decisions; the current Concept and ER implementations use the same entity list.

The practical value is making differences in understanding reviewable. Choose a feature, build a model with evidence, and review unresolved relationships with business and development colleagues. If that small maintenance process is sustainable, the canvas can become a shared reference for handing over the connection between screens and data.

Generator: rendering and validation

Sources and verification

We inspected the README, skill definition, extraction rules, sample model and generator. Running the generator with the bundled sample produced HTML containing five entities, three screens and five relationships. Extraction accuracy on a real project and reductions in rework were not measured. Source links are pinned to the inspected commit; the live demo may change.

GitHub commit: 914d68fe3f12