Documentation

macOS / Linux — Homebrew

brew install Grandpied33/sth/sth
sth version

Windows — winget ou Chocolatey

# winget
winget install Grandpied33.STH

# Scoop
scoop bucket add sth https://github.com/Grandpied33/scoop-sth
scoop install sth

# Chocolatey
choco install sth

Binaire depuis GitHub Releases

Si vous préférez une installation manuelle ou que vous êtes sur une plateforme non couverte, téléchargez l'archive correspondante depuis la page Releases (chaque archive est accompagnée d'un fichier SHA256SUMS pour vérifier l'intégrité), puis placez le binaire dans votre PATH.

# macOS / Linux
tar -xzf sth-darwin-arm64.tar.gz   # ou linux-amd64, darwin-amd64
chmod +x sth
sudo mv sth /usr/local/bin/

# Windows : extraire sth-windows-amd64.zip et déplacer sth.exe dans un dossier de %PATH%

Vérifier l'installation

sth version

Depuis la racine de votre projet (typiquement un dossier qui contient déjà .claude/) :

sth init
? Fournisseur          › github | gitlab | azure-devops | bitbucket | sth-cloud
? Dépôt / org-projet   › acme-corp/skills
? Branche / ref        › main
? Catalogue            › SKILLS.md
? Dossier cible        › .claude/skills

La configuration est écrite dans .sth/project.json (schema v2). Aucun secret n'y est stocké — STH lit les tokens Git depuis votre environnement et la clé STH Cloud depuis le keychain de votre OS.

Si vous avez choisi sth-cloud, authentifiez-vous avec :

sth login                  # invite à coller votre clé
sth login lsk_live_xxxxx   # passe la clé en argument (utile en CI)

Lancer sth sans argument dans un terminal interactif ouvre le menu guidé qui propose la prochaine action utile (init, list, install, update, buddy…).

Lancer sth sans argument dans un terminal interactif joue une courte animation de réveil — 💤 puis 👀 — puis fige Buddy sur l'état réel du projet (à jour, mise à jour disponible, pas de configuration, etc.). Le tout dans un encadré de 78 caractères de large, parfait pour les terminaux modernes.

╭────────────────────────────────────────────────────────────────────────────╮
│                                                                            │
│      💧                                                                    │
│    ╭─────╮   STH dev                                                       │
│    │ >/< │   Skills Transfer Hub.                                          │
│    ╰─────╯                                                                 │
│                                                                            │
│  Astuce : tapez `sth help` pour voir la liste des commandes.               │
│  STH gère .claude/skills depuis un dépôt distant.                          │
│                                                                            │
╰────────────────────────────────────────────────────────────────────────────╯

Hors TTY (sortie redirigée, exécution en CI), seule la frame finale est imprimée — pas d'animation, pas de réécriture du buffer.

STH s'appuie sur les variables d'environnement de votre shell pour les providers Git. La variable générique STH_TOKEN est tentée en premier, suivie de la variable spécifique au provider. Aucun secret n'est persisté dans .sth/.

Pour la CI, deux patterns selon le provider : exportez le PAT (Git) ou la STH_CLOUD_API_KEY dans le contexte de la pipeline. Les installations self-hosted (GitHub Enterprise, GitLab self-managed) ne sont pas encore supportées — ouvrez une issue si le besoin est critique.

STH peut découvrir vos skills de deux manières — vous choisissez celle qui colle à votre dépôt.

1. SKILLS.md (manifeste explicite)

| Type  | Name           | Folder | Source                    | Description           |
| ----- | -------------- | ------ | ------------------------- | --------------------- |
| skill | analyse-risque | skills | skills/analyse-risque.md  | Check-list QSE        |
| agent | reviewer       | agents | agents/reviewer.md        | Revue de PR auto      |

2. Auto-détection (bundles)

Si votre dépôt suit la convention category/folder/SKILL.md, STH détecte les bundles automatiquement :

react/form-wizard/SKILL.md         → bundle "react/form-wizard"
react/form-wizard/templates/...    → tous les fichiers synchronisés
commands/release-helper/SKILL.md   → bundle "commands/release-helper"

Buddy traduit en un coup d'œil l'état de votre projet. Lancée avec --watch, elle réagit en direct aux changements de fichiers.

• 💧  >/< — Tout est à jour
• ⚠️  o.O — Mise à jour disponible
• 😶  ._. — Pas de configuration
• ❌  x x — Erreur
• ⏳  >_< — En cours
• ✅  ^.^ — Terminé

La configuration vit à la racine de votre projet, dans .sth/project.json. Vous pouvez la committer sans risque — elle ne contient aucun secret. Le schema v2 supporte plusieurs providers déclarés dans le tableau providers.

{
  "schema_version": 2,
  "providers": [
    {
      "id": "default",
      "provider": "github",
      "repository_id": "acme-corp/skills",
      "catalog_ref": "main",
      "catalog_path": "SKILLS.md",
      "target_dir": ".claude/skills"
    }
  ],
  "resources": []
}

Pour utiliser STH Cloud à la place du Git, le bloc provider devient :

{
  "id": "default",
  "provider": "sth-cloud",
  "repository_id": "votre-organisation",
  "catalog_ref": "main",
  "catalog_path": "SKILLS.md",
  "target_dir": ".claude/skills"
}

L'état des installations est stocké dans <target_dir>/sth-state.json (par exemple .claude/skills/sth-state.json). Il liste pour chaque ressource installée : le provider d'origine, les fichiers gérés, leurs hashes SHA-256 et le statut. sth status compare le disque à ce manifeste pour détecter les modifications locales.