iamk3nnyt/claude-skills

Transforme une idée de fonctionnalité en une spécification d'une page couvrant le problème, le public cible, le périmètre MVP, les non-objectifs, des critères d'acceptation Given/When/Then numérotés, les routes impactées, les données et emails, ainsi que les questions ouvertes. À utiliser lorsque l'utilisateur dit « brief », « spec this », « scope this » ou « what would it take », ou avant de commencer une fonctionnalité dont le périmètre est flou.

Qu'est-ce que claude-skills ?

Cette compétence guide l'assistant IA pour transformer une idée de fonctionnalité vague en un 'brief' structuré d'une seule page. Elle s'applique lorsque l'utilisateur évoque des termes comme 'brief', 'spec this', 'scope this', ou avant de démarrer une tâche au périmètre incertain. Le processus commence par une phase silencieuse de recherche dans le fichier CLAUDE.md du dépôt, les entrées mémoire, les routes, schémas et modèles d'emails pertinents, en ne posant des questions que si une décision impacte le périmètre (trois questions maximum). Un modèle précis est utilisé pour organiser le brief : problème, public cible en citant la source, périmètre MVP en 3 à 6 points livrables et observables, non-objectifs explicites, critères d'acceptation en format Given/When/Then numérotés (testables), touches (routes, tables/champs existants en priorité, emails, variables d'environnement, tiers), risques (argent, légal, délivrabilité, SEO, i18n), et questions ouvertes numérotées avec une valeur par défaut. La sortie se fait dans le chat, avec un résumé d'une phrase et le brief complet. Les critères de sortie garantissent l'observabilité et l'absence d'éléments superflus dans le MVP, avec des valeurs par défaut pour toutes les questions ouvertes.

Compatible avec✓Claude Code~Codex CLI~Cursor

npx skills add https://github.com/iamk3nnyt/claude-skills/tree/HEAD/skills/brief

Documentation

brief

Fonctionnalité : $ARGUMENTS

D'abord, ancrer le contexte (en silence)

Lire le fichier CLAUDE.md du dépôt et les entrées mémoire de ce projet. Parcourir rapidement les routes, le schéma et les modèles d'email concernés par la fonctionnalité. Les spécifications citent les vrais chemins de fichiers et les champs existants.
Interroger uniquement si une décision modifierait le périmètre. Poser une question à la fois via AskUserQuestion avec une option recommandée, et ne pas dépasser 3 questions. Tout le reste devient une hypothèse dans les questions ouvertes.

Règles maison pour le périmètre

MVP signifie le minimum conventionnel construit avec les champs et composants existants. « Comme n'importe quel e-commerce » signifie le flux standard, pas une plateforme.
Ne jamais ajouter de composants, paramètres, écrans d'administration ou analyses qui n'ont pas été demandés. Les lister plutôt dans les Non-objectifs.
Fonctionnalités partenaire ou API : « clé API » signifie généralement un identifiant de tenant dans l'environnement, pas un portail développeur.
Respecter les contraintes du projet issues de CLAUDE.md/mémoire (ex. « aucune modification de schéma »). Signaler tout ce qui en violerait une.

Modèle

# <Fonctionnalité> : brief
**Problème :** une ou deux phrases, le problème de l'utilisateur, pas la solution.
**Pour :** qui, et combien si connu (citer la requête ou la source).
**MVP :** 3 à 6 points, chacun livrable et observable.
**Non-objectifs :** ce que nous ne faisons explicitement pas maintenant.
**Critères d'acceptation**
1. Given <état>, when <action>, then <résultat observable>.
2. … (chacun testable via un flow-check, un smoke test ou un test unitaire)
**Touches :** routes · tables/champs (existants en priorité) · emails · env/secrets · tiers
**Risques :** argent, juridique/RGPD, délivrabilité, SEO (noindex/canonique), i18n
**Questions ouvertes :** numérotées ; chacune avec ma valeur par défaut si non répondue

Sortie

Dans le chat par défaut. N'écrire docs/briefs/<slug>.md que si demandé.
Une phrase de résumé (« Brief ci-dessous : N critères, M questions ouvertes »), puis le brief. Rien après.

Critères de sortie

Chaque critère d'acceptation est observable et correspond à une vérification (étape de flow-check, attente d'un smoke test ou test).
Rien dans le MVP qui n'a pas été demandé ou n'est pas strictement nécessaire pour ce qui a été demandé.
Chaque question ouverte a une valeur par défaut, afin que la construction puisse commencer sans attendre.