Від Ручного Кодування до Майстерності ШІ: Як Я Переосмислив Розробку за Допомогою Кодуючих Агентів
Особистий досвід: Протягом останнього року я практично не написав жодного рядка коду вручну. Це може здатися дивним, враховуючи, що я все життя присвятив інженерії, і навіть ділився своїми знаннями про створення ШІ-агентів, рядок за рядком, на своєму YouTube-каналі. Проте, саме це сталося: я повністю перейшов на використання ШІ-помічників для кожного етапу розробки. Система, яку я відточив за останні шість місяців, вражає своєю простотою та ефективністю. По суті, це цілісний набір “навичок” для кодуючих агентів, таких як Claude Code або Codex. Ці навички – це готові, багаторазові промпти та комплексні робочі процеси, які скеровують ШІ-агента через специфічні етапи розробки.
Сьогодні я хочу поділитися цим набором навичок, який я зібрав, і продемонструвати, як ви можете інтегрувати його у свою роботу, або ж просто отримати натхнення. Я розумію, що у вас, ймовірно, вже є власний інструментарій та робочий процес для ШІ-кодування, і я не очікую, що ви відразу відмовитеся від нього. Навіть якщо ви запозичите лише кілька ідей чи прикладів, це буде чудовим результатом. Сьогодні стало надзвичайно легко вказати ШІ-агенту на репозиторій, сказати: “Гей, мені подобається ось це, візьми цю навичку” – і інтегрувати її в те, що ви вже маєте.
Нотатки про особистий досвід: Ключова перевага моїх навичок полягає в їхній мінімалістичності та легкій інтеграції. Це означає, що вам не обов’язково приймати їх усі. Можете вибрати лише кілька – чудово! Навіть кілька ідей – це вже значний крок вперед. Це суттєво відрізняється від деяких інших фреймворків для агентного кодування, таких як GitHub Spec Kit чи Gastown. Хоча це вражаючі проєкти, їхнє використання часто вимагає повної адаптації до їхніх процесів. Весь цикл розробки програмного забезпечення визначається за вас. Це може бути ефективно, якщо ви починаєте з абсолютно чистого аркуша. Однак, як правило, я припускаю, що ви вже маєте певний налагоджений процес. Тому я пропоную бібліотеку, з якої ви можете обрати те, що вам найбільше підходить.
Крім того, будь-яку з цих навичок надзвичайно легко адаптувати під ваш код чи стиль роботи. І це саме те, на чому ми сьогодні зосередимося. Звісно, якщо ви починаєте з нуля, ви можете використати повний набір навичок, який я застосовую у своєму циклі розробки. Пізніше я також розгляну підхід “спочатку валідація”, який дозволяє моделі “готувати” результати, зберігаючи при цьому впевненість у їхній якості. Чесно кажучи, це найважливіший елемент усього мого процесу. Це також ключовий фокус мого курсу з агентного кодування в спільноті Dynamis, де я детально розбираю повний цикл розробки ШІ. Тож, якщо вам це цікаво, посилання будуть в описі.
Гаразд, з цим розібралися. Давайте я покажу вам, наскільки просто встановити ці навички та інтегрувати їх у ваш проєкт.
Як Ці “Чарівні” Навички Інтегруються у Ваш Проєкт?
Ми розпочнемо з README файлу в репозиторії, посилання на який також буде в описі. Оскільки більшість з вас використовує Claude Code, я створила ці навички як плагін для ринку Claude Code. Щодо інших кодуючих агентів, я розповім трохи згодом.
Ви копіюєте першу команду, заходите до свого Claude Code (якщо він вже запущений) і додаєте мій плагін. Поки він встановлюється, я скопіюю другу команду для фактичного встановлення.
Ось, перша команда виконана. Тепер встановлюємо. Є кілька опцій: зазвичай, я рекомендую вибрати перший варіант. Це встановить навички для будь-якої кодової бази. Ви також можете встановити їх лише для поточного репозиторію, в якому відкритий Claude Code, або для колаборантів, якщо ви працюєте в команді. Знову ж таки, найчастіше обирають перший варіант.
Це все! Процес займає лише кілька секунд. Тепер, якщо ми введемо plugins, ми побачимо всі встановлені плагіни, включно з “Kohs AI skills”. Ви також можете побачити їх, якщо введете /skills. Бачите? Весь вміст репозиторію одразу доступний нам. І якщо я введу, наприклад, /piv, ми побачимо всі команди циклу, які ми детальніше розглянемо трохи згодом.
А якщо ви використовуєте кодуючий агент, відмінний від Claude Code, встановлення майже таке ж просте. Це може звучати дещо незвично, але вам просто потрібно скопіювати URL цього репозиторію, надати його вашому кодуючому агенту і сказати: “Ось колекція навичок для Claude Code. Я хочу, щоб ти встановив їх у цьому репозиторії для цього кодуючого агента, як-от Codex, Py, чи GitHub Copilot”. І це спрацює! Це займе трохи більше часу, але все одно настільки ж легко інтегрувати ці навички для будь-якого кодуючого агента.
Отже, Навички Встановлено. Давайте розберемося, Куди Ми Потрапили.
Тепер я покажу вам повний процес розробки і як кожна з цих навичок у ньому задіяна. Ми будемо дотримуватися високорівневого підходу. Якби я занурювалася в деталі кожної навички та її виконання, це відео було б значно довшим. Тож, дайте мені знати в коментарях, якщо є якийсь аспект цього процесу, який ви хотіли б, щоб я детальніше розглянула в наступному відео. Я справді могла б зробити окреме відео для кожної навички. Не тому, що вони складні, а тому, що є так багато найкращих практик, які можна засвоїти, щоб отримати максимум від вашого процесу.
Тож, зараз я просто покажу вам, як все виглядає, коли ми збираємо все до купи. Як перейти від “нічого” до “готового коду” з вашими кодуючими агентами?
Зовнішній та Внутрішній Цикли: Простота, Що Веде до Магії
Мій робочий процес зі ШІ-кодуванням складається з двох циклів. Це проста, як двері, система, яка полегшує мені побудову будь-чого.
- Зовнішній цикл – це найвищий рівень планування: створення PRD (Product Requirements Document) та специфікацій.
- Внутрішній цикл – це місце, де ми пишемо код. Ми беремо окрему задачу (ticket) або проблему (issue), плануємо роботу з кодуючим агентом, отримуємо код, а потім валідуємо його разом з агентом, який робить те саме.
І, звісно, почнемо з зовнішнього циклу, адже саме так починається будь-яка робота. У зовнішньому циклі ви робите менше, оскільки виконуєте його один раз на задачу.
- Для розробки з чистого аркуша (greenfield development), коли ви починаєте проєкт з нуля, тут ви окреслюєте MVP (Minimum Viable Product) – те, що нам потрібно побудувати, щоб отримати перший прототип нашої програми.
- Для роботи з існуючим кодом (brownfield development), коли ви працюєте над вже написаним кодом, ви визначаєте більшу функціональність або набір функцій, які ви хочете реалізувати для наступного спринту. Яким буде наступне еволюційне зростання вашого проєкту?
Навичка “PRD”: Хто, Що і Навіщо?
І перша навичка, яку ми використовуємо, – це “PRD”. Адже ваш PRD, або документ з вимогами до продукту, визначає “що” і “чому” для вашого наступного обсягу роботи. Ви надягаєте “капелюх” менеджера проєкту, щоб спрямувати вашого кодуючого агента допомогти вам визначити, що саме ми будуємо? Яку проблему ми насправді намагаємося вирішити? Бо ви хочете переконатися, що все інше, що ми робимо в процесі розробки, створює щось варте створення. Саме це ми тут встановлюємо.
Давайте я покажу, як виглядає ця навичка в репозиторії. Зазирнемо у папку skills нашого репозиторію. А всередині ми знаходимо plan/create_prd. Я сказала, що не буду заглиблюватися в кожну навичку, але цю я мушу показати.
Отже, у вас є кілька прикладів того, як працюють мої навички. Більшість моїх навичок мають аргумент. Є щось, що ми визначаємо тут. Тож, коли я заходжу в Claude Code і вводжу /plan PRD, я можу натиснути Tab для автозавершення. Ви бачите підказки щодо аргументів. Це дає вам уявлення про те, що можна вказати. Який вхід для цієї навички? Тож, вона знає, з чим працювати.
І тут ми можемо вказати нашу ідею продукту. Це може бути щось дуже загальне, на кшталт: “Я хочу створити трекер фінансів”. Не знаю, вигадую випадковий приклад. Вам не потрібно бути надто конкретними, тому що як частина цієї навички, вона насправді буде “інтерв’ювати” вас. Вона задасть купу запитань, щоб витягти з вас важливі речі, які нам потрібно визначити в PRD: цільового користувача, гіпотезу, яку потрібно довести, щоб зрозуміти, чи варто це будувати, типові речі, які ви б мали в PRD. Ця навичка навчає агента: “Ось що нам потрібно отримати від користувача, тобто від тебе. А ось як ми це оформимо в документ PRD”.
Наш Спонсор Сьогодні: Agora – Інфраструктура для Вашої Голосової AI-Магії
До речі, сьогоднішнього спонсора – Agora, інфраструктурну платформу для створення ваших голосових AI-агентів. Вони мають власну мережу реального часу з понад 200 точок присутності по всьому світу, яка маршрутизує ваше аудіо та відео, оминаючи затори. І завдяки цьому вони вже десятиліттями підтримують найбільші голосові та відео-додатки.
І це важливо, тому що створення вашого голосового агента – це значно більше, ніж просто завантаження SDK. Ви використовуєте його, щоб зшити разом ваш LLM, text-to-speech та speech-to-text. Але після того, як у вас є голосовий агент, де ви його розгортаєте? І як ви його розгортаєте так, щоб він був по-справжньому масштабованим і достатньо швидким, щоб здавалося, ніби він веде справжню розмову?
Ну, з Agora ви не тільки отримуєте SDK для створення голосового агента, але й отримуєте конвеєр та мережу під ним, щоб вам не довелося підтримувати та масштабувати вашого голосового агента. А з швидким стартом у їхній документації ви можете запустити власного голосового агента Agora менш ніж за 5 хвилин. Одна команда для встановлення. Надайте цей промпт вашому кодуючому агенту, і він створить це для вас.
Подивіться:
>> Hey Cole, Im your Agora voice agent. Ask me anything.
>> Hey, hows it going?
>> Hello.
>> Very, very responsive. Like, this is pretty good. Thanks.
>> Im glad you think so.
Звісно, їхній швидкий старт – це лише початкова точка, але в Agora є безліч конфігурацій. Ви можете підключитися до будь-якої моделі. Їхній рушій також працює з LLM, сумісними з OpenAI. Тож, будь-який агент, який ви вже створили, ви можете перетворити на голосового агента Agora. Ви отримуєте перші 300 хвилин розмовної AI безкоштовно. І єдині облікові дані, які вам потрібні для створення вашого голосового агента, – це ваш App ID та сертифікат.
Тож, якщо ви вагалися створювати голосового агента, бо не були впевнені, як їх створювати, розгортати та масштабувати, Agora – це ваше рішення. Посилання на них буде в описі.
І щоб показати вам приклад, ось PRD, який я згенерувала за допомогою цієї навички. Ми маємо заяву про проблему, докази, усі розділи, які ми просили агента створити після інтерв’ю з нами.
Важливо те, що ми зовсім не описуємо, як саме ми будемо впроваджувати ці нові функції в кодову базу. Ми зосереджуємося на “що” і “чому”, тому що у нас є окрема навичка, яка визначає нашу специфікацію. Це “як”. Фактично, занурення в архітектуру для нашої реалізації.
І дуже важливо мати цей роздільний зв’язок. Він важливий, тому що це дійсно дві окремі розмови, які ви будете мати зі своїм кодуючим агентом. Спочатку ви описуєте і з’ясовуєте “що” і “чому”. Потім ви плануєте архітектуру. Ви заглиблюєтеся в технічну реалізацію, “як”. Як ми будемо створювати наступний набір функцій?
І тому я рекомендую запускати ці навички в окремих розмовах. Я не буду показувати цю навичку зараз, тому що процес дуже схожий на попередню: агент проводить з вами інтерв’ю. Він базується на шаблоні для створення архітектурного документа. І тепер у вас є другий артефакт, який передує створенню завдань (tickets).
Навичка “Slice Epic”: Розбиваємо Велике на Маленьке
І кожен діалог генерує документ, який переходить до останнього кроку зовнішнього циклу. Тому що тепер, коли ми маємо повний обсяг роботи, спланований для нашої наступної епічної задачі, нам потрібно розділити її на невеликі, зручні для роботи шматки, щоб не перевантажувати нашого агента надто великими запитами в кожній розмові.
Отже, відповідальність цієї навички – взяти два попередні результати і визначити залежності, з’ясувати, що ми можемо робити паралельно. По суті, просто підготувати ґрунт для всіх внутрішніх циклів, коли ми будемо виконувати фактичну розробку.
І ось я покажу, як це виглядає, коли ми переходимо до Claude Code. Назва навички для цього кроку – piv slice epic, так? Тому що ми беремо епічну задачу і розбиваємо її на невеликі шматки роботи. І вона приймає два аргументи: у нас є специфікація або архітектурний документ, і PRD. Тож, тепер вона знає “що”, “чому” і “як”. Тож, вона може створити всі залежності та вибудувати їх.
І ви можете побачити тут, що ми також можемо вказати сторінки Confluence, якщо хочемо. Багато компаній, з якими я працюю, зберігають свої PRD та документи специфікацій не локально. Вони зберігають їх у Confluence. Тож, я хотіла зробити цю навичку справді гнучкою. Не має значення, чи зберігаєте ви це в Confluence, чи маєте PRD у форматі markdown. Ця навичка зможе його отримати, якщо у вас є, знаєте, сервер MCP для доступу до будь-де, де ви зберігаєте ваші документи.
Тож, ви надаєте два шляхи або URL-адреси. І тоді вона створить усі завдання для вас, які потрібно реалізувати у вашому внутрішньому циклі. І ви будете проводити більшу частину свого часу у внутрішньому циклі, тому що пам’ятайте, ми робимо зовнішній цикл лише один раз на епічну задачу. Ці навички дуже, дуже важливі, але ви будете використовувати ті, що тут, набагато більше, тому що тепер у вас може бути навіть десятки завдань, якщо ви працюєте над більшою епічною задачею.
Тож, ми пройдемо процес планування, впровадження та валідації для кожного з них. Отже, наша навичка slice видає купу окремих частин роботи. Це можуть бути markdown-документи, GitHub-завдання, Jira-квитки, неважливо. Суть у тому, що кожне з цих завдань є входом для цілого внутрішнього циклу.
Внутрішній Цикл: Де Код Оживає
І тут ми спрямуємо кодуючого агента на це завдання і скажемо: “Ось що ми хочемо реалізувати. Я хочу, щоб ти дослідив кодову базу і допоміг мені спланувати цю конкретну реалізацію”.
Навичка “Prime”: Знайомимося з Кодом
Я зазвичай починаю з навички prime. Ось вона, prime codebase. Є кілька різних прикладів, якщо ви хочете зрозуміти конкретну частину вашої кодової бази, наприклад, якщо ви працюєте тільки з фронтендом. prime codebase – це більш загальний варіант, який просто досліджує кодову базу, потенційно з точки зору конкретної проблеми, яку ви хочете йому надати. Наприклад, якщо ви хочете надати йому Jira-завдання або markdown-файл для наступного шматка роботи, він дослідить кодову базу, як вона стосується того, що ви хочете побудувати далі.
У будь-якому випадку, важливо те, що ваш кодуючий агент має свої глобальні правила, але в іншому випадку він досить “дурний” на початку розмови, чи не так? Тож, ми, по суті, завантажуємо контекст.
Навичка “Plan”: Агент Вас “Розпитує”
Після запуску навички prime, ми переходимо до навички, де ми справді плануємо роботу з агентом. Важливо розуміти, що plan ми виконуємо в тій самій розмові, де щойно запускали prime. Я, можливо, мала б показати справжню розмову, щоб зробити це конкретнішим, але, гадаю, ви зрозуміли ідею, чи не так? Чи можете ви запустити SLP prime codebase або щось подібне?
І після дослідження кодової бази ми використовуємо це як контекст для переходу до PIV plan implementation. Тут ви також можете вказати завдання, над яким працюєте, якщо ви ще не вказали це на кроці prime, оскільки це необов’язково.
І тепер ми сплануємо це конкретне завдання. А процес насправді досить схожий на створення нашого PRD або документа специфікації. Агент почне з інтерв’ю з вами, ставлячи купу запитань, щоб переконатися, що ви на одній хвилі щодо всього. Тому що найнебезпечніше тут – це коли кодуючий агент робить припущення щодо того, що ви насправді хочете побудувати або як ви хочете це побудувати. Тому що LLM впевнено роблять жахливі припущення. Саме тому нам потрібен повний робочий процес, де агент справді ставить вам багато запитань, проводить багато досліджень у кодовій базі, а потім тільки тоді створює план для переходу до реалізації.
І так, це варто витрат часу з самого початку. І я знаю, ми ще навіть не написали жодного рядка коду, але саме це потрібно для отримання надійних результатів за допомогою допомоги ШІ-кодування. Переконайтеся, що ви на одній хвилі. Створіть план, а потім реалізуйте на його основі.
Ось як виглядає результат навички планування, якщо ви не налаштовували речі в навичці, про що ми поговоримо в кінці відео. Але формат плану завжди однаковий. Це одна з речей, яку ми визначаємо в навичці планування – шаблон, чи не так? Ми завжди хочемо мати опис функції та історію користувача. Це те, що робить навички надійними та повторюваними, тому що кожна навичка, яка має вихідний документ, подібний до цього, має шаблон, якого повинен дотримуватися кодуючий агент.
І так, ми маємо заяву про проблему, заяву про рішення, що виходить за межі, і не-цілі. Я, ви можете змінити всі ці розділи, якщо хочете, але це чудово працює для мене як керівництво для агента перед впровадженням.
І оскільки ми справді заглиблюємося в конкретну роботу, ми навіть виділяємо речі в кодовій базі, як-от: ось контекст, на який ми хочемо посилатися, файли, які нам потрібно змінити, документацію, яку ми хочемо прочитати. У нас навіть є покроковий план реалізації для файлів, які ми хочемо створити та редагувати.
І тоді найважливіша частина всього документа плану тут – це стратегія тестування. На цьому я хочу зосередитися на кілька хвилин з вами. Це те, що справді відрізняє мій підхід від інших. Це спосіб, яким кодуючий агент визначає стратегію валідації ще до того, як ми напишемо жодного рядка коду.
І ви можете бачити, що це досить вичерпно. У нас є модульні тести, інтеграційні тести, крайні випадки, які ми хочемо, щоб агент протестував. У нас є всі конкретні команди, які він буде запускати для лінтування та перевірки типів, модульного тестування, інтеграційного тестування, ручного валідування. Як ми можемо керувати додатком, як користувач, також за допомогою таких інструментів, як браузер агента, щоб він міг виконувати автоматизацію браузера.
Підхід “Валідація Спочатку”: Дозвольте Моделі “Готувати”
Це найважливіша частина плану. І я поясню вам чому. Підхід “валідація спочатку” стає все кращим і кращим, оскільки LLM стають більш потужними. Тому я називаю це Test-Driven Development (TDD), але для агентів. Якщо ви інженер, ви знаєте, що це означає. В іншому випадку, не хвилюйтеся.
По суті, те, що ми робимо, це: ще до того, як напишемо жодного рядка коду, ми сплануємо, як тестувати цей код. І це важливо, тому що це означає, що те, що ми отримуємо від агента, ніколи не є його першою спробою. Він може писати та запускати всі тести, які ми визначили в плані. Тож, він може ітерувати над своєю власною роботою. Нам доводиться втручатися значно менше. Ми отримуємо значно менше “ШІ-сміття”, коли він може виконувати всі ці тести та виправляти свою власну роботу.
І так, кожна річ, яку ми будемо створювати в цьому завданні, як-от кінцева точка або обробка помилок, ми визначаємо з агентом у плані, як ми будемо тестувати цю річ?
І тому я закликаю вас, коли ви створюєте ці плани, переглядати їх самостійно. Переконайтеся, що валідація виглядає добре, документація, на яку він буде посилатися, виглядає добре. Тому що, якщо цей план хороший, тоді ви дуже конкретно визначаєте кінець. Ви кажете: “Ось що означає “готово”, і ось як ви можете валідувати речі, щоб бути впевненими в цьому”.
І, як я вже казала, ця стратегія стає все потужнішою, чим потужнішими стають LLM. Борис Турней, творець Claw Code, сказав це минулого місяця: “Ви хочете описати завдання, ви хочете описати обмеження та критерії виходу, включаючи валідацію, а потім просто дозволити моделі готувати та повернутися трохи пізніше”. Я обожнюю це. Просто дозвольте моделі готувати.
По суті, мантра тут така: ви хочете бути конкретними щодо кінця, тобто, що саме ви шукаєте? Яка стратегія валідації? А потім ви дозволяєте агенту будувати дорогу до цього. Вам не потрібно бути конкретними щодо засобів. Ось чому я кажу, що стратегія валідації – це найважливіша частина ваших планів сьогодні, тому що, доки агент має “гальма” та інструкції для тестування та ітерації над своєю роботою, він дістанеться туди, тому що він будує шлях. Він пише код і може адаптуватися до всього, що піде не так, коли він перевіряє свою власну роботу.
І мені це подобається, тому що це допомагає нам усвідомити, де ми насправді присвячуємо наш час, коли проходимо внутрішній цикл. Документи плану іноді здаються досить перевантаженими всім контекстом, файлами, які ми будемо створювати та редагувати, але не надто хвилюйтеся з цього приводу. Звісно, все ще важливо валідувати весь план, але я даю вам дозвіл зосередитися переважно на стратегії валідації та переконатися, що агент справді розуміє, що ви хочете побудувати.
Навичка “Implement”: Свіжа Розмова для Свіжого Коду
Тому що тепер, що ми збираємося зробити, щоб швидко завершити внутрішній цикл, це взяти документ плану, який ми щойно створили, і надіслати його в навичку implement. І ми зробимо це в абсолютно новій розмові. Ми робимо розділення, як ми зробили з цими двома навичками, тому що робота з реалізації дуже відрізняється від планування. Ваша розмова про планування, ймовірно, вже дуже довга. Ми хочемо уникнути “ротації контексту”, тому що великі мовні моделі мають “тупу зону”, де вони перевантажуються інформацією, так само, як і люди. І оскільки документ плану, який ми тут виводимо, є єдиним контекстом, який нам справді потрібен для написання коду, ми можемо просто перейти до навички implement у новій розмові, так?
Тож, я просто вводжу /piv і тоді єдиний аргумент – це шлях до плану. Тож, просто клацніть правою кнопкою миші у VS Code, скопіюйте повний шлях до плану, вставте його сюди і запустіть. Ось і все, що вам потрібно зробити.
І тоді реалізація, коли вона проходить через план, агент автоматично пройде через етапи валідації, які ми маємо в плані. І тому, по суті, етап валідації вбудований прямо в реалізацію. Ви можете запустити його як окрему річ. У мене є абсолютно окрема навичка, якщо ви хочете більше зробити щось на кшталт одноразової валідації, але зазвичай ви робите ці речі одночасно.
І тоді, коли агент каже, що він готовий, ви просто проводите власний огляд коду та ручне тестування, якщо хочете. Зазвичай, особливо якщо ви більш технічно підковані, я все ж рекомендую перевіряти роботу агента. Просто тому, що ви заздалегідь визначили стратегію валідації, це не означає, що він зробить ідеальну роботу. Тож, робіть будь-яку валідацію, яку хочете, так? Це огляд, який ви робите самостійно. У мене є навички, які допомагають вам виконати цей огляд.
І тоді ви завершите це завдання, відкривши pull request, так? Тож, зазвичай ви будете використовувати щось на кшталт GitHub для управління своїми кодовими базами. Тож, у вас є ця пропозиція, так? Ось робота, яку я зробила у внутрішньому циклі для цього завдання. Я пропоную тепер об’єднати це з основною кодовою базою.
І ось, коли ви це зробите, так? Ви проводите огляд pull request. Ви вважаєте його добрим. Ви його об’єднуєте. Тоді ви просто переходите до наступного завдання і знову виконуєте внутрішній цикл, доки не виконаєте все, що ви створили як завдання за допомогою цієї навички.
Висновок: Не Бійтеся Делегувати Магії
І ось він – повний робочий процес. Безумовно, це відео вийшло трохи довшим, ніж я очікувала, але я хотіла справді допомогти вам досягти успіху. Повний процес розробки. Я знаю, ми не запускали жодної з цих навичок, але ви знаєте, як вони поєднуються, коли ви виконуєте їх у нових розмовах або продовжуєте ту ж, як ми робимо з prime та plan.
І так, ви, безумовно, можете налаштувати всі ці навички на свій смак. Кожну з цих навичок я намагаюся зробити максимально мінімалістичною, але, безумовно, у мене є свої думки щодо того, якою має бути найкраща структура для PRD чи плану, або як агент має проводити з вами інтерв’ю. І тому, якщо ви хочете відредагувати будь-які з цих файлів, це насправді досить легко. Зазвичай, що я роблю, це заходжу в розмову з Claude, беру skill.md для PIV. Ну, давайте візьмемо, наприклад, plan implementation. Копіюю це. Заходжу сюди і просто кажу: “Гей, Claude, я хочу змінити XYZ щодо цієї навички, так?” Я ніколи не пишу ці навички вручну або не роблю дрібних налаштувань вручну. Я завжди змушую кодуючого агента робити ці редагування на основі базового опису, яке я йому даю.
І тому, якщо вам щось не сподобається в цих навичках, коли ви будете їх інтегрувати, вибиратимете та комбінуватимете з бібліотеки, яку я вам пропоную, її дійсно легко налаштувати під те, що вам потрібно. Якщо ви хочете змінити структуру, якщо ви хочете змінити шаблони, дуже легко використовувати вашого кодуючого агента для цього.
І з цим, я сподіваюся, ви знайшли ці навички досить корисними, незалежно від того, чи будете ви використовувати їх усі, чи лише деякі з них. І я буду продовжувати додавати до цього репозиторію, просто щоб зробити його колекцією всіх навичок, які я використовую для всього. Тож, переважно те, що зараз є в репозиторії, – це основні навички для мого SDLC, але я маю багато інших планів.
І тому, якщо ви цінуєте це відео і з нетерпінням чекаєте на більше контенту про навички та ШІ-кодування, я буду дуже вдячна за лайк та підписку. І з цим, побачимося в наступному відео!
