メニュー
Convention ADR Sameva. Déclenche sur : "ADR", "décision d'architecture", "choix technique justifié", "journal de décisions", "architecture decision record", "trade-off", "alternative écartée", "phase-zero", "restructuring".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Pattern de persistance locale Hive dans Sameva — boîtes dynamiques + sérialisation JSON (toJson/fromJson), clés par utilisateur, offline-first. À utiliser pour créer ou modifier un modèle persisté localement, ouvrir une boîte, lire/écrire dans Hive, ou implémenter un service/ViewModel source de vérité avec stockage local. Pour la sync cloud, voir sameva-supabase ; pour les tests, voir sameva-testing.
Patterns d'animation Flutter (Lottie/Rive) et mapping GameEventBus pour Sameva. Déclenche sur : "animation", "Lottie", "Rive", "glow", "shimmer", "GameEventBus", "AnimationController", "feedback", "confetti", "montée de niveau", "level-up", "SFX", "son", "particules".
Carte de suppression des données utilisateur (RGPD, droit à l'effacement) pour Sameva. Déclenche sur : "RGPD", "suppression de compte", "delete account", "droit à l'effacement", "effacer mes données", "purge", "anonymisation", "export de données".
Guide for upgrading Stripe API versions and SDKs
Applique la logique métier Sameva (quêtes, récompenses, items, équipement, Hive, Supabase). Utiliser lors de l'implémentation ou modification de règles de jeu, de récompenses, d'inventaire, d'équipement, ou d'accès données.
Applique l'architecture Clean et Provider du projet Sameva. Utiliser lors de l'ajout de fonctionnalités, du refactoring, de la création de pages ou providers, ou quand l'utilisateur demande où placer du code ou comment structurer une feature.
| name | sameva-adr |
| description | Convention ADR Sameva. Déclenche sur : "ADR", "décision d'architecture", "choix technique justifié", "journal de décisions", "architecture decision record", "trade-off", "alternative écartée", "phase-zero", "restructuring". |
Un ADR (Architecture Decision Record) capture une décision structurante : pourquoi on a tranché ainsi, quelles options ont été écartées, et ce que ça engage. Objectif : qu'une décision ne se re-discute pas trois fois, et qu'un nouvel arrivant comprenne le « pourquoi » sans archéologie git.
Avant tout chantier structurel (nouvelle couche, changement de state management,
refonte navigation, choix de dépendance lourde, schéma de données, découpage de
modules), on rédige l'ADR d'abord et on s'arrête pour validation humaine.
Pas de code structurel tant que l'ADR n'est pas approuvé. Un ADR rejeté ou
remplacé n'est jamais supprimé : il passe en statut Remplacé par NNNN.
Convention proposée : docs/adr/NNNN-titre-en-kebab.md
(ex. docs/adr/0001-source-de-verite-unique-quetes.md).
docs/adr/,
docs/decisions/, adr/, .adr/…) avant d'en imposer un. S'il existe, suivre
la convention en place. Sinon, créer docs/adr/ (le dossier docs/ existe
déjà ; docs/adr/ n'existe pas encore au moment de l'écriture de cette skill).# NNNN — Titre court de la décision
- **Statut** : Proposé | Accepté | Remplacé par NNNN | Déprécié
- **Date** : AAAA-MM-JJ
## Contexte
Le problème, les contraintes, ce qui force une décision maintenant.
Factuel, pas de solution ici.
## Décision
Ce qu'on fait, à l'impératif. Une décision claire, pas un menu d'options.
## Alternatives écartées
- **Option A** — pourquoi écartée (coût, risque, dette, complexité…).
- **Option B** — pourquoi écartée.
(Une décision sans alternatives écartées est suspecte : on n'a pas cherché.)
## Conséquences
Ce que ça engage : positif ET négatif. Nouvelles contraintes, dette acceptée,
chantiers induits, ce qui devient plus dur.