Saltar al contenido
WebViewGold Del vibe coding a la App Store
Español
Consigue WebViewGold

Claude Code

Comandos slash personalizados y hooks para publicar apps de WebViewGold con Claude Code

Dos archivos pequeños eliminan la mayor parte del riesgo de una publicación. Un comando /release-check hace que Claude Code recorra siempre la misma lista de comprobación, empezando por la pregunta de si esta versión necesita siquiera una compilación para la tienda, y un hook rechaza cualquier commit que fuera a publicar un Config.swift o un Config.java apuntando a localhost. Los dos viven en el repositorio, así que todo tu equipo y cada sesión en la nube los tienen.

Desde $109 de pago único por plataforma, o deja que nuestro equipo lo haga todo desde $698.

  • Garantía de aprobación – o te devolvemos el dinero en 14 días
  • Sin programar
  • Pago único, actualizaciones gratuitas
  • Soporte humano 24/7
  • Hecho en Alemania desde 2014 · ISO 27001

Los comandos guían, los hooks obligan

Un comando personalizado es un prompt guardado. Un archivo en .claude/commands/release-check.md se convierte en /release-check en todas las sesiones de ese repositorio. Claude Code ha fusionado los comandos con las skills: una skill en .claude/skills/release-check/SKILL.md crea el mismo comando y puede incluir archivos adicionales, y los archivos de comandos existentes siguen funcionando. Para una sola lista de comprobación, la carpeta commands es el sitio más sencillo.

Un hook es otra cosa. Es un comando de shell que Claude Code ejecuta por sí mismo en un momento fijo, por ejemplo justo antes de una llamada a una herramienta. El modelo no tiene voto: cuando un hook PreToolUse termina con el código 2, la llamada se bloquea y Claude recibe tu mensaje de error en su lugar. Es justo lo que quieres para el único error que nunca debe llegar a los usuarios.

Una regla práctica: las pautas van en CLAUDE.md, los procedimientos repetibles se convierten en comandos y todo lo que nunca debe ocurrir se convierte en un hook.

El comando /release-check

Guárdalo como .claude/commands/release-check.md. Las líneas que empiezan con ! se ejecutan antes de que Claude vea el prompt e insertan su salida, así que cada comprobación parte del estado real del repositorio. allowed-tools aprueba de antemano exactamente los comandos que necesita la comprobación, y disable-model-invocation evita que Claude inicie por su cuenta una comprobación de versión.

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 configuración del hook

Fusiona esto con .claude/settings.json, el archivo de ajustes del proyecto que se sube con commit y se comparte (los ajustes personales van en .claude/settings.local.json). El matcher Bash ejecuta el script antes de cada comando de shell que Claude quiera lanzar; el propio script ignora todo lo que no sea un commit.

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

Con una buena versión optimizada de su aplicación web, puedes tener una impresionante aplicación móvil en un par de minutos. ¡Además del servicio al cliente es muy agradable y muy útil! ¡Puedo recomendar WebViewgold :-)

Julian Koch · Cofundador de Dueldonkey · CodeCanyon

El script del hook

Guárdalo como .claude/hooks/guard-native-config.sh y hazlo ejecutable. Claude Code envía la llamada prevista a la herramienta como JSON por stdin; el script lee el comando con jq y, si es un commit, ejecuta el comprobador compartido. El código de salida 2 bloquea el commit y entrega el texto de stderr a Claude, que normalmente corrige la URL por sí solo.

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

El comprobador compartido para Claude y Git

Mantén la regla en sí en un solo script, para que el hook de Claude Code y un hook pre-commit normal de Git apliquen exactamente lo mismo. Guárdalo como scripts/check-native-config.sh, ejecutable. 10.0.2.2 es la dirección con la que el emulador de Android llega a tu ordenador, un resto clásico de las pruebas.

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

Configúralo y demuestra que funciona

Quince minutos, incluido un commit bloqueado a propósito.

  1. Crea los archivos

    Crea .claude/commands/release-check.md, .claude/hooks/guard-native-config.sh y scripts/check-native-config.sh, y luego ejecuta chmod +x .claude/hooks/guard-native-config.sh scripts/check-native-config.sh. O pega el prompt que hay más abajo y deja que Claude Code los cree y los adapte.

  2. Comprueba que jq está instalado

    El hook analiza el JSON con jq (brew install jq en macOS, sudo apt install jq en Debian o Ubuntu; las sesiones en la nube ya lo traen). Sin jq, el script no puede leer el comando y lo deja pasar todo, y por eso los siguientes pasos incluyen una prueba.

  3. Registra el hook

    Fusiona el JSON con .claude/settings.json, conservando los ajustes que ya hay, y haz commit. Ejecuta /hooks en Claude Code para confirmar que la entrada PreToolUse está cargada.

  4. Provócalo a propósito

    Pon HOME_URL en Config.java a http://10.0.2.2:3000, prepara el archivo con git add y pide a Claude Code que haga commit. El commit debe rechazarse con tu mensaje. Después restaura la URL de producción.

  5. Cubre también los commits manuales

    Crea .githooks/pre-commit con las dos líneas #!/usr/bin/env bash y exec ./scripts/check-native-config.sh, hazlo ejecutable y ejecuta git config core.hooksPath .githooks una vez en cada clon. Los commits desde Xcode, Android Studio o la terminal pasan ahora por la misma regla, y también los commits del propio Claude, justo en el momento en que Git los crea.

  6. Ejecuta la comprobación de versión

    Antes de cada versión, escribe /release-check 1.4.0. La primera respuesta te dice si vas a publicar un despliegue o una compilación para la tienda; la guía sobre cambios web frente a cambios nativos explica por qué esa distinción importa tanto en las apps de WebViewGold.

Deja que Claude Code lo instale todo

Útil cuando tus carpetas no coinciden con los ejemplos. Claude adapta las rutas y te muestra cada archivo antes de guardarlo.

Pégalo en Claude Code en la raíz de tu repositorio
Configura las herramientas de publicación de este repositorio. Nuestra app web también se publica como apps de iOS y Android creadas con WebViewGold; los proyectos nativos están en native/ios y native/android (comprueba primero la estructura real y ajústate a ella). Localiza las rutas reales de Config.swift, Config.java, Info.plist, AndroidManifest.xml y app/build.gradle antes de escribir nada.

1. Crea .claude/commands/release-check.md: un comando con la lista de comprobación de la versión, con frontmatter (description, un argument-hint para la versión, allowed-tools limitado a comandos de git de solo lectura, npm run lint, npm run build, Read, Grep y Glob, y disable-model-invocation: true). Primero debe decidir si la versión cambia archivos nativos y, por tanto, necesita una compilación para la tienda; después debe comprobar las URLs de producción, los números de versión y de compilación, los permisos, los archivos de firma que Git rastrea y las rutas /privacy, /terms y /delete-account.
2. Crea scripts/check-native-config.sh: debe salir con 1 cuando un Config.swift o Config.java preparado para el commit contenga localhost, 127.0.0.1, 0.0.0.0, 10.0.2.2, una dirección 192.168.x.x o un host de ngrok o trycloudflare. Ignora las líneas de comentario. Con --include-worktree, comprueba también los cambios que no están preparados.
3. Crea .claude/hooks/guard-native-config.sh: un hook PreToolUse para la herramienta Bash que lea la entrada JSON con jq, ignore todo salvo git commit, ejecute el comprobador (con --include-worktree para commit -a, --all o un git add en el mismo comando) y salga con 2 y un mensaje claro en stderr cuando la comprobación falle.
4. Registra el hook en .claude/settings.json sin eliminar ningún ajuste existente.
5. Crea .githooks/pre-commit para que ejecute el mismo comprobador.

Haz ejecutables los scripts, muéstrame cada archivo antes de guardarlo y luego dime cómo probar el hook con una URL localhost puesta a propósito.

Qué regla de publicación va en cada sitio

ReglaMejor lugarPor qué
Los archivos de configuración apuntan a producción, nunca a localhostHook más hook pre-commit de GitNo debe publicarse nunca. Un commit bloqueado sale más barato que una app rota en manos de los usuarios o una compilación rechazada.
Números de versión y de compilación incrementados/release-checkRequiere criterio: solo las versiones nativas necesitan números nuevos, y el último número de compilación subido no está en el repositorio.
Reglas de las tiendas como 4.2, 4.8, 5.1.1 y 3.1.1CLAUDE.md más el subagente de revisiónPautas mientras programas y una revisión estricta antes de publicar.
Lint y build sin errores/release-check o CIDemasiado lento para un hook en cada commit; ideal como paso de la lista o como comprobación de estado obligatoria.
Los archivos de firma nunca se suben con commit.gitignore más la comprobación de versiónEvítalo con .gitignore y verifícalo con git ls-files antes de cada versión.

Errores habituales

  • El código de salida 1 no bloquea. Solo el código de salida 2 (o una respuesta JSON con permissionDecision en deny) detiene la llamada a la herramienta. La salida 1 se notifica como error del hook y el commit sigue adelante.
  • El hook solo ve a Claude. Se ejecuta con las llamadas a herramientas que hace Claude Code. Los commits desde tu IDE o tu terminal se lo saltan, y por eso el mismo comprobador también se ejecuta como hook pre-commit de Git.
  • Los hooks se ejecutan con tus permisos. Revisa los cambios en .claude/settings.json y .claude/hooks/ en los pull requests como cualquier otro script; un hook se ejecuta en la máquina de todo el que abre el proyecto.
  • Líneas ! sobrecargadas. Los comandos en línea de un archivo de comando necesitan entradas allowed-tools que coincidan. Limítalos a comandos sencillos de solo lectura y pon las tuberías y la lógica en las instrucciones, donde Claude las ejecuta como llamadas normales a herramientas.
  • Falta el argumento. $ARGUMENTS es lo que escribes después del nombre del comando. Si ejecutas /release-check sin versión, la comprobación no tiene con qué comparar; el argument-hint está ahí para recordártelo.
  • Secretos en los prompts. Los archivos de comandos se suben con commit. Nunca pongas en ellos contraseñas del keystore, claves de API ni contraseñas de cuentas demo.

Preguntas frecuentes

¿Están obsoletos los comandos slash personalizados de Claude Code?

No, se fusionaron con las skills. Los archivos de .claude/commands/ siguen funcionando y crean los mismos comandos /nombre. Una skill como .claude/skills/release-check/SKILL.md añade archivos de apoyo y carga automática; cámbiate a ese formato cuando un comando crezca más allá de un solo archivo.

¿Dónde van los comandos personales?

En ~/.claude/commands/ o ~/.claude/skills/ dentro de tu carpeta personal. Están disponibles en todos los proyectos de tu máquina, pero no se comparten con tu equipo.

¿Podría el hook corregir la URL en lugar de bloquear el commit?

Podría reescribir el archivo, pero las reescrituras silenciosas esconden los problemas. Bloquear con un mensaje claro es más seguro: Claude lee el mensaje, pone la URL de producción y vuelve a hacer commit, y tú ves lo que ha pasado.

¿Funcionan los hooks y los comandos en Claude Code en la web?

Sí. Las sesiones en la nube usan el .claude/settings.json, los comandos y las skills del repositorio, y jq viene preinstalado en el entorno en la nube. Los hooks de tu ~/.claude/settings.json personal se quedan en tu propia máquina.

¿Un hook en cada llamada a Bash ralentiza a Claude?

Apenas. El script termina de inmediato con todo lo que no sea un commit. Las versiones recientes de Claude Code también aceptan un campo if en el hook, por ejemplo "Bash(git commit *)", para que el script solo arranque con los comandos que coincidan.

Tres formas de llevar tu app a las tiendas

El mismo resultado, con distinta cantidad de trabajo por tu parte. Las tres incluyen la garantía de aprobación y soporte humano 24/7.

Hazlo tú mismo

$109 por plataforma, pago único

La licencia de WebViewGold: un proyecto de Xcode o Android Studio listo para usar. Pega tu URL, define nombre e icono, activa funciones, compila y envía. Actualizaciones gratuitas para siempre.

Ver planes en la página principal

Full Service

$698 por plataforma $798

Envíanos tu URL y tu icono. Nuestro equipo configura, compila y entrega tu app en 72 horas, en marca blanca y con los proyectos fuente. Ambas plataformas por $1,158.

Detalles del Full Service Con tecnología de WeSetupYourWebViewApp

Precios de la Oferta de invierno válidos hasta el 31 de diciembre de 2026.

¿Listo para lanzar tu app?

Garantía de aprobación en App Store & Google Play – o te devolvemos el dinero en 14 días

¿Prefieres delegarlo? Full Service: configuramos, compilamos y entregamos en 72 horas, desde $698 por plataforma. ¿Preguntas? Chatea con nosotros 24/7.

Los reembolsos se conceden bajo las condiciones indicadas en nuestras FAQ: un rechazo por motivos ajenos al contenido por parte de Apple y/o Google, reclamado dentro de los 14 días posteriores a la compra.