Add doubynet skill and extend check_versions.py to cover installed skills

Claude/skills/doubynet/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: doubynet
+description: Update doubynet dokumentation
+metadata:
+  version: v1
+---
+
+Tvým úkolem je zkontrolovat a případně aktualizovat dokumentaci sítě DoubyNet.
+
+  ## 1. Načti dokumentaci
+  `/home/honza/Syncthing/Programy/DoubyNet/` (lokální, Syncthing-synchronizovaná
+  složka na Honza-PCL — žádný manuální upload/download, synchronizace na ostatní
+  zařízení běží na pozadí sama):
+  - `README.md` (index služeb + sekce "Router — port-forwarding")
+  - `CLAUDE.md` (konvence zápisu dokumentace — dodržuj ji při jakékoli úpravě)
+  - všechny `<Hostname>/<Služba>/<Služba>.md` soubory
+  - `<Hostname>/CHANGELOG.md` (jeden na hosta, průběžný záznam změn — viz krok 4)
+
+  Vytvoř si z toho kompletní obraz zdokumentovaného stavu: hosty, služby, jak se spouští,
+  sítě/porty, VM, autostart, propojení mezi službami (např. Caddy → cíl).
+
+  **Pozor na historické dokumenty.** Některé `.md` soubory popisují něco, co už
+  neexistuje (např. staré, fyzicky rozebrané disky/pole), a mají to nahoře jasně
+  označené (banner typu "⚠️ pole už neexistuje, dokument je od teď čistě
+  historický"). Takový dokument **needituj aktuálními fakty** — zjištěné aktuální
+  informace patří do dokumentu, který nahrazuje popisovanou věc (banner na to
+  obvykle přímo odkazuje). Smysl historického dokumentu je zůstat nezměněný jako
+  záznam toho, co bylo.
+
+  ## 2. Ověř realitu
+  Pro každé tvrzení v dokumentaci ověř skutečný stav na příslušném stroji (SSH, `systemctl`,
+  `virsh`, `ss -tlnp`, obsah configů apod.). Ověřuj z relevantního hlediska — např. dostupnost
+  webu přes DNAT/reverse proxy testuj z jiného stroje než je cíl (self-test ze stejného hostu
+  může dát falešně negativní výsledek kvůli tomu, jak netfilter zachází s lokálně generovaným
+  provozem).
+
+  **Některá fakta nejdou ověřit žádným příkazem** — typicky cokoliv, co žije jen v UI
+  zařízení bez API/SSH přístupu (např. nastavení port-forwardingu na routeru). V
+  takovém případě si o autoritativní export/screenshot řekni uživateli přímo, místo
+  abys realitu odhadoval nebo nechal needokumentovanou.
+
+  Neprováděj destruktivní ani produkci ovlivňující příkazy bez potvrzení uživatele. Pokud
+  narazíš na to, že nemáš potřebná oprávnění (sudo, SSH klíč), zeptej se uživatele, jak
+  pokračovat — nezkoušej to obcházet.
+
+  ## 3. Porovnej a nahlas rozdíly
+  Sestav přehledný seznam nesrovnalostí mezi dokumentací a realitou (co dokument tvrdí vs.
+  co je skutečně nastavené/běžící). Tenhle přehled ukaž uživateli **před** jakoukoli úpravou
+  souborů.
+
+  ## 4. Aktualizuj dokumentaci
+  Až uživatel potvrdí (nebo pokud jde o triviální/jednoznačné doplnění), uprav příslušné
+  `.md` soubory tak, aby odpovídaly realitě:
+  - Dodržuj šablonu a konvence z `CLAUDE.md` (formát tabulek, PascalCase názvy, atd.)
+  - Nikdy nezapisuj hesla/tokeny/klíče v plaintextu — nahraď je `<PLACEHOLDER>` tokenem
+  - Pokud přidáváš novou službu/VM, přidej ji i do řádku v `README.md`
+  - Fakta, co se netýkají jedné služby na jednom hostu (např. síťová topologie,
+    port-forwarding na routeru), patří do vlastní sekce v `README.md` — nenuť je
+    do složky jedné služby jen proto, že model "jedna složka = jedna služba" jinam
+    nesedí
+  - Zapiš stručný záznam do `<Hostname>/CHANGELOG.md` dotčeného hosta (nejnovější
+    nahoře) — co se zjistilo, co se změnilo, proč
+  - Po úpravách ověř, že žádný relativní markdown odkaz (`](...)`) nevede na
+    neexistující soubor — procházka stromem a kontrola existence cíle každého odkazu
+
+  Žádný manuální "upload" na server není potřeba — soubory žijí lokálně v Syncthing
+  složce, synchronizace běží sama.
+
+  Na konci stručně shrň, co bylo nekonzistentní a co jsi opravil.
+
+