Skill Composition and Reuse¶

Miért kell composition?¶

Ha minden skill egy fókuszált capability, akkor egy valódi user goal gyakran több skill együttműködését igényli.

Például:

"Nézd meg ezt a hibás PR-t, javítsd a tesztet és frissítsd a dokumentációt."

Ez több külön responsibility:

PR Review Skill
Test Failure Analysis Skill
Implementation Skill
Documentation Update Skill

A kérdés:

Hogyan kombináljuk ezeket úgy, hogy ne egy új mega-skill legyen belőlük?

Ez a skill composition problémája.

Atomic vs composite capability¶

Egy atomic skill egy jól körülhatárolt task-level responsibility.

Például:

Analyze Test Failure

Egy composite capability több ilyen skill eredményét használhatja:

Resolve Failing Pull Request
├── review_pull_request
├── analyze_test_failure
├── propose_code_change
└── verify_tests

A composite capability nem feltétlenül maga is „skill”. Lehet:

workflow,
orchestrator service,
agentic loop,
planner/executor rendszer.

Ez fontos határ.

Mikor hívjon egy skill másik skillt?¶

Közvetlen skill-to-skill dependency lehet valid, ha a dependency:

stabil,
egyirányú,
szűk contracttal rendelkezik,
a parent capability természetes része.

Például:

Release Notes Skill
      ↓
Change Summary Skill

Ha a release notes skill mindig egy strukturált change summaryból dolgozik, ez logikus dependency lehet.

Viszont ha a hívási lánc dinamikus:

Skill A may call B or C
B may call D
D may call A

akkor már inkább runtime orchestration problémáról beszélünk.

Prefer orchestration over hidden nesting¶

Gyenge:

User
 ↓
Skill A
  ↓ hidden call
Skill B
  ↓ hidden call
Skill C

A caller nem látja:

mi futott le,
hol hibázott,
mennyi token/tool cost volt,
milyen permission kellett,
hogyan lehet retry-zni.

Jobb:

Orchestrator
├── Skill A
├── Skill B
└── Skill C

ahol az execution path explicit.

A composition legyen megfigyelhető és kontrollálható, ne rejtett prompt-internal mechanizmus.

Sequential composition¶

A legegyszerűbb pattern:

Skill A output
      ↓
validation / mapping
      ↓
Skill B input
      ↓
Skill B output

Példa:

PR Review Skill
      ↓
structured findings
      ↓
Fix Planning Skill

A typed contract itt különösen fontos.

Gyenge lánc:

A: "There may be something wrong around retries..."
 ↓
B re-interprets free text

Jobb:

{
  "finding_type": "NON_IDEMPOTENT_RETRY",
  "severity": "HIGH",
  "location": "RetryService.java:87",
  "evidence": "charge() is retried without an idempotency key"
}

Parallel composition / fan-out¶

Egy task több független nézőpontból elemezhető:

PR diff
 ├── Security Review Skill
 ├── Architecture Review Skill
 └── Test Coverage Review Skill
        ↓
     Aggregator

Ez akkor jó, ha a részfeladatok valóban függetlenek.

Előnye:

párhuzamosítható,
külön evaluálható,
specializált skill-eket kapunk.

Hátránya:

költség nő,
conflict reconciliation kellhet,
duplicate findingokat össze kell vonni.

Aggregator pattern¶

Az aggregator feladata:

multiple structured results
        ↓
merge / deduplicate / prioritize
        ↓
final result

Nem feltétlenül kell LLM-nek lennie.

Például severity alapján determinisztikusan rendezhetünk és azonos location+rule alapján deduplikálhatunk.

A semantic konfliktusokat viszont model vagy human review oldhatja fel.

Shared primitive vs shared skill¶

Nem minden újrahasznosítható elem skill.

Például:

read_repository_file

egy tool/capability primitive.

summarize_code_change

lehet skill.

normalize_severity_enum

valószínűleg deterministic helper function.

Hasznos kérdés:

Kell ehhez semantic reasoning, vagy egyszerű software primitive?

Ne csináljunk agent skillt minden reusable functionből.

Dependency inversion skill compositionnél¶

Egy skill ne feltétlen konkrét másik skill nevéhez kötődjön.

Gyenge:

ReleaseNotesSkill requires ChangeSummarySkillV3

Jobb:

ReleaseNotesSkill requires capability:
change_summary_provider

A runtime mapelheti:

change_summary_provider
       ↓
ChangeSummarySkill v3

vagy tesztben:

change_summary_provider
       ↓
Fixture implementation

Ez ugyanaz a dependency inversion, mint klasszikus architektúrában.

State ownership compositionnél¶

Több skill esetén felmerül:

Ki birtokolja a közös state-et?

Általában jobb:

Orchestrator / Runtime owns workflow state
Skill receives explicit input
Skill returns explicit output

mint:

Skill A silently writes shared memory
Skill B silently reads it

Az explicit state flow könnyebben debugolható.

WorkflowState
   ↓         ↑
Skill A   result A
   ↓
WorkflowState updated
   ↓
Skill B

Error propagation¶

Ha Skill A hibázik, Skill B ne feltétlenül induljon el.

Például:

Fetch Current Deployment Skill
        ↓ TOOL_UNAVAILABLE
Risk Analysis Skill

A risk analysis current deployment adat nélkül lehet invalid.

A workflow policy dönthet:

TOOL_UNAVAILABLE → stop
PARTIAL_RESULT → continue with warning
INSUFFICIENT_CONTEXT → request more input

Ezt ne a nested skill lánc implicit módon döntse el.

Failure isolation¶

Párhuzamos compositionnél:

Security Review → SUCCESS
Architecture Review → SUCCESS
Test Review → TOOL_TIMEOUT

Lehetséges outcome:

PARTIAL_RESULT

és a final report jelezze:

Test coverage could not be evaluated because CI data was unavailable.

Ez jobb, mint mindent eldobni, ha egy opcionális branch hibázik.

Workflow vs Agent Loop¶

Ha a sorrend előre ismert:

A → B → C → D

akkor workflow a természetesebb.

Ha a következő capability az előző observation alapján dől el:

observe
 ↓
decide next skill
 ↓
execute
 ↓
observe

akkor agentic loop felé megyünk.

Példa workflow:

extract invoice data
 → validate
 → store

Példa agentic:

investigate production incident
 → choose which signal to query next based on observations

Ne használjunk agent loopot ott, ahol egy egyszerű workflow elég.

Example: PR resolution pipeline¶

Pull Request
    ↓
PR Review Skill
    ↓
findings[]
    ↓
Fix Planning Skill
    ↓
change_plan[]
    ↓
Implementation Skill
    ↓
patch
    ↓
Test Runner tool
    ↓
Test Failure Analysis Skill if needed
    ↓
Verification

Itt több külön boundary van:

review semantic task,
fix planning semantic task,
implementation semantic task,
test running deterministic/tool task,
failure analysis semantic task.

Nem érdemes mindezt egy:

CodingSkill.doEverything()

capabilitybe összenyomni.

Composition depth¶

Túl mély nesting problémás:

A → B → C → D → E → F

mert nő:

latency,
cost,
failure probability,
observability igény,
context drift.

Érdemes explicit execution budgetet használni és rendszeresen felülvizsgálni, hogy a chain tényleg szükséges-e.

Circular dependencies¶

Kerülendő:

Architecture Review Skill
       ↓
Refactoring Skill
       ↓
Architecture Review Skill

ha nincs explicit loop controller.

A circular capability graph könnyen végtelen executionhöz vezet.

Ha ismétlés szükséges, az legyen agentic loop vagy workflow retry policy, explicit stop conditionnel.

Skill library modularity¶

Egy jó skill library hasonlít egy jó modular codebase-re:

clear responsibilities
explicit interfaces
small dependency graph
few shared primitives
no hidden globals

A cél nem a maximális skill-szám.

A cél a hasznos modularitás.

Anti-pattern: mega-skill¶

SoftwareEngineeringSkill
├── requirements
├── architecture
├── implementation
├── review
├── test
├── deploy
└── incident response

Ez:

nehéz route-olni,
túl sok toolt kér,
nehezen evaluálható,
security permissionje túl széles,
promptja gyorsan gigantikus lesz.

Anti-pattern: skill-as-function-call fetish¶

Nem kell minden 20 soros deterministic helperből skill.

Ha a feladat:

calculate retry delay

és a formula ismert, írjunk kódot.

Anti-pattern: hidden shared memory¶

Skill A writes "current_plan" to memory
Skill B assumes it exists

Ez temporal coupling.

Jobb explicit input/output contract.

Anti-pattern: workflow logika skill promptban¶

Gyenge:

"First call skill A, then B, unless C, then retry D..."

egy óriási system promptban.

A deterministic control flow legyen orchestration code-ban, ahol lehet.

Takeaways¶

A skill composition célja a fókuszált capabilityk újrahasznosítása, nem új mega-skillek gyártása.
Sequential és parallel composition is hasznos pattern.
Az execution orchestration legyen explicit és megfigyelhető.
Typed contractok csökkentik a skill-to-skill semantic driftet.
Shared primitive nem feltétlen skill; használjunk normál kódot és toolokat is.
Preferáljuk a capability dependencyt konkrét implementation dependency helyett.
A közös state-et tipikusan runtime/workflow birtokolja, nem rejtett skill memory.
Failure policy az orchestrator felelőssége legyen, ne implicit nesting.
Előre ismert lépésekhez workflow; dinamikus next-action döntéshez agentic loop.
Circular dependency helyett explicit loop + stop condition.