NOISY Lab · overview

Designers build screens directly in the product, with an agent beside them

Each designer works on their own computer in the Claude Code app. They say what they want; the agent takes the existing NOISY screen as the base, builds variants in the real prototype, captures them on phone and desktop and puts them on the Wall. PM chooses, and developers get a package from the approved version. The rules, the brand and the usage limit are guarded by the system, not by people's memory.

1 task = 1 branch on GitHub Screenshots at 390 and 1440 px for every version 1 design system, checked on every save

What changes

Figma stays for references and approved screens. Variants are built and checked in the product itself.

Figma only
With NOISY Lab
Starting point
The screen is redrawn from an image
The agent takes the existing screen from design-sources/ (approved by PM, the demo, uplay) and changes only what was asked
Variants
Drawn one by one
All at once in the prototype, at one address, with phone and desktop screenshots
Many versions
Drafts scattered across files and chats
Every version is on the Wall: compared side by side, and PM sees what is waiting for a choice
To developers
An image without states or edge cases
A package from the approved version: screenshots, specification, prototype code, design system and who approved it
Brand
Depends on people's memory
Only the design system's colours, fonts and components; checked on every save and on GitHub
Taste and interrupted work
The agent forgets, the chat gets lost
Taste lives in the personal folder; every task is recorded and continues in a new session or another model

What is built in

The brand is protected

Rules, scripts and settings are a protected foundation: a change needs PM approval, and an attempt is blocked automatically. The design system changes inside a task and goes in after approval by one teammate other than the author.

Starts from what exists

Before any change the agent records the foundation: which screen it takes and whether it is TAKE, ADD or REWORK. Before showing, it puts the original next to the new version, and any difference outside the request is a failure.

The limit is protected

A cheaper model for everyday work, variants all at once, no unnecessary screenshots. The stronger model only for the final pass.

Nothing gets lost

Every task is a GitHub branch with a draft pull request and a note with its goal and state. A backup is made after every response, and a mistake is undone with history and restore. Rejected work goes to an archive.

One design system

Colours, fonts and the ready buttons, cards and chips come only from the design system. A check before every save and on GitHub stops drift.

Learns from mistakes

A blocked mistake comes with an exact fix and the agent fixes it itself. A repeated mistake becomes a proposal for a new rule or check.

Away from the AI template

The agent knows the NOISY product and look, writes a brief with real content before building, and the Impeccable detector looks for over 60 signs of the AI template in every change. Average is not "done".

The agent knows who is working

It recognises the person by the Git email on the computer and loads their taste. It also works if all designers share one account.

Verified

The checks are automatic and run on GitHub and on the computer.

PRevery pull request goes through checks: design system, tests and a prototype build
E2Enpm run qa:flow: an agent walks the whole designer path in a clean copy, from a new task to the Wall
390npm run qa:wall: the Wall at 390 and 1440 px, with no overflow, broken screenshots or console errors
hooksthe foundation protection has its own tests (npm run test:guards)

What we need from management

The system works. These decisions set how smoothly it runs.

Decision

Seat type in Claude Team

Standard: $25 per month ($20 billed annually), about 1.25 times the Pro limit. Premium: $125 ($100 annually), 6.25 times. For daily work with the agent Standard will likely run out; an option is Standard with extra credits and a spending cap. US prices, excluding tax.

Decision

A seat for each or a shared account

A seat for each is recommended: their own limit, and in line with Anthropic's terms. A shared account works as a fallback, but the limit runs out for everyone at once.

Needed

A paid GitHub plan

The repository is private. A required pull request with green checks on the main branch needs a paid plan; until then the local hooks and the pull request checks work, but a deliberate bypass remains possible.

Needed

Company email sign-in on Cloudflare

The shared Wall and the previews are on Cloudflare Pages and open for anyone with the address. Restricting them to company emails (Cloudflare Access) needs a payment card on the account, even on the free plan.

Needed

A Full or Dev seat in Figma

With such a seat the agent reads Figma up to 200 times a day. With View or Collab it is only 20 times a month.

Needed

A Mobbin plan

Pro, Team or Enterprise for examples from other apps. Without it the agent works, just without them.

How it works day to day: the For designers tab. How it is built and where the code is: the In depth tab.

NOISY Lab · for designers

You say what you want. You choose. The agent does the rest.

You do not need to know Git or commands. You write to the agent in the Claude Code app the way you write to a colleague. Designers write in Bulgarian; the phrases below are shown as typed, with an English gloss.

1 session = 1 task Variants at 390 and 1440 px You install only Claude

The first time

Once per computer. You install only the Claude app; the agent downloads everything else itself. After that it remembers you.

  1. Install the Claude appyou

    From claude.ai/download, with the company account. You install nothing else.

  2. Get the project folderyou

    You clone the shared repository from GitHub; PM gives you the address. If you do not have GitHub yet, PM gives you a copy of the folder.

  3. Open it and type „нов съм“ (I'm new)you

    The Code tab, choose the folder. Any other message works too, for example „здрасти“ (hi). Answer "yes" to the app's questions (trusted folder, Figma, Mobbin).

  4. Downloads what is missingthe agent

    Git (keeps every version), Node.js (runs the prototype and the checks), Google Chrome (captures the screens) and the prototype packages. A few minutes, no password. If the Mac shows an "Install Command Line Developer Tools" window, click Install. If the agent asks, close and reopen the app once.

  5. Three questions and you are setthe agent

    Name, role, zones. The agent creates your personal folder and checks that everything works.

Every day

A new session for every task. Here is what you can type; the button copies the sentence.

Variants · make 3 Arena variants for phoneНаправи 3 варианта на Arena за телефон.
From Figma · build this from this frameНаправи това по този фрейм: [линк към конкретен фрейм]
To see it · show it on phone and desktopПокажи ми го на телефон и на десктоп.
Choice · we keep B, remove the othersОставяме Б, махни другите.
Correction · the title is too big, the cards are clutteredЗаглавието е твърде голямо, картите са претрупани.
Continue · continue the theatre-search taskПродължи задачата theatre-search.
Save · save this versionЗапази тази версия.
The Wall · show me the WallПокажи ми Стената.
Approval · I approve Maria's design systemОдобрявам дизайн системата на Мария.
Hand-off · it is done, send B for approvalГотово е, пусни Б за одобрение.

What the agent can do

Ready-made skills. You do not call them by name: you write in plain words and the agent picks the right one.

SkillWhat it is forType, for example
designEvery design task: a new screen, a change, variants, a fix. Keeps the work inside the design system and shows no result without the checks.„Направи екрана за класиране в Arena.“ (make the Arena standings screen)
clone-referenceCloning from a reference: a Figma frame, a Mobbin screen, a site or a photo. Measures the original, builds it with NOISY components and shows them side by side.„Направи го 1:1 като този фрейм: [линк].“ (make it 1:1 like this frame)
noisy-reviewA strict review before showing or handing over: design system, brand, copy, accessibility, signs of AI.„Готово ли е за програмистите?“ (is it ready for developers?)
ImpeccableThe finishing commands and the vocabulary against the generic AI look.„Направи critique на екрана.“ „По-смело.“ „По-спокойно.“ „Опрости го.“ (critique, bolder, calmer, simplify)
spec-builderHelps PM describe a screen with cases and criteria (for PM).„Нова спецификация за Arena.“ (new Arena specification)
onboardingCreates your profile on first start.„Нов съм.“ (I'm new)
team-setupConnects the project to GitHub and runs the acceptance test (for PM, once).„Свържи с GitHub.“ (connect to GitHub)
review-design-mdA section-by-section review of the design rules.„Да прегледаме DESIGN.md.“ (let's review DESIGN.md)
skill-builderYour own personal skill for something you do often.„Повтарям това често, направи ми умение.“ (I repeat this often, make me a skill)
FigmaReads a specific frame and brings it into the prototype.„Направи това по този фрейм: [линк].“ (build this from this frame)
MobbinFinds real screens from published apps.„Покажи ми 6 примера за търсене в стрийминг приложение.“ (show me 6 search examples in a streaming app)

The frontend-design plugin is only for marketing and landing pages, not for product screens. Cloning means: structure, spacing and layout come from the reference, while colours, fonts, logo and components are NOISY's. Third-party logos, photos and copy do not go in.

Mobbin

A library of over 600,000 screens and flows (sign-up, payment, search) from real published phone and web apps. The agent searches it by meaning.

What for

Before a new screen you see how others solve the same thing: filters, a player, a live match, a subscription. The agent shows 6 examples, you choose, it records the choice in your taste and builds the solution with NOISY components.

What you need

A paid Mobbin plan; PM arranges the company one. Without it the agent works normally, just without Mobbin examples.

Connecting, once

Type /mcp, choose mobbin, then Authenticate. Sign in to your Mobbin account in the browser. mobbin then shows as connected. Figma connects the same way.

Examples · show me 6 examples of filters in a streaming catalogueПокажи ми 6 примера за филтри в стрийминг каталог.
Choice · I like the second one, save it to my taste because the cards are largeХаресва ми вторият, запиши го във вкуса ми, защото картите са едри.
From an example · build the screen from this Mobbin exampleНаправи екрана по този пример от Mobbin.
Check · is Mobbin connected?Свързан ли е Mobbin?

Every search uses the limit, so ask precisely and in one go. Mobbin screenshots expire after 30 days, so the agent keeps the link and why you like it.

Your personal folder

designers/[your-name]/ in the project's main folder. The agent creates it on „нов съм“ (I'm new). The whole team can see it, so no passwords or private things.

WhatWhereHow you add itHow you get it back
Profile: role, zones, emailprofile.mdThe agent writes it on „нов съм“ (I'm new)„Покажи ми профила ми.“ (show me my profile)
Taste: likes, dislikes, decisionstaste/taste.mdSay it in the chat; the agent records it after your "yes"„Какво знаеш за вкуса ми?“ (what do you know about my taste?)
Reference imagestaste/Drop the image in the chat: „запиши я като референция, харесвам ...“ (save it as a reference, I like ...)„Покажи референциите ми за Arena.“ (show my Arena references)
Opinions on a tasklearnings/[task].mdThe agent records your short answers„Какво казах за theatre-search?“ (what did I say about theatre-search?)
Proposals for the systemproposals/„Предлагам нов вид чип за ...“ (I propose a new chip type for ...)„Покажи моите предложения.“ (show my proposals)
Personal skillsskills/„Направи ми умение за ...“ (make me a skill for ...)„Какви умения имам?“ (what skills do I have?)
Your DESIGN.md reviewreviews/design-md.md„Да прегледаме DESIGN.md.“ (let's review DESIGN.md)„Какво отговорих за цветовете?“ (what did I answer about colours?)

The work itself is not in the personal folder: every task has its own branch and a note with its state, and the code is in prototype/. Ask „Покажи задачите ми.“ (show my tasks) or „Докъде сме с theatre-search?“ (where are we with theatre-search?).

Where everything else lives

WhatWhereType, for example
Colours, fonts, logo, zone marksdesign-system/„Дай ми цветовете на NOISY с кодовете.“ (give me the NOISY colours with codes) „Къде е логото в SVG за тъмен фон?“ (where is the SVG logo for a dark background?)
Ready componentsdesign-system/COMPONENTS.md„Какви карти имаме?“ (what cards do we have?)
The look and the restrictionsDESIGN.md„Какви са правилата за сенки?“ (what are the shadow rules?)
The product: zones, plans, pricesPRODUCT.md„Колко струва Together?“ (how much is Together?)
Interface copydocs/COPY.md„Как пишем бутоните?“ (how do we write buttons?)
Screen specificationsspecs/[zone]/[screen].md„Какво пише в спецификацията на Theater Browse?“ (what does the Theater Browse spec say?)
Decisions and open questionsdecisions/DECISIONS.md„Какво е решено за Theater?“ (what has been decided for Theater?)
NOISY's own imagesprototype/public/media/„Добави този постер в медиите, източник: [откъде е].“ (add this poster to media, source: ...)

What goes where

  • References and images for taste: in the chat or in taste/.
  • A Figma link: in the chat, to a specific frame.
  • A NOISY image of your own: in the chat with its source; the agent puts it in media.

What you do not add

  • A new colour, component or rule directly: say „предлагам ...“ (I propose ...), PM decides.
  • AI images, third-party logos and third-party design.
  • Passwords and confidential data.

What you get

The variants are at one address. You switch with ?v=a, ?v=b, ?v=c at the end of the address.

The Wall and a preview link

Every variant is a version on the Wall: the local one is ready at once, the shared one after 3-5 minutes. You switch the variant with ?v= at the end of the address.

Phone and desktop screenshots

At 390 and 1440 px, with a note if something overflows the screen.

What differs from what

A short label on every variant, so you can choose quickly.

When you choose, the other variants go to the archive. Nothing is deleted.

The preview opens inside the app, in the Browser panel (Cmd+Shift+B), and you can click around in it. Archive the session only after "done": the agent saves the work after every stage, and unsaved work is lost on archiving.

How the agent learns your taste

From real work, without surveys. Nothing becomes a rule without your "yes".

1 · question

Sometimes it asks

One short question, for example „Какво не ти хареса в Б?“ (what didn't you like in B?). You can skip it.

2 · note

Records what was said

In the task notes, in your personal folder.

3 · repetition

Notices a pattern

When something repeats, it proposes making it a rule.

4 · rule

Asks you

After "yes" the rule goes into your personal taste and applies to every following task.

Want it faster? Give references straight away: „Харесвам как изглежда [сайт], защото ...“ (I like how [site] looks, because ...).

The limit and the rules

The agent saves usage on its own. These three habits help the most.

New task, new session

A long old conversation costs more than a new one. The task is recorded, you lose nothing.

A specific frame

A link to one Figma frame, not to the whole file.

Corrections in one go

All remarks in one message, not one word at a time.

The agent uses only

  • The colours, fonts and logo from the NOISY design system.
  • NOISY images and materials, with no AI images or third-party design.
  • If something is missing, say „предлагам ...“ (I propose ...). PM decides.

The agent never

  • Changes the design system without approval.
  • Deletes files or merges someone else's work.
  • Publishes anything to production.

If something does not work

First type „провери компютъра“ (check the computer) to the agent. It finds the problem and usually fixes it itself.

You seeWhat you do
The agent asks „Кой си?“ (who are you?) every timeSay "yes" when it offers to set the Git email on the computer.
„Тази промяна иска одобрение от PM“ (this change needs PM approval)You are touching the protected foundation. The agent will make a proposal instead.
The preview does not open„Пусни прегледа отново.“ (start the preview again)
Figma does not respondType /mcp, choose figma and sign in with your Figma account.
Everything is slow or the limit is running outType /usage. It shows what uses the limit.
The limit has run outThe task is recorded. It continues tomorrow from the same place.

NOISY Lab · in depth

How the system is built

The project is one Git folder with the rules, the design system, the prototype, the versions and the personal folders. The agent (Claude Code in the app, Codex or another) reads AGENTS.md, recognises the person by the Git email on the computer and gives every task its own branch. Scripts and hooks guard the foundation, the limit and other people's work mechanically, without relying on the agent remembering the rule. Here a developer finds where the code is, how to run it and where to get the approved design.

5 zones: Discover, Theater, Arena, Newsroom, Showtime 9 agent skills 6 version statuses 2 account modes

File structure

What is at the root of the repository and who uses it. Purple is the protected foundation: it changes only with PM approval.

noisy-lab/
├── AGENTS.md  CLAUDE.md   the rules for the agent; CLAUDE.md points to AGENTS.md (agent)
├── .claude/  .codex/     settings, hooks and status bar for Claude Code and for Codex (agent)
├── .agents/skills/       agent skills; .claude/skills is a link to them (agent)
├── .mcp.json             connection to Figma and Mobbin (agent)
├── .impeccable/          settings of the AI template detector (agent)
├── .github/              workflows, the team, CODEOWNERS, pull request template (PM, developer)
├── scripts/              tasks, versions, the Wall, checks, hooks (agent, PM, developer)
├── PRODUCT.md            what NOISY is: confirmed facts (agent, PM)
├── docs/                 guides, system specifications, COPY.md with the interface copy (everyone)
├── DESIGN.md             the look and the restrictions; the YAML block is generated from tokens.css (designer, agent)
├── design-system/        tokens, components, brand (designer, developer, agent)
├── design-sources/       registry of existing screens and their screenshots: the design foundation (agent, designer)
├── prototype/            the Next.js prototype (developer, designer, agent)
├── specs/                screen specifications with cases С1, С2 (PM, developer, QA)
├── versions/             saved versions with screenshots and history (PM, developer)
├── tasks/                a note for every task: goal, done, remaining (agent)
├── designers/  pm/       personal folders: profile, taste, lessons, skills (the person themselves)
├── decisions/            decisions and open questions (PM)
├── tests/                motion check in the Theater demo (developer)
├── archive/              rejected variants and outdated material, nothing is deleted (agent)
├── package.json          npm test, npm run qa:flow, npm run qa:wall (developer)
├── vercel.json           old build config for the prototype; previews run on Cloudflare Pages
├── TASK-HANDOFF.md  ZA-ZHORKATA.md  notes for the pilot and for a trial folder
└── README.md             entry point: who reads what and how to run the prototype

One level deeper

PathWhat is thereWho uses it
prototype/app/The pages: theatre/, atlas/, board/, lab/, design-system/developer, designer
prototype/components/, prototype/lib/The components, data and logic of the screensdeveloper, agent
prototype/sections/theatre/Sections in versions v1.tsx, v2.tsx for the /lab/ pagedesigner, agent
prototype/public/demo/app/The app demo (home, Arena, match, player, subscription): the 1:1 foundation for the screensagent, designer
design-system/tokens.css, components.cssColours, fonts, spacing and the ready components; the prototype loads them directlyeveryone
design-system/COMPONENTS.md, brand/The component catalogue; the logo and zone marks as SVGdesigner, developer
design-sources/screens.jsonWhere each screen is in the three sources, with search names; snimki/ holds the screenshots at 390 and 1440 pxagent, designer
scripts/hooks/The guards and automatic actions of the agent and of Gitdeveloper, PM
scripts/qa/, scripts/tests/The flow and Wall checks; the script testsdeveloper
.github/workflows/checks.yml, odobrenie.yml, pregled.yml, pregled-deploy.yml, stena.yml, lichno.yml, design-md-izvestie.ymldeveloper, PM
.github/team.jsonWho is PM and who can approve, by Git emailPM
versions/<screen>/<version>/meta.json and the version's screenshotsPM, developer
docs/FOR-DEV.mdThe list of approved screens for developersdeveloper
docs/GUIDE.md, docs/SYSTEM.md, docs/TEAM-SETUP.mdHow to work, how it is built, how to set up a new computerdesigner, PM, developer

Glossary of Bulgarian names

The team speaks Bulgarian, so some folders, workflows and data values have Bulgarian names (transliterated or in Cyrillic). They stay as they are because scripts, links and history point to them. Full list in docs/GLOSSARY.md. Older commit messages are partly in Bulgarian; history is not rewritten, and since 11.11.2026 a hook keeps new commit messages in English.

NameLiterallyMeaning here
stena, „Стената“the wallThe Wall: the team board with every version of every screen (stena-*.mjs, workflow stena.yml “Team Wall”)
osnovabaseBase: the screen before any change; version id versions/<screen>/osnova/
snimkiphotosScreenshots of source screens: design-sources/snimki/
pregled, pregled-deployreview / previewThe Preview link workflow and its deploy step
odobrenieapprovalThe Design system approval workflow
lichnopersonalThe Personal folder workflow (profile and taste)
izvestienoticeNotice to the team when DESIGN.md or the design system changes
ZA-ZHORKATA.mdfor ZhorkataNotes for Zhorkata (a teammate’s nickname)
чернова · за-одобрение · одобрено · върнато · архив · в-разработка · готовоstatusesdraft · waiting for PM · approved · returned · archived · in development · done
Approved-by: (older: Одобрено-от:)approved byCommit line naming the PM who approves a foundation change
НЛ27 · Р17 · С1decision · decision · caseDecision numbers (НЛ = NOISY Lab, Р = решение) and spec cases (С = случай)
ВЗЕМИ / ДОБАВИ / ПРЕРАБОТИtake / add / reworkThe three design paths: copy the source 1:1, add to it, redesign

The prototype: where the code is and how to run it

The prototype is Next.js 15 with React 19, a static export and sample data. It is not NOISY's production code and has no connection to live data; the developer takes the layout, states, motion and behaviour from it.

Running it locally

In the project's main folder, with Node.js 22 or newer:

sh scripts/setup.sh
npm --prefix prototype ci
npm --prefix prototype run dev

Open http://localhost:3210. npm run dev from the root does the same. Build: npm --prefix prototype run build.

Addresses inside

  • /atlas/: every component on its own page, with states and where it is used; the zone flows.
  • /design-system/: the tokens and components, generated from design-system/.
  • /lab/: screens assembled from sections; each section's version is switched from the panel.
  • /board/: a draft of the Wall with the local versions.

Switches

  • ?v=a, ?v=b: a screen variant.
  • ?data=demo, today, future, edge: data mode. edge shows missing metadata, long text and slow loading.

Packages are installed with npm ci only in the main folder. Task working folders link to them from there, and guard-foundation refuses npm ci, install, update and uninstall through a link, because otherwise npm deletes the packages in the main folder too. The Claude Code app starts the preview with .claude/launch.json on port 3220.

The data is a snapshot: the "schedule, recording, catalogue" chain in Theater is a hypothesis until the technical team confirms it. There is no real EPG, payment or TV navigation.

The path of a task

From a new session to review. Purple is the person's work, grey is the agent's.

New session "Make 3 variants of …" Who the person is whoami: Git email → profile Task task.mjs start: branch, draft PR Foundation TAKE / ADD / REWORK Variants ?v=a, b, c in the prototype Show me screenshots 390 and 1440, Wall Choice the others → archive/ Review for approval, PM chooses A correction returns to "Variants". Limit used up: the task continues with continue in a new session or in Codex.

  1. New sessionthe person

    The designer opens a new session in the app's Code tab and writes what they want. Each session lives in its own folder .claude/worktrees/<name>/, so two sessions never touch the same files.

  2. Who the person isthe agent

    node scripts/design-task.mjs whoami reads the Git email on the computer and finds the profile. The agent says in one sentence which profile it loads, and loads that person's taste.

  3. Taskthe agent

    node scripts/task.mjs start "<task>" creates a task/<person>/<task> branch, a tasks/<task>/<person>.md note (goal, done, remaining, decisions), a draft pull request and a preview link. Unsaved work is carried over and the prototype packages are linked. Only task.mjs creates task branches.

  4. Foundationthe agent

    start records the source screen from design-sources/. If the record is missing or the person names another screen, the agent runs node scripts/design-source.mjs. The first line of the brief is „Основа: <screen>, <frame date>, path, changing only: <list>“ (Foundation: ...). In depth: The design foundation.

  5. Variantsthe agent

    First it locks what stays the same (specification, tokens, content), then builds all variants in one turn, on one screen, with a ?v= switch and a short label saying what differs.

  6. Show methe agent

    node scripts/task.mjs show --screen <zone>-<screen> --url <local-url> --variants a,b saves the work, captures every variant at 390 and 1440 px with shot.mjs (also checking horizontal overflow), creates a Wall version for each variant and prints the links. The agent opens the local Wall in the Browser panel and gives the link to the shared one.

  7. Choicethe person

    The designer chooses or gives a correction. On „избирам Б“ (I choose B) the other variants go to archive/<task>/ with the reason in the note, so the developer does not inherit dead code, while their screenshots stay on the Wall.

  8. Savingthe agent

    After every response there is a hidden backup, which reaches GitHub at least every 30 minutes. A task stage is saved with task.mjs save, and what was said about taste goes to the personal folder with save-personal.

  9. ReviewPM

    On "done" the version becomes "for approval" and task.mjs review hands the work over. PM looks at the Wall, compares and chooses. PM merges the pull request with gh pr merge --merge (no squash: versions point to the exact commit).

  10. Hand-offPM

    The approved screen goes into docs/FOR-DEV.md, and design-version.mjs handoff builds the package for developers. In depth: From version to implementation.

The design foundation

The agent does not draw from scratch. "Make X" means "find the approved piece X sits on, and build X on top of it".

Three sources

  • Approved by PM: the latest approved version on the Wall or in Figma, on the For DEV page.
  • The demo in prototype/public/demo/app/: our prototype of the app.
  • uplay: the developers' live build, at uplay.noisy.net.

The order is as listed. Figma For DEV with „непотвърдена ревизия“ (unconfirmed revision) is only a helper. The name For DEV is not an approval.

The registry

design-sources/screens.json describes every screen, its search names and where it is in each source. Screenshots at 390 and 1440 px, page.html and styles.json are in design-sources/snimki/. The frame date is in snapshotAt; over 24 hours or a missing frame means a new screenshot before work.

The Wall's foundation

node scripts/import-foundation.mjs cuts the existing screens into elements (header, hero, rows, cards) and records one "osnova" (foundation) version per element. So the Wall starts with the real look of the product, and new versions are compared against it.

PathWhenWhat the agent does
TAKE (ВЗЕМИ)By defaultCopies the existing screen 1:1 and changes only what was asked.
ADD (ДОБАВИ)A new element in an existing screenThe same foundation plus the element in the language of the neighbouring screens; reviews 2-3 neighbouring screens as an atlas.
REWORK (ПРЕРАБОТИ)Only with an explicit „не ползвай съществуващия екран за <екран>“ (don't use the existing screen for ...) recorded in the taskA new design from scratch. The word „нов“ (new) alone is not enough.

Before showing, the agent runs node scripts/check-new-values.mjs (a new value outside the tokens) and node scripts/side-by-side.mjs --diff: the original next to the new version at 390 and 1440 px, where the difference outside the allowed zone must be 0. Three failed rounds in a row stop the fixing, and the agent reports what is left. node scripts/overlap-check.mjs checks that new elements do not cover text or controls of the foundation.

Versions and the Wall

Every saved draft is a version: a frozen card with screenshots at 390 and 1440 px, the exact commit, author, note, status and history. All versions are on the Wall, one row per screen, like a canvas.

Local Wall

Ready at once on the designer's computer, with unsaved versions. node scripts/stena-live.mjs <screen>/<version> builds it and prints the path. Only visible on that computer.

Shared Wall

Address: https://noisy-designlab.pages.dev. Every screen has a /e/<screen>/ page, and #<version> points to the exact version. It appears within 3-5 minutes of pushing to GitHub, and an open Wall checks every 10 seconds and offers "Show" when a new version arrives.

How it is published

GitHub Actions: pregled.yml builds the prototype without secrets, pregled-deploy.yml uploads it to Cloudflare Pages without running task code, and stena.yml builds the Wall with the generator from main and the versions from all branches.

What the statuses mean

StatusMeaningWho sets it
чернова (draft)A saved version nobody has sent for a choice yet.the agent, on save
за-одобрение (for approval)Waiting for PM's choice.the designer („прати я на PM“, „готово“: send it to PM, done)
одобрено (approved)PM chose exactly this version. Never automatic.PM only; the script and commit-msg check it by Git email
в-разработка (in development)A developer has taken the version. Requires prior approval.the developer
готово (done)The implementation is finished and QA has passed every case from the package README.QA
върнато (returned)Work goes back to design from any stage, with a note why. Removes the approval.PM or the developer (a question to the designer)

The order is чернова, за-одобрение, одобрено, в-разработка, готово; no step is skipped. Every transition (who, when, note) is in the version's meta.json. "Approved" on the Wall is PM's design choice; merging the pull request on GitHub is accepting the code. For each screen, "Selected" is only the latest approval; other approved versions stay visible as "superseded". Description: docs/VERSIONS.md.

From version to implementation

Where the developer gets the design to implement: version, Wall, FOR-DEV, package.

  1. Find the approved screendeveloper

    Open docs/FOR-DEV.md (generated with design-version.mjs index, containing only what PM approved) or the "For DEV" filter on the shared Wall. If the list is empty, there is no approved screen yet.

  2. See the version on the Walldeveloper

    The screen page /e/<screen>/ shows the screenshots at 390 and 1440 px, the author, note, status and history. "Open" leads to the live prototype version, and "Copy link" gives the address of the exact version.

  3. Get the packagedeveloper

    node scripts/design-version.mjs handoff <screen>/<version> creates a folder in handoff/ and a zip. It works only for approved versions, and the code comes from the approved commit, not today's main. The handoff/ folder is not committed to Git: it is sent to the developer.

  4. Implementdeveloper

    Read the package README.md: who approved it and when, the exact commit, and "What the screen must do" (the cases and criteria from the specification). Layout, states and motion are in source/prototype/; colours and fonts only from source/design-system/. Production code, live data and integrations are your work.

  5. Answer or returndeveloper

    "In development" at the start. A question to the designer is върнато (returned) with a note: it goes back to the designer and removes the approval, and the designer makes a new version that PM approves again. QA sets "done".

What is in the package

  • README.md: approver, date, commit, behaviour, how to ask a question
  • SPEC.md: the specification at the moment of approval
  • the screenshots at 390 and 1440 px, approved by PM
  • source/prototype/: app, components, lib, data
  • source/design-system/: tokens and components
  • meta.json: the version history

How to run the approved version

From the full repository, at the approved commit: npm --prefix prototype ci, then npm --prefix prototype run dev. The task's preview address shows the latest state of the branch, which may differ from the approved one.

Who the person is

The agent recognises the person by the computer, not by the Claude or GitHub account. That is why it also works with a shared account.

  1. whoami at the start of the session

    node scripts/design-task.mjs whoami reads git config user.email.

  2. Searches the main folder

    It looks for the - Git имейл: (Git email) line in every profile.md in the main folder (the first one from git worktree list), not in the session folder. So a new session sees the profile even if it was created a minute ago.

  3. Returns the matches

    Name, role, personal folder (personalDir) and the ready save command (savePersonal).

  4. Decides

    One match: it says which profile it loads and continues. Zero or several: it asks „Кой си?“ (who are you?) once. No profile: the onboarding skill with its questions. If the person changes in the same session, it loads the new profile and carries nothing over from the previous one.

Who did what

  • Every commit carries the computer's name and email, and the task/<person>/<task> branch says whose task it is.
  • A pull request is opened from the person's account; with a shared account the author is written in the template.
  • The Git email can be set by hand, so the reliable check is the review before merging.

Which is the latest design

  • What is accepted is in main; open pull requests are work in progress.
  • On the Wall, "Selected" is the latest approval for the screen.
  • The agent records why a variant was chosen in the task note itself, so the next session or another model knows it.

Personal data

The personal folder lives in the project's main folder, because every new session starts from main and sees only what is saved there.

What is in it

  • profile.md: name, role, zones, Git email
  • taste/taste.md: a short taste summary, read every time
  • learnings/<task>.md: notes from real work
  • lessons/: lessons about workflow mistakes
  • skills/: personal skills
  • proposals/: proposals for the shared foundation

What loads every time

  • The profile and taste.md
  • The descriptions of personal skills
  • Only the current task's learnings/
  • Old journals only if the person mentions them, so the context does not grow

save-personal

After every change in the personal folder the agent runs the command from whoami. It saves only the personal folder as a commit to main, whichever branch it is run from; other unsaved changes are not touched.

With a shared repository

The same commit goes to a personal/<role>/<folder> branch and the script opens a pull request with gh, so the protection of main is not bypassed. If the folder was cloned from someone's copy, origin points to their working folder and nothing is pushed; doctor reports it.

One task, one working folder

All task commands are in scripts/task.mjs (--help describes them). The agent runs them itself; the person does not type them.

CommandWhat it does
start "<task>" --goal "<goal>"A new task: a branch from the latest main, a note, a draft pull request, a preview link. Carries over unsaved work and links the packages.
show --screen ... --url ... --variants a,b"Show me" in one command: save, screenshots, Wall versions, links.
save "<note>"Saves a stage and pushes it to GitHub.
list, list --allAll of the team's tasks; who is working, on what and with what goal.
continue <task>Continues your own task or takes over a colleague's task on a new branch, without touching theirs. Then update.
updateBrings the team's accepted changes into the task. On a conflict it stops so a person can choose.
history, restore <number|version>Restore points, and restoring the whole work, selected paths or a screen from the Wall. A restore is a new step and can itself be undone.
checkpoint, autosaveAn intermediate save at the end of the session; a hidden backup after every response.
reviewHands over for review. Refuses "done" if the screenshots are older than the latest change.

The registry and locking

Tasks live on GitHub: a branch and a draft pull request from the first minute, so everyone sees the others' work. Two people creating a task at the same time do not collide: the second waits for the lock.

Why packages are a link

npm ci for every session costs minutes and hundreds of MB. The link to the main folder is safe as long as nobody runs npm ci through it. That is why the guard refuses it, and scripts/lib/link-deps.mjs links only when the lock files match.

How the agent learns taste

What it does

  • After a variant, a rejection or a hand-off it may ask one short question about what was shown, at most one per stage.
  • It records only what was actually said in learnings/<task>.md.
  • On repetition it proposes a short line in taste/taste.md and applies it after "yes".

What it does not do

  • It does not stop work if the person does not answer.
  • It does not make a rule from a single answer.
  • Personal rules do not override shared ones: the brand and the design system rank above taste.

scripts/hooks/learn-capture.mjs recognises corrections such as „не така“ (not like that) and „не ми харесва“ (I don't like it) and reminds the agent to fix the work and record the lesson. A weekly report of friction points: node scripts/learnings-digest.mjs.

Saving the limit

Designers do not track tokens, so the system does.

MechanismWhere
Sonnet by default; automatic conversation compaction at 250,000 tokens.claude/settings.json
A bar at the bottom with the conversation size: green, yellow (new topic = new session), red (save and open a new session)scripts/statusline.mjs
Reading node_modules, .next and package-lock.json is forbidden.claude/settings.json
No automatic check in the Browser panel after every edit.claude/launch.json
Variants in one go, screenshots only for the result, no subagents without an explicit requestAGENTS.md
Only taste.md and the current task's learnings/ are readAGENTS.md
Opus only for the final pass or after two rejections, in a new session with a saved noteAGENTS.md

On „лимитът свършва“ (the limit is running out) or „всичко е бавно“ (everything is slow), /usage shows what uses it.

Skills

Nine skills in .agents/skills/; Claude sees them through the .claude/skills link, Codex reads them directly. The designer does not call them by name.

SkillWhat it is for
designThe entry point for every design task: foundation, TAKE/ADD/REWORK, variants, checks and self-correction from screenshots.
clone-referenceRecreates a screen from a reference (Figma frame, Mobbin, a site) with NOISY components and tokens: measures, builds and compares side by side.
noisy-reviewA strict review before showing or handing over: design system, AI template, brand, copy, accessibility, states.
impeccableThe AI template detector and the finishing commands (polish, clarify, adapt and others).
onboardingA new person's profile on first start, or when whoami does not find the Git email.
review-design-mdWalks a designer through DESIGN.md section by section and collects the reviews.
skill-builderCreates or improves a personal skill; shared skills go through a proposal.
spec-builderHelps PM write a screen specification following specs/TEMPLATE.md.
team-setupConnects the project to the shared repository, turns on review, protects the foundation and runs the acceptance test. Run by PM, once.

The frontend-design plugin is enabled in .claude/settings.json, but only for marketing and landing pages. It is forbidden for product screens.

One design system, automatic checks, lessons

The single source

The prototype loads design-system/tokens.css and components.css directly. Colours only var(--...), fonts only var(--font-body) (Manrope) and var(--font-head) (Unbounded), font sizes only from the --t-* scale.

Existing components 1:1

If the button, card or chip exists, the agent uses it exactly as is. In the prototype it changes only position and width. A different look goes through a design system change.

The live page

/design-system/ in the prototype is generated from the tokens and components with node scripts/ds-catalog.mjs: a new colour or button shows there at once, as a draft on the designer's computer.

Mobbin for examples

The agent searches real screens from published apps, 6 at a time. They show how others solve the problem; the solution uses NOISY components.

WhenCheckWhere
Before every commitThe design system in the staged files: colours, fonts, sizes, overridden components. A failure blocks and gives an exact fix.scripts/hooks/pre-commit, scripts/check-design.mjs
Before every commitA change to the protected foundation needs an „Одобрено-от: <PM name>“ (Approved-by) line.scripts/hooks/commit-msg
Every pull request and mainDesign system, all tests, a prototype build..github/workflows/checks.yml
Before showingNew values against main; the original next to the new version; overlapping elements.check-new-values.mjs, side-by-side.mjs, overlap-check.mjs
Every change to DESIGN.mdDESIGN.md matches tokens.css.node scripts/design-md.mjs --check

  1. Self-correction

    A blocked save says exactly what to fix and how. The agent does it itself, and bypassing the check is forbidden (git commit --no-verify and changing core.hooksPath are refused).

  2. Lesson

    When a person corrects an agent's workflow mistake, it becomes a lesson in the personal folder (lessons.mjs add). Every blocked commit is written to the computer's log.

  3. Rule or check

    node scripts/lessons.mjs report collects everyone's lessons. A mistake repeated twice becomes a proposal for a new rule or automated check; PM decides, and lessons.mjs done closes it.

Quality design: no AI template

Without rules the agent produces the average interface from the internet: purple gradients, identical cards with icons, centred layouts. Five layers stop it.

LayerWhat it is forWhere
The product truthWhat NOISY is, who it is for and which facts are confirmed; the agent does not invent.PRODUCT.md
Direction and restrictionsTokens in YAML and rules: hierarchy, rhythm, zones, a list of AI template signs.DESIGN.md (the YAML block is generated with design-md.mjs)
WorkflowFoundation, a brief with real content, existing components, all states, checks before showing..agents/skills/design/
DetectorImpeccable: over 60 generic patterns and UX mistakes; a hook after every edit and a full check at the end of the turn..agents/skills/impeccable/, .claude/settings.json, .codex/hooks.json, .impeccable/config.json
ReferencesMeasures the reference, reduces it to tokens and compares side by side.clone-reference, scripts/measure-ref.mjs, scripts/side-by-side.mjs

noisy-review runs before hand-off. Impeccable is updated only with approval, by copying a new version into .agents/skills/impeccable/. States, consistency between screens and recovery after an error are checked on every screen: what an empty list, a lost connection or a failed payment looks like.

Approval

Two kinds of choice that must not be confused: the design choice on the Wall, and accepting a change to the design system.

A screen's design

PM chooses a version on the Wall (status одобрено, approved). Only PM can set it: the script recognises PM by the Git email in .github/team.json. PM merges other tasks on GitHub when they are "Ready for review".

The design system

Mandatory approval applies only to design-system/ and DESIGN.md: one teammate other than the author ("approval": "any" in .github/team.json). They run node scripts/ds-approve.mjs <task> from their own folder. The approval is valid only for the current commit, and a new change needs a new one.

How the person is recognised

Designers use a shared GitHub account, so GitHub Reviews cannot tell people apart. Identity is the Git email from the approver's own folder, recorded in .github/team.json. The branch author, whoever opened the pull request and the commit authors cannot approve.

The rest

odobrenie.yml counts the approvals in a pull request. When DESIGN.md or design-system/ changes, design-md-izvestie.yml requests review from the other designers and comments which sections changed. lichno.yml merges a pull request from personal/ if all files are in the author's personal folder.

Protection

The protected foundation is PRODUCT.md, docs/COPY.md, AGENTS.md, CLAUDE.md, .claude/, .agents/, .github/, .impeccable/, .codex/, .mcp.json, scripts/ and .gitignore. design-system/ is protected outside a task and open inside one; its acceptance is described above.

GuardWhen it runsWhat it blocks
scripts/hooks/guard-foundation.mjsClaude Code, before every edit and commandA change to the protected foundation without PM's phrase; npm ci, install, update and uninstall through shared packages
scripts/hooks/commit-msgEvery commit, after sh scripts/setup.shA commit to the protected foundation without „Одобрено-от: <name>“ (Approved-by). Guards Codex and the terminal too
Protected main and CODEOWNERSWith a shared repositoryMerging without green checks and approval where it is mandatory

How approval works

PM's last message in their session is exactly ОДОБРЯВАМ ОСНОВАТА (I approve the foundation). "I approve" in another message does not count, and the same phrase from a designer never counts: the agent makes a proposal in <personal folder>/proposals/.

The limits

The hook also guards the session folders in .claude/worktrees/. Codex and other agents have no pre-edit guard; commit-msg stops them. The command check recognises listed commands and literal paths; it does not prove that arbitrary code is safe. The protection guards against mistakes, not against deliberate bypass by a person with access.

Computer check

The designer says „провери компютъра“ (check the computer); the agent runs node scripts/doctor.mjs and fixes what is safe. First, on a Mac, sh scripts/install-mac.sh downloads what is missing: Git (Apple's tools), Node.js in ~/.noisy-tools and Chrome in ~/Applications, with no password and no Homebrew.

CheckWhat it looks at
node, browser, claude-versionNode.js 22+, a browser for screenshots, a recent enough app version
git-email, profile, personalEmail, a matching profile, a saved personal folder
hooks, deps, mcp, plugin, impeccableGit protection, packages, Figma and Mobbin servers, plugin, detector
place, location, branch, lock, registryThe right folder, a task branch, locks, the registry
remote, github, approvers, main-sync, uncommittedA shared repository and real GitHub access, approvers, an up-to-date main, unsaved work

Tests

Every test runs in a temporary copy and does not touch the real project. A change in scripts/ needs all of them to pass.

CommandWhat it protects
npm testEverything below plus check:design, check:designmd and test:new (the tests in scripts/tests/). Also runs on GitHub.
npm run test:guardsProtected paths, shell commands, npm through links
npm run test:doctor, test:shot, test:measureThe computer check, screenshots (width, overflow, stopped server), reference measurement
npm run test:design, test:lessons, test:versionsThe design system check, lessons, versions and statuses
npm run test:fidelity, test:wallThe comparison with the foundation, the Wall and the foundation registry
npm run qa:wallBuilds the Wall and opens it headless at 390x844 and 1440x900: the start page, a module page, a screen page, the canvas and 404.html. Looks for overflow, console errors, broken screenshots, raw CSS in the text and a serif font in buttons. A failure saves a screenshot; the exit code is 1.
npm run qa:flowA full replay of the designer path: a clean copy of origin/main with a local origin (nothing reaches GitHub), claude -p with the project settings, then grading of the transcript: no failed scripts, 2+ versions of one screen, a Wall link in the reply, no question to PM; finally qa:wall on the copy's Wall. The report is report.md next to the copy. Grading a transcript only: node scripts/qa/flow-e2e.mjs --transcript <file>.

All scenarios and how each is covered: docs/SCENARIOS.md. Motion consistency in the Theater demo: node tests/figma-for-dev/run.mjs.

Accounts

Everyone works on their own computer. Identity is their Git email, so the system works the same in both modes.

A: a seat for each (recommended)B: a shared account (fallback)
LimitEach has their ownShared: runs out for everyone at once
Who the person isThe Git email on the computerThe same, unchanged
TermsIn line with the Team planA Team seat is for one person: a shared login breaks the terms and Anthropic may restrict access
Chat historyPersonalEveryone sees everyone's chats

Seat type in Claude Team

Standard: 1.25 times the Pro limit, $25 per month or $20 billed annually. Premium: 6.25 times, $125 or $100. The limit is per person and does not transfer. Management decides.

Figma

The agent reads Figma up to 200 times a day with a Full or Dev seat on a paid plan. With View or Collab it is 20 times a month. A designer without a seat works without Figma links, entirely in prototype/.

GitHub

Designers use a shared account, PM their own. Design system approval goes by Git email, not by GitHub account (see Approval).

Mobbin

Pro, Team or Enterprise. Each designer signs in with their own user, or the administrator adds it as a connected tool for the organisation.

GitHub and Cloudflare

The shared repository is private. Previews and the Wall run on Cloudflare Pages.

Protecting main

node scripts/github-protect.mjs apply turns everything on at once: a required pull request, the checks check and "PM approval", no admin exception, no force push and no deletion. verify compares the live settings with the desired ones. On a free plan for a private repository GitHub refuses, and the script says a paid plan is needed.

Push rules

After every stage the task branch goes to GitHub; merging only through a pull request and without squash. Personal folders come as separate pull requests.

Previews

Every task branch has a permanent Cloudflare Pages address (pm/preview.json), rebuilt on every push. It is a test address, never production.

Preview safety

Task code is not trusted, so building and publishing are separated: pregled.yml has no secrets, and pregled-deploy.yml only uploads the built files. The Wall shows names without emails. Do not put confidential data, contracts or prices in the prototype.

A new team project is connected with one prompt to the agent, and team-setup finishes the job: it checks that the repository is empty, writes .github/CODEOWNERS and the protection, and runs the acceptance test. In depth: docs/TEAM-SETUP.md.

Other models and the limit

A task lives in its branch and its note, not in the chat. Rules, skills and memory are files in the repository.

When the limit runs out

  • The task note is updated after every stage, and the automatic backup sends it to GitHub.
  • The new agent first checks the real files and the last successful stage.
  • Work continues with node scripts/task.mjs continue <task> in Codex or in a new session. There are never two writers in one folder.

A chat without file access

node scripts/model-context.mjs builds a local .md with the rules, the profile, the note and the chosen specification. Nothing is uploaded. In depth: docs/MODELS.md.

Automation in both

The backup, correction capture, the DESIGN.md notice and the AI template check are set up for both Claude (.claude/settings.json) and Codex (.codex/hooks.json). In Codex they are enabled once on first start. The Wall panel is Claude's; Codex opens the Wall in the browser at the same link.

Improvements

Anyone can propose an improvement: a component, colour, rule, skill or check. Description: docs/IMPROVING.md.

  1. Personal, immediatelythe person

    Taste and personal skills go into the personal folder and apply at once. Personal rules do not override shared ones.

  2. Shared, as a proposalthe person

    For the whole team („предлагам ...“, I propose ...) the agent writes <personal folder>/proposals/<date>-<topic>.md: what, why, a screenshot or link, the affected files.

  3. Implementationthe agent, PM

    After PM's „ОДОБРЯВАМ ОСНОВАТА“ (I approve the foundation) the agent makes the change, runs npm test, adds a case to docs/SCENARIOS.md, writes Одобрено-от (Approved-by) in the commit and records important decisions in decisions/DECISIONS.md.

What changesWhere
Colour, spacing, radiusdesign-system/tokens.css and the table in design-system/README.md
Componentdesign-system/components.css, design-system/COMPONENTS.md, prototype/components/
Agent ruleAGENTS.md
Model, limits, permissions.claude/settings.json
Tool (MCP server).mcp.json, only from an official source
Script or checkscripts/ with a test in scripts/tests/

What is still open

Open items first, then plans. A plan is not done.

Decision

Seat type and account mode

Standard or Premium; a seat for each or a shared account. Management.

Needed

A paid GitHub plan

Mandatory protection of main in a private repository. Until then the hooks and pull request checks work, but a bypass remains possible.

Needed

A Cloudflare card for company email sign-in

Until then the Wall and preview addresses are open to anyone who knows them. The data has no emails, but the links stay within the team.

Needed

Figma seats and a Mobbin plan

Full or Dev for every designer; Pro, Team or Enterprise on Mobbin.

Decision

Font scale and the DESIGN.md review

The --t-* scale is checked against the Figma variables, and the designers review DESIGN.md with review-design-md; until then it is a draft.

Decision

One home for the design system

Proposal: values are edited in a Figma library, and the repository keeps a generated copy. For a meeting with the designers. Until then the /design-system/ page is generated from the files.

Decision

Two people on one screen

Proposal: shared research in Figma, each implements their variant in a separate file, and only the chosen one goes into main. The screen has a visible lead, without exclusive ownership.

External

The schedule and recordings in Theater

The "schedule, recording, catalogue" chain is a hypothesis until the technical team confirms it. Until then the data is sample data.

Test

Two people, two computers

The acceptance test with two people on two computers is still to come.

Test

Windows

Not tested. Skills are a symbolic link: Windows needs Developer Mode and git config --global core.symlinks true before cloning.

Plans

Plan

The Wall along the viewer's journey

Besides by screen, the Wall is to be ordered along the viewer's path through the product: from home through search and a title to the player and the subscription, so the whole experience can be seen and compared at once.

Plan

A live prototype with swappable sections

Today /lab/ assembles a screen from sections with a version switch for each, but only a Theater demo exists (hero, filters, rail). The plan is to cover all zones, with real sections from the designers.

Plan

Component states for developers

For every component the developer gets its states (rest, hover, focus, pressed, empty, error, loading) in one place. Today /atlas/ shows states and where the component is used; the plan is to make them complete and part of the hand-off package.

Plan

A system for many projects

To serve not only NOISY but also the team's other products, for example Elemental. The proposal is a separate repository per project, a shared kit for the mechanics (scripts, hooks, skills) and a shared home for profiles, so taste is not learned again. Nothing has been reorganised yet. Until then a new project starts as a copy of the foundation without design-system/, prototype/ and the personal folders.