Hogyan tanítottam meg egy AI-t, hogy navigálja az API Gateway infrastruktúrámat (hogy nekem ne kelljen)

A cikk Bódis Tamás, a Nitrowise AI és BigData vezetőjének angol nyelvű blogbejegyzése alapján készült.

Megjegyzés: A bejegyzésben szereplő összes alkalmazásnév, SAMU azonosító, kulcsalias, felhasználónév és egyéb potenciálisan érzékeny azonosító kitalált példákkal van helyettesítve. A tényleges rendszerazonosítókkal való bármilyen hasonlóság pusztán a véletlen műve.

Amikor az „egyszerű kérdések” egyáltalán nem egyszerűek

Ismerős, amikor valaki Slacken rádír: „Hé, meg tudod nézni, miért nem működik az ügyfél API az UAT-on?”

Elsőre egyszerűnek tűnik, igaz? Csakhogy ez azt jelenti, hogy megnyitsz hét különböző böngészőfület, váltogatsz a négy authentikációs kontextus között, és próbálod felidézni, hogy az adott környezet esetén a „tst1” vagy az „uat8” elnevezést használjuk-e. Ez az én életem Integration Engineerként egy cégnél, ahol még a legegyszerűbb kérdés megválaszolása is maratoni futás az infrastruktúra-tájon. Minden. Egyes. Alkalommal.

Az eszközök labirintusának körbejárása

Képzeld el, hogyan néz ki az „ellenőrizni az ügyfél API-t” valójában:

SwaggerHub tartalmazza az OpenAPI specifikációkat. Különböző csapatok különböző verziókat publikálnak különböző időpontokban. Az ügyfél API? Lehet v0.0.1, v0.0.3, vagy valaki múlt kedden feltolta a v0.0.7-et, és elfelejtette megemlíteni a standupon.

GitLabon vannak a tényleges konfigurációk – values.yaml fájlok, környezet specifikus override-ok, integrációs policy-k és annyi YAML behúzás, hogy egy Python fejlesztő sírva fakadna. Minden API-nak megvan a saját repo-ja, mert nyilván utáljuk magunkat.

A Tyk Gateway több dataplane-en fut (dev, tst1, tst2, uat8, uat13, uat15, prod – igen, tényleg ennyi). Minden környezetnek megvan a saját dashboardja, és természetesen ugyanannak az API-nak mindenhol teljesen különböző belső ID-jai vannak. Mert a következetesség túlértékelt.

A JIRA-ban követjük a munkát, ahol a hibák rejtélyes utalásokat tartalmaznak, mint például „ellenőrizd a CPM integrációt”, valahol a harmadik és negyedik komment között elrejtve. Sok szerencsét ahhoz, hogy kitaláld, hogy a CPM itt valójában a Customer and Party Management-et jelöli.

A SAMU – az Enterprise Architecture eszközünk – állítólag „nem csak az IT részleg, hanem minden érintett számára szeretett eszköz a transzformációs tevékenységekben”. Ezt szó szerint a dokumentációból idéztem. Az igazság? Itt tartjuk a kanonikus elnevezéseket, így ezzel kell együtt élnünk.

A HashiCorp Vault tárolja a secreteket. Nem akarom, hogy az AI közvetlenül hozzáférjen az értékekhez, de az nagyon hasznos tud lenni, ha meg tudja erősíteni azt, hogy „igen, ez a secret létezik és múlt csütörtökön frissítették”.

Az igazi probléma: Halál ezer tab által

Ez az, amit egy „egyszerű” ügyfél API-probléma vizsgálata valójában jelent:

Megnyitom a JIRA-t, és olvasok valami „CPM customer service error”-ról. Első rejtvény: mi a fene az a CPM? Megnézem a SAMU-ban és rájövök, hogy ez a Customer and Party Management azonosító ID00005832-vel. Okos.

Aztán a Tyk Dashboardon keresek minden olyan dolgot, ami tartalmazza az ID00005832-t. Plot twist: három különböző API is fut ez alatt – customer-management, customer-search és customer-notifications. De melyik az, amelyik valóban hibás? Vissza a JIRA-hoz, hogy dekódoljam a homályos leírást.

Miután kitaláltam, hogy melyik API-ról van szó, lekérem a konfigurációját a Tyk-ból, majd ugrok GitLabra, hogy megtaláljam a forrás values.yaml-t. A fájl hivatkozik egy SwaggerHub specifikációra, így most ott tartok, hogy ellenőrzöm az OpenAPI definíciót a SwaggerHub-ban. Amíg ott vagyok, észreveszem, hogy három újabb verzió is létezik a spec-ből. Valószínűleg ellenőrizni kellene, hogy ezek számítanak-e.

És vissza a JIRA-hoz, hogy dokumentáljam a megállapításaimat.

Ez tizenhárom külön lépés öt rendszerben. És még semmit sem javítottam – ez csak a nyomozás.

A nagy villanykörte pillanat: Mi lenne, ha nem kéne ezt csinálnom?

Írtam már scripteket korábban. Sokat. De nem az egyedi feladatok automatizálása a valódi probléma. A kognitív terhelés volt a gyilkos – emlékezni arra, hogy melyik rendszer melyik azonosító formátumot használja, nyomon követni, hogy hol járok a vizsgálati folyamatban, és annyi context-switch, hogy még álmomban is új böngészőfüleket nyitogattam.

Mi lenne, ha egy olyan AI assistantre bízhatnám ezt az egész kuszaságot, ami elég jól érti az infrastruktúránkat, hogy elvégezze helyettem a vizsgálatokat?

Ismerős a helyzet?
Több ügyfelünknél úgy látjuk, hogy az infrastruktúra kivizsgálások hasonló terhelést jelentenek.
Ha szeretnéd, szívesen átbeszéljük, nálatok hogy lehetne AI-t érdemben bevonni.

Miért nem építettem MCP szervereket

Az első megérzésem az volt, hogy Model Context Protocol (MCP) szervereket építsek. Ilyet már korábban is csináltam – remekül működik, ha arra van szükséged, hogy strukturált megoldásra van szükséged. De itt a lényeg: az MCP szerver fejlesztésnek overhead-je van. Protokoll-tudatos kódot írsz, kezeled az állapotváltozásokat, teszteled a kommunikációs réteget. Nem nehéz, de munka.

Gyorsan akartam haladni és iterálni. Ha rájövök, hogy valami nem működik jól, akkor azt Markdown fájl szerkesztésével akarom javítani, nem a szerver kód refaktorálásával.

Claude Skill-ek: a gyorsabb út

A Claude Code-nak a skill rendszere teljesen más megközelítést kínált. Ahelyett, hogy protokoll-infrastruktúrát építettem volna, képes voltam:

• CLI eszközöket létrehozni, amelyek strukturált adatot adnak vissza
• dokumentációkat írni, melyek megtanítják az AI-t ezek használatára
• workflow-kat definiálni, amik irányítják a többlépéses folyamatokat
• iterálni úgy, hogy csak dokumentációs fájlokat szerkesztek

A felismerés, ami mindent megváltoztatott: az AI-nak nem kell komplex protokoll. Egyszerűen csak jó toolokra és világos instrukciókra van szüksége.

Kiderült, hogy az AI tanítása nagyon hasonlít ahhoz, amikor egy nagyon okos gyakornokot tanítasz, aki mindent szó szerint ért, és sosem fárad el az ismétlődő feladatoktól.

Így építettem: Egyszerre egy eszköz

A git history-m úgy néz ki, mint amikor valaki lassan rájön, hogy van valami jó ötlete:

e13adb0 Initial commit: Tyk CLI and utility scripts
6a6b26c Add tyk-gateway skill for Claude
ce640d2 add gitlab connection
92c84ac vault cli based integration into the skill
183e13f reorganized skillset
a18a403 swaggerhub cli tool for the skill

Minden egyes commit egy olyan pillanatot jelképez, amikor azt mondjuk: „Ó, ha ez meglenne, akkor az AI ezt is meg tudná csinálni.”

A 6 CLI tool

tyk-dashboard-cli volt az első. Lekérdezi a Tyk Gateway-t, YAML-t ad vissza. Egyszerű. Így az AI tud API-kat, policy-kat és kulcsokat keresni anélkül, hogy nekem kellene manuálisan navigálnom a dashboardon.

tyk-gitlab-cli jött ezután. Az AI-nak olvasnia kell a konfigurációs fájlokat, ellenőrizni a pipeline-állapotokat, és látnia kell, mely branchek léteznek. GitLab hozzáférést adni olyan volt, mintha átadtam volna neki a királyság kulcsait – jó értelemben.

tyk-jira-cli elkerülhetetlen volt. A kontextusunk fele JIRA-ticketekben él. Az AI most tudja olvasni az issue-kat, kinyerni az információkat és akár strukturált kommenteket írni az eredményeiről. Ez különösen nagy előrelépés.

tyk-integration-naming-cli a rosetta kő. Egy olyan homályos név esetén, mint például „customer”, ez visszaadja a kanonikus SAMU ID-t, az integráció aliast és minden egyéb azonosítót, amire szükség van ahhoz, hogy bárhol keress. Ez az eszköz az oka, hogy a keresések valóban működnek.

tyk-vault-cli biztosítja a read-only secret ellenőrzést. Az AI így megerősítheti, hogy „a secret ezen az útvonalon létezik, múlt kedden frissítették” anélkül, hogy valaha is meglátná a tényleges értéket. A security csapat boldog, én boldog vagyok, mindenki boldog.

tyk-swaggerhub-cli bezárja a kört. Amikor egy JIRA issue említ egy SwaggerHub URL-t, az AI ezt használja ahelyett, hogy megpróbálná közvetlenül lekérni az URL-t (erről a konkrét hiba-módról később).

Tanítás dokumentációval

Itt van valami, amit a saját káromon tanultam meg: mindenben explicitnek kell lenned.

A JIRA CLI dokumentációja tartalmazza ezt a részt:

Az argumentumok szóközzel vannak elválasztva (NEM kettősponttal):

tyk-jira-cli get-issue ILD-2017           # CORRECT
tyk-jira-cli get-issue:ILD-2017           # WRONG

Miért kell ezt szájbarágósan leírnom? Mert tesztelés közben az AI megpróbálta a kettőspontos szintaxist. Többször is. „Okos” tippeket tett a parancs struktúrájára más minták alapján, amiket máshol látott.

Pedánsnak lenni a dokumentációban nem az AI intelligenciájának kétségbevonása, hanem a kétértelműség megszüntetése, hogy ne pazaroljon tokeneket különböző variációk kipróbálására.

A Skill definíciója: Mindent összehangolni

Maga a skill egy SKILL.md fájlban lakik, ami fő koordinátorként szolgál. Néhány szabállyal nyit, amit a saját bőrömön kellett megtanulnom:

KRITIKUS SZABÁLYOK

1. SOHA ne használd a Fetch vagy a WebFetch függvényeket semmilyen URL-hez. Minden külső hozzáférésnek a biztosított CLI eszközökön keresztül kell történnie.
2. A JIRA issue-kban található URL-ek NEM közvetlen hozzáférésre szolgálnak. Elemezze őket, és használja a megfelelő CLI eszközt.
3. SwaggerHub URLek → Owner/ApiName kinyerése → tyk-swaggerhub-cli get api-metadata "Owner/ApiName" használata

Ezek a szabályok azért léteznek, mert az AI természetes ösztöne, amikor URL-t lát, hogy megpróbálja lekérni (fetch). De a belső rendszereink autentikációt igényelnek, amivel az AI közvetlenül nem rendelkezik. A CLI eszközök kezelik ezt a komplexitást.

Szó szerint meg kellett mondanom neki, hogy „nem, ne fetch-eld le, még akkor se, ha URL-nek néz ki”, mire abbahagyta a próbálkozást.

A furcsa elnevezési konvencióink megértése

Az egyik legtrükkösebb rész a domain modellünk kódolása volt:

Core koncepció: Egy ID, több API

KRITIKUS: Egyetlen samu_id (pl.: ID00007219) gyakran többOAS API-hoz is kapcsolódik, nem csak egyhez.

Ez azért történik, mert a mi világunkban egy „Alkalmazás” egy logikai csomagoló, és alatta több microservice lakik, mindegyik saját API definícióval. Mindegyik ugyanazon a SAMU ID-n osztozik, de különböző service nevük van.

Példa: egy ID, több API

Application: Order Management (ID00007219)
├── API: order-processing        (samu_id: ID00007219, service_name: order-processing)
├── API: order-tracking          (samu_id: ID00007219, service_name: order-tracking)
└── API: order-fulfillment       (samu_id: ID00007219, service_name: order-fulfillment)

Ennek megértése nélkül az AI őszintén összezavarodott, amikor a „customer API” keresése három találatot adott. Most már tudja, hogy ez az elvárt működés, nem hiba.

Workflow-k: A valódi varázslat

Az egyedi eszközök jók, de a workflow-k azok, ahol a valódi érték rejlik. Ezek kódolják a problémamegoldás tényleges folyamatát.

Az API Kivizsgálási Workflow

Ez a workflow végigviszi az AI-t egy teljes kivizsgáláson:

# 1. Get JIRA context
tyk-jira-cli get-issue PROJ-123

# 2. Resolve fuzzy names to real identifiers (CRITICAL step)
tyk-integration-naming-cli search application "customer"

# 3. Find API in Tyk
tyk-dashboard-cli search oas "ID00008541"

# 4. Get GitLab configuration
tyk-gitlab-cli get file <project-id> values.yaml

# ... and so on

A workflow folytatódik az OpenAPI specifikációk ellenőrzésével, a deploymentek vizsgálatával és a JIRA frissítésével a megállapítások alapján. Ez az én nyomozási folyamatom, kódba öntve.

Az OpenAPI Verzióellenőrző Workflow

Ez kifejezetten azért létezik, mert meguntam nézni, ahogy az AI próbálja lekérni a SwaggerHub URL-eket:

KRITIKUS: Soha ne fetch-elj SwaggerHub URL-eket

Ha ezt látod:

https://swaggerhub.kubeapps.pgsm.hu/apis/ACME/OrderManagementService/0.0.3

Nyerd ki: ACME/OrderManagementService és használd:

tyk-swaggerhub-cli get api-metadata "ACME/OrderManagementService"

Egy dedikált munkafolyamat létrehozására volt szükség explicit példákkal, mielőtt ez végleg elakadt.

A Repository Módosítási Workflow

Amikor tényleg változtatnod kell a dolgokon:

# 1. Get current config from GitLab
tyk-gitlab-cli get file <project-id> values.yaml --by-id

# 2. Find available versions in SwaggerHub
tyk-swaggerhub-cli get api-metadata "ACME/OrderManagementService"

# 3. Verify the new version spec is valid
tyk-swaggerhub-cli get api "ACME/OrderManagementService/0.0.5"

# 4. Clone repo, update, commit, push, create MR

Ez a munkafolyamat további dokumentációra is hivatkozik a Helm konfigurációs szintaxisával, a felsőbb rétegű hitelesítési mintákkal és middleware-ek beállításával kapcsolatban.

Hogyan épül fel minden?

A képességnek van egy build folyamata, ami mindent összeállít:

skills/                           # Source (edit here)
└── company-integration-engineer/
    ├── SKILL.md
    └── workflows/
        ├── api-investigation.md
        └── ...

tyk/                              # CLI docs
├── tyk-dashboard-cli.md
└── ...

skill_dist/                       # Built artifact
└── company-integration-engineer/
    ├── SKILL.md
    ├── workflows/
    ├── tools/
    └── tyk-editor/

A ./build_skill_dist.sh futtatása mindent egy terjeszthető csomagba másol, amelyet a Claude Code fel tud használni.

Az iterációs folyamat (Vagy: tanulás a hibákból)

Semmi sem működött tökéletesen elsőre. Vagy másodikra. Íme, mi tört el, és hogyan javítottam meg:

Probléma: Rossz parancs szintaxis. Az AI megpróbálta a tyk-jira-cli get-issue:ILD-2017 parancsot kettősponttal.
Megoldás: Explicit példákat adtam hozzá a helyes vs. helytelen használatról minden CLI doksihoz.

Probléma: URL-ek közvetlen lekérése. Talált egy SwaggerHub URL-t a JIRA-ban, és WebFetch-et próbált a CLI helyett.
Megoldás: Hozzáadtam a CRITICAL RULES-t a tetejére, plusz egy dedikált workflow-t, ami bemutatja az URL-to-CLI transzformációt.

Probléma: CLI opciók találgatása. Olyan opciókkal próbálkozott, mint --query vagy --project, amik nem léteztek.
Megoldás: Dokumentáltam a tényleges opciókat gyakori mintákkal példaként.

Probléma: SAMU keresés kihagyása. Közvetlenül a Tyk-ban keresett szabad szöveggel, eredménytelenül.
Megoldás: Az Integration Naming-et tettem az explicit „START HERE” lépéssé minden workflow-ban.

Minden hiba jobbá tette a dokumentációt. Az AI sosem lett frusztrált a javításaimtól, ami üdítő ahhoz képest, amikor hús-vér embereknek magyarázol. Bár néha még mindig elfelejt néhány utasítást, amit korábban már elmondtam neki.

Hogyan néz ki a gyakorlatban

Most már kérhetem ezt: „Ellenőrizd az ILD-2017 JIRA issue-t, és nézd meg, van-e újabb OpenAPI verzió.”

Az AI:

1. Lekéri a JIRA issue-t.
2. Kinyeri a SwaggerHub hivatkozást a leírásból.
3. Használja a CLI-t az elérhető verziók ellenőrzésére.
4. Jelentést tesz az aktuális verzióval, a legfrissebb verzióval és javaslatokkal.

Ami régen 15 percet vett igénybe öt rendszeren keresztül, most körülbelül 30 másodperc.

Valós use-case-ek a mindennapi munkából

1. use-case: OpenAPI verzióelemzés automatikusan generált JIRA kommenttel

A kérés: Nézd meg, van-e újabb OpenAPI verzió az ebben a JIRA issue-ban szereplő API-hoz.

Az AI lekérte az issue-t, megtalálta a SwaggerHub hivatkozást, és lekérdezte az összes elérhető verziót:

tyk-jira-cli get-issue ILD-2017
tyk-swaggerhub-cli get api-metadata "ACME/OrderManagementService"

Felfedezett hét verziót, azonosította, hogy három újabb verzió létezik annál, mint amire az issue hivatkozik, majd megkértem, hogy „írj egy kommentet a JIRA issue-hoz, ami leírja az elemzésedet”.

Az AI megformázott egy professzionális kommentet verzióösszehasonlító táblázattal, teljes előzménnyel és javaslatokkal, majd hozzáadta:

tyk-jira-cli add-comment ILD-2017 "OpenAPI Version Analysis..."

Nem kellett megírnom a kommentet. Nem kellett formáznom. Az AI megcsinálta mindezt az alapján, amit talált.

2. use-case: Policy szám elemzés

A kérés: Keresd meg a team/integration kulcsot, és számold meg, hány policy kapcsolódik hozzá.

tyk-dashboard-cli search key --filter-alias "team/integration"
# Found: 687 policies

tyk-dashboard-cli get key "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6"
# 94 direct API access rights, full breakdown by application

Az AI teljes elemzést adott: összes policy, közvetlen hozzáférési jogok, lebontás rendszerenként, környezeti címkék. Aztán beszélgettünk a kapacitástervezésről – előrevetítve, hogy a teljes deployment mind az 5 PREPROD környezetben 100%-os lefedettséggel nagyjából 6800 policy-t jelentene ezen a kulcson.

Ez az a fajta insight, aminek a manuális összeállítása egy órámba telt volna.

3. use-case: Amikor az AI új eszközöket épít

A kérés: Készíts egy jelentést az összes kulcsról és a policy számaikról.

Ahelyett, hogy lefuttatott volna 103 egyedi lekérdezést, az AI felismerte ezt scriptelési lehetőségként, és írt egy shell scriptet:

#!/bin/bash
# Query all keys with pagination (11 pages)
# Extract alias and policy count
# Sort by count descending
# Output formatted report

Az eredmény egy újrahasznosítható script volt, ami ilyen jelentéseket generál:

team/integration: 687 policies
consumer/app-alpha: 512 policies
consumer/mobile-gateway: 489 policies
consumer/partner-api: 463 policies
...
(103 keys total)

Az AI a CLI eszközök megértését felhasználva új automatizációt épített rájuk. Eszközöket adtam neki, és ő további eszközöket hozott létre. Ekkor tudtam, hogy ez működik.

Kibővített dokumentáció: A Tyk Editor

Amikor API konfigurációkat módosítunk, a szintaxis számít. Nagyon. A skill tartalmazza a Tyk Resource Deployer dokumentációt (a „Tyk Editor” doksimat):

tyk-editor/
├── index.md
├── helm/
│   ├── upstream.md
│   ├── middlewares.md
│   ├── plugins.md
│   └── x-tyk-config.md
├── cicd/
│   └── ...
└── tyk/
    └── ...

Amikor az AI-nak módosítania kell egy values.yaml fájlt, ezekre a dokumentumokra hivatkozik, hogy megértse az upstream authentikációt, a header transzformációkat, a végpont szintű middleware-t és a Helm templating mintákat.

A Repository Modification workflow explicit módon irányítja:

Olvasd el a releváns dokumentumokat a tyk-editor/-ból, MIELŐTT bármin változtatsz:

• Upstream/auth → tyk-editor/helm/upstream.md
• Middlewares → tyk-editor/helm/middlewares.md
• Plugins → tyk-editor/helm/plugins.md

Működő minták

1. A strukturált output megkönnyíti a láncolást

Minden CLI eszköz YAML-t ad ki. Ez nem véletlen:

apis:
  - api_version: 0.0.6
    versions: [0.0.1, 0.0.2, 0.0.3, 0.0.4, 0.0.5, 0.0.6]

Az AI parsolja ezt, összehasonlítja a verziókat, és eldönti, mi legyen a következő lépés. Nincs szükség további utasításokra.

2. A környezeti kategóriák jobbak a nyers környezetneveknél

Ahelyett, hogy egyedi környezetekkel foglalkoznánk, kategóriákba szervezzük őket:

• NONPROD → dev (saját consumer kulcsai vannak)
• PREPROD → tst1, tst2, uat8, uat13, uat15 (alapértelmezett a legtöbb munkához)
• PROD → prod (minden elkülönítve)

Ez egyezik azzal, ahogyan valójában gondolkodunk.

3. A „KEZDD ITT” minta

Minden workflow az Integration Naming-gel kezdődik:

# Before anything else:
tyk-integration-naming-cli search application "customer"
# → id: ID00005832, integration_alias: cpm

# Now search with confidence:
tyk-dashboard-cli search oas "ID00005832"
tyk-gitlab-cli search projects "cpm"

Ennek a lépésnek a kihagyása üres vagy hibás eredményekhez vezet. Kötelező első lépéssé tétele a hibák egy teljes kategóriáját küszöbölte ki.

4. Mutasd meg a rossz módszert is

Minden CLI dokumentáció tartalmaz explicit példákat a helytelen használatra:

# CORRECT:
tyk-gitlab-cli search projects "name"

# WRONG:
tyk-gitlab-cli search:projects "name"      # colon syntax doesn't work
tyk-gitlab-cli get file --project 636      # this option doesn't exist

Megmutatni azt, ami nem működik, meglepően hatékony.

5. Az URL-ek adatok, nem végpontok

Ez egy mentális váltás volt számomra és az AI számára is. Amikor találsz egy URL-t a JIRA-ban, kezeld parsolandó adatként:

URL: https://swaggerhub.example.com/apis/ACME/ServiceName/0.0.3
                              ↓
Extract: ACME/ServiceName
                              ↓
CLI: tyk-swaggerhub-cli get api-metadata "ACME/ServiceName"

Ugyanez a minta érvényes a GitLab URL-ekre, Tyk Dashboard linkekre, mindenre.

6. A megoldások eszközökké válnak

Amikor az AI megold egy komplex feladatot, az a megoldás újrahasznosítható scriptté válhat. A policy számlálós példa ezt gyönyörűen megmutatta – egy egyszeri lekérdezés tartós eszközzé vált.

Az AI elég jól érti a CLI mintákat ahhoz, hogy ciklusokba, feltételes ágakba és adattranszformációkba rendezze őket. Az eredeti skill megsokszorozza önmagát.

Amit az AI skillek építéséről tanultam

Kezdj CLI-kkel, ne protokollokkal. Egy jól megtervezett CLI, ami strukturált adatot ad ki, minden, amire szükséged van. Hagyd a szerver-infrastruktúrát.

A dokumentáció szó szerint tréningadat. A dokumentációd minősége közvetlenül meghatározza, milyen jól teljesít az AI. Légy explicit. Mutass példákat. Számíts a hibákra.

Iterálj a tényleges hibák alapján. Figyeld, hogyan használja az AI a skilledet, azonosítsd, hol rontja el, és javítsd azokat a konkrét eseteket. Minden finomítás javítja az összes jövőbeli végrehajtást.

A korlátok funkciók. Megmondani az AI-nak, mit NE tegyen, hibák teljes kategóriáit előzi meg. A CRITICAL RULES szekció nem opcionális.

A workflow-k kódolják a szakértelmet. Az egyedi eszközök hasznosak, de a workflow-k, amelyek kombinálják őket – ott lakik a domaintudásod, és ott van a valódi érték.

Workflow dokumentációs minták

A döntési fák működnek

A workflow-k explicit elágazási logikát tartalmaznak:

If values.yaml Has SwaggerHub Reference

When OAS.openapi contains /Owner/Api/Version:

tyk-swaggerhub-cli get api "Owner/Api/Version"

If values.yaml Has Local File Reference

When OAS.openapi starts with ./:

tyk-gitlab-cli get file <project-id> openapi.yaml --by-id

Ez kezeli azt a feltételes logikát, ami egyébként próbálgatást igényelne.

Verifikációs ellenőrzőlisták

A workflow-k explicit verifikációval végződnek:

Verification Checklist

• Entity resolved in Integration Naming
• Pipeline status: success
• API active in Tyk
• SAMU ID matches across systems
• Consumer keys exist in Vault

Az AI nem hirdet győzelmet idő előtt.

Gyakori hibák táblázatok

A workflow-k explicit anti-patternöket tartalmaznak:

Wrong	Right
Fetch(https://swaggerhub...)	tyk-swaggerhub-cli get api-metadata
WebFetch(url)	Use the CLI tool
Opening in browser	Use CLI commands

A kontrasztos formátum meglepően hatékony.

Mezőleképezés rendszerek között

A komplex rendszereknek vannak mezőik, amelyek egymásra képeződnek le:

Integration Naming	values.yaml	Tyk API Name	Policy Name
id: ID00008541	samu_id: ID00008541	contains ID00008541	id00008541-...
integration_alias: cpm	integration_alias: cpm	path contains cpm	–

Ez segít az AI-nak megérteni, hogy ugyanaz a dolog máshogy jelenik meg mindenhol – itt nagybetűvel, ott kisbetűvel, egyik helyen előtaggal, máshol utótaggal.

Hogyan fut a gyakorlatban

Amikor elindítom a skillt egy feladattal:

1. Skill betöltése – A Claude Code betölti a SKILL.md-t, először látja a CRITICAL RULES-t.
2. Kontextus létrehozása – Az AI megérti a szerepét és a korlátait.
3. Workflow kiválasztása – Kiválasztja a megfelelő workflow-t a feladat alapján.
4. Eszköz dokumentáció – Elolvassa a releváns CLI dokumentumokat végrehajtás előtt.
5. Végrehajtás – Futtatja a parancsokat helyes szintaxissal.
6. Ellenőrzés – Ellenőrzi az eredményeket az elvárt minták alapján.
7. Jelentés – Formázza a megállapításokat (táblázatok, JIRA kommentek stb.).

A SKILL.md orchestrál mindent, a workflow-kra mutatva a feladatokhoz és az eszköz dokumentumokra a végrehajtási részletekhez.

Hogyan tovább

Az alapok szilárdak. A jövőbeli lehetőségek közé tartozik:

• Automatizált deployment verifikáció – Verifikációs workflow futtatása automatikusan a pipeline befejezése után.
• Környezetek közötti drift detection – Configok összehasonlítása mindenhol, eltérések jelzése.
• Consumer hozzáférés auditálás – Rendszeres jelentések arról, kinek mihez van hozzáférése.
• Verziófrissítési ajánlások – Proaktív értesítések az újabb OpenAPI verziókról.

Ezek mindegyike csak egy újabb workflow a meglévő CLI eszközök kihasználásával.

Még mindig fejlődik

A skill folyamatosan javul. Találok edge case-eket, adok hozzá új workflow-kat, finomítom a dokumentációt. De az alap stabil, és minden fejlesztés megsokszorozza a rendszer képességeit.

A kulcsfontosságú felismerés: ezt sokkal könnyebb megépíteni, mint gondolnád. Nem kell AI szakértőnek lenned, vagy komplex infrastruktúrát építened. Amire szükséged van:

• Jó CLI eszközök, amelyek strukturált adatot adnak ki.
• Világos dokumentáció példákkal.
• Hajlandóság az iterálásra a hibák alapján.

Az AI elintézi a többit.

A számok nyelvén

CLI Eszközök: 6 specializált parancssori interfész, amelyek lefedik a Tyk, GitLab, JIRA, SAMU, Vault és SwaggerHub rendszereket.

Workflow-k: 6 vezetett folyamat, amelyek kódolják a kivizsgálási és módosítási mintákat.

Időmegtakarítás: A kivizsgálás ~15 percről ~30 másodpercre csökkent.

Valós adatok a használatból:

• 103 consumer kulcs követése környezeteken keresztül.
• 687 policy egyetlen kulcson (tervezett 6800 a teljes deploymentnél).
• 7 felfedezett OpenAPI verzió egyetlen lekérdezésben.
• Automatizált JIRA kommentek strukturált elemzéssel.

Mit jelentene ez a ti infrastruktúrátokban?

Ez a cikk egy konkrét belső rendszerre épült, de a minta sok nagyvállalati környezetben megismételhető:
API Gateway-ek, több környezet, széttöredezett tooling, magas context-switch költség.

Ha CTO-ként vagy DevOps / Platform vezetőként kíváncsi vagy, hogyan lehet ezt biztonságosan és kontrolláltan AI-jal támogatni, szívesen végigmegyünk rajta együtt.

Ez a skill egy folyamatos evolúciót képvisel abban, ahogyan dolgozom. Minden iteráció okosabbá teszi a rendszert, minden új use-case lehetőségeket tár fel. Az AI a jobb dokumentációból tanul, nem komplex tréningből. És őszintén? Ez a legjobb része.

Tamás Bódis