ERICK NOLASCO
← All work

Musterhall Design Language

Co-founder & Product Design Lead · Side venture, part-time · Pre-launch

The visual language and token system I designed for Musterhall, a pre-launch side venture building a trends and knowledge learning platform. One token source, web and Flutter.

Role
Co-founder & Product Design Lead
Timeline
2025 – Present
Platform
Web + mobile design system
Tools
Claude Code, ClickUp, Style Dictionary, Storybook

At a glance

The problem
One brand green did every job, so it meant nothing. Web and Flutter also needed the same numbers.
What I did
As co-founder I lead product and UX/UI: I run the backlog in ClickUp, scope features, write the specs, own the mocks and give design acceptance on what ships (see the AI workflow case). Here, the system: I own every token value, wrote it as an agent skill, and sign off the production walks. Engineering owns the build.
Key decision
Color encodes. It never decorates. Green split into identity and action. Status got its own hues, metadata none.

The system in the product

Pre-launch. Storybook captures of the shipped components with fixture data, in both themes; the featured course photo comes from the product mockups. Token chips use the same values as the plates below.

The Musterhall home in two browser windows, dark in front and light behind, with the stencil M logo, a green Request access button and a featured Half Guard Foundations course tile with a jiu-jitsu photo, and the marketing lander on a phone.
The product: the home in dark and light, and the lander on a phone.
The Musterhall marketing lander in a dark browser window and on an iPhone: the headline Get good at something with something on a green highlight, Start learning and Request access buttons, and a course player showing a jiu-jitsu lesson beside its outline.
The marketing lander, desktop and iPhone, built on the same tokens. Pre-launch, demo content.
The light home screen beside six token chips: muster for the mark and the Hand-checked dot, action for Request access, action-soft for the free preview chip, brass-soft for the founding instructor chip, control-edge for Log in and Search, and ink for prices.
One screen, six tokens, each with one job. Prices carry no accent.
Two phones showing an instructor profile with session offerings and a Book a session button, one in the dark theme and one in the light theme.
Instructor booking on a phone, dark and light, from one token set.
A group live session in dark and light: a green speaking ring, a REC chip, a Muted pill, a Mock room chip, and Report and Leave buttons, above chips for the action, danger, warn and info tokens.
Status hues in a live room, each paired with a label.
The data viz foundations in light and dark: eight categorical chart slots in fixed order, and a worked line chart and stacked bar chart in blue and aqua.
The chart law as it ships: eight fixed slots, no green, in both themes. See Plate 03.

Overview

Musterhall monogram

Musterhall

I’m a co-founder and lead product and UX/UI.

Every plate is rendered from the real tokens; every contrast figure is computed at build. The reasoning and evidence sit in the deep dives under each plate.

Decisions and tradeoffs

As co-founder I lead product as well as the system. These calls shaped it, each with what it cost.

  • Split the brand green into two jobs. One chartreuse did identity, verification and every buy button, so it meant nothing. I moved it to a true green with two roles on one hue. The cost is a strict green budget that every screen has to respect.
  • Code is canonical, not Figma. I deferred a Figma library on purpose, because a hand-built twin would drift from the shipped tokens. The cost is no Figma library to pull from. The written spec and the Storybook catalog stand in for it.
  • Each app pins its own tokens. Web and Flutter consume one source, but a token change lands only when each app re-pins. That trades speed for control over when a change ships.
  • Measured, with the gaps listed. Contrast is computed, and where the system falls short the page says so instead of hiding it.

Color encodes. It never decorates.

Plate 01 The intent palette
  • Identity --muster

    The mark and verified badge, once per component.

    Dark theme: Verified #65cd5c
    Light theme: Verified #297d22
  • Interactive --action

    Fills, links, focus.

    Dark theme: Primary #4d9f45
    Light theme: Primary #297623
  • Positive --ok

    Non-money positives.

    Dark theme: Approved #2fbebe
    Light theme: Approved #007375
  • Informational --info

    In progress.

    Dark theme: In review #3faff3
    Light theme: In review #006ab4
  • Caution --warn

    Drafts, retryable failures.

    Dark theme: Draft #ffc039
    Light theme: Draft #7d5100
  • Serious --danger

    Errors, destructive states.

    Dark theme: Declined #ff6661
    Light theme: Declined #c21725
  • Broadcast --live

    A badge, not a control.

    Dark theme: Live #ff6661
    Light theme: Live #c21725
  • Ceremony --brass

    Only what is earned.

    Dark theme: Founding #d9ba70
    Light theme: Founding #70570f
  • Metadata --ink-2

    Prices and counts: no accent.

    Dark theme: 00.00 000 items #b9b7b2
    Light theme: 00.00 000 items #404249
Deep dive Role notes
  • Identity. The mark and the verified badge, at most once per component. Not a button, link or chart.
  • Interactive. Primary fills, links, selection and focus.
  • Positive. Non-money positives such as connected, published and approved. Teal, kept off the green band on purpose.
  • Serious. As a control, danger is always an action, not a badge.
  • Broadcast. The same red hue as danger with a different job: a dot and a label, no fill, so it can’t read as a button.
  • Ceremony. Metal, not color. Not interactive, not a status.
  • Status always pairs an icon with a label.
Color is spent only where it means something, and each meaning has its own form. Token CSS, both themes
Deep dive Why green was split One hue, two roles, and a budget every screen respects.

The base is neutral: ink on charcoal, or on warm parchment in light mode. Color is spent only where it carries information.

One chartreuse used to do identity, verification and every buy button. I moved it to a true green and split it into two roles on one hue.

Edge cases are written down: a confirmed booking wears teal, a payment marked paid keeps green, and something still processing wears neither. One exception to the budget: a single hero money figure per surface may wear action green.

Plate 02 One hue, many jobs
  1. Step 50#c5fdbf No dark theme role No light theme role
  2. Step 75#d6f1d2 No dark theme role Light theme roles: action-soft
  3. Step 100#9cf093 No dark theme role No light theme role
  4. Step 150#65cd5c Dark theme roles: mustermuster-text No light theme role
  5. Step 200#5db655 No dark theme role No light theme role
  6. Step 250#4d9f45 Dark theme roles: actionaction-text No light theme role
  7. Step 300#3a8c32 Dark theme roles: hover No light theme role
  8. Step 350#297d22 Dark theme roles: press Light theme roles: muster
  9. Step 375#297623 No dark theme role Light theme roles: action
  10. Step 400#1c6316 No dark theme role Light theme roles: muster-textaction-texthover
  11. Step 450#0b3807 No dark theme role Light theme roles: press
  12. Step 475#0e230c Dark theme roles: action-soft No light theme role
  13. Step 500#031802 Dark theme roles: muster-inkaction-ink No light theme role

The green budget

  1. Law 1

    One identity green per component.

    Verified
  2. Law 2

    One solid primary per surface.

    Primary Secondary Tertiary
  3. Law 3

    Green may write. It may not outline.

    Not allowed: a green border on a secondary button
    Tertiary Allowed: green text on a tertiary action
  4. Law 4

    Meta rows carry no accent.

    00.00 000 items 0h 00m
Identity and action share one green hue, and action states only step darker so they can’t read as identity. Token references, design-system skill

Data viz: the chart law

Eight categorical slots in a fixed order, no green, and status hues kept out of series, checked against a simulated deuteranopia view.

Plate 03 The dataviz law

Categorical, fixed order, not cycled

  1. 01 Blue Revenue analysis
  2. 02 Aqua
  3. 03 Amber Labelled directly in light
  4. 04 Slate Other, baseline, remainder
  5. 05 Violet
  6. 06 Red
  7. 07 Magenta
  8. 08 Orange
Deep dive Colorblind simulation

No green slot. Slot 4 was a green three degrees off the brand hue, so it became a neutral slate. Amber measures 2.60:1 on light (computed), so it always carries a label.

Simulated deuteranopia

Dark As designed Simulated
Light As designed Simulated

Simulated, not observed. Slate and magenta, aqua and magenta, and red and orange converge, so series should be labelled directly. That is my reading of this check, not yet a written rule.

Why chart hues can sit near status hues

The rule bans reusing a status token as a series, not sharing a hue. A plot mark and a status chip with an icon and label differ in form and context. Green is the exception: a series that reads as the brand mark is a real misread.

Charts get eight fixed hues and no green, so a series can’t pass for the brand. Chart tokens, Machado 2009 simulation

Components and states, measured

Plate 04 Tiers and states

Dark

Tier resthoverpressfocusdisabled
Primary Action fill Primary, rest Primary, hover Primary, press Primary, focus Primary, disabled
Secondary Neutral edge Secondary, rest Secondary, hover Secondary, press Secondary, focus Secondary, disabled
Tertiary Action text Tertiary, rest Tertiary, hover Tertiary, press Tertiary, focus Tertiary, disabled

Light

Tier resthoverpressfocusdisabled
Primary Action fill Primary, rest Primary, hover Primary, press Primary, focus Primary, disabled
Secondary Neutral edge Secondary, rest Secondary, hover Secondary, press Secondary, focus Secondary, disabled
Tertiary Action text Tertiary, rest Tertiary, hover Tertiary, press Tertiary, focus Tertiary, disabled
Deep dive State rules

Hover moves one step, press two, hover only under a fine pointer. Disabled is 0.6 opacity. Focus is a 2px action outline. Measured gap: in light, the ghost press step equals the page ground, so only the 0.98 press scale shows it.

An action inside a status tint

A ghost in the card’s own ink, weight 600.

Every tier is drawn in five states and both themes, from the shipped button rules. Shipped button rules
Deep dive The contrast ledger Every pairing computed, including where the system falls short.
Plate 05 The contrast ledger

Found by measuring, open in the system

Found by measuring, open in the system: computed WCAG contrast ratios, dark and light themes
Pairing Used for Bar Dark Light
--action-ink / --action-hover Primary label, hover 4.5:1 4.38:1below 7.06:1pass
--action-ink / --action-press Primary label, press 4.5:1 3.56:1below 12.70:1pass
--ink-4 / --bg-2 Placeholder text 4.5:1 3.18:1below 3.11:1below
--bg-4 / --bg Ghost press fill n/a 1.18:1visible 1.00:1no change
Deep dive Full ledger

Resting pairs

Resting pairs: computed WCAG contrast ratios, dark and light themes
Pairing Used for Bar Dark Light
--ink / --bg Primary text 4.5:1 18.77:1pass 18.06:1pass
--ink-3 / --bg Captions 4.5:1 5.91:1pass 6.28:1pass
--action-ink / --action Primary label 4.5:1 5.60:1pass 5.41:1pass
--ok / --ok-soft Status on its tint 4.5:1 6.36:1pass 4.69:1pass
--control-edge / --bg-2 Control boundary 3.0:1 3.18:1pass 3.11:1pass
--ink-4 / --bg-2 Disabled text n/a 3.18:1exempt 3.11:1exempt
--line / --bg Divider n/a 1.69:1exempt 1.67:1exempt

Fixed by measuring, light theme

Positive status: 52% to 49% lightness

As specced4.16:1 As shipped4.69:1

Teal copied its siblings’ nominal lightness and missed AA. New tones are now matched by measured contrast.

Identity as text gets its own token

--muster4.27:1 --muster-text6.08:1

Identity green is graphic-grade on raised ground. Verified labels now use a text-only token one rung darker.

Text needs 4.5:1, 14px bold included; boundaries need 3:1. Disabled controls and dividers are exempt. The token comment still assigns placeholder text to the disabled ink.

Contrast is computed from the tokens at every build, and the four gaps it finds are listed, not hidden. Computed, WCAG 2
Deep dive What the system does for the person using it
Plate 06 What it does for the person using it
  1. Rule: Green means identity, action or money
    The person experiences: Green is never decoration, so it is worth noticing
    Prevents: Trust color on every price and button
  2. Rule: Status pairs an icon with a label
    The person experiences: Status reads without telling hues apart
    Prevents: Meaning carried by color alone
  3. Rule: One solid primary per surface
    The person experiences: The next step is obvious
    Prevents: Two asks competing for attention
  4. Rule: Control edges clear 3:1
    The person experiences: You can see what is clickable
    Prevents: Buttons that vanish into the page
  5. Rule: LIVE is a dot and a label
    The person experiences: Status doesn’t look pressable
    Prevents: Tapping a badge that does nothing
  6. Rule: Low-contrast chart slots carry a label
    The person experiences: Every series can be named
    Prevents: A chart only some readers can read
Deep dive The stated reasons, and more rules
  • Green. When everything is colored, color means nothing. One chartreuse once did identity, verification and commerce, so buy buttons wore the trust color. Prices, counts and roles now carry no accent.
  • Status. Status tones are reserved and always shown with an icon and a label. A status icon matches its subject, so color encodes severity and the icon encodes what.
  • One primary. A page may repeat its one ask, but not run a second, different accent fill. Peer rows carry no fill, so peers can’t have different prominence.
  • Control edges. “A bordered button announces itself by shape” is only true if the shape is perceivable. The divider token measured too low for that, so controls got their own edge token.
  • LIVE. A solid green pill read as a button and doubled the green beside real ones. The pulse moves a ring instead of fading the dot, because a fading dot dropped below 3:1 mid-cycle.
  • Charts. The amber slot measures low on light grounds, so it needs a direct label or a table, not color alone.
  • Touch. Targets are 44px, 48px under a coarse pointer, and every tappable shows a press state.
  • Waiting. Skeletons where the shape is known, and determinate progress where the length is known: a spinner standing in for a known wait misleads.
  • Motion. Reduced motion turns movement off; only short opacity fades remain.
Each rule exists to stop a specific misread, not to make the screen prettier. Rationale: design-system skill and token comments

Type

Plate 07 Type ramp
  • H1 40–124px

    Display.

  • H2 34–88px

    Stage voice.

  • H3 22px

    Card heads

  • Title 18px

    Titles

  • Lede 17–19px

    Ledes

  • Body 16px

    Body copy

  • Label 13px

    Labels

  • Chip 11px

    Chips

  • Micro 10px

    Micro

The UI band is closed

  1. 16px
  2. 13px
  3. 11px
  4. 10px
Deep dive The closed band

Specs: H1 fluid 40 to 124px, 600, −0.04em. H2 fluid 34 to 88px, 600, −0.035em. H3 22px, 600. Title 18px, 600. Lede fluid 17 to 19px. Body 16px, 400, 1.5 line height, 60ch measure. Label 13px, 500. Chip 11px, 700, 0.04em. Micro 10px, 600, 0.06em.

No step may be added between 16, 13, 11 and 10. 14 was requested twice and refused; both requests resolved to 13. Its one named use is the pill button label, derived as the label size plus 1px. Display scales with the viewport; the UI band doesn’t, but still honors a 200% system text scale. Chip and micro are shown here at true size.

Display type is fluid for moments; UI type is four fixed sizes, and a fifth was refused. Type tokens
Deep dive Two faces

Funnel Display is for moments. Geist is for everything else.

The mark family

Plate 08 The mark family
The Musterhall monogram on a dark ground: a distressed stencil M with a star beneath it, in green.
M and star, always together.
The monogram in the deeper green drawn for light grounds.
Each ground gets its own green.
Favicon at 64 pixels. Favicon at 48 pixels. Favicon at 32 pixels. Favicon at 16 pixels.
Smaller sizes get simpler cuts.
Stacked lockup on a light ground: the green monogram above the MUSTERHALL stencil wordmark in ink.
Green mark, ink wordmark: one green.
Horizontal lockup on a dark ground: green monogram beside the MUSTERHALL wordmark in light ink.
The horizontal lockup carries the header.
Horizontal lockup in a single ink color on a light ground.
Mono ink once the green is spent.
The glyph can change; the mark still spends a surface’s one identity green. Stencil brand kit
Deep dive Why it looks the way it does

A muster is a military assembly. The name says it: every instructor here passes muster. The register is on-theme for the name, not borrowed style, and two of Musterhall’s founders are veterans. So the military touches are built in: a stencil M with a rally star, a true green that leans military and reads earned, not gamified, brass kept for rank and ceremony, and a plain voice wherever money moves.

Plate 09 Why it looks the way it does
  1. 01 The muster point A green dot before the word: the spot where people assemble.
  2. 02 Explorations Marks off muster, hall and rank, drawn and reviewed side by side.
  3. 03 The crest Heraldry, the most hall-native idea; my own artwork became the emblem.
  4. 04 Stencil M and rally star The military register made literal, and decided.
Deep dive How the mark got here
  • The dot. The first identity rule made the green dot lead the word and named it the muster point: the marked spot where people assemble. Losing green was acceptable in one-color print; losing the dot was not.
  • Explorations. I asked for alternatives that played off muster, hall and military: an assembly point, a chevron that reads as both rank and the hall’s roof, a monogram drawn as a gabled hall. Then I redirected: the dot isn’t mandatory, more range, simplicity first. Every candidate went into one catalog, judged side by side at icon size and at a true 16px.
  • The crest. My brief was a simple shield. Heraldry turned out to be the most hall- and military-native idea, so the work narrowed to the crest family, less intricate, and the crest replaced the dot. My own counterchange artwork, a shield split down the middle with a Pomeranian inverting across it, became the app emblem.
  • The stencil. I supplied the stencil M with a rally star, set beside MUSTERHALL in a stencil face whose bridges match the mark’s cuts. The stencil face is logo-only; the product stays in Funnel Display and Geist. The identity slot and its one-green budget didn’t change, only the glyph. The dog left the mark, not the brand.
  • The green. The old chartreuse sat in the crowded esports lane and read gamified, not earned. It moved to a true green, and brass arrived for what is earned: rank, certificates, ceremony. Rank, when it exists, is a metal ramp from bronze to pewter to gold, the way insignia encode it.
  • The voice. The military register (muster, roll call, standing by, in good standing) is load-bearing brand, but it lives in what you do, not what you buy. Money and destructive controls stay plain: Join, Membership, Cancel.
The mark kept changing; the muster idea and the one-green rule held. Identity kit, stencil identity, naming and voice docs
Deep dive Usage rules

The monogram replaced an earlier crest emblem. The M and the star are one mark and are not separated. The cut follows the displayed size: the textured artwork at 128px and up, a clean cut below 64px with texture off and stencil bridges kept, and an ultra cut at 16px with the bridges sealed. Below a readable wordmark size, the mark goes alone. The ink grammar is fixed: duo is the primary, with dark-ground files on dark grounds and light-ground files on light. Mono ink is the default once a surface has spent its green. Brass and one-color green lockups are for ceremony and single-ink print only, so they are not shown here. The source is still a raster, so large-format and vector jobs wait for a redraw.

Built, checked, and readable by agents

One token source feeds web and Flutter. The design law ships as an agent skill, tokens named for their job, and checks that fail loudly, so engineers and agents make everyday token calls without waiting on me.

Deep dive One source, two platforms
Plate 10 One source, many platforms
  1. Authored once
    • tokens/primitives.json
    • theme/semantic.json
    • tokens/*.json
  2. Built and checked

    build.js

  3. Generated, never hand-edited
    • Web build/css/tokens.css
    • Web build/ts/*.ts
    • Mobile Dart, Flutter package
Deep dive Pipeline detail
tokens/primitives.json
Per-hue OKLCH ramps. Internal only.
theme/semantic.json
App-facing roles, each with a dark and light value.
tokens/*.json
Radius, space, type, motion, layout, state.
build/css/tokens.css
OKLCH verbatim. Light under [data-theme="light"].
build/ts/*.ts
Constants for code that can’t read CSS variables.
Dart, Flutter package
sRGB colors with the OKLCH source as a comment. Themes as a ThemeExtension.
build.js
Style Dictionary, plus an OKLCH to sRGB converter. Tests and a CI check for stale outputs.

The same token, two platforms

tokens.css :root (dark), then [data-theme="light"]
--vert-250: oklch(63% 0.15 142);
--action: var(--vert-250);

--action: var(--vert-375);
Dart the ramp step, then the light action role
/// oklch(63% 0.15 142)
static const vert250 = Color.from(alpha: 1, red: 0.3009, green: 0.6235, blue: 0.2707);

static const action = Color.from(alpha: 1, red: 0.1613, green: 0.4625, blue: 0.1355);

Tokens that can’t cross to Flutter sit on a web-only list, each with a reason. Shadows are on it: mobile is flat by ruling. The emitter throws on an unknown type, so nothing drops silently.

One JSON source builds the web CSS and the Flutter package, so both apps run on the same numbers. Token build

I own the token values. Engineering owns the build and CI. Each app pins its own copy, so a token change lands only when that app re-pins.

Deep dive Docs and checks
Plate 11 Docs that answer, checks that fail

What fails the build

  • Lint Raw hex and token literals
  • Lint Em dashes in product copy
  • Guard test A var(--token) with no real token
  • Guard test A text size off the ramp
  • Catalog test Chart slot 4 turning green
  • Token tests Decided colors drifting
Deep dive The catalog

The lint rejects raw hex, z-index and other token literals in components, and em dashes in product copy. One guard test fails any var(--token) that names a token that doesn’t exist, which the browser would drop silently; another fails any text size off the ratified ramp. A catalog test fails if the neutral chart slot is reverted to green. Token tests pin the decided colors, font stacks and breakpoints. CI fails a change whose generated outputs are stale.

The catalog groups color by role

Identity --muster

Scarce. The mark and the verified badge only, at most once per component. If it is interactive it is --action.

  • --muster #65cd5c
  • --muster-ink #031802
Rules that kept breaking now fail as lint, tests or CI instead of living as reminders. Component library, token repo

The written spec is the source of truth. The Storybook catalog shows each token live, with its rule beside it. I deferred a Figma library on purpose: code is canonical, and a hand-built twin would drift. Reasoning also travels in the emitted CSS. The hover token’s comment:

One ramp step darker than rest; darken only, because lightening collides with --muster (vert-150).

Token work moves in numbered rounds: a written decision, then an emit and tests. Before a round merges, a reviewer on a different model tries to break it, and I check each finding against the source. On rounds 12 and 13 that step corrected citations, narrowed a Flutter claim and recomputed a control-edge figure.

Deep dive Designing a system agents can build with

On Musterhall, agents write most of the code. A design system in a file someone has to remember to open doesn’t survive that. So the design law ships in three forms an agent can use and a machine can check.

  • A skill for design work. Agents load the system as a skill: the non-negotiables, one reference per topic, and links to the sources. Rules are written as instructions, such as “Never hardcode a colour, radius or type value. Consume the tokens by name.”
  • Tokens named for their job. A control edge uses --control-edge and a buy button uses --action. When the name says what it’s for, the right choice is the obvious one, for a person or a model.
  • Checks that fail loudly. A lint rule that runs before every push rejects hardcoded hex colors and raw z-index values. A test catches references to tokens that don’t exist, and a script checks mockups for off-scale spacing, type and color.

So engineers and agents make everyday token decisions without waiting on me. Design acceptance still happens on every ticket. My time goes to the calls a rule can’t make, like a new pattern or an edge case the law doesn’t cover yet.

Non-negotiables come first, then one reference per topic and links to the canonical sources. When skill and spec disagree, the spec wins. It also says how to prove a claim: search the emitted CSS for a token, measure a contrast before quoting it, script cross-file sweeps.

Skills load when the model judges them relevant. One token round ran without it, so the token repo’s guidance now requires it. The wider workflow is in AI-Native Product Workflow.

Deep dive Checked on production Production walks against the verification standard.
Plate 12 Checked on production walks

These are acceptance walks on production, run from written scripts with a phone learner and a web host on test accounts, and signed off by me. They are not research sessions with real users, and that kind of testing is still ahead.

  1. Observed: After the phone rejoined, the host saw “Camera off” while the learner’s camera was on.
    Finding: The state misreported the camera.
    Proposed: An honest-states rule: reconnecting keeps the last frame dimmed with a banner, and “Camera off” means off.
  2. Observed: On the terms screen, the walk checked the button tiers in both themes.
    Finding: One solid button, a bordered neutral Log out, no green border.
    Passed: None needed. The tier rules held on production.
  3. Observed: A walk found secondary buttons still outlined in green.
    Finding: Right about the live state; the fix was already waiting in an open change.
    Process: A walk finding is now checked against open changes before it is filed.
Deep dive How the walks run
  • Each walk follows a written script with pass and fail boxes. A row that couldn’t be run stays open; it is not counted as passed.
  • Every row records what was actually seen, and the build that was walked. A human closes the ticket, not an agent session.
  • A step that the docs and code don’t support is marked unverified. It is walked anyway, and what happened is written down.
  • One more observation: a phone learner couldn’t see the host’s shared screen. It is open as a mobile gap, and the full-screen video brief requires phones to show it.
  • The same brief proposes the next layout: the remote person fills the screen, the self-view floats, and controls stay at the 44 or 48 touch floor.
Production walks test the rules where people will meet them, and what they find changes the system. Walk-evidence records and the verification standard
Deep dive How AI was used
How AI was used

Designing for AI

  • A design system agents can read and machines can check: an agent skill, tokens named for their job, and lint that fails loudly

Designing with AI

  • Claude builds token rounds and screens from my specs. Before a round merges, Grok, a different model, tries to break it, and I check each finding against the source
  • Specs, tickets and reviews run through connected tools: the vault, ClickUp, Slack and GitHub. In Slack, the team runs Git and Vercel tasks through Cursor
The full workflow

Outcome

One visual language across web and mobile, measured, with its open gaps listed.