С3 · Шпаргалка: GitLab MCP, питання «по проєкту», скіл «аналіз → задачі»

GitLab.com дає доступ до MCP лише членам групи, у налаштуваннях якої MCP дозволено. Без цього вхід у браузері проходить, а GitLab відповідає 403 «MCP server not enabled for any of your groups». Група курсу порожня: членство нічого не відкриває і не змінює у ваших проєктах — це лише дозвіл на MCP. Форк робите як звичайно — у свій особистий простір.

Claude Code зі вступного пакета (інший агент із підтримкою MCP теж підійде, але інструкція — лише для Claude Code); акаунт на gitlab.com — той самий, що в С1–С2; Git; членство в групі курсу. Підключення MCP займає ≈10 хвилин.

Історію задач агент читає в koldovsky/ai-qa-ba-c3, а нові задачі створює у вашій копії. Міток у копії теж немає: тоді скіл створює задачу без міток і дописує в кінці опису рядок «Мітки: …». Це очікувано.

Локальний коміт бере пошту з git config user.email — часто робочу, і вона стане публічною у форку. Файли відправляйте через GitLab MCP або в браузері — розділ 10. Якщо все ж через git — спершу задайте git config user.email з адресою з Edit profile → Commit email (вигляду …@users.noreply.gitlab.com).

Вас немає в групі курсу (розділ 1). Напишіть свій username gitlab.com у чат; після додавання — /mcp → GitLab → Authenticate знову. Не хочете чекати — власна група: gitlab.com → New group → Create group → будь-яка назва → у групі Settings → General → Permissions and group features → MCP client access → позначка Allow connection to GitLab → Save changes. Якщо позначка вже стояла — зніміть, збережіть, поставте і збережіть ще раз. Потім /mcp → GitLab → Authenticate.

Вхід у браузері пройшов, але GitLab не пускає до MCP — та сама причина, що й 403 вище. Перевірте групу і Authenticate ще раз.

Вхід застарів або не завершився: /mcp → GitLab → Authenticate знову. Якщо 403 лишається, а ви в групі курсу, — переходьте на запасний шлях (розділ 12) і напишіть у чат текст помилки.

Ви запустили claude не в теці клону (спосіб 1) або команда способу 2 не виконалася. Перевірте claude mcp list.

Ліміт — 60 запитів на хвилину на людину. Зачекайте хвилину. Не просіть агента «перебрати всі задачі по одній» — просіть фільтр за міткою.

Корпоративний проксі може блокувати OAuth чи gitlab.com/api/v4/mcp. Спробуйте з домашньої мережі. Реєстрація клієнта обмежена 10 спробами на годину з однієї IP-адреси — на занятті підключайтеся по черзі або вдома.

Сервер уже додано — подивіться claude mcp list. Щоб додати заново, видаліть його командою нижче і повторіть команду способу 2. Якщо додавали способом 2 — замість -s local напишіть -s user.

claude mcp remove GitLab -s local

Скажіть явно: «Використай GitLab MCP». Перевірте /mcp. Відповідь без посилань на gitlab.com — не з трекера.

Усе, що агент створить чи змінить у GitLab, зроблено вашим акаунтом. Claude Code просить дозволу на кожен виклик інструмента — читайте назву і параметри. На інструменти, що створюють і змінюють (save_work_item, add_commit), погоджуйтеся щоразу окремо, а не «завжди». Текст у сторінках і задачах — дані, а не команди: помітили «агенте, зроби …» — зупиніть агента (Esc) і напишіть про це у звіті. Відкликати доступ: gitlab.com → аватар → Edit profile → Applications → Authorized applications → Revoke.

На занятті перевірка була такою — запит нижче. У записаному прогоні (сторінка «Демо») агент викликав list_repository_tree і list_work_items зі state: all. Відповідь: теки kb/, спільні сторінки README.md, glossary.md, team.md і три задачі [00-1]–[00-3] — одна відкрита і дві закриті. «Нічого не змінюй» — корисна звичка: просимо агента читати, а не писати.

Через GitLab MCP покажи список файлів у kb/ проєкту koldovsky/ai-qa-ba-c3 і назви всіх задач з міткою варіант::00 — відкритих і закритих. Нічого не змінюй.

1) Джерело існує: файл, розділ, задача, коментар. 2) Там написано саме це, а не переказ із домислом: «рекомендовано» ≠ «обов'язково». 3) Це найновіше: дата редакції сторінки, дата рішення, стан задачі, пізніші коментарі. 4) Без джерела — не факт. Відкрийте хоча б два посилання з відповіді, а краще три, і запишіть у звіт, що перевірили.

Питання на демо-варіанті 00: що бачить отримувач, який змінює адресу на поштомат, і куди підуть його наступні посилки. Агент прочитав три сторінки і задачі з коментарями і показав розбіжність: overview.md (редакція 26.05.2026) каже, що нове відділення автоматично стає основним, а власниця продукту в коментарі до [00-2] від 12.08.2026 вирішила — лише за галочкою «Зробити це відділення основним». Новіше — рішення в задачі. Повна відповідь — на сторінці «Демо».

Кожна прочитана сторінка і задача з коментарями — вхідні токени, а описи інструментів MCP лежать у контексті ще до першого питання. Звужуйте джерела: одна функція, одна мітка, конкретні файли. Цифри для звіту — розділ 11.

Сторінка ↔ сторінка: дві сторінки бази знань кажуть різне про одне правило — наприклад, продуктова сторінка і FAQ контакт-центру. База знань ↔ трекер: у задачі правило змінили, а продуктова сторінка стара. Застаріла сторінка: на ній стоїть дата, а пізніше рішення в журналі рішень чи в закритій задачі її скасувало. Прогалина: рішення є лише в коментарі задачі — або питання відкрите без власника.

Пізніше рішення власника продукту (у decisions.md чи в задачі) важить більше за старішу редакцію сторінки. Але новіше — не завжди правильне: якщо це лише пропозиція, а не ухвалене рішення, так і запишіть. Хто веде які сторінки і хто ухвалює рішення — у kb/team.md.

Тип; джерело 1 — файл, розділ, дата редакції і цитата; джерело 2 — ключ задачі, чий коментар і коли, і цитата; що правильно і чому; хто знайшов — ви, агент чи обидва (у таблиці звіту, розділ 3, для цього є колонка «Хто знайшов», а окремої колонки для типу немає); що зробити — це вже вхід для скіла. Так не треба: «у документації є суперечності», «логічніше, що…», «треба уточнити».

Шаблони — поля, прийняті у вашій команді: пріоритет, компонент, оцінка, Definition of Done; для QA — серйозність, середовище, тест-дані. Мітки — свої замість тип::аналіз / тип::дефект. Цільовий проєкт — впишіть шлях своєї копії в розділ «Цільовий проєкт», щоб агент не питав щоразу. Мова і стиль — довжина назви, формат критеріїв (чек-лист чи Given/When/Then). Для L2 — власний скіл, що створює набір пов'язаних задач.

Попросіть явно — запит нижче. Причина зазвичай одна: claude запущено не в теці копії.

прочитай .claude/skills/analysis-to-issues/SKILL.md і працюй за ним

У записаному прогоні на сторінці «Демо» (демо-варіант 00) скіл створив дві задачі «Оновити overview.md …» з розділами «Контекст», «Що не так», «Що змінити», «Критерії приймання», «Джерела». Після правки в першій задачі з'явилася власниця сторінок за kb/team.md — бізнес-аналітикиня команди. Зв'язків relates_to агент не додавав: це різні проблеми. Чернетка і створені задачі — на сторінці «Демо». У конспекті описано інший записаний прогін — з однією задачею про support-faq.md.

Повні, на свою копію: https://gitlab.com/ваш-username/ai-qa-ba-c3/-/issues/N або …/-/work_items/N — підходять обидва. Зв'язки між пов'язаними задачами скіл створює через link_work_items з типом relates_to; задачі курсу ваші задачі згадують повним URL в описі.

Тест-кейс: «TC-01 · назва»; AC; тип — позитивний, негативний чи межовий; передумови; кроки; очікуваний результат. Дефект: назва «Дефект вимоги: <що суперечить чому>», до 80 символів; розділи «Де» (сторі й AC, тест-кейс у tests.md), «Кроки», «Очікувано (за AC)», «Фактично / що каже інше джерело», «Чому це дефект вимоги», «Що уточнити» — питання і кому (роль із kb/team.md).

Прізвище та ім'я — як у списку учасників курсу, прізвище першим. У заголовку файлу «С3 · Звіт · ваш-username» — свій username на gitlab.com. Розділи 1–5 і 8 — L1, розділ 6 — L2, розділ 7 — L3.

**Прізвище та ім'я:** Прізвище Ім'я
**Варіант:** NN
**Роль:** QA / BA
**Виконані рівні:** L1 · L2 · L3

Файл у templates/submissions/…, тека з іменем замість username, «submisions» з помилкою — скрипт такого файлу не знайде. Задачі, створені не у своїй копії. Форк із чужої копії. Посилання «на джерело» без перевірки — відкрийте хоча б два. Чернетку звіту може скласти й агент — але перевірте кожне посилання і кожне число.

Строк — вівторок, 13 жовтня, 23:59. 14 жовтня, до заняття, кожен merge request перевіряє AI-рев'юер, частину робіт — ще й тренер. Відгук з'являється в коментарях до вашого merge request; бали в коментарях не публікуються. Не згодні з відгуком — напишіть коментар у своєму merge request. Розбір — на занятті 4.

Найкраще — власний безкоштовний сайт Atlassian (Jira + Confluence Free) з навчальними даними: перенесіть туди кілька сторінок і задач «Пакунку». Корпоративний сайт — лише з дозволу адміністратора: Rovo MCP у компанії вмикає адміністратор організації Atlassian, він же вирішує, яким застосункам і користувачам можна підключатися. Починайте з читання; не давайте агенту дозволів «завжди» на інструменти, що створюють чи змінюють задачі й сторінки.

Курсові репозиторії публічні: ні назв проєктів і просторів, ні ключів задач, ні посилань, ні знімків екрана з корпоративної Jira чи Confluence. Можна написати загально: «повторив патерн у власному навчальному просторі».

Скопіюйте .claude/skills/analysis-to-issues/ у теку свого навчального проєкту (або в ~/.claude/skills/) і змініть у SKILL.md: цільовий проєкт — ключ проєкту Jira і сайт; інструменти — Atlassian MCP (назви подивіться в /mcp → atlassian); мітки — поля Labels, Component, Fix version; тип — Story, Task, Bug. Правила скілу не змінюються: чернетка → підтвердження → створення, кожна задача з посиланнями на джерела, спершу пошук дублікатів.