docs: add usage instructions with npx command to README

CLAUDE.md

@@ -0,0 +1,3 @@
+# Claude Code Rules
+
+Always read [docs/DEV.md](docs/DEV.md) at the start of every conversation before doing any work in this project.

README.md

@@ -5,3 +5,9 @@ CLI pour créer un projet Next.js avec le CMS @zen/core
 > [!WARNING]
 > Ce projet est en développement actif et n'est pas encore prêt pour une utilisation en production. L'API, la structure et les fonctionnalités peuvent changer à tout moment.
 
+## Utilisation
+
+```bash
+npx --registry https://git.hyko.cx/api/packages/zen/npm/ @zen/start
+```
+

docs/DEV.md

@@ -0,0 +1,44 @@
+# DEV
+
+## Standards
+
+On suit ces deux guides :
+
+- [GUIDE.md](./dev/GUIDE.md) : conventions générales de rédaction et de structure
+- [REDACTION.md](./dev/REDACTION.md) : règles de style, ton et formatage
+
+---
+
+## Publier le package
+
+Le package `@zen/start` est publié sur le registre npm à `https://git.hyko.cx`.
+
+### 1. Configurer l'authentification
+
+Créer un token d'accès dans Gitea (Settings → Applications → Generate Token), puis l'enregistrer localement :
+
+```bash
+npm config set //git.hyko.cx/api/packages/zen/npm/:_authToken TOKEN
+```
+
+Remplacer `TOKEN` par le token généré.
+
+### 2. Build et publish
+
+```bash
+npm publish
+```
+
+---
+
+## Bump de version
+
+Modifier `"version"` dans `package.json` en suivant [semver](https://semver.org/) :
+
+| Type | Version |
+|------|---------|
+| `fix` | PATCH `1.x.X` |
+| `feat` | MINOR `1.X.0` |
+| Breaking change | MAJOR `X.0.0` |
+
+---

docs/dev/GUIDE.md

@@ -0,0 +1,37 @@
+# GUIDE
+
+## Langue du code
+
+Tout ce qui est **code** est en **anglais**, sans exception :
+- Noms de fichiers (sauf dossiers de routes Next.js, voir ci-dessous)
+- Variables, fonctions, classes, composants
+- Commentaires dans le code
+- Props, événements, constantes, types
+- Git commit
+
+## Langue du contenu affiché
+
+Tout ce qui est **visible par l'utilisateur** est en **français** :
+- Textes, titres, descriptions, labels
+- Slugs et noms de dossiers qui correspondent à des routes URL
+- Documentations, README.md
+
+## Messages de commit Git
+
+Tous les messages de commit doivent être rédigés en **anglais**, en suivant le format conventional commits :
+
+```
+<type>(<scope>): <description courte>
+```
+
+Types courants : `feat`, `fix`, `refactor`, `style`, `docs`, `test`, `chore`
+
+Exemples :
+- `feat(auth): add OAuth2 login support`
+- `fix(api): handle null response from payment gateway`
+- `docs(guide): add git commit message conventions`
+- `chore(deps): update dependencies`
+
+## Guide de rédaction
+
+Se référer à `REDACTION.md` avant de rédiger tout contenu textuel.

docs/dev/REDACTION.md

@@ -0,0 +1,163 @@
+# GUIDE DE RÉDACTION
+Dernière modification : 2026-04-12
+
+## La voix de l'entreprise
+
+On parle comme une personne, pas comme une organisation. Direct, sans fioritures.
+
+On dit **"on"** — jamais "nous sommes heureux de", jamais "notre équipe d'experts". Une seule exception : quand on cite quelqu'un nommément, on peut utiliser "je".
+
+La technique est là parce qu'elle est utile, pas pour impressionner. Si une explication technique ne sert pas le lecteur, elle ne sert pas le texte.
+
+---
+
+## Ce qu'on évite absolument
+
+**Les superlatifs vides**
+*de premier plan, leader, de pointe, best-in-class, incontournable*
+
+**Les promesses floues**
+*solutions sur mesure, accompagnement personnalisé, approche holistique*
+
+**Le corporate**
+*nous nous engageons à, notre mission est de, dans une optique de, à cet effet*
+
+**La sur-promesse**
+Si on ne peut pas le garantir, on ne l'écrit pas. Jamais.
+
+**Les métaphores usées**
+*pont entre, clé en main, écosystème, synergies, à 360°*
+
+**Le tiret long (—)**
+Reformuler la phrase plutôt que d'insérer une incise.
+
+**Les chevilles inutiles**
+*Ainsi, En effet, Il convient de noter que, N'hésitez pas à*
+
+**Le passif sans raison**
+Préférer la forme active. "On a livré le projet" plutôt que "le projet a été livré".
+
+---
+
+## Formules qui marchent
+
+**Plutôt ça :**
+> "On dit non quand c'est la bonne réponse."
+> "On pense à comment les choses vont tenir dans six mois."
+> "Ce n'est pas le bon projet pour nous. Voilà pourquoi."
+
+**Pas ça :**
+> "Notre approche centrée client garantit des résultats optimaux."
+> "Nous mettons notre expertise au service de vos ambitions."
+> "Une équipe passionnée à votre écoute."
+
+**La règle d'or :** si ça pourrait figurer dans la communication d'un concurrent sans changer un mot, c'est à réécrire.
+
+---
+
+## Structure des textes
+
+### Titres
+Courts, affirmatifs, sans point. Une idée, pas une liste. Pas de question rhétorique.
+
+> ✓ "Zéro raccourci. Zéro compromis."
+> ✓ "On livre. On reste."
+> ✗ "Une approche rigoureuse pour des résultats durables"
+> ✗ "Pourquoi nous choisir ?"
+
+### Corps de texte
+Phrases courtes. Une idée par phrase. Maximum deux virgules par phrase — si on en compte plus, couper.
+
+Paragraphes de trois à quatre phrases maximum. Une ligne blanche entre chaque paragraphe.
+
+Pas de bullet points pour des concepts. Seulement pour des listes réelles (étapes, éléments techniques, options).
+
+### Appels à l'action
+Concrets et à l'infinitif. Pas d'exclamation.
+
+> ✓ "Discuter de votre projet"
+> ✓ "Voir comment on travaille"
+> ✗ "Contactez-nous pour en savoir plus !"
+> ✗ "Passez à l'action"
+
+---
+
+## Selon le format
+
+### Site web
+Chaque page a une seule idée principale. Le visiteur doit comprendre l'essentiel en dix secondes. Les détails viennent après, pour ceux qui cherchent.
+
+Pas de jargon en page d'accueil. Le jargon technique appartient aux pages de service, là où le lecteur s'y attend.
+
+### Courriels
+Objet : concret, pas accrocheur. Dire ce dont il s'agit, pas promettre quelque chose.
+
+> ✓ "Proposition — Refonte infrastructure"
+> ✗ "Une opportunité à ne pas manquer"
+
+Corps du courriel : aller droit au but dès la première phrase. Pas de "j'espère que ce message vous trouve bien." Si on doit écrire plus de quatre paragraphes, se demander si c'est le bon format.
+
+### Applications et interfaces
+Chaque message, étiquette ou instruction doit avoir un seul sens possible. Pas de formulation qui force l'utilisateur à interpréter.
+
+Le ton reste humain, même dans un contexte technique. "Une erreur s'est produite" est mieux que "Erreur 403 — accès non autorisé" si le lecteur n'est pas développeur.
+
+Les messages de confirmation, d'erreur et d'aide suivent les mêmes règles que le reste : courts, directs, actifs.
+
+### Articles et billets
+Un angle précis, pas un survol. Mieux vaut un article sur un problème concis que dix paragraphes vagues.
+
+Commencer par un fait, un constat ou une situation — pas par une définition.
+
+> ✓ "La plupart des migrations ratent pour la même raison : on sous-estime ce qui dépend de ce qu'on déplace."
+> ✗ "La migration de données est un processus complexe qui nécessite une planification rigoureuse."
+
+Terminer sur ce qu'on retient, pas sur une invitation à nous contacter.
+
+### Propositions et soumissions
+Pas de section "qui sommes-nous" en ouverture. Le client le sait déjà ou s'en fout pour l'instant.
+
+Commencer par le problème du client, tel qu'on l'a compris. S'il se reconnaît dans les deux premiers paragraphes, le reste a de la valeur.
+
+La solution vient après le diagnostic. Jamais avant.
+
+### Documents internes
+Mêmes règles de clarté que pour les textes externes. Un document interne mal écrit crée autant de confusion qu'une mauvaise communication client.
+
+Titres de section descriptifs, pas génériques. "Décision retenue et raison" est mieux que "Résultats".
+
+Si un document dépasse deux pages, se demander si l'information ne serait pas mieux transmise autrement.
+
+### Réseaux sociaux
+Un seul message par publication. Si on a besoin d'un fil de publications pour expliquer, c'est probablement un article.
+
+Le ton reste celui de l'entreprise — pas plus décontracté sous prétexte que c'est un réseau social.
+
+Pas de hashtags décoratifs. Seulement ceux qui servent la découverte du contenu.
+
+---
+
+## Parler de ce qu'on fait
+
+Ne jamais affirmer qu'on est "les meilleurs" ou "différents des autres". Le montrer, pas le dire.
+
+Quand on parle de ce qu'on fait, on parle de situations concrètes. Pas de généralités.
+
+> ✓ "On a refusé un mandat parce que le calendrier ne tenait pas."
+> ✗ "On valorise l'honnêteté dans nos relations clients."
+
+---
+
+## Révision d'un texte
+
+Avant de publier ou d'envoyer, se poser ces questions :
+
+1. **Est-ce qu'un concurrent pourrait signer ce texte ?** Si oui, réécrire.
+2. **Est-ce qu'on promet quelque chose qu'on ne contrôle pas ?** Retirer ou nuancer.
+3. **Est-ce que chaque phrase dit quelque chose ?** Supprimer celles qui ne font que meubler.
+4. **Est-ce que le lecteur sait quoi faire ou quoi penser après ?** Si non, préciser.
+5. **A-t-on utilisé le mot "solution" ?** Le remplacer. Presque toujours.
+
+---
+
+*Ce guide évolue. Si une formule sonne faux ou si un cas n'est pas couvert, on l'ajuste.*