Як Claude Code врятував мене від нестерпно нудної роботи на цілий тиждень

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Всім привіт! Мене звати Андрій. Я працюю на позиції Android/Flutter developer у GlobalDev Group, де розробляю мобільні рішення для наших клієнтів.

В цій статті я розкажу, як за допомогою Claude Code (CLI-інструмент від Anthropic) і кількох MCP-серверів я побудував автоматизований пайплайн, який за 1 годину зробив роботу, на яку зазвичай іде цілий робочий тиждень. (Дисклеймер: звісно потрібно ще враховувати час, який пішов на ручну перевірку результатів після АІ, загальну кількість потраченого часу можна переглянути у фінальній частині) Якщо коротко — AI сам зайшов у Figma, розібрав дизайни, потім залогінився у робочий веб-застосунок, поклацав по ньому, перехопив усі API-запити з Network-панелі, а потім звірив результати зі Swagger-документацією. І все це — без єдиного рядка ручного копіювання.

Нижче я покажу, як це налаштовується, як працює кожна фаза, і які результати ми отримали — щоб ви могли оцінити, наскільки цей підхід зайде у вашому workflow.

🧩 Контекст: чому взагалі виникла ця задача

У нас був типовий для аутсорсу сценарій. Команда дизайнерів підготувала нові екрани для модуля Time Tracking — красивий, сучасний дизайн із тижневим календарем, формою створення записів, системою погодження, панчклоком і всім, що очікуєш від повноцінного тайм-трекера.

Спочатку планувалося написати новий API під ці екрани. Але бекенд-команда на той момент була зайнята іншим великим модулем, який стояв у планах уже давно. Водночас наша мобільна команда виявилась швидшою за очікування — UI-компоненти вже були готові до підключення.

І тоді замовник прийняв прагматичне рішення:

«Існуючий бекенд уже обробляє тайм-трекінг. Давайте спочатку використаємо те, що є, а новий API зробимо пізніше, коли бекенд-команда звільниться.»

Рішення логічне. Але для нас як мобільної команди це означало одне: потрібно дуже точно розібратися, що з існуючого API ми можемо використати, що потребує адаптації, а чого дійсно не вистачає і треба просити бекенд-команду допилити.

Для цього треба було звести воєдино три джерела інформації:

1. Figma-макети — що мобільний додаток повинен робити
2. Веб-застосунок — які API зараз реально використовуються
3. Swagger-документація — які ендпоінти бекенд загалом підтримує (зокрема ті, які веб-додаток не використовує)

Класичний підхід — це відкрити три вкладки, клікати, копіювати URL-и в табличку, шукати в Swagger через Ctrl+F, і так цілий тиждень. На 7 екранів. І ще й не пропустити нічого.

Я подумав: а що, якщо автоматизувати весь цей процес?

💡 Ідея: Claude Code — це не чат-бот, а агентний рантайм

Багато розробників знайомі з AI-асистентами рівня «запитання — відповідь». Claude Code — це дещо інше. Це CLI-інструмент від Anthropic, який працює як повноцінний агент: він може читати файли, виконувати bash-команди, і — найважливіше — підключатися до зовнішніх інструментів через MCP (Model Context Protocol).

MCP — це, по суті, універсальний адаптер, через який AI отримує доступ до реальних систем: Figma, браузер, API, бази даних — що завгодно. Хтось написав MCP-сервер — Claude може ним користуватися як інструментом.

Для цього проєкту я підключив два MCP-сервери:

1. Figma MCP (офіційний remote) — Читає дерево компонентів, текст, стилі, spacing — усе з Figma-файлу
2. Chrome DevTools MCP (Google) — Керує реальним Chrome-браузером: перехоплення мережевих запитів, навігація, кліки, заповнення форм

А щоб Claude знав, що саме робити, я написав три Skills — markdown-файли з детальними інструкціями для кожної фази.

Загальна архітектура пайплайна:

Кожна фаза запускається як окрема сесія Claude Code, а не як субагент всередині однієї. Чому? Бо кожна фаза потребує 50—100k токенів контексту (дерева DOM, мережеві логи, Swagger JSON). Якщо запхати все в одну сесію — контекстне вікно переповнюється, і якість відповідей різко падає.

«Передача даних» між фазами — це просто markdown файли на диску. Фаза 1 пише markdown. Фаза 2 його читає, робить свою роботу, пише свій markdown. Фаза 3 читає все попереднє й генерує фінальний звіт.

Ніякого LangChain. Ніяких кастомних агентних фреймворків. Тільки Claude Code, три markdown-інструкції і два MCP-сервери.

🛠️ Налаштування: MCP-сервери та конфіг

Перше, що потрібно зробити — підключити MCP-сервери в Claude Code. Це робиться один раз:

# Figma MCP (офіційний remote-сервер)
claude mcp add --scope user --transport http figma https://mcp.figma.com/mcp

# Chrome DevTools MCP (Google)
claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest

Після додавання Figma MCP — потрібно авторизуватися: запускаєте Claude Code, вводите /mcp, обираєте figma, проходите OAuth. Це разова операція.

Конфіг зберігається у .mcp.json в корені проєкту:

{
  "mcpServers": {
    "figma": {
      "type": "http",
      "url": "https://mcp.figma.com/mcp"
    },
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

А щоб Claude не запитував «Чи можна мені клікнути кнопку? А прочитати файл?» на кожній дії, потрібно налаштувати permissions:

{
  "permissions": {
    "allow": [
      "mcp__figma__*",
      "mcp__chrome-devtools__*",
      "Bash(curl:*)", "Bash(mkdir:*)", "Bash(cat:*)", "Bash(jq:*)"
    ]
  }
}

Після цього всі три фази можуть працювати автономно, без ручного підтвердження кожної дії.

🎨 Фаза 1: Аналіз дизайну (The Design Whisperer)

Ціль: розібрати нові Figma-макети і сформувати структурований опис кожного екрана — які UI-компоненти є, які дані вони відображають, і які API-операції дизайн передбачає.

Промпт

Сам промпт для Claude виглядає майже розчаровуюче просто:

claude --model opus "Read the phase1-design-parser skill in .claude/skills/. 
Then analyze the Figma Time Module design at this URL: 
https://figma.com/design/XXXX/Project-X?node-id=XXXX-XXXX"

Вся «розумна» частина — в skill-файлі. Промпт просто вказує джерело й запускає процес.

Як працює Skill-файл

Я написав .claude/skills/phase1-design-parser.md — детальну інструкцію, яка каже Claude:

• отримати структуру Figma-файлу через MCP
• пройтися по кожному екрану (фрейму) в дизайні
• знайти всі інтерактивні елементи: кнопки, форми, списки, тоглери, fab-и, свайпи
• класифікувати кожен елемент за CRUD-операцією (CREATE, READ, UPDATE, DELETE, NAVIGATE)
• ідентифікувати сутності даних (TimeEntry, Project, Employee, ApprovalStatus)
• задокументувати стани UI (empty state, loading, error)
• згенерувати .md-файл на кожен екран + common_ui.md для спільних компонентів

Вміст phase1-design-parser.md:

---
name: phase1-design-parser
description: "Analyzes Figma designs via the Figma MCP server and generates
per-screen markdown documentation for Flutter development."
---

# Phase 1: Figma Design Parsing Skill

## Objective
Parse all screens from a Figma Time Module design and generate structured
markdown documentation that will drive API endpoint mapping in later phases.

## Workflow

1. **Get File Overview**
   Use the Figma MCP `get_file` or equivalent tool with the provided Figma URL
   to retrieve the file structure. Identify all top-level frames/pages that
   represent individual screens.

2. **For Each Screen Frame:**
   a. Use Figma MCP tools to retrieve the frame's layout tree, component instances,
      text content, and design tokens (colors, spacing, typography).
   b. Identify all interactive elements: buttons, inputs, dropdowns, toggles,
      date pickers, lists, tabs, FABs, swipe actions.
   c. Classify each interactive element by its **likely data operation**:
      - CREATE (forms, "Add" buttons)
      - READ (lists, detail views, dashboards)
      - UPDATE (edit buttons, inline editing, toggles)
      - DELETE (delete buttons, swipe-to-delete)
      - NAVIGATE (tabs, back buttons, links)
   d. Identify data entities visible on screen (e.g., TimeEntry, Project,
      Employee, ApprovalStatus).
   e. Note any conditional UI (empty states, error states, loading states).

3. **Generate Per-Screen Markdown**
   Save to `output/phase1/screen_.md` with this structure:
   # Screen: 
   ## Visual Summary

   ## UI Components
   | Component | Type | Data Entity | Operation | Notes |
   |-----------|------|-------------|-----------|-------|
   | "Save" button | Button | TimeEntry | CREATE | Bottom of form |
   | Time list | ScrollView/List | TimeEntry[] | READ | Grouped by date |

   ## Data Fields Displayed/Collected
   - field_name (type, required/optional, validation notes)

   ## User Actions (Interaction Map)
   1. User taps "+" FAB → Opens create time entry form
   2. User swipes entry left → Reveals delete action
   3. User taps entry → Navigates to detail/edit view

   ## Expected API Operations
   - GET list of time entries (filtered by date range, employee)
   - POST new time entry
   - PUT update time entry
   - DELETE time entry

   ## State Variations
   - Empty state: "No time entries for this period"
   - Loading state: Skeleton cards
   - Error state: Retry banner

4. **Generate Common UI Markdown**
 Save to `output/phase1/common_ui.md` documenting:
 - Shared navigation patterns (bottom nav, drawer)
 - Shared components (app bar config, card styles, status badges)
 - Design tokens (primary colors, font sizes, spacing scale)
 - Shared data entities referenced across multiple screens

 ## Output Checklist
 - [ ] One `screen_*.md` per unique screen in Figma
 - [ ] One `common_ui.md` for shared components
 - [ ] Every interactive element classified with a data operation
 - [ ] Every visible data field documented with its type

Що отримали

Вісім структурованих markdown-файлів — по одному на екран + спільні компоненти:

output/phase1/
├── screen_approval_manager.md
├── screen_calendar_weekly.md
├── screen_clock_in.md
├── screen_home_dashboard.md
├── screen_login.md
├── screen_time_entry_form.md
├── screen_time_entry_types.md
└── common_ui.md

Ось приклад того, що Claude згенерував для екрана створення тайм-ентрі:

## UI Components
| Component         | Type          | Data Entity       | Operation | Notes                     |
|-------------------|---------------|-------------------|-----------|---------------------------|
| Save button       | Button        | TimeEntry         | CREATE    | Bottom of form            |
| Delete button     | Button (red)  | TimeEntry         | DELETE    | Only visible in edit mode |
| Type selector     | Dropdown      | TimeEntryType     | READ      | 14 type options           |
| Duration input    | WheelPicker   | TimeEntry.hours   | CREATE    | Auto-calc from/until      |
| Weekday toggles   | ToggleGroup   | RecurringPattern  | CREATE    | Mon–Sun, recurring tab    |
| Dimension fields  | TextInput[]   | TimeEntry.dims[]  | CREATE    | Configurable per company  |

Claude не просто склав список компонентів — він зрозумів інтент. Побачивши вкладку «Recurring» він правильно передбачив, що має існувати окремий API-ендпоінт для повтроювальних записів. Побачивши кнопку «Delete», що з’являється тільки в режимі редагування, класифікував її як conditional DELETE.

Навіть бізнес-правила задокументував: «якщо заповнені поля From та Until — поле Duration стає readonly і показує автоматично обчислений час».

Витрачено часу: ~15 хвилин на роботу ШІ + ~1 година на мануальну перевірку для гарантії точності та уникнення помилок. Скільки б це зайняло вручну: ~1 день.

👻 Фаза 2: Мережевий розвідник (The Network Ghost)

Тут починається найцікавіше.

Ціль: залогінитись у робочий веб-застосунок, пройтися по модулю Time, перехопити всі API-запити з Network-панелі браузера і зіставити їх із екранами з Фази 1.

Chrome DevTools MCP: що він вміє

Chrome DevTools MCP дає Claude прямий доступ до реального Chrome-вікна — не headless-симулятора, а справжнього браузера, який можна спостерігати в реальному часі. Доступні інструменти:

• navigate — перехід за URL
• click — кліки по елементах
• fill / fill_form — заповнення форм
• take_screenshot — скриншоти для візуальної перевірки
• list_network_requests — перегляд усіх XHR/fetch-запитів
• get_network_request — повні деталі конкретного запиту (headers, body, response)
• execute_javascript — виконання JS в контексті сторінки

Так, AI може дивитися на Network-вкладку.

Промпт

Наступний промпт виглядає також досить просто, єдине — він вказує на URL та логін/пароль:

claude --model opus "Read the phase2-web-tester skill in .claude/skills/. 
Phase 1 output is in output/phase1/.

Log into the web app at https://your-service.com/login with:
- Email: your_email
- Password: your_password

Then explore the Time Logging feature, capture all API network requests, 
and generate the result files in output/phase2/."

Skill-файл Фази 2

.claude/skills/phase2-web-tester.md — найбільший з трьох. Він каже Claude:

1. Спочатку прочитати ВСІ файли з Фази 1 — вони служать як «тест-план»
2. Відкрити Chrome, перейти на сторінку логіну
3. Ввести логін і пароль, натиснути «Submit»
4. Перейти в модуль Time
5. Для кожної дії з тест-плану: виконати дію → перехопити мережеві запити → записати деталі ендпоінта
6. Якщо в дизайні є фіча, а у веб-застосунку її немає — записати як NOT FOUND
7. Згенерувати result_<screen>.md з таблицями знайдених і пропущених ендпоінтів

Ключова ідея: Фаза 1 каже Claude що тестувати, а Claude сам розбирається як взаємодіяти з конкретним UI.

Ось повний набір інструкцій, який ми використовували:

Вміст phase2-web-tester.md:

---
name: phase2-web-tester
description: "Logs into the existing web app, explores the Time feature,
captures network requests, and maps them to the Phase 1 design screens."
---

# Phase 2: Web Testing & Network Sniffing Skill

## Objective
Autonomously explore the current web app's Time Logging feature while
capturing all API calls, then map those calls to the new Figma design screens.

## Prerequisites
- Phase 1 output files must exist in `output/phase1/`
- Chrome DevTools MCP must be connected

## Workflow

### Step 1: Read Phase 1 Outputs
Read ALL `output/phase1/screen_*.md` and `output/phase1/common_ui.md` files.
Build a mental model of:
- Every screen in the new design
- Every expected API operation per screen
- Every user action that needs testing

### Step 2: Launch Browser & Login
Using Chrome DevTools MCP tools:
1. Navigate to the web app login URL
2. Fill in credentials (provided in the prompt)
3. Submit the login form
4. Wait for redirect / dashboard load
5. Take a screenshot to confirm successful login

### Step 3: Navigate to Time Module
1. Find and click the navigation element for Time/Time Logging
2. Take a screenshot of the initial Time view
3. Call `list_network_requests` to capture the initial data-loading API calls

### Step 4: Systematic Feature Exploration
For each user action documented in Phase 1 screen files:
1. **Clear mental network log** (note the current request count)
2. **Perform the action** (click button, fill form, navigate)
3. **Capture network requests** using `list_network_requests`
4. **For each API request captured:**
   - Record: method, URL path, status code, request body (if POST/PUT)
   - Use `get_network_request` for full details on XHR/fetch calls
   - Filter to only API calls (ignore static assets, analytics)
5. **Take a screenshot** after each significant action
6. **Map the request** to the corresponding Phase 1 screen/action

**Exploration priority order:**
1. View/list time entries (READ)
2. Create a new time entry (CREATE)
3. Edit an existing time entry (UPDATE)
4. Delete a time entry (DELETE)
5. Filter/search time entries
6. Approve/decline time entries (if accessible)
7. Any other Time-related features visible in the UI

### Step 5: Generate Result Files
For each Phase 1 screen, create `output/phase2/result_.md`:
# API Mapping: 

## Captured Endpoints
| Action | Method | Endpoint | Status | Request Body | Response Shape |
|--------|--------|----------|--------|-------------|----------------|
| Load entries | GET | /api/v1/time-entries?date=... | 200 | — | { items: [...] } |
| Create entry | POST | /api/v1/time-entries | 201 | { projectId, hours, ... } | { id, ... } |

## Endpoint Details
### GET /api/v1/time-entries
- **Query params observed:** startDate, endDate, employeeId, projectId
- **Response structure:** (document key fields)
- **Pagination:** offset/limit or cursor-based?
- **Auth header:** Bearer token / cookie-based

### POST /api/v1/time-entries
- **Request body:** { ... }
- **Validation observed:** (any 400 responses?)

## ⚠️ MISSING Endpoints (New Design Actions Without Current API Coverage)
| Design Action | Expected Operation | Current Status |
|--------------|-------------------|----------------|
| Bulk approve | PUT (batch) | NOT FOUND in web app |
| Weekly summary | GET (aggregate) | NOT FOUND in web app |

## Notes
- Authentication mechanism: Bearer / Cookie / etc.
- Base URL pattern: https://api.your-service.app/api/v1/...
- Any rate limiting or pagination observed

## Key Rules
 - ONLY capture XHR/Fetch requests to the API domain (api.your-service.app)
 - Ignore: images, CSS, JS bundles, analytics, websocket frames
 - If a web feature doesn't exist for a design screen, note it as ENTIRELY MISSING
 - If you hit an error or can't access a feature, document what happened

Що відбувалося

Я спостерігав у реальному часі, як Claude:

1. Залогінився — відкрив сторінку логіну, заповнив поля, натиснув Submit, зробив скриншот дашборду для підтвердження ✅
2. Знайшов модуль Time — проскролив навігацію, клікнув потрібний пункт ✅
3. Перехопив початкові запити — у момент завантаження сторінки Claude зібрав десятки XHR-запитів: salary cycles, periods, entry types, employment data, dimensions ✅
4. Створив тайм-ентрі — знайшов flow створення, заповнив поля, відправив форму — перехопив POST /api/timeentry з повним request body і response ✅
5. Пройшовся по решті екранів — approval workflows, тижневий вигляд, типи записів, clock-in

Трюк з fetch-інтерцептором

list_network_requests від Chrome DevTools MCP іноді обрізає великі response body. Тому в skill-файлі є fallback — Claude інжектить monkey-patch для fetch прямо на сторінку через execute_javascript:

const _origFetch = window.fetch;
window.__apiLog = [];
window.fetch = async (...args) => {
  const res = await _origFetch(...args);
  const url = typeof args[0] === 'string' ? args[0] : args[0]?.url || '';
  if (url.includes('/api/')) {
    const clone = res.clone();
    window.__apiLog.push({
      url, method: args[1]?.method || 'GET',
      status: clone.status,
      response: await clone.text().catch(() => null)
    });
  }
  return res;
};

Потім Claude забирає повні логи через JSON.stringify(window.__apiLog). Кожен request body. Кожен response. Без обрізання. AI, який патчить рантайм браузера, щоб покращити свою ж спостережуваність — ми живемо в майбутньому :).

Нюанс з ітераціями

Підхід Claude не був ідеальним з першого разу. В output-директорії можна побачити свідчення — шість ітерацій скриптів взаємодії, кожна адаптована під те, що Claude виявив на попередньому кроці:

output/phase2/
├── explore.mjs            (19 KB)  ← Перша спроба: широке дослідження, неправильні селектори
├── explore2.mjs           (15 KB)  ← Уточнені CSS-селектори під Kendo grid
├── explore3.mjs           (15 KB)  ← Адаптація під inline-редагування (не модальна форма)
├── explore_time_deep.mjs  (18 KB)  ← Глибоке дослідження CRUD-потоків тайм-ентрі
├── explore_time_deep2.mjs (14 KB)  ← Дослідження approval workflow
└── explore_final.mjs      ( 8 KB)  ← Фінальний чистий прогін — всі цільові ендпоінти перехоплено

Веб-застосунок використовує Kendo UI inline grid для тайм-ентрі (а не повноекранну форму, як у нових Figma-макетах), тому Claude мусив адаптувати свою стратегію взаємодії. Він ітерував — пробував різні CSS-селектори, підлаштовував тайминги кліків, вивчав поведінку grid’а з редагуванням на місці — поки не знайшов правильний підхід. Саме так працював би й людина-тестувальник, тільки стиснуто в хвилини замість годин.

Найцінніший результат: таблиця «MISSING»

Головна цінність Фази 2 — не ті ендпоінти, які Claude знайшов, а ті, яких він не знайшов:

## ⚠️ MISSING Endpoints
| Design Action              | Expected Operation     | Status                     |
|----------------------------|------------------------|----------------------------|
| Recurring time entry       | POST (recurring rules) | NOT FOUND in web app       |
| Clock-in / punch clock     | POST (punch-in)        | ENTIRE FEATURE MISSING     |
| Bulk approval              | PUT (batch)            | NOT FOUND in web app       |
| Weekly hours summary       | GET (aggregate)        | NOT FOUND in web app       |

Але «NOT FOUND in web app» ≠ «не існує в API». Веб-додаток може просто не використовувати цей ендпоінт. Саме для цього потрібна Фаза 3.

Витрачено часу: ~25 хвилин на виконання ШІ + ~2 години на мануальну перевірку ендпоінтів.
Скільки б це зайняло вручну: ~3 дні.

🔍 Фаза 3: Swagger-детектив (The Swagger Detective)

Ціль: взяти кожен «MISSING» ендпоінт з Фази 2 і пошукати його у Swagger-документації — бо зрілий бекенд часто має більше можливостей, ніж будь-який окремий фронтенд використовує.

Чому ця фаза — найважливіша

Ось важливий факт про бекенд-системи, які розвиваються роками: API-поверхня часто значно більша, ніж те, що використовує конкретний UI. Ендпоінти створюються для адмінок, для внутрішніх інструментів, для фіч, які були депріоритизовані на фронтенді. Ці приховані можливості можуть заощадити тижні бекенд-розробки — якщо знати, що вони існують.

А у нашому Swagger було 500+ задокументованих ендпоінтів і 300+ описів схем. Прошукати вручну — це кілька днів Ctrl+F.

Промпт

Фінальний промпт виглядає також досить просто, єдине — він вказує на URL до Swagger-документації:

claude --model opus "Read the phase3-swagger-reconciler skill in .claude/skills/. 
Phase 2 output is in output/phase2/.

The Swagger docs are at https://api.your-service.app/swagger/

Reconcile all missing endpoints against Swagger and generate the final mapping files in output/phase3/, 
including a MASTER_SUMMARY.md."

Вся «розумна» частина — в skill-файлі. Промпт просто вказує джерело й запускає процес.

Як працює Skill

.claude/skills/phase3-swagger-reconciler.md інструктує Claude:

1. Завантажити Swagger JSON через curl і розпарсити jq
2. Прочитати всі таблиці «MISSING» з Фази 2
3. Для кожного пропущеного ендпоінта — пошукати у Swagger за ключовими словами шляху, HTTP-методом і полями схеми
4. Оцінити: EXACT MATCH (підходить як є), PARTIAL MATCH (потрібна невелика адаптація), NO MATCH (треба будувати)
5. Згенерувати фінальні файли + Файл MASTER_SUMMARY.md

Вміст phase3-swagger-reconciler.md:

---
name: phase3-swagger-reconciler
description: "Cross-references Phase 2 missing endpoints against the Swagger
documentation to find existing but unused endpoints or confirm gaps."
---

# Phase 3: Swagger Reconciliation Skill

## Objective
For every MISSING endpoint identified in Phase 2, search the Swagger/OpenAPI
documentation to find candidate endpoints. Produce a final mapping document
per screen.

## Workflow

### Step 1: Fetch & Parse Swagger
curl -s https://api.your-service.app/swagger/v1/swagger.json | jq '.' > /tmp/swagger.json

If the Swagger UI is at /swagger/, try common JSON endpoints:
 - `/swagger/v1/swagger.json`
 - `/swagger/doc.json`
 - `/api-docs` 

Parse the JSON to extract:
 - All paths and their HTTP methods
 - Request/response schemas
 - Authentication requirements
 - Tag groupings (find the "Time" or "TimeEntry" tag) 

### Step 2: Read Phase 2 Missing Endpoints
 Read ALL `output/phase2/result_*.md` files.
 Extract every row from the "MISSING Endpoints" tables. 

### Step 3: For Each Missing Endpoint
 1. **Search Swagger paths** for related endpoints using:
 - Path keywords (time, entry, entries, approval, timesheet)
 - HTTP method matching (if expecting POST, look for POST endpoints)
 - Schema matching (if the design needs fields X, Y, Z — find endpoints whose request/response schemas contain those fields)

 2. **Evaluate fit:**
 - EXACT MATCH: Endpoint exists and serves the exact purpose
 - PARTIAL MATCH: Endpoint exists but needs query param changes or the response shape differs slightly
 - NO MATCH: No endpoint in Swagger serves this purpose

 3. **For partial matches**, document:
 - What the endpoint provides vs. what the design needs
 - Whether the gap can be handled client-side (filtering, aggregation)
 - Whether a backend change is needed (new query param, new field)

 ### Step 4: Generate Final Output For each screen, create `output/phase3/result_swagger_.md`:
# Final API Mapping: 

## ✅ Confirmed Endpoints (from Phase 2 capture)
| Action | Method | Endpoint | Confidence |
|--------|--------|----------|------------|
| Load entries | GET | /api/v1/time-entries | HIGH — captured live |

## 🔍 Resolved from Swagger (previously missing)
| Design Action | Swagger Endpoint | Fit | Notes |
|--------------|-----------------|-----|-------|
| Bulk approve | PUT /api/v1/time-entries/batch-approve | EXACT | Accepts { ids: [...] } |
| Weekly summary | GET /api/v1/reports/time-summary | PARTIAL | Returns monthly; needs date param |

## 🔴 Requires New Backend Endpoint
| Design Action | Proposed Endpoint | Reason |
|--------------|-------------------|--------|
| Manager dashboard | GET /api/v1/time-entries/team-overview | No existing endpoint provides team-level aggregation |

## Swagger Schema Reference
### TimeEntry (from Swagger definitions)

json { "id": "string", "employeeId": "string", "projectId": "string", "hours": "number", "date": "string (ISO 8601)", "status": "enum: draft|submitted|approved|rejected", "notes": "string" }

## Flutter Implementation Notes
- Auth: Use Bearer token from login endpoint (document which one)
- Base URL: https://api.your-service.app
- Content-Type: application/json
- Pagination: document pattern for list endpoints
- Error handling: document common error response shape

## Output Checklist
 - [ ] Every Phase 2 "confirmed" endpoint carried forward
 - [ ] Every Phase 2 "missing" endpoint resolved or flagged
 - [ ] Swagger schema snippets for all referenced models
 - [ ] Clear BUILD/NO-BUILD verdict for backend team

Результат: сюрприз

Фаза 2 ідентифікувала 33 «пропущених» ендпоінти по 7 екранах. Звучить як ціла гора бекенд-роботи. Але Фаза 3 показала іншу картину:

• ✅ Точний збіг у Swagger: 16 ендпоінтів існує — веб-додаток просто їх не використовує
• 🔍 Частковий збіг: 8 ендпоінтів є, але потрібна клієнтська адаптація
• 🔴 Дійсно відсутній: 9 ендпоінтів, які бекенд-команді потрібно ще реалізувати

Фаза 3 вберегла нас від запиту 24 ендпоінтів, які вже існували.

Без цієї звірки ми б прийшли до бекенд-команди з повідомленням «нам потрібно 33 нових ендпоінти». Вони б витратили час на те, що вже було реалізовано і сиділо в 575-ендпоінтній Swagger-специфікації, яку ніхто не має часу читати від початку до кінця.

Найкращі знахідки

Прихований batch-ендпоінт: Фаза 2 сказала — «немає bulk-створення записів». Фаза 3 знайшла POST /api/timeentry/batch — він був там увесь час, просто веб-додаток його не використовував. Ми можемо реалізувати фічу «Recurring Entry» з Figma-макетів без жодної бекенд-роботи.

Скарбниця з approval-ами: Фаза 2 зловила 2–3 ендпоінти погодження, які використовує веб-додаток. Фаза 3 знайшла ще 10 — approve single, reject with reason, bulk approve by ID list, bulk approve by filter, approve entire period, approve entire cycle. Система погодження вже була enterprise-рівня — просто веб-UI використовував лише найпростіший варіант. Наш Flutter-додаток отримає багатший workflow ніж веб-версія від першого дня.

POST /api/balances: Claude знайшов ендпоінт для отримання даних про баланси (відпустки, овертайм), який використовує POST-with-body замість GET із query-параметрами. Частина, на якому ми б витратили години дебагу, якщо б очікували стандартних REST-конвенцій.

Фінальні вердикти

| Екран               | Вердикт                                                |
|---------------------|--------------------------------------------------------|
| Login               | ✅ BUILD — всі критичні auth-ендпоінти існують          |
| Home Dashboard      | ✅ BUILD — збирається з існуючих ендпоінтів             |
| Calendar / Weekly   | ✅ BUILD — повний CRUD + approval + holidays            |
| Time Entry Form     | ✅ BUILD — повний CRUD, recurring = batch workaround    |
| Entry Type Picker   | ✅ BUILD — список типів підтверджено (12 із 14)         |
| Clock-In            | 🔴 BACKEND REQUIRED — фіча повністю відсутня            |
| Approval Manager    | ✅ BUILD — покриття ендпоінтами повне                   |

Шість із семи екранів можна підключати до існуючого API вже зараз. Тільки Clock-In потребує нових бекенд-ендпоінтів — і навіть там Claude задокументував partial workaround через існуючі поля StartTime/EndTime.

Ось Executive Summary зі згенерованого файлу MASTER_SUMMARY.md:

Витрачено часу: ~10 хвилин на роботу ШІ + ~1 година на мануальну перевірку для гарантії точності та уникнення помилок. Скільки б це зайняло вручну: ~1 день.

📂 Структура проєкту

Вся система — це:

your-project/
├── .claude/
│   ├── skills/
│   │   ├── phase1-design-parser.md
│   │   ├── phase2-web-tester.md
│   │   └── phase3-swagger-reconciler.md
│   ├── scripts/
│   │   └── network-interceptor.js    ← Puppeteer fallback
│   └── settings.local.json           ← permissions
├── .mcp.json                          ← MCP конфіг
└── output/
    ├── phase1/   ← screen_*.md + common_ui.md
    ├── phase2/   ← result_*.md + captured JSON + screenshots
    └── phase3/   ← result_swagger_*.md + MASTER_SUMMARY.md

Три markdown skill-файли. Один JSON-конфіг. Три сесії Claude Code. Ніяких оркестраційних фреймворків.

⚙️ Важливі нюанси

Як і з будь-яким інструментом, тут є моменти, про які варто знати.

Контекстне вікно

Кожна фаза має залишатися в межах ~100k токенів. Фаза 2 — найпроблемніша: одне завантаження сторінки генерує сотні мережевих запитів. Skill-файл включає агресивну фільтрацію (ONLY capture XHR/Fetch to the API domain), щоб Claude не тонув у CSS-файлах та аналітичних пінгах. Для Фази 3 маленький jq-скрипт фільтрує Swagger JSON до time-related ендпоінтів, заощаджуючи ~60% контексту.

Legacy UI ≠ новий дизайн (і це нормально)

Новий Figma-макет показує повноекранну форму тайм-ентрі. Веб-додаток використовує Kendo UI inline grid — ви редагуєте клітинки прямо в таблиці. Claude адаптувався, але це зайняло кілька ітерацій. Lesson learned: skill-файл має описувати що знайти, а не де клікнути. Нехай AI сам розбирається з конкретним UI.

POST-as-GET — реальність legacy API

Існуючий API використовує POST-запити з request body для речей, які логічно мали б бути GET із query-параметрами (наприклад, POST /api/balances замість GET /api/balances?definitionId=X). Claude виявив це під час Фази 2 і задокументував — деталь, на якій Flutter-команда зекономила годину дебагу помилок.

Token ≠ Bearer

API використовує кастомний формат заголовку Authorization, який відрізняється від стандартної схеми Bearer. Маленька деталь, яку Claude перехопив із реальних хедерів. Саме такі речі зазвичай не документуються і коштують розробнику годину безрезультатного пошуку причини 401-х помилок.

AI не замінює ваш аналіз

Claude чудово справляється з рутинною роботою — клікати, записувати, порівнювати. Але інтерпретація результатів, прийняття рішень «що будувати першим», і комунікація з бекенд-командою — це все ще на вас. AI — це інструмент, який усуває найбільш монотонну частину discovery-фази.

📊 Цифри: переведення в бізнес-цінність

Штучний інтелект виконав найважчу рутинну роботу, але перевірка людиною була критично важливою для забезпечення точності та запобігання галюцинаціям при маппінгу. Додавання 1–2 годин на мануальну перевірку після кожної фази означає, що загальне завдання все одно виконується приблизно за півдня, замінюючи повноцінний 40-годинний робочий тиждень.

Що ще заощадили

• 24 ендпоінти, які Фаза 2 позначила як «missing», були знайдені у Swagger — це запобігло зайвим запитам до бекенд-команди
• Batch-ендпоінт (POST /api/timeentry/batch) знайдений в існуючому API — повністю знімає потребу в новому ендпоінті для рекурентних записів
• 10 approval-ендпоінтів знайдено, які веб-додаток не використовує — Flutter-додаток зможе запропонувати глибші можливості з першого релізу
• Повні request/response схеми захоплено для кожного ендпоінта — готові для генерації Dart-моделей через freezed / json_serializable

Головна цінність — не час, а впевненість

Замість того, щоб починати Flutter-розробку з припущеннями про те, що API може і не може, ми маємо:

• Вердикт BUILD / BACKEND REQUIRED для кожного екрана
• Точний інвентар ендпоінтів із формами запитів і відповідей
• Пріоритизований список із 9 реальних бекенд-гепів (із workaround-ами, де можливо)
• Архітектурні нотатки для Flutter-команди (auth-патерни, пагінація, стратегія завантаження даних)

Продакт-менеджери можуть планувати спринти з реальними даними. Бекенд-команда отримує фокусний, пріоритизований список. А мобільна команда починає роботу над шістьма екранами вже зараз, з повною впевненістю в API-контрактах.

Повторюваність

Цей пайплайн — не одноразовий трюк. Skill-файли — це шаблони, які можна використовувати повторно. Спрямуйте їх на будь-яку комбінацію Figma + веб-додаток + Swagger — і весь flow повториться. Наступний маппінг модуля — це три проомпти й перерва на каву.

🚀 Як спробувати самому

Все, що потрібно:

1. Встановити Claude Code CLI (2.x+)

2. Підключити MCP-сервери:

claude mcp add --scope user --transport http figma https://mcp.figma.com/mcp
claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest

3. Написати три skill-файли в .claude/skills/. Ключова структура кожного:

• Objective — одне речення, що таке «готово»
• Workflow — нумеровані кроки
• Output format — точний markdown-шаблон (це клей між фазами)
• Error handling — що робити, коли щось пішло не так

4. Запустити послідовно:

claude --model opus "Follow phase1 skill. Figma URL: "
claude --model opus "Follow phase2 skill. Login:   "
claude --model opus "Follow phase3 skill. Swagger: "

5. Відкрити output/phase3/MASTER_SUMMARY.md — це ваш фінальний делівері.

Висновок

Claude Code з MCP-серверами чудово справляється з рутинною, але критично важливою роботою: розбір дизайнів, тестування веб-додатків, звірка зі Swagger-документацією. Найприємніше — значно менше «контекст-перемикань» між трьома вкладками браузера і табличкою .xlsx.

Але важливо:

• AI не приймає рішення за вас. Він збирає дані й структурує їх — але вибір пріоритетів, комунікація з командою і відповідальність за архітектурні рішення залишаються на інженері.
• Skills — це ключ. Якість результату безпосередньо залежить від якості ваших інструкцій у skill-файлах. Витратьте час на їх написання один раз — і вони працюватимуть для кожного наступного модуля.
• File-based handoffs — це просто і надійно. Кожна фаза незалежно перевірювана. Якщо Фаза 1 щось неправильно визначила — ви можете поправити файл вручну перед запуском Фази 2. Ніяких чорних скриньок.

Цей підхід не замінює розробників — він прибирає найбільш монотонну частину їхньої роботи, щоб вони могли фокусуватися на архітектурі та продукті. І, мабуть, це найкраще застосування AI в розробці на сьогодні.

Happy Coding! 🚀

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.