Когда-то я решил, что писать свои стандарты — это признак зрелости. Например, внедрил правила для оформления API. Это был высер по мотивам OpenAPI, но с поправкой на мою тогдашнюю гениальность. В итоге ни одна стандартная библиотека с этим "гениальным" стандартом не дружила: местами он был избыточен, местами недостаточно гибок. Новичкам приходилось раскуривать наши наработки и TTM был не так мал, как хотелось бы.
Тогда я думал, что правила — это спасение. Оказалось, что это смирительная рубашка, которую я же и сшил. Неудобная, колется, но все обязаны носить.
Как не упасть в эту же яму? На универсальный рецепт не претендую (кажется, до этого я всё-таки дорос 😁), но кое-какие советы сформулирую.

Полезно сесть с листочком и провести аудит "а что у нас вообще есть?". Насколько зрелый тимлид у команды? Насколько команда придерживается стандартов? Каких стандартов? Как у команды с гигиеническим минимумом по тестам? По инфре для разработки? Как вообще с тестированием решений? С соблюдение процессов?
Список проверяемых атрибутов вряд ли может быть универсальным. Я бы предположил, что выписывать надо то, что вы умеете замечать, в чём вы разбираетесь, либо у вас есть тот, кто может достоверно это проаудировать.

Когда аудит проведён — можно сравнить полученные значения "зрелости" с требованиями, предъявляемыми продуктами.
Стартапу важна скорость, госу — стабильность. Не каждое правило подходит под любую задачу, это не золотой молоток.

Когда команд становится больше одной — этот подход позволяет сформулировать стратегию. Бессмысленно улучшать то, что и так хорошо, надо чинить там, где прохудилось. Руководитель не должен строить храм стандартов. Его задача — работать с людьми и помогать им расти. Стандарты — это инструмент, а не религия.