About
Thorbis Design System is the public interface constitution for Thorbis, the operating system for the trades. It records how product surfaces should look, move, talk, expose state, recover from failure, and work on the devices used by dispatchers, technicians, owners, and customers.
What this site is
This is a working design reference, not a portfolio theme or a generic component skin. Rules define Thorbis decisions. Research preserves the evidence and names its sources. Components connect accessible ShadCN primitives to Thorbis tokens, profiles, states, and verification requirements. Resources package those decisions for people and coding agents.
The system favors quiet chrome, precise work, durable state, honest recovery, keyboard operation, and mobile behavior that survives real field conditions. When the sources disagree, Thorbis law wins; research remains visible so the reasoning can be challenged without turning every implementation into a new visual language.
Stewardship and source
Byron Wade maintains these notes from the perspective of a plumber and product builder. The public repository records changes, tests, and decisions. The site is part of the broader Thorbis product identity, while product support and commercial questions remain with Thorbis. Start with Rules, inspect the component catalog, and use llms.txt when an agent needs a compact map.
Applied bookmark research
Reviewed 2026-09-06. These examples reinforce the existing owners; they do not introduce another visual style or claim the product behavior is implemented. Read the 26-source review and access limits.
Close the loop with evidence, not the word polished
Vague design requests produce repeated subjective revisions and hide which parts of the result were actually checked.
A review records the person and task, the observed defect, the owning rule, the smallest correction, and its verification. Preserve source access limits. Turn repeated feedback into a better existing default rather than another detached instruction file.
Thorbis example. Instead of make the button premium, record that its pending state moves the label, identify the UI owner, compare the corrected state under the same content, and attach the relevant checks and remaining uncertainty.
Verify. Separate a source that was read from a demo that was exercised. Separate a passing content test from a browser check, and a committed branch from a deployed release. Report failed and skipped checks explicitly.
Do not import. No fabricated research, inferred paid lesson content, unmeasured uplift claim, or declaring work live because a commit exists.
Open the tracking skill · Evidence: Agents with Taste; Train Your Judgement; Developing Taste; How we think about design; Design Engineer Principles
Make the task easier, not the screen busier
A feature can look complete while the dispatcher still has to reconstruct context or wait for unrelated content.
Start from one person, interruption, and completed task. Keep the current job and its next action usable while optional evidence arrives. Treat the real constraint as part of the brief, not something polished away afterward.
Thorbis example. For assigning a tech, show the job, relevant availability, and the consequence of the assignment. Do not make the dispatcher traverse a marketing-style sequence or a new shell to finish a routine task.
Verify. Walk through the task with representative long and missing records. Check that the essential action remains understandable when optional content is slow or unavailable. Record the result rather than claiming a performance improvement without measurement.
Do not import. No additional shell, feature hero, framework migration, or new dependency. Keep the approved surface role.
Open the product skill · Evidence: Design Engineer Principles; How we think about design; Component Architecture for React Server Components