Transcription
Итак, директор Google Cloud недавно выпустил свою библиотеку навыков для продакшн-класса, основанную на лучших практиках разработки программного обеспечения в Google. И сегодня мы собираемся протестировать ее. Честно говоря, многие из существующих инструментов для оркестрации ваших рабочих процессов кодирования или ИИ-кодирования кажутся все более сложными, и эта сложность не всегда приводит к улучшению результатов. Именно поэтому эта библиотека кажется мне очень классной, поскольку она представляет собой просто набор навыков, которые мы можем предоставить кодирующим агентам, обеспечивая гибкость между различными этапами этих процессов. На высоком уровне, всего семь команд слэш запускают всю эту систему, а внутри них 19 различных навыков, составляющих эти семь областей. Так что, если вы устали топтаться на месте, постоянно ища лучшее решение, это может быть именно то, что вам нужно. Мы рассмотрим все эти команды и то, как они работают, различные навыки, которые действуют на каждом из этих этапов, и мы создадим несколько новых функций в этом приложении, над которым я работал. Структура этого действительно напоминает мне GitHub's spec kit, который я до сих пор использую, когда хочу сделать что-то действительно надежное и убедиться, что в реализации нет упущений. Работает это следующим образом: сначала мы уточняем или определяем идею, то есть что именно мы пытаемся сделать, и результатом работы этих навыков является PRD (Product Requirements Document). Как только у нас есть PRD, мы можем перейти к созданию плана. И этап планирования приведет к тому, что все в этом спецификации будет преобразовано в серию поэтапных задач. Это будут небольшие, ограниченные задачи, разбитые на разные этапы. Теперь, когда у нас есть эти этапы и задачи внутри них, мы можем перейти к инкрементальной сборке. Инкрементальная сборка означает создание вертикальных срезов. Если вы новичок в этом, есть разница между горизонтальным и вертикальным нарезанием сборки. Лучший способ понять, что делает срез вертикальным: предположим, я хочу создать весь процесс онбординга для моего приложения. Если бы я нарезал это горизонтально, я бы создал все различные компоненты фронтенда. Например, компоненты регистрации, компоненты входа, возможно, различные компоненты фронтенда для управляемого онбординга. Я бы создал все это, а затем создал бы, например, все эти вещи для бэкенда: фактический процесс регистрации, фактический процесс онбординга с серверной логикой, API, схему базы данных, все это. В то время как вертикальное нарезание означало бы: я создам весь срез аутентификации. Я создам фронтенд, я создам бэкенд, я создам все это одновременно. Таким образом, мы переходим к реализации всех этих задач с помощью вертикальных срезов. Как только мы закончили и фактически создали эти вещи, система проходит через этап верификации. Она будет тестировать все и, возможно, отлаживать найденные проблемы. А затем у нас есть дополнительная функциональность для обзора. То есть, проведение надлежащего QA-обзора, уточнение кода, его упрощение, а затем мы можем выпустить. Это будет означать фактическое размещение в GitHub, например, управление различными ветками продакшена и стейджинга и всем таким. Все это очень здорово на высоком уровне, но не имеет особого смысла, если мы не знаем, какие навыки входят в его состав, и именно на это мы посмотрим дальше. Как я уже сказал, их 19. Я не буду охватывать все из них. Я охвачу те, которые считаю действительно ценными. Первый — это уточнение идеи. Если вы не начинаете с четкой идеи и примерно знаете, что хотите сделать, но это немного расплывчато, уточнение идеи поможет вам превратить эту расплывчатую вещь в конкретную концепцию того, что вы собираетесь построить. Теперь, когда у вас есть это, вы можете использовать навык разработки на основе спецификаций. И эта штука сделает следующее: она пройдет и напишет ваш PRD. И у нее есть своя версия этого, которая, возможно, немного отличается от того, что вы видели в других инструментах или даже в других рабочих процессах, которые я демонстрировал на канале раньше. Она создает этот PRD для вас, и вы можете использовать его, независимо от того, работаете ли вы над новым проектом, новой функцией в существующем проекте, что мы рассмотрим немного позже, или просто вносите большие изменения в то, что уже существует. Итак, как только у нас есть спецификация, которая является основным результатом этапа определения, мы переходим к планированию. И этот навык возьмет эту спецификацию и разобьет ее на небольшие задачи, которые можно проверить и которые имеют четкие критерии приемки. Конечным результатом этого должно быть то, что мы сможем выполнить эту задачу и проверить, что она была выполнена должным образом. Например, если бы это была настройка проекта, это могло бы быть обеспечение прохождения всех проверок линтинга, успешная первая сборка приложения и тому подобное. Возможно, если бы мы создавали конечные точки API в рамках задачи, это могло бы быть обеспечение того, что при отправке определенного полезного груза мы получаем ожидаемый тип ответа, что сервер работает правильно, и тому подобное. Затем мы переходим к набору навыков для создания, и здесь много всего, но есть два основных навыка, которые используются при использовании команд для создания, которые мы рассматривали ранее. Первый — это инкрементальная реализация, и это навык, который проходит и выполняет эти вертикальные срезы. Он реализует вещь, тестирует ее, проверяет, что было сделано, а затем фиксирует изменения. Это делается в контексте цикла разработки, управляемого тестами. Он следует циклу "красный, зеленый, рефакторинг". Если вы не знаете, что это такое, это означает, что вы сначала напишете тест, который не проходит. Вы напишете минимальную логику, которая фактически заставляет вещь работать и проходит тест, а затем вы будете рефакторить. Существуют и другие навыки, которые вы можете вызвать, или которые будут вызваны в зависимости от того, что делается. Некоторые из них включают инжиниринг контекста, то есть извлечение правил и тому подобного по мере необходимости, фронтенд-инжиниринг пользовательского интерфейса. Когда вы работаете над компонентами, системами дизайна, управлением состоянием на фронтенде, обеспечением отзывчивости, всем этим. По сути, всякий раз, когда вы создаете пользовательский интерфейс, он будет вызывать это. И аналогично для бэкенда, всякий раз, когда мы работаем с API, различными границами между тем, что мы создаем на бэкенде, он будет вызывать этот навык проектирования API и интерфейсов. Затем, когда дело доходит до проверки и обзора всего, есть ряд других навыков, которые помогают нам выполнять части этого процесса. Тестирование в браузере с использованием MCP Chrome, рабочие процессы отладки, которые помогают нам действительно сузить круг до первопричины фактической проблемы, с которой мы имеем дело, обзоры качества кода, упрощение, безопасность и укрепление, оптимизация производительности. В нем есть множество действительно замечательных вещей, которые помогают нам взять то, что мы получили на этапе начальной сборки, и убедиться, что это действительно хорошо и будет работать так, как мы хотим. Итак, сказав все это, давайте перейдем к нашему проекту и попробуем эти навыки, начиная с этапа спецификации. И прежде чем мы перейдем к первому навыку, я покажу вам приложение, с которым мы работаем, чтобы у вас был контекст. Оно помогает нам настраивать и создавать рецепты. Под капотом происходит некоторая инженерия подсказок, чтобы убедиться, что рецепт, который мы хотим приготовить, действительно хорош. Например, если бы я сказал: "Приготовь мне французский луковый суп с бурбоном", он бы начал потоковую передачу ответов от Claude, а затем у него есть этот небольшой генеративный пользовательский интерфейс, который пройдет через него, и как только он получит полный поток ответа, он сгенерирует карточку рецепта с ингредиентами, шагами и вкусовым профилем, а также несколькими другими вещами. И теперь, когда эта штука закончена, мы видим, что она генерирует эту карточку для нас. Бурбон, французский лук, что угодно. У него есть ингредиенты, разные шаги, а внизу есть опция сохранить рецепт. И это будет фокусом того, что мы делаем здесь, потому что я хочу иметь возможность делать итерации рецептов, верно? Например, я попробую это, но изменю это, или я захочу изменить это в будущем, но я хочу иметь след этой вещи. Моя мысль о том, как бы я это сделал, если бы строил это только для себя, была бы сделать это как интерфейс в стиле git, но для пользователя, я думаю, это, вероятно, было бы довольно... И поэтому нам нужно подумать, как мы собираемся это сделать. И поэтому мы спустимся сюда, хорошо? Я очищу все, что у нас есть, а затем мы используем первый навык, который был для идей. И эта штука называлась "уточнение идеи", и я скажу ей именно то, что я только что сказал вам. Я хочу иметь опцию в стиле форка, где пользователи могут создавать варианты рецепта и сохранять информацию о том, из какого корневого рецепта он был получен. Он показывает все варианты рецепта на оригинале. И под этим я подразумеваю, что если я нахожусь на этой карточке рецепта, и я не уверен, куда именно это пойдет в пользовательском интерфейсе, но это должно показать мне, например, вот, знаете, пять вариантов, которые вы приготовили в прошлом, примерно так я это представляю. Эта штука запускается, и теперь она пройдет через это, и у нее есть свои специфические способы мышления об этом, и она обрамляет все через идею "как мы можем", а затем говорит: "Хорошо, как мы можем позволить пользователям делать эту вещь, которую я только что описал?". Она исследует кодовую базу, а затем предложит нам несколько различных вариантов, обычно от трех до пяти вариантов, которые являются разными, например, направлениями системного дизайна, которые мы могли бы выбрать. И вот, вопросы поступают, и мы можем отвечать на них. Итак, первое: что запускает эту вещь? Происходит ли это через чат? Происходит ли это на самой странице рецепта? Где мы запускаем этот форк в первую очередь? Думая о MVP, я не хочу переусложнять это инструментами и маршрутизацией намерений пользователя и всем этим безумием. Поэтому я просто скажу, что они идут и нажимают "форк" на рецепте, а затем он загружает его в чат с контекстом этого рецепта и говорит: "Эй, что вы хотите сделать?". Мне это нравится. Как должны отображаться варианты на странице оригинального рецепта? Опять же, я думаю, я выберу самый простой вариант, который является простым списком. Могут ли пользователи форкать рецепты других людей или только свои? Теоретически, если у нас есть социальные функции, они должны иметь возможность форкать рецепты других людей, но нам нужно будет подумать о том, как мы будем обрабатывать безопасность на уровне строк в нашей базе данных. Так что, вероятно, будет немного больше. Но пока я скажу, давайте позволим это для будущего, но сейчас я буду использовать эту штуку, и я не хочу переусложнять то, что мне не нужно прямо сейчас. Должны ли форки иметь возможность форкать? То есть, можно ли создавать варианты вариантов? Я бы сказал, да. Я не вижу причин, почему бы и нет. Так что мы можем сказать "неограниченная глубина", хорошо? Итак, давайте отправим все эти ответы. Она подумает об этом, а затем вернется и даст нам наши, так сказать, направления дизайна для этой вещи, что мы видим сейчас. И весь этот поток, через который она проходит, она прошла и сказала: "Хорошо, вот семь различных направлений, а затем давайте оценим их и сойдемся на одном финальном направлении, которое мы возьмем". Все это встроено в навык, поэтому он проходит через эти конкретные этапы, что приятно, потому что вы можете быть уверены, что он будет работать так для вас, когда вы будете его запускать. Давайте посмотрим на направления и выберем одно. Итак, по сути, то, как это происходит: она взяла все вопросы, на которые мы ответили, и теперь говорит: "Ну, вот различные направления, которые вы могли бы выбрать. Это своего рода UX или дизайн системы. Вот как вы могли бы взять эту вещь". Самым простым было бы это базовое средство ремикса, где вы нажимаете "форк", и оно делает именно то, что мы описали. ИИ спрашивает, что вы хотите изменить. У него есть ссылка на родительский рецепт, а затем на странице оригинального рецепта отображается раздел вариантов с карточками, очень просто, а затем мы можем получить другие, стать немного более "острыми". Ха-ха, каламбур. Мы можем стать более "острыми" в том, как мы хотим это сделать, верно? Мы можем показать разницу, но я бы не хотел, чтобы это выглядело слишком "технически", поэтому это должно быть читаемо человеком. Вот что вы изменили. Ну, это вариант. Отклонение вкуса, подчеркните, что вы изменили во вкусовом профиле. Мне кажется, это немного трюкачество. Меня это сейчас не очень волнует. Исследователь родословной, есть куча других идей, которые, по-моему, немного сумасшедшие. Мне нужно что-то базовое для этого. Я действительно хочу. И поэтому я думаю, что направление А — это то, что я бы предпочел. Меня не волнует форк с учетом вкуса. Так что мы просто скажем "чистый форк". Мы будем двигаться вперед. И снова, мы на этапе идеи. Вот что я имею в виду, когда говорю, что мы можем перейти от расплывчатой идеи к чему-то очень конкретному и тому, что вы можете предпринять. Так что очень приятно, что это помогает нам продумать такой тип вещей, в то время как многие библиотеки на самом деле этого не делают. Вы просто говорите, что хотите, а затем LLM делает предположения и выходит и делает это. Мне очень нравятся библиотеки, у которых есть такой вид опросного, конфликтного подхода к вещам. Следующее, что мы собираемся сделать, потому что у нас есть эта идея, которая была проработана. Они хранят это, кстати, в вашем проекте. Итак, мы находимся в docs, ideas, recipe forking. Теперь я запущу их навык "разработка на основе спецификаций". И это позволит нам детализировать, что это означает на практике? Какие вещи нужны пользователю? Каковы критерии приемки? Как мы будем это проверять? Все это будет проработано. Она исследует кодовую базу, посмотрит, что у нас есть, какая у нас схема, какие файлы у нас есть, как все структурировано, а затем она создаст спецификацию или PRD для нас. Итак, что мы получаем в итоге, это, как я уже сказал, PRD. Какова цель того, что мы собираемся попытаться построить? Как выглядит успех? Каковы основные критерии приемки? Какой тип технологий будет задействован? Каковы параметры или соглашения о стиле кода, которые у нас есть в проекте? Каковы границы этой вещи? То есть, что она всегда должна делать? Что ей нужно спросить у нас, прежде чем она это сделает? Чего она никогда не должна делать? Например, обходить политики безопасности строк. Мы получаем эту подробную версию того, что нужно сделать, но этого недостаточно для создания. Вы не захотите взять это и сказать: "А теперь создайте это", верно? Потому что мы хотим создать, опять же, вертикальные срезы, которые мы можем реализовать, где у нас есть очень проверяемые, тестируемые вещи. И если бы мы просто отправили это, мы не обязательно получим это. И поэтому следующим шагом в этом процессе является то, что мы должны сначала очистить наш контекст. И теперь мы собираемся перейти к этапу планирования. И поэтому мы вызовем следующий навык, который называется "планирование и разбивка задач", и мы просто передадим контекст конкретного плана, над которым мы работаем, то есть этой штуки с форком. И теперь, если мы вернемся в этот репозиторий GitHub, мы сможем увидеть, что именно он будет делать и какой именно процесс он пройдет. Он будет использовать режим планирования. Он определит граф зависимостей. То есть, из всех вещей, которые мы собираемся построить, что от чего зависит и как это повлияет на последовательность построения. Он нарежет его вертикально и даст примеры того, что является плохим примером, как горизонтальное нарезание, о котором мы говорили ранее, где мы бы создали все данные базы данных, все конечные точки API, все компоненты пользовательского интерфейса, а затем соединили бы все это вместе, вместо того, чтобы сказать: "Пользователь может создать учетную запись". Круто. Нам нужна схема, нам нужен API для этого, и нам нужен пользовательский интерфейс для этого. Вот в чем разница между горизонтальным и вертикальным. Затем он запишет все задачи в этом конкретном формате, и как только у нас будет это, мы сможем перейти к фактическому созданию. Итак, теперь, когда это сделано, у нас есть план для нашей сборки, записанный в документацию нашего проекта. И поэтому, если бы мы посмотрели на это, у нас есть обзор того, какие важные архитектурные решения были приняты, но затем какие различные этапы сборки. И поэтому эти вещи теперь организованы на основе зависимости того, что нужно сделать. Итак, наш первый этап будет посвящен основам, обеспечению настройки нашей базы данных и типов. Этап два будет основной сборкой бэкенда. Этап три будет фактическим пользовательским интерфейсом чата, и так далее, и так далее. Итак, что мы будем делать дальше, это вернемся в нашу консоль. Я очищу это. И теперь мы будем использовать фактическую команду сборки. Все, что я собираюсь сделать, это передать команду agent skills build {slash} и затем мы укажем репозиторий, над которым работаем, и скажем: "собрать этап один". Я очень рекомендую вам явно указывать этапы, над которыми нужно работать, потому что я обнаружил, что с этой библиотекой, если вы этого не сделаете, она попытается пройти и построить весь план сразу, и это, очевидно, очень плохо для вашего контекста. И все жалуются на то, как Claude сжигает свои контекстные окна в наши дни. Так что убедитесь, что мы этого не делаем. Итак, первый этап был завершен довольно быстро, очистили контекстное окно, и теперь мы запускаем ту же самую команду, но я говорю "этап два". И еще одна вещь, которую я добавляю, это обеспечение того, чтобы она фактически использовала навык для этого API и проектирования интерфейсов, где это применимо, потому что я обнаружил, что иногда лучше, если вы знаете, что хотите, чтобы навык использовался, просто сказать ему сделать это и не полагаться на то, выберет ли он использовать этот навык, когда он вам действительно нужен. Просто скажите ему использовать его. И теперь круто то, что мы можем видеть, что она использует этот подход разработки, управляемого тестами, по мере выполнения. Итак, когда она начала выполнять задачу шесть в этом этапе, которая заключается в форкировании контекста или форкировании контекста в системной подсказке и в API чата, сначала она напишет тесты, которые не проходят, верно? А затем она перейдет к обеспечению того, чтобы они не проходили, а затем она реализует логику, которая заставит этот тест фактически пройти. Итак, теперь, когда это сделано, мы перейдем к этапу три, который больше связан с фронтендом этой сборки. И я делаю то же самое. Я говорю: "Этап три, но убедитесь, что вы используете навык инжиниринга пользовательского интерфейса фронтенда". Итак, если бы мы фактически посмотрели на этот навык, причина, по которой мне очень нравится такой тип библиотеки, заключается в том, что она гибкая, но также и в том, что она предлагает хорошие способы делать вещи в системе. Например, документирование того, как должны выглядеть шаблоны компонентов фронтенда, чтобы быть сделанными хорошо. Обеспечение того, чтобы мы разделяли получение данных от фактического представления вещи. Обеспечение того, чтобы при работе с управлением состоянием, которое в данном случае может включать все, что происходит с форкированием, мы использовали подход, который действительно имеет смысл на основе контекста приложения. Обеспечение того, чтобы экраны ошибок или обработка ошибок, которые она создает, имели смысл и не просто выдавали ошибку и показывали нам пустой экран. Все эти вещи очень важны, и они встроены в навык, который сейчас используется. Итак, мы видим, что навык был вызван, и теперь он проходит через него и просто создает все на основе этих параметров. Итак, теперь, когда это сделано, он переходит к этапу четыре. Итак, ребята, момент истины, мы можем проверить это. У нас есть этот рецепт. Мы видим эту кнопку "форк рецепта". Если мы нажмем на нее, она должна создать новый чат. Она должна иметь эту штуку "форк" в URL, что она и делает. Пока не похоже, что она что-то делает, но я дам ей секунду и посмотрю, может быть, есть небольшая задержка, и если она начнет отправлять сообщение. Да, мы видим это прямо здесь. Очевидно, что это время нужно обновить. Итак, она спрашивает нас, что мы хотим сделать, и дает нам несколько вариантов, как мы можем это изменить. Я мог бы сказать что-то вроде: "Сделай его более сытным рецептом, больше похожим на рагу, чем на суп. Используй О, мы возьмем эту говядину. Используй говядину в качестве мяса, хорошо?". И теперь, надеюсь, это пройдет и создаст нам новый рецепт. Давайте посмотрим. Она спрашивает нас больше информации, что хорошо. Выбирайте. Мне все равно. Я просто хочу протестировать логику всего этого. Хорошо, генерируется новая карточка рецепта, что хорошо. Надеюсь, это пройдет и сработает, и бум. Итак, мы видим, что теперь мы можем сохранить рецепт. Хорошо, рецепт сохранен. Тушеное мясо из французского лука с бурбоном и говядиной. Итак, мы можем посмотреть на это. Он не ссылается на родительский рецепт, но, возможно, если мы вернемся к рецептам, это очень медленно, кстати, для рендеринга всего. Так что, очевидно, есть вещи, которые мне нужно оптимизировать, что мы рассмотрим через секунду, что мы можем сделать для этого. Если мы зайдем в оригинальный рецепт, хорошо, то он не рендерит пользовательский интерфейс для этого. Итак, правильно, он должен показывать нам список рецептов, которые были форкнуты от родителя, но теперь мы можем вернуться и фактически использовать этот навык отладки. Я просто скажу ему, что именно происходит. Я не буду сходить с ума. Он должен показывать список рецептов, которые были форкнуты от родителя. Я почти уверен, что у нас это было в планах, и этого нет, верно? Я должен видеть это где-то здесь в пользовательском интерфейсе как прокручиваемую сетку. И поэтому он пройдет через это и попытается понять, в чем заключается первопричина проблемы. По мере того, как эта штука движется, кажется, что она построила большую часть этого, но она не рендерит. Итак, это есть в API. Он должен срабатывать, когда variants.length больше одного, но этого не происходит. И поэтому кажется, что конечная точка, которую мы имеем, не соответствует тому, что она искала. И поэтому она сузила проблему и движется через нее и пытается ее исправить. Итак, что они пытаются мне сказать здесь? Но это... Похоже, проблема в том, что корневой рецепт. То есть, если мы смотрим на говядину или на оригинальный рецепт, тот, от которого он был "форкнут". Поскольку это оригинал, у него есть нулевое поле в ID корневого рецепта. И поэтому, когда он вызывает это, он возвращает ноль и не работает должным образом, как кажется. Итак, он утверждает, что нашел первопричину и собирается попытаться ее исправить. И поэтому мы посмотрим на это после того, как это будет сделано. Хорошо, похоже, это исправило. Так что это действительно хороший навык, который у нас есть, чтобы действительно найти первопричину и просто исправить вещь, а не копаться в 50 миллионах разных вещей. У нас есть два разных варианта. У нас есть этот летний травяной, который я сделал за кадром, а затем у нас есть тушеное мясо из французского лука с говядиной. Мы можем нажать на него и посмотреть, и он покажет нам, от чего он был форкнут. Так что, возможно, мы можем сделать так, чтобы некоторые из этого выглядели лучше, но что касается основной логики, все работает. Итак, теперь, когда у нас есть это, давайте посмотрим, какие еще навыки мы можем использовать в качестве небольшой вишенки на торте. Я уже все это проверил вручную, так что я не буду проходить через это. У нас есть два других набора навыков. У нас есть навыки, ориентированные на обзор, где мы можем посмотреть на качество того, что мы написали, и я знаю, что, вероятно, есть некоторые проблемы с тем, что у нас есть. Мы на самом деле не касались создания индексов для базы данных на случай, если она станет больше, и нам нужно будет работать внутри базы данных эффективно. А затем у них также есть навыки для отправки этой вещи. Например, если бы я хотел загрузить это в Vercel прямо сейчас, но убедиться, что все тесты пройдут перед развертыванием, как я могу это сделать? Давайте зайдем и посмотрим на навыки обзора, а затем посмотрим на последний навык отправки. И поэтому мы можем спуститься вниз и просто запустить этот agent skills review. И пока это работает, мы можем посмотреть, что именно он просматривает. Он запускает эту штуку под названием "пятиосевой обзор". И поэтому он будет смотреть на все, что у нас есть в нашей кодовой базе, по этим измерениям. Номер один: корректность. Делает ли это то, что он утверждает, что делает? Номер два: читаемо ли это и просто ли это? Если бы кто-то другой посмотрел на это прямо сейчас, имело бы это смысл? И есть много соглашений, которые объясняют, как он определяет, что это читаемо и просто. И номер три: соответствуют ли какие-либо из изменений, которые мы внесли, поскольку это должно работать в ветке, какие-либо из этих изменений общему дизайну системы? Соответствует ли это нашим существующим шаблонам? Сохраняет ли это границы между различными модулями и тем, что они должны обрабатывать? Не ввели ли мы какие-либо уязвимости безопасности? И затем у него есть навык, который может помочь в этом и исправить это. И затем детальная оптимизация производительности через этот навык оптимизации производительности. И снова, он будет смотреть на кучу разных частей. И затем, в зависимости от размера изменения, я думаю, в данном случае мы смотрим, вероятно, на тысячу строк, которые мы изменили в этой ветке, над которой мы работали. У него есть различные механизмы для эффективного просмотра вещей. Вот что он делает по мере выполнения. У него есть процесс, через который он работает, а затем это общий процесс обзора, который он будет использовать. И поэтому очень важно запустить это, потому что, очевидно, у нас появились некоторые вещи, которые нам действительно нужно решить. Например, мы не используем ORM с Supabase. Это помогло бы нам избежать таких вещей, как уязвимость к SQL-инъекциям. И поэтому, насколько бы умными мы ни думали, что такие инструменты, как Claude Code и тому подобное, они будут делать такие ошибки. И поэтому крайне важно, чтобы мы запускали такой процесс и видели, что это за вещи, и строили реальный план для решения всех этих проблем. И снова, он смотрит на каждый из этих параметров. Корректность, делает ли он то, что должен делать? Читаемо ли это и просто? Работает ли это в рамках архитектуры, которая у нас уже есть? И снова, вопросы безопасности, которые нужно решить. Это все проблемы, которые, прежде чем мы фактически отправим эту вещь, нам нужно убедиться, что все это исправлено. И поэтому, используя эту библиотеку, мы могли бы использовать навык планирования агента и сказать: "Создай мне всеобъемлющий план для решения всех критических проблем". Прямо сейчас он пройдет через тот же процесс, который мы прошли ранее, но с точки зрения исправления этих потенциальных проблем безопасности. Теперь, поскольку я разрабатывал это локально, у меня нет конвейера развертывания, подключенного к GitHub или чему-либо подобному. Так что, пока это делается, мы можем посмотреть на последний навык, который предназначен для настройки конвейера непрерывной интеграции и развертывания. И поэтому мы зайдем и создадим новый репозиторий GitHub. У меня есть пустой репозиторий здесь. Я назвал его forkcast V2. И поэтому мы пройдем через это и просто запустим эти команды. Мы вернемся в наш терминал. Я открою новое окно. Мы добавим origin, создадим нашу основную ветку. Хорошо, эта штука теперь реализует эти изменения. И поэтому мы просто зайдем в это, создадим новый экземпляр Claude Code в том же каталоге. Мы скажем ему использовать навык для создания нашего конвейера CI/CD с использованием GitHub actions. Убедитесь, что у нас есть правильная стратегия ветвления для управления тестами перед слиянием в main. Так что мы будем использовать этот навык для выполнения основной работы по созданию инфраструктуры, которая нам нужна. В основном, я хочу его для создания GitHub actions, чтобы, когда мы отправим эту штуку в GitHub, она автоматически запускала все наши тесты и делала все это, прежде чем мы фактически сольем это в нашу основную ветку продакшена, которую мы используем. В зависимости от сложности приложения и всего такого, могут использоваться различные структуры. В нашем случае у нас нет настроенного сквозного тестирования. Это просто личный проект для меня, и все такое. У меня его нет. И поэтому у нас не будет какого-то супер-пупер надежного многоэтапного тестирования. И поэтому он это знает, верно? Он делает определенные предположения на основе того, что он прочитал в нашем проекте, и рекомендует нам создавать функции в ветках функций. Они сливаются в ветку разработки, где происходит все тестирование и тому подобное. А затем, когда все будет хорошо, мы сливаем это в нашу основную ветку. И поэтому он просто движется вперед и создает все это. И поэтому, если бы мы посмотрели в наш проект сейчас, у нас есть каталог GitHub, который содержит эти конфигурации для того, как мы будем фактически отправлять вещи в наш репозиторий GitHub и убеждаться, что мы правильно запускаем все тесты и тому подобное. И снова, все это было настроено для нас с использованием этого навыка, что довольно круто. И через секунду, как только мы закончим эти исправления, мы фактически отправим все, что у нас есть, и запустим тесты и посмотрим на результаты. Итак, теперь, когда мы находимся в нашем проекте и отправляем изменения, скажем, в нашу кодовую базу, и мы хотим слиться в main из нашей ветки разработки, у нас есть все эти различные тесты, которые должны пройти, прежде чем это может произойти. Так что у нас не может быть ситуации, когда мы просто отправляем вещи в нашу кодовую базу продакшена, которые просто не работают. И поэтому все это было сделано этим навыком, который позволил нам создать эти GitHub actions, эти CI (непрерывная интеграция) и CD (непрерывное развертывание) actions, которые будут запускаться всякий раз, когда мы пытаемся сделать push. Так что мы можем зайти и фактически посмотреть на это и увидеть: хорошо, весь линтинг прошел, все проверки типов прошли, все тестирование прошло, и теперь он пытается фактически запустить сборку, чтобы убедиться, что финальная сборка прошла. И поэтому есть вещи, которые мы можем сделать, чтобы зайти сюда и дальше заблокировать ветки, чтобы убедиться, например, что вам даже не разрешено напрямую пушить в main, чтобы вы никогда не совершили ошибку, но это видео для другого дня. Так что у меня будет ссылка на этот репозиторий в описании ниже. Обязательно подпишитесь, если вам нравятся более длинные видео, подобные этому, где мы разбираем что-то в реальном контексте, потому что если есть одна вещь, которую я ненавижу, то это видео, ориентированное на список дел, которое никоим образом не практично и пропускает все действительно важные вещи. Так что, если вам нравится такой тип вещей, обязательно подпишитесь, и где-то рядом с моей головой YouTube будет рекомендовать видео, которое вам может понравиться. Так что обязательно посмотрите и его. Но на этом все для этого видео. Увидимся в следующем.