Норм

после первого проекта все стайлгайды поменяются так что не парься особо по этому поводу - просто копипасть

Так себе совет. Иногда наоборот дизайн система сдерживает

Просто надо уметь говорить "этого нет в дизайн системе, утвердите изменение в нее"

ох

а есть кейсы? Или мне достаточно для первого шага раскидать конфиги в пакете и прописать их в package.json?

Для начала попробуйте :)

не думаю что хотя-бы один разработчик хотел бы что его “сдерживали”. А если все-таки загоняют в рамки то тут или он не джун и начнет спорить или джун и начнет спрашивать почему так, и нужно что кто-то ему пояснил. Что возможно только идет в небольших компаниях с устоявшимся коллективом - это уже идет врознь с изначальным описание контекста вопроса.
Но это мое мнение. Мб я не прав так как менеджментом особо не занимался.

окей)
А без публикации я не смогу их связать линками? И как после публикации это сделать? Например следом уйдет весь атомарный дизайн, он потребуется в новых задачах, и хочется чуствовать что работаешь в одном проекте (локально) тестируя уи на любом из проектов

Вы не правы

Как раз наоборот сдерживание очень важный элемент

давать ему возможность писать что он хочет и как хочет? Лишь бы писал? Это не код а один сплошной баг

Поставьте дизайнеру задачу "нарисуй мне что хочешь" и ему сложно

Ограничения позволяют улучшить систему так как сокращают пространство поиска решений

плюсик

Это применимо не только к дизайну но и глобально к любым вопросам

Выходить из-за рамок системы надо только когда доказано что эти рамки не позволяют эффективно решить задачу

Ну если компания/организация у тебя это загон для джунов и их нада сдерживать то это офк круто. Наверно.

если нет и прийдет сенъер писать проект с 0, например, а ты ему такой вручаешь стайлгайд и говоришь у нас в компании так заведено

весьма вероятно что тот кто писал этот стайлгайд квалификацией пониже и начнется спор