Ghid operator pentru Hermes Skills

Ce face

hermes-skills este skill-ul umbrelă pentru administrarea ecosistemului de skill-uri din Hermes Agent: instalare, integrare, depanare, consolidare și igienă de bibliotecă.

Îl folosești pentru skill-uri locale, pachete third-party, diferențe între CLI și gateway, erori MCP, limite de tool-uri, drift de credentiale, bucle de restart și workflow-uri în care scripturi locale trimit Hermes să genereze artefacte.

Principiul central: skill-urile sunt infrastructură mentenabilă. Preferă skill-uri umbrelă, pe clase, cu secțiuni clare, în locul multor skill-uri înguste pentru o singură sesiune. Skill-urile înguste se absorb sau se arhivează; referințele nu se lasă rupte. Un sertar murdar nu devine sistem doar pentru că are YAML.

All guides

Când îmi folosește

Declanșează acest ghid când apar cereri sau simptome despre:

• skills, hermes skills, third party skills, skill integration;
• tool-uri care există în CLI, dar lipsesc sau sunt restricționate prin gateway;
• erori MCP la boot;
• hermes broken, runtime issues, loguri cu WARNING/ERROR repetitiv;
• consolidarea unor skill-uri duplicate sau prea înguste;
• generarea de drafturi locale printr-un script care folosește Hermes Dispatch;
• întrebări despre porturi, gateway, client OpenAI-compatible sau reachability.

Nu îl folosi ca permisiune automată pentru schimbări live. Pentru gateway, MCP-uri, credentiale, servicii persistente sau dezactivări de servere, regula este investigație și recomandare; modificările cer aprobare explicită când pot afecta runtime-ul.

Cum îl invoc / declanșez

Într-un runtime agentic, îl declanșează cererea operatorului sau detectarea unei probleme relevante: skill-uri, gateway, MCP, tool parity, runtime health sau integrare third-party.

Pentru triere runtime, începe cu inventarierea logurilor, fără a imprima secrete:

ls -lt <hermes-logs-dir> | head -15
tail -200 <hermes-logs-dir>/errors.log

Pentru diferențe gateway versus CLI, verifică serviciul gateway și comanda reală cu care rulează:

launchctl list | grep <hermes-gateway-service>

Apoi inspectează plist-ul sau unitatea de serviciu, working directory-ul, profilul activ, toolsets, disabled_toolsets, bridge/platforms și configurația relevantă. Nu presupune că gateway-ul moștenește toolset-ul CLI. Nu edita allowlist-ul de utilizatori ca să repari tool parity: controlează accesul utilizatorilor, nu lista de tool-uri.

Dacă operatorul întreabă ce port folosește Hermes, verifică live serviciile, socketurile și configurația fără să ghicești. Raportează pe suprafețe: gateway, webhook/API, dashboard sau proxy.

Exemplu practic

Caz tipic: un tool merge în hermes CLI, dar nu apare prin gateway-ul de mesagerie.

Pașii corecți:

1. confirmi că gateway-ul rulează;
2. citești configurația serviciului pentru comanda exactă și working directory;
3. compari profilurile, toolsets și disabled_toolsets;
4. verifici bridge/platforms și allowlist-ul doar pentru scopul lui real;
5. identifici gap-ul cu dovezi din fișiere și loguri;
6. dai o singură recomandare clară, cu raționament.

Nu spune că există o restricție manuală dacă nu ai văzut-o. Nu promite că tool-ul există pe Telegram sau altă suprafață de mesagerie dacă nu este înregistrat acolo. Nu aplica schimbări live de gateway fără aprobare.

Output / unde aterizează

Pentru integrare third-party, pattern-ul sigur este:

1. clonezi repo-ul într-o locație permanentă de sursă, sub un alias stabil;
2. faci symlink către directorul de skill-uri sau către subfolderele necesare;
3. verifici că skill-urile apar în biblioteca Hermes;
4. păstrezi repo-ul sursă curat, actualizabil prin git pull.

Nu copia fișierele dacă vrei update-uri și atribuire păstrate. Aliasul trebuie să fie scurt, stabil și neconflictual.

Pentru workflow-uri generate prin Hermes Dispatch, output-ul real este artefactul local, nu sumarul final al agentului. Verifică independent directorul țintă: câte fișiere există, ce s-a schimbat recent și dacă markerul generatorului este prezent. În propose-only mode, separă clar scrierea de drafturi locale de acțiuni externe sau ireversibile precum promovare, ștergere, postare, cheltuire ori editarea fișierelor negenerate.

Limite / gotchas

Gateway-ul are sandboxing și înregistrare de tool-uri separată de CLI. Diferența poate fi intenționată.

Pentru clienți OpenAI-compatible pe mobil, endpoint not found indică frecvent formă API sau reachability. Verifică suprafața gateway, baza URL cu sufixul /v1, modelul configurat și tokenul de gateway. Nu folosi secretul webhook drept API key. Un 404 pe root poate fi normal; sănătatea se verifică prin /health și rutele /v1/....

La MCP boot failure, cauzele probabile sunt directoare allowlist lipsă, binare lipsă sau variabile de mediu greșite. Nu crea symlink-uri oarbe ca să ocolești fail-closed. La limite de tool-uri, preferă dezactivarea duplicatelor doar după aprobare; serverele aparent duplicate pot deservi gazde diferite.

La drift de credentiale, nu afișa, copia sau rezuma secrete. Verifică existența sursei canonice și actualizează doar prin procedura aprobată, cu backup unde e cazul.

Nu declara „fixed” înainte de restartul necesar și re-verificarea logurilor. Regula finală: verifici artefactul, nu povestea despre artefact. Logs mint prin omisiune. Filesystem-ul, mai rar.