## Forrás

[Building verification loops in Claude Code with skills](https://claude.com/blog/building-verification-loops-in-claude-code-with-skills). Anthropic blog, Delba de Oliveira tollából, 2026. július 22.

## Összegzés

A cikk a verifikációs hurkokat (verification loops) mutatja be, mint a Claude Code egyik alapvető mintáját. Az ismétlődő kézi ellenőrzési lépéseket skill-ekbe csomagolva a Claude maga zárja a visszacsatolási kört, és az ember más feladatra szabadul fel. A verifikációs hurok három fázisból áll: kontextusgyűjtés, cselekvés, eredmény-ellenőrzés. Az utolsó fázist érdemes skill-be önteni, ha a manuális lépések ismétlődnek. A skill-be öntés négyféle mintát követ: standalone (kézi hívás), embedded (a létrehozó skill része), chained (skill hív skillt), és on-every-PR (CI automatikus). A kulcsszó a description mező, ami az első 57 karakterében hordozza a trigger-erőt.

## A lényeg

Három építőkocka a verifikációs hurok kialakításához. Először a beépített mechanizmusok: a `/verify` skill (önálló build/check), a toolchain-figyelés (linter, type checker, futásidejű hibák), a Code Review multi-agent service, a GitHub Actions integráció, és a Spec Validation skill (markdown spec ellenőrzés). Másodszor a saját hurok megírása: írd le a manuális lépéseket, kérdezd meg a Claude-ot a best practices-ről, és kódold `SKILL.md` fájlba (a skill-creator plugin interjúja a leggyorsabb út). Harmadszor az indítási minta: standalone-tól az embedded-en át a chained-ig, fokozatosan növelve az automatizmust, ahogy a skill stabilizálódik.

A sikeres verifikációs hurok legfontosabb eleme a description mező. Az LLM ez alapján dönti el, hogy behívja-e a skillt. Ha a description túl általános, a skill sosem fut le; ha túl specifikus, hamis pozitívok jönnek. Az arány megtalálása maga a skill authoring feladata; a cikk ezt "match the check to where it runs" néven írja le. A description első 57 karaktere a kritikus trigger-zóna; e felett a többi mező (Related Skills, do_not_use_for) csak a szűkítést szolgálja.

A chained verifikáció formálisan is lezárja a teljes fejlesztési ciklust: a `/simplify` skill hívja a `/verify`-t, ami a Code Review-t, és így tovább. A wrapper skill formálisan kodifikálja a megszokott sorrendet. Ami eddig "megszokás" volt ("mindig futtatom a /verify-t a /simplify után"), az mostantól contract (a /simplify MINDIG hívja a /verify-t, amikor kész). A token-költség nő, de a kézi figyelemigény csökken. A cikk hangsúlyozza: a chain bevezetése előtt tesztelni kell a lokális workflow-ban, mert a hibás chain szélesebb körben is hibásan fut.

## Kulcs pontok

- A verifikációs hurok három fázisa: kontextusgyűjtés, cselekvés, eredmény-ellenőrzés. Az utolsó fázis ismétlődés esetén skill-be önthető.
- A beépített verifikációs eszközök: `/verify` skill, toolchain-alapú hibafigyelés (linter, type checker, futásidejű hibák), Code Review multi-agent research preview, GitHub Actions integráció, Spec Validation skill (markdown spec ellenőrzés).
- A saját verifikációs hurok írása: manuális lépések leírása, skill-creator plugin vagy kézzel írt `SKILL.md` fájl, description mező a triggerhez. A skill-creator interjúja a leggyorsabb út, ha az agent már van, akinek a munkáját rendszeresen ellenőrzöd.
- A verifikációs hurok indítási mintái: standalone (kézi), embedded (a producing skill részeként), chained (skill hív skillt), on-every-PR (CI automatikus); fokozatos bevezetés az automatizmusba, ahogy a skill stabilizálódik.
- A description mező az első 57 karakterében hordozza a trigger-erőt; ez a teljes verifikációs rendszer kritikus pontja. Ha a description fuzzy vagy általános, a skill sosem fut le, vagy rossz kontextusban fut le.
- A chained verifikáció csökkenti az emberi figyelmet, de token-költséget növel. A cikk kifejezetten ajánlja a chain lokális tesztelését széles bevezetés előtt.
- A verifikációs hurok a személyes infrastruktúrától a team infrastruktúráig terjedhet: ami magánszinten megfogja a hibákat, az PR-szinten is megfogja mások commitjaira.
- A "pro tip" a cikkből: a verification check nem kell, hogy kvalitatív legyen. Determinisztikus szabály is lehet ("ne migráljunk oszlopot backfill nélkül"), amit a generikus linter nem fog meg, de a projekt-specifikus loop megfog.

## Hogyan kapcsolódik a saját működésünkhöz

A cikk egy-az-egyben leírja azt a mintát, amit a saját SOUL.md "PID control = feedback loop" néven említ. A `podcast-processing` + `media-pipeline-post-processing` skillpáros már megvalósítja az anti-style post-process, auto-review gate, és high-confidence-only promote policy formájában. Az újdonság a cikkben a "spec validation" pattern önálló skill formájában: a Nuclear Pulse-hoz most külön `verify-nuclear-pulse-spec` skill készült, ami 9 hard rule-t és 3 soft rule-t ellenőriz, és a `references/SPEC.md`-ben van dokumentálva, hogy a szabályok verziózottan kezelhetők legyenek.

A másik kézzelfogható előny a `simplify-after-patch` skill. Ez az embedded wrapper minta saját implementációja: a `simplify-code` skill (ami a 3-agent parallel review-t végzi) most már opt-in auto-triggerként fut le substantív code patchek után, de csendben marad typos és olvasási műveletek után. A trade-off explicit: a 3-agent fan-out drága, ezért a trigger küszöb magas. A cikk ezt "match the check to where it runs" néven írja le, és a mi implementációnk ezt a Phase 1–3 logikával valósítja meg (Phase 1: trigger feltételek ellenőrzése; Phase 2: emberi megerősítés kérése; Phase 3: hand-off a `simplify-code`-nak).

A harmadik kézzelfogható match a Rubrics in Claude Managed Agents (beta) mintával van, de a mi rendszerünkben ez az `auto_review.py` LLM-mock scorer. A különbség: az Anthropic-féle megoldás egy külön grader agent, míg nálunk a mock LLM egyetlen subagent-szerű hívás, ami a summary-t pontozza. A cél azonos: külső, determinisztikus ítész, aki az elfogultság-mentes pontozást adja. A mi rendszerünkben ez a `auto-review-history.json`-ba kerül, és a golden dataset promote policy onnan veszi a high-confidence entry-ket.

A negyedik kapcsolódási pont a chained wrapper skill-ek általános mintája. A `media-pipeline-post-processing` most már formálisan is chain leíróval rendelkezik (4 lépés: tmp cleanup → concat → post-process → auto-review gate). Ez volt az első konkrét alkalmazása a "chained" mintának a mi rendszerünkben, és a cikk megerősíti, hogy ez a helyes irány. A további chain-ekre jelöltek: a `simplify-after-patch` → `simplify-code` lánc (már megvalósítva), és egy jövőbeli `lint-after-patch` → `code-review` lánc, ami a script-szintű ellenőrzéseket automatizálná a code patchekhez.

## Záró intelem

Ha a verifikációs hurok nem differenciál a tipikus és a ritka ellenőrzések között, akkor vagy túl sokat fut (token-költség felzabálja a sessiont), vagy túl keveset (emberi figyelem kell mindenhol). Az arány megtalálása a skill authoring feladata. A `simplify-after-patch` most ezt kísérli meg: opt-in auto-trigger, csak substantív patchekre, különben csend. A tapasztalatok előttünk: ha a küszöböt túl alacsonyra állítjuk, a session zajossá válik; ha túl magasra, a hibák átcsúsznak.

A másik intelem a chained verifikáció költségvetése. A cikk hangsúlyozza, hogy a chain széles bevezetése előtt tesztelni kell. A mi rendszerünkben a chain komplexitás jelenleg alacsony (3-4 lépés), és a pipeline-ok dedikált staging mappákban futnak, így a chain-hiba hatása korlátozott. Ha a chain komplexitás nő (pl. egy „release-ready” pipeline 6+ lépéssel), a tesztelési stratégiát újra kell gondolni.

A harmadik intelem a description mező auditálhatósága. A skill leírók első 57 karaktere a trigger; ha ez elromlik (pl. egy commit túl általánossá teszi), a skill láthatatlanná válik. A megelőzés: a skill authoring checklist tartalmazza a description-mező auditot, és a simplify-after-patch a description-t is ellenőrzi a 3-agent review során (kategorizálva: a description triggerere a harmadik review-terület).

## Hivatkozások

[1] Anthropic blog: Building verification loops in Claude Code with skills, 2026. július 22., Delba de Oliveira
[2] A szerzőhöz kapcsolódó loop engineering cikk: Getting started with loops, 2026. június 30.
[3] Kontextuális háttér: The new rules of context engineering for Claude 5 generation models, 2026. július 24.

## Források

1. Anthropic blog: [Building verification loops in Claude Code with skills](https://claude.com/blog/building-verification-loops-in-claude-code-with-skills), 2026. július 22., Delba de Oliveira. A cikk a verification loops mint verification patternt írja le, négy indítási mintával (standalone, embedded, chained, on-PR).
2. Loop engineering sorozat: Getting started with loops, 2026. június 30., Anthropic Engineering blog. A bevezető cikk a loops alapjait tárgyalja, mielőtt a verifikációs-specifikus részletekbe megy.
3. Context engineering háttér: The new rules of context engineering for Claude 5 generation models, 2026. július 24., Anthropic Engineering blog. A context-window kezelés és a verifikációs hurkok kapcsolatát írja le, különösen a hosszú kontextusú session-ök cost-vs-attention trade-offját.

## Belső referenciák

- **SOUL.md**, "PID control = feedback loop" mint a feedback rendszerünk alapmetaforája. A verifikációs hurkok ezt a PID-szabályozó hurok P (azonnali korrekció) és I (heti review) komponenseit testesítik meg.
- **`podcast-processing`** skill, a `media-pipeline-post-processing` chain első konkrét alkalmazója. A chain 4 lépése: tmp cleanup → concat → terminus/anti-style post-process → auto-review gate.
- **`media-pipeline-post-processing`** skill, a most frissített chain leíróval (4 lépés explicit sorrendben + score küszöbök: ≥0.80 high-confidence, 0.70–0.79 manual accept, <0.70 reject+rewrite, NEVER passive accept).
- **`simplify-code`** skill, a standalone 3-agent parallel review. A `simplify-after-patch` wrapper most már opt-in auto-triggerként fut le substantív patchekre.
- **`simplify-after-patch`** skill, az embedded wrapper minta saját implementációja. Az opt-in küszöb: SKILL.md body edit, új skill scaffold, ≥3 fájl code patch. Typos és olvasási műveletek kimaradnak.
- **`nuclear-pulse-weekly/SPEC.md`**, a spec validation pattern saját alkalmazása. 9 hard rule (címformátum, H2-ek, narrative constraint, stb.) + 3 soft rule (em dash, filler words, corporate-register verbs).
- **`verify-nuclear-pulse-spec`** skill, a spec alapján önállóan futtatható verification skill. R1–R9 hard checks, W1–W3 soft warnings, 5 fázisú verdikt.
- **`auto_review.py`** script, a mock LLM scorer (a `podcast-processing` reference mappájában). A score-ok a -ba kerülnek, és a golden dataset promote policy onnan veszi a high-confidence entry-ket (score ≥ 0.80).
- **`MEMORY.md`** `Pipeline lessons` szekció, az itt dokumentált `TARGET_WORD_COUNT 2000-2800/rész` és a `HU accent pitfall` tanulságok a pipeline-ok alapvető korlátai.

## Kapcsolódó belső források

A wiki a `[ai automation](../../topics/ai-automation.md)` topic-ot ajánlja fel a tárolási helynek, mivel a verifikációs hurkok az AI agent authoring részét képezik. A `media pipeline post processing` wiki entry a chain-leíró belső referenciája. A `podcast pipeline architecture` (ha létezik) a podcast-összefoglalók pipeline-leírását tartalmazza, és a verifikációs hurok ennek a pipeline-nak a post-processing lépése.