Skill Mental Model

Miért kell külön „skill” fogalom?

Egy LLM alkalmazásban nagyon gyorsan megjelennek ismétlődő feladatok:

• pull request átnézése,
• support ticket osztályozása,
• incident összefoglalása,
• számlaadatok kinyerése,
• deployment ellenőrzése,
• dokumentáció frissítése.

Ezeket minden alkalommal új promptként is meg lehet fogalmazni, de nagyobb rendszerben hamar szükség lesz egy stabilabb absztrakcióra.

Az Agent Skill hasznos mental modelje:

Egy újrahasznosítható, névvel és határral rendelkező capability, amely meghatározza, hogy egy AI rendszer egy adott feladatosztályt hogyan végezzen el.

A skill nem feltétlenül csak prompt. Tartalmazhat például:

Skill
├── purpose
├── instructions
├── input contract
├── output contract
├── knowledge / context policy
├── tools
├── examples
├── constraints / permissions
└── success / evaluation criteria

Fontos, hogy a skill kifejezés nem univerzálisan szabványosított fogalom. Különböző platformok mást nevezhetnek skillnek. Ebben a knowledge base-ben engineering absztrakcióként használjuk: egy reusable capability contractként.

Prompt vs Skill vs Tool vs Workflow vs Agent

Ezek könnyen összemosódnak, pedig más szinten vannak.

Fogalom	Elsődleges szerep
Prompt	Egy modellhívás viselkedésének instruálása és kontextusa
Tool	Külső művelet vagy adatforrás, amelyet a rendszer meghívhat
Skill	Újrahasznosítható feladat-capability és annak contractja
Workflow	Előre definiált lépések és kontrollfolyam
Agent	Runtime, amely cél alapján döntéseket hozhat és képességeket használhat

Prompt

Egy prompt például:

Review this pull request.
Focus on correctness, architecture and backwards compatibility.
Return findings ordered by severity.

Ez önmagában egy instrukció.

Ha ugyanezt több helyen, stabil input/output formával, fix értékelési szempontokkal és GitHub olvasó toolokkal akarjuk használni, akkor már érdemes skillként kezelni.

Tool

A tool valamilyen konkrét capability:

get_pull_request_diff(pr_number)
read_repository_file(path)
run_tests(test_scope)

A tool nem mondja meg, hogy miért, mikor vagy hogyan kell PR-t review-zni. Csak egy műveletet biztosít.

A PR review skill használhatja ezeket a toolokat.

PR Review Skill
      │
      ├── read_repository_file
      └── get_pull_request_diff

Tehát:

A tool egy mechanikai capability; a skill egy task-level capability.

Workflow

A workflow explicit kontrollfolyam lehet:

1. Fetch PR diff
2. Run static analysis
3. Run tests
4. Ask model for review
5. Publish report

Itt a lépések nagy részét az alkalmazás előre meghatározza.

Egy skill ezzel szemben inkább azt írja le, hogy hogyan kell egy képességet végrehajtani, nem feltétlenül a teljes end-to-end folyamatot.

Agent

Az agent egy magasabb szintű runtime:

Goal
 ↓
Agent
 ├── PR Review Skill
 ├── Test Failure Analysis Skill
 ├── Documentation Skill
 └── tools

Az agent például eldöntheti, hogy a feladat megoldásához először teszthibát kell elemezni, majd PR review-t kell futtatni.

A skill tehát nem maga az agent. Egy agent több skillt használhat.

Reusable capability vs one-off instruction

Nem minden promptból kell skillt csinálni.

Egyszeri kérés:

Fogalmazd át ezt az emailt udvariasabbra.

Ehhez valószínűleg nincs szükség külön skill architektúrára.

Viszont ha egy alkalmazás minden customer escalation emailt ugyanazon policy alapján generál, auditálható outputtal és CRM adatokkal, akkor már indokolt lehet:

Customer Escalation Response Skill

A skill akkor kezd értéket adni, amikor legalább néhány ezek közül fontos:

• ugyanaz a capability sokszor kell,
• több agent vagy workflow használja,
• stabil input/output contract kell,
• toolok tartoznak hozzá,
• domain szabályokat kell követnie,
• külön akarjuk tesztelni/evaluálni,
• külön akarjuk verziózni,
• security vagy permission boundary tartozik hozzá.

Példa: GitHub PR Review Skill

Egy task-level mental model:

Name:
  review_pull_request

Purpose:
  Identify material correctness and architecture risks in a PR.

Inputs:
  repository
  pull_request
  review_focus

Instructions:
  Focus on correctness, architecture, regressions and tests.
  Do not invent code outside the supplied/retrieved repository state.

Tools:
  fetch_diff
  read_file
  read_tests

Output:
  findings[]
  summary
  confidence

Constraints:
  read-only
  never merge or modify the PR

A runtime ezekből összeállíthatja a tényleges modell-inputot és toolkészletet.

A fontos absztrakció:

Application asks for capability
          ↓
    PR Review Skill
          ↓
 model + context + tools
          ↓
      typed result

Az alkalmazásnak így nem kell minden hívásnál újra tudnia a teljes prompt részleteit.

Skill boundary: mi tartozzon egy skillbe?

Egy jó skillnek egy koherens felelőssége van.

Jó határ lehet:

Analyze Test Failure

Túl kicsi lehet:

Explain One Stack Trace Line

Túl nagy lehet:

Develop Software

A túl nagy skill általában több, egymástól független capabilityt mos össze:

Mega Coding Skill
├── requirements analysis
├── architecture
├── coding
├── testing
├── deployment
├── documentation
└── incident response

Ebből nehéz megmondani:

• milyen input kell,
• milyen toolhoz férhet hozzá,
• mi számít sikernek,
• hogyan evaluáljuk,
• hol hibázott.

Jobb:

Requirements Analysis Skill
Architecture Review Skill
Implementation Skill
Test Failure Analysis Skill
Documentation Update Skill

Ezeket később workflow vagy agent komponálhatja.

A skill nem feltétlenül egyetlen modellhívás

Egy skill implementationje lehet egyszerű:

input → LLM → output

De lehet összetettebb is:

input
 ↓
retrieve context
 ↓
LLM selects tool
 ↓
tool result
 ↓
LLM produces structured result

Vagy akár több determinisztikus lépést is használhat.

Ezért fontos különválasztani:

Skill interface
      ≠
Skill implementation

Ugyanazt a skill contractot később más modellel, más prompttal vagy más tool backenddel is meg lehet valósítani.

Ez ugyanaz a gondolkodás, mint egy jól definiált software interface-nél.

Capability vs implementation

Például a skill neve:

Get Current Deployment Health

A skill ne azt ígérje, hogy:

Use Kubernetes API v1 with tool X.

A capability inkább:

Given a deployment target, return its current health and material problems.

A runtime implementálhatja ezt:

Kubernetes tool

vagy később:

Argo CD tool

A skill így kevésbé kötődik infrastruktúra-részletekhez.

Anti-pattern: minden prompt egy skill

Ha minden apró instrukcióból külön skill lesz:

summarize_text
summarize_short_text
summarize_long_text
summarize_markdown
summarize_email
summarize_ticket
...

akkor a skill registry maga válik komplexitássá.

A reusable abstraction csak akkor hasznos, ha ténylegesen van stabil, különálló responsibility.

Anti-pattern: „skill = system prompt”

Egy skill lehet pusztán instruction package, ha az adott platform ezt a modellt használja.

De architekturálisan veszélyes mindig így gondolni rá:

skill = prompt text

mert akkor elvesznek olyan fontos részek, mint:

• input/output contract,
• tool dependency,
• permission boundary,
• version,
• failure semantics,
• evaluation.

Jobb mental model:

skill
  ↓
capability contract
  ↓
one possible implementation
  ↓
prompt + model + tools

Anti-pattern: a skill mint jogosultsági autoritás

Attól, hogy a skill instructionje azt mondja:

Only delete test environments.

még nem szabad a modellre bízni, hogy valóban csak test környezetet töröljön.

A skill leírhatja a szabályt, de az alkalmazásnak determinisztikusan is enforce-olnia kell:

LLM requests delete
       ↓
application authorization
       ↓
environment == TEST ?
       ↓
execute / reject

A skill behavioral abstraction, nem security boundary önmagában.

Mikor ne vezessünk be skillt?

Skill abstraction nélkül egyszerűbb lehet a rendszer, ha:

• csak egyetlen egyszeri modellhívás van,
• nincs reusable behavior,
• nincs külön tool vagy contract,
• nincs szükség külön verziózásra/evaluationre,
• a feladat determinisztikus kóddal egyszerűbben megoldható.

A cél nem az, hogy mindenből agentic abstraction legyen.

A cél:

Ott használjunk skillt, ahol egy stabil task-level capability külön névvel, contracttal és lifecycle-lal valóban csökkenti a rendszer komplexitását.

Takeaways

• A skill nem univerzális szabvány, hanem hasznos engineering abstraction.
• A skill egy reusable task-level capability, nem egyszerűen egy prompt.
• Prompt instruál, tool műveletet biztosít, workflow kontrollfolyamot ad, agent képességeket választ és használhat.
• A skill interface és az implementation legyen különválasztható.
• Jó skillnek koherens responsibilityje és világos boundaryja van.
• Ne készítsünk skillt minden apró promptból, és ne építsünk mindent tudó mega-skilleket.
• A skill instructionje nem helyettesíti az alkalmazás authorization- és validation-boundaryjait.