Aller au contenu
WebViewGold Du vibe coding à l'App Store
Français
Obtenir WebViewGold

Claude Code

Commandes slash personnalisées et hooks pour publier des apps WebViewGold avec Claude Code

Deux petits fichiers suppriment l'essentiel du risque d'une release. Une commande /release-check fait suivre à Claude Code la même checklist à chaque fois, en commençant par la question de savoir si cette release a besoin d'un build pour les stores, et un hook refuse tout commit qui livrerait un Config.swift ou un Config.java pointant vers localhost. Les deux vivent dans le dépôt : toute votre équipe et chaque session cloud en profitent.

Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.

  • Garantie d'approbation – ou remboursement sous 14 jours
  • Aucun codage requis
  • Paiement unique, mises à jour gratuites
  • Support humain 24/7
  • Conçu en Allemagne depuis 2014 · ISO 27001

Les commandes guident, les hooks imposent

Une commande personnalisée est un prompt enregistré. Un fichier .claude/commands/release-check.md devient /release-check dans toutes les sessions de ce dépôt. Claude Code a fusionné les commandes avec les skills : un skill placé dans .claude/skills/release-check/SKILL.md crée la même commande et peut embarquer des fichiers supplémentaires, et les fichiers de commandes existants continuent de fonctionner. Pour une simple checklist, le dossier commands reste l'endroit le plus simple.

Un hook est d'une tout autre nature. C'est une commande shell que Claude Code exécute lui-même à un moment précis, par exemple juste avant un appel d'outil. Le modèle n'a pas son mot à dire : quand un hook PreToolUse se termine avec le code 2, l'appel d'outil est bloqué et Claude reçoit votre message d'erreur à la place. C'est exactement ce qu'il vous faut pour la seule erreur qui ne doit jamais atteindre vos utilisateurs.

Une règle pratique : les consignes vont dans CLAUDE.md, les procédures répétables deviennent des commandes, et tout ce qui ne doit jamais arriver devient un hook.

La commande /release-check

Enregistrez-la sous .claude/commands/release-check.md. Les lignes qui commencent par ! s'exécutent avant que Claude voie le prompt et y insèrent leur sortie : chaque vérification part ainsi de l'état réel du dépôt. allowed-tools pré-approuve exactement les commandes dont la vérification a besoin, et disable-model-invocation empêche Claude de lancer une vérification de release de sa propre initiative.

markdown
---
description: Pre-release check for the web app and the WebViewGold iOS and Android projects. Starts by deciding whether this release needs a store build.
argument-hint: "[version, for example 1.4.0]"
allowed-tools: Bash(git status *), Bash(git log *), Bash(git describe *), Bash(git diff *), Bash(git ls-files *), Bash(npm run lint), Bash(npm run build), Read, Grep, Glob
disable-model-invocation: true
---

# Release check for version $ARGUMENTS

## Repository state
- Branch and changes: !`git status --short --branch`
- Last release tag (a commit hash if there is no tag yet): !`git describe --tags --abbrev=0 --always`
- Recent commits: !`git log --oneline -20`

## 1. Does this release need a store build?
Run git diff --stat from the last release tag to HEAD. Native changes are files under
native/ios or native/android: Config.swift, Config.java, Info.plist, AndroidManifest.xml,
build.gradle, entitlements, icons and splash images.
- No native changes: report "Web-only release: deploy, no store build needed" and go to step 3.
- Native changes: a new App Store and Google Play build is needed. Continue with step 2.

## 2. Native checks
- Config.swift: host and webviewurl use the production domain over HTTPS.
- Config.java: HOST and HOME_URL match the iOS values.
- Neither file contains localhost, 127.0.0.1, 10.0.2.2, a 192.168.x.x address,
  an ngrok or trycloudflare host, or a preview deployment URL.
- iOS: the marketing version is $ARGUMENTS, the build number is higher than the last
  uploaded build, and every extension target (for example OneSignalNotificationServiceExtension)
  uses the main bundle ID as prefix.
- Android: versionName is $ARGUMENTS and versionCode is higher than the last upload.
  Report targetSdk; I will compare it with Google's current requirement.
- Every iOS usage description and every Android permission belongs to a feature we use.
- git ls-files shows no signing material: *.jks, *.keystore, *.p12, *.mobileprovision,
  keystore.properties.

## 3. Web app checks
- npm run lint and npm run build pass.
- /privacy, /terms and /delete-account still exist and are linked from settings.
- No new checkout, price or external payment link is visible when isNativeApp() is true.
- No new logging of tokens, email addresses or other personal data.

## Output
One table: check, result (pass, fail, needs me), evidence (file:line or command output).
Then a short list of what I must do by hand: deploy, store uploads, TestFlight,
release notes. Do not fix anything inside this command; I will ask for fixes separately.

La configuration du hook

Fusionnez ceci dans .claude/settings.json, le fichier de réglages du projet qui est commité et partagé (vos réglages personnels vont dans .claude/settings.local.json). Le matcher Bash lance le script avant chaque commande shell que Claude veut exécuter ; le script ignore lui-même tout ce qui n'est pas un commit.

json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/guard-native-config.sh",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

Avec une bonne version optimisée de votre application Web, vous pouvez avoir une superbe application mobile en quelques minutes. De plus, le service client est très agréable et très utile! Je ne peux que recommander WebViewGold :-)

Julian Koch · Co-fondateur de DuelDonkey · CodeCanyon

Le script du hook

Enregistrez-le sous .claude/hooks/guard-native-config.sh et rendez-le exécutable. Claude Code envoie l'appel d'outil prévu en JSON sur stdin ; le script lit la commande avec jq et, pour les commits, lance le vérificateur partagé. Le code de sortie 2 bloque le commit et transmet le texte de stderr à Claude, qui corrige alors généralement l'URL de lui-même.

bash
#!/usr/bin/env bash
# .claude/hooks/guard-native-config.sh
# PreToolUse hook (matcher: Bash). Blocks "git commit" while a staged Config.swift
# or Config.java contains a development URL. Exit 0 = allow, exit 2 = block.

input=$(cat)
cmd=$(printf '%s' "$input" | jq -r '.tool_input.command // empty')

# Not a commit? Allow immediately.
printf '%s' "$cmd" | grep -Eq 'git( -C [^ ]+)? commit' || exit 0

cd "${CLAUDE_PROJECT_DIR:-.}" || exit 0

# "commit -a", "--all" or a "git add" in the same command also commit unstaged
# changes, so check the working tree too.
flag=""
if printf '%s' "$cmd" | grep -Eq 'commit.* (-[a-zA-Z]*a|--all)|git( -C [^ ]+)? add '; then
  flag="--include-worktree"
fi

if ! report=$(./scripts/check-native-config.sh $flag 2>&1); then
  {
    echo "Commit blocked: a native config file points to a development URL."
    echo "$report"
    echo "Set host and webviewurl (Config.swift) and HOST and HOME_URL (Config.java)"
    echo "to the production HTTPS domain, stage the files again and retry the commit."
  } >&2
  exit 2
fi
exit 0

Le vérificateur partagé pour Claude et Git

Gardez la règle elle-même dans un seul script, pour que le hook Claude Code et un hook pre-commit Git classique imposent exactement la même chose. Enregistrez-le sous scripts/check-native-config.sh, exécutable. 10.0.2.2 est l'adresse par laquelle l'émulateur Android atteint votre ordinateur, un reste classique des tests.

bash
#!/usr/bin/env bash
# scripts/check-native-config.sh [--include-worktree]
# Exit 1 if a staged Config.swift or Config.java contains a development URL.
# Used by the Claude Code hook and by the Git pre-commit hook.

pattern='localhost|127\.0\.0\.1|0\.0\.0\.0|10\.0\.2\.2|192\.168\.[0-9]+\.[0-9]+|\.ngrok(-free)?\.(app|io|dev)|\.trycloudflare\.com'
# Add the preview hosts you use, for example: |-git-[a-z0-9-]+\.vercel\.app

scan() { # $1 = file, $2 = label; file content on stdin
  local hits
  hits=$(grep -nE "$pattern" | grep -vE '^[0-9]+:[[:space:]]*(//|\*)')
  if [ -n "$hits" ]; then
    printf '%s (%s):\n%s\n' "$1" "$2" "$hits"
    return 1
  fi
}

status=0
for f in $(git diff --cached --name-only --diff-filter=ACMR | grep -E '(^|/)Config\.(swift|java)$'); do
  git show ":$f" | scan "$f" "staged" || status=1
done

if [ "$1" = "--include-worktree" ]; then
  for f in $(git diff --name-only | grep -E '(^|/)Config\.(swift|java)$'); do
    scan "$f" "working tree" < "$f" || status=1
  done
fi

exit $status

Mettez-le en place et prouvez qu'il fonctionne

Un quart d'heure, commit volontairement bloqué compris.

  1. Créez les fichiers

    Créez .claude/commands/release-check.md, .claude/hooks/guard-native-config.sh et scripts/check-native-config.sh, puis lancez chmod +x .claude/hooks/guard-native-config.sh scripts/check-native-config.sh. Ou collez le prompt plus bas et laissez Claude Code les créer et les adapter.

  2. Vérifiez que jq est installé

    Le hook analyse le JSON avec jq (brew install jq sur macOS, sudo apt install jq sur Debian ou Ubuntu ; les sessions cloud l'ont déjà). Sans jq, le script ne peut pas lire la commande et laisse tout passer : c'est pour cela que les étapes suivantes comprennent un test.

  3. Enregistrez le hook

    Fusionnez le JSON dans .claude/settings.json en conservant les réglages déjà présents, puis commitez-le. Lancez /hooks dans Claude Code pour confirmer que l'entrée PreToolUse est bien chargée.

  4. Déclenchez-le exprès

    Mettez HOME_URL à http://10.0.2.2:3000 dans Config.java, ajoutez le fichier à l'index et demandez à Claude Code de commiter. Le commit doit être refusé avec votre message. Remettez ensuite l'URL de production.

  5. Couvrez les commits faits à la main

    Créez .githooks/pre-commit avec les deux lignes #!/usr/bin/env bash et exec ./scripts/check-native-config.sh, rendez-le exécutable et lancez git config core.hooksPath .githooks une fois par clone. Les commits faits depuis Xcode, Android Studio ou le terminal se heurtent désormais à la même règle, tout comme ceux de Claude, au moment précis où Git les crée.

  6. Lancez la vérification de release

    Avant chaque release, tapez /release-check 1.4.0. La première réponse vous dit si vous livrez un déploiement ou un build pour les stores ; le guide modifications web ou natives explique pourquoi cette distinction compte autant pour les apps WebViewGold.

Laissez Claude Code tout installer

Utile quand vos dossiers diffèrent des exemples. Claude adapte les chemins et vous montre chaque fichier avant de l'enregistrer.

À coller dans Claude Code, à la racine de votre dépôt
Mettez en place l'outillage de release de ce dépôt. Notre web app est aussi publiée sous forme d'apps iOS et Android construites avec WebViewGold ; les projets natifs se trouvent dans native/ios et native/android (vérifiez d'abord l'arborescence réelle et adaptez). Trouvez les chemins réels de Config.swift, Config.java, Info.plist, AndroidManifest.xml et app/build.gradle avant d'écrire quoi que ce soit.

1. Créez .claude/commands/release-check.md : une commande de checklist de release avec un frontmatter (description, un argument-hint pour la version, allowed-tools limité aux commandes git en lecture seule, npm run lint, npm run build, Read, Grep et Glob, et disable-model-invocation: true). Elle doit d'abord déterminer si la release modifie des fichiers natifs et nécessite donc un build pour les stores, puis vérifier les URL de production, les numéros de version et de build, les autorisations, les fichiers de signature suivis par Git, et les routes /privacy, /terms et /delete-account.
2. Créez scripts/check-native-config.sh : sortie avec le code 1 quand un Config.swift ou un Config.java indexé contient localhost, 127.0.0.1, 0.0.0.0, 10.0.2.2, une adresse 192.168.x.x, ou un hôte ngrok ou trycloudflare. Ignorez les lignes de commentaire. Avec --include-worktree, vérifiez aussi les modifications non indexées.
3. Créez .claude/hooks/guard-native-config.sh : un hook PreToolUse pour l'outil Bash qui lit l'entrée JSON avec jq, ignore tout sauf git commit, lance le vérificateur (avec --include-worktree pour commit -a, --all, ou un git add dans la même commande) et se termine avec le code 2 et un message clair sur stderr quand la vérification échoue.
4. Enregistrez le hook dans .claude/settings.json sans supprimer aucun réglage existant.
5. Créez .githooks/pre-commit, qui lance le même vérificateur.

Rendez les scripts exécutables, montrez-moi chaque fichier avant de l'enregistrer, puis expliquez-moi comment tester le hook avec une URL localhost volontaire.

Quelle règle de release va où

RègleMeilleur endroitPourquoi
Les fichiers de config pointent vers la production, jamais vers localhostHook plus hook pre-commit GitNe doit jamais partir. Un commit bloqué coûte moins cher qu'une app cassée entre les mains des utilisateurs ou qu'un build refusé.
Numéros de version et de build incrémentés/release-checkDemande du discernement : seules les releases natives ont besoin de nouveaux numéros, et le dernier numéro de build envoyé ne figure pas dans le dépôt.
Règles des stores comme 4.2, 4.8, 5.1.1 et 3.1.1CLAUDE.md plus le sous-agent de reviewDes consignes pendant le développement, une review stricte avant la release.
Le lint et le build passent/release-check ou CITrop lent pour un hook à chaque commit, idéal comme étape de checklist ou comme status check obligatoire.
Les fichiers de signature ne sont jamais commités.gitignore plus la vérification de releasePrévenir avec .gitignore, vérifier avec git ls-files avant chaque release.

Pièges

  • Le code 1 ne bloque pas. Seul le code de sortie 2 (ou une réponse JSON avec permissionDecision réglé sur deny) arrête l'appel d'outil. Le code 1 est signalé comme une erreur de hook, et le commit passe quand même.
  • Le hook ne voit que Claude. Il s'exécute pour les appels d'outils que fait Claude Code. Les commits lancés depuis votre IDE ou votre terminal le contournent : c'est pourquoi le même vérificateur tourne aussi comme hook pre-commit Git.
  • Les hooks tournent avec vos droits. Relisez les modifications de .claude/settings.json et de .claude/hooks/ dans les pull requests comme n'importe quel autre script ; un hook s'exécute sur la machine de toute personne qui ouvre le projet.
  • Des lignes ! surchargées. Les commandes en ligne d'un fichier de commande ont besoin d'entrées allowed-tools correspondantes. Limitez-les à de simples commandes en lecture seule et mettez les pipes et la logique dans les instructions, où Claude les exécute comme des appels d'outils normaux.
  • Un argument oublié. $ARGUMENTS correspond à ce que vous tapez après le nom de la commande. Lancez /release-check sans version, et la vérification n'a rien à quoi se comparer ; l'argument-hint est là pour vous le rappeler.
  • Des secrets dans les prompts. Les fichiers de commandes sont commités. N'y mettez jamais de mots de passe de keystore, de clés d'API ni de mots de passe de comptes de démo.

Questions fréquentes

Les commandes slash personnalisées de Claude Code sont-elles obsolètes ?

Non, elles ont été fusionnées avec les skills. Les fichiers de .claude/commands/ continuent de fonctionner et créent les mêmes commandes /nom. Un skill comme .claude/skills/release-check/SKILL.md ajoute des fichiers d'appui et le chargement automatique ; passez à ce format quand une commande dépasse un seul fichier.

Où vont les commandes personnelles ?

Dans ~/.claude/commands/ ou ~/.claude/skills/, dans votre dossier personnel. Elles sont disponibles dans tous les projets de votre machine, mais ne sont pas partagées avec votre équipe.

Le hook pourrait-il corriger l'URL au lieu de bloquer le commit ?

Il pourrait réécrire le fichier, mais les réécritures silencieuses masquent les problèmes. Bloquer avec un message clair est plus sûr : Claude lit le message, met l'URL de production et commite à nouveau, et vous voyez ce qui s'est passé.

Les hooks et les commandes fonctionnent-ils dans Claude Code sur le web ?

Oui. Les sessions cloud utilisent le .claude/settings.json, les commandes et les skills du dépôt, et jq est préinstallé dans l'environnement cloud. Les hooks de votre ~/.claude/settings.json personnel restent sur votre propre machine.

Un hook sur chaque appel Bash ralentit-il Claude ?

À peine. Le script se termine immédiatement pour tout ce qui n'est pas un commit. Les versions récentes de Claude Code acceptent aussi un champ if sur un hook, par exemple "Bash(git commit *)", pour que le script ne démarre que pour les commandes correspondantes.

Trois façons de mettre votre app dans les stores

Même résultat, charge de travail différente de votre côté. Les trois formules incluent la garantie d'approbation et le support humain 24/7.

Faites-le vous-même

$109 par plateforme, paiement unique

La licence WebViewGold : un projet Xcode ou Android Studio prêt à l'emploi. Collez votre URL, définissez le nom et l'icône, activez les fonctionnalités, compilez et soumettez. Mises à jour gratuites à vie.

Voir les offres sur la page principale

Full Service

$698 par plateforme $798

Envoyez-nous votre URL et votre icône. Notre équipe configure, compile et livre votre app sous 72 heures, en marque blanche, projets sources inclus. Les deux plateformes pour $1,158.

Détails du Full Service Propulsé par WeSetupYourWebViewApp

Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.

Prêt à publier votre app ?

Garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours

Vous préférez déléguer ? Full Service : nous configurons, compilons et livrons sous 72 heures, dès $698 par plateforme. Des questions ? Chattez avec nous 24/7.

Les remboursements sont accordés aux conditions indiquées dans notre FAQ : un refus non lié au contenu par Apple et/ou Google, demandé dans les 14 jours suivant l'achat.