Vérification UI avant commit

VérifiéSûr

Génère les actifs du projet, démarre un serveur local et demande à l'utilisateur de vérifier visuellement l'interface avant de valider. Aide à détecter les régressions UI avant qu'elles ne soient commit. Utilisé lorsque les modifications affectent les templates, composants, styles ou autres comportements observables de l'interface.

Spar Skills Guide Bot
TestingIntermédiaire
7002/06/2026
Claude Code
#verify-ui#visual-approval#templ#tailwind-css#go

Recommandé pour

Notre avis

Cette compétence permet de construire les assets statiques, de lancer le serveur et d'obtenir une approbation visuelle avant de valider les modifications.

Points forts

  • Intègre la vérification visuelle directement dans le flux de validation.
  • Automatise les étapes de build et de migration.
  • Réduit les risques de déploiement de modifications non vérifiées.
  • Fonctionne avec des projets Go utilisant Templ et Tailwind CSS.

Limites

  • Nécessite que le serveur soit accessible en local (port 8080).
  • Dépend d'une validation humaine, ce qui peut ralentir le processus.
  • Ne couvre pas les tests automatisés (ex: tests d'interface).
Quand l'utiliser

Utilisez cette compétence avant chaque validation qui modifie l'interface utilisateur (composants, templates, styles, migrations).

Quand l'éviter

Ne l'utilisez pas pour des changements purement backend ou sans impact visuel, ni lorsqu'une validation humaine n'est pas possible (CI/CD).

Analyse de sécurité

Sûr
Score qualité90/100

The skill runs local build commands and a local development server; no destructive, exfiltrating, or obfuscated actions. User is prompted before database migrations. It is safe for its intended use.

Aucun point d'attention détecté

Exemples

Verify UI before commit
I have changes to the homepage template and some CSS. Please verify the UI before I commit.
Build and check UI
Run the verify-ui workflow for my current changes.

name: verify-ui description: Build assets, run server, and get visual approval before committing observable changes.

When to use

  • Before committing any changes that affect observable UI behavior
  • This includes: templates, components, styles, handlers, models surfaced in UI, migrations
  • When CLAUDE.md or /commit skill directs you here

Prerequisites

  • Changes to verify should already be implemented (not staged/committed yet)

Workflow

  1. Build static assets:

    • Run templ generate to regenerate templ files
    • Run make css to rebuild Tailwind CSS
    • Report any errors and stop if build fails
  2. Database migrations (if applicable):

    • Check for pending migrations: make migrate-status
    • If pending, ask user before running: make migrate
    • Skip if no database changes
  3. Start server:

    • Run go run ./cmd/tfo-webapp in background
    • Wait for server to be ready (check output for listening message)
    • Report the URL (typically http://localhost:8080)
  4. Request visual inspection:

    • Tell user: "Server running at http://localhost:8080 - please verify the UI"
    • Use AskUserQuestion to get approval:
      • "Does the UI look correct?"
      • Options: "Yes, looks good" / "No, needs changes"
  5. Handle response:

    • If approved: Stop server, report ready to commit
    • If not approved: Stop server, ask what needs to change, do NOT proceed to commit
  6. Cleanup:

    • Always stop the background server when done

Output

  • Commands run and their outcomes
  • Server URL for inspection
  • User's verification decision
  • Clear next step (proceed to commit or fix issues)
Skills similaires