Application Web90

Extension Chrome avec Claude Code

I gave Claude Code a "taste file" and made it name the 3 most generic things on every screen before calling it done

r/ClaudeCodeu/duct_tape_and_agents30 septembre 2026

Résumé

Le projet présente une méthode pour améliorer l'interface utilisateur d'une extension Chrome en utilisant Claude Code. L'auteur a créé un fichier DESIGN.md qui définit les règles de design et de voix pour le projet, et utilise Claude Code pour appliquer ces règles et améliorer l'interface utilisateur.

Pourquoi c’est intéressant

Ce projet est intéressant car il montre comment utiliser Claude Code pour améliorer l'interface utilisateur d'une application web, et comment définir des règles de design et de voix pour obtenir une interface utilisateur plus cohérente et plus utilisateur.

Comment Claude est utilisé

Le projet utilise Claude Code pour développer une extension Chrome, avec des règles de design et de voix définies dans un fichier DESIGN.md pour améliorer l'interface utilisateur.

Idées dérivées

  1. 01

    Audit UI

    Créer un outil d'audit automatique pour les interfaces utilisateur web, en utilisant Claude Code pour détecter les éléments génériques et les améliorer.

  2. 02

    Recommandation de design

    Développer un système de recommandation de design pour les applications web, en utilisant Claude Code pour analyser les meilleures pratiques de design et les appliquer aux projets.

  3. 03

    Test automatisé

    Créer un outil de test automatisé pour les applications web, en utilisant Claude Code pour simuler des interactions utilisateur et détecter les erreurs.

Afficher le post original
I'm building a Chrome extension with Claude Code in VS Code. The code was fine. The UI had that unmistakable AI-built look: stock shadcn cards, centered empty states, three buttons doing the same thing. So I tried two things. 1. A DESIGN.md that CLAUDE.md declares binding. It isn't a style guide; it's a list of decisions: • one sentence on what the product is for, and a rule that every screen has to serve it • who it's for, plus a "could this screen be screenshotted into a client email as-is?" test • voice rules: evidence before verdict, sentence case, button labels that say the outcome, a banned-words list • every data view must define loading, empty, error and partial states • a list of banned defaults (gradient heroes, icon-card grids, bare spinners, a score with no evidence under it) 2. An "edit pass" as the definition of done. Before any phase counts as finished, Claude has to render every changed screen at side-panel width in light and dark, write down the 3 most generic things about each, fix them or justify keeping them, and put the list in its summary. Some of what it caught on its own screens: • three filled primary buttons on Home, two doing the same thing • raw database errors shown to users • every recommendation button labelled "Go" • an ISO date in a header • "2 of 1 page tracked" on a downgraded account • a feature card still promising something I'd dropped weeks ago It even overrode my own prompt once. I'd written a button label as "Run it", and it changed it to "Run the assessment", citing the voice rules. Fair. A few other habits that have held up: • Short prompts that point at files. My long phase prompts kept getting truncated on paste, so now the spec lives in the repo and the prompt says "read X, do phase Y, stop". • Plan first on anything touching the database or money. Claude audits, dry-runs and lists stop conditions. I run the actual push and deploy myself. • Test on real sites. Tests passed and the mocks looked great; the real pages still found things no fixture could. The taste file is the one I'd recommend first. It turns "make it look less AI-made" into something Claude can actually check itself against. Anyone else doing something like this? Curious what's on other people's banned-defaults lists.