Communitygithub.com

rbikbov/frontend-starter

Crée des Architecture Decision Records (ADR) documentant les décisions techniques clés avec contexte, alternatives envisagées, compromis, conséquences et responsables. À utiliser pour documenter les « décisions d'architecture », « choix techniques », « décisions de conception » ou « ADR ».

Qu'est-ce que frontend-starter ?

Ce skill permet aux développeurs et architectes de créer des Architecture Decision Records (ADR) structurés et complets. Son objectif est d'assurer une documentation claire et traçable des décisions techniques importantes au sein d'un projet. Le skill est agnostique à la plateforme (compatible avec Claude Code, Cursor, Codex) et repose sur un modèle d'ADR éprouvé. L'utilisateur fournit la décision technique, et le skill génère un document incluant le contexte, les alternatives envisagées, les compromis (tradeoffs), les conséquences positives et négatives, ainsi que les risques atténués. Il intègre également des mécanismes de numérotation des ADR, un workflow de statut (Proposé, Accepté, Déprécié, Remplacé), et un guide anti-patrons. Le skill produit un fichier markdown prêt à être intégré dans le dossier `docs/adr` du projet, facilitant la révision collaborative et la prise de décision éclairée.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/rbikbov/frontend-starter/tree/HEAD/.claude/skills/adr-writer
Voir l'original→Voir toutes les compétences

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentation

Rédacteur d'ADR

Documentez les décisions d'architecture avec un contexte clair, des alternatives et des conséquences. Rédigez en français.

Modèle d'ADR

# ADR-[Numéro] : [Titre court de la décision]

**Statut :** [Proposé | Accepté | Déprécié | Remplacé par ADR-XXX]  
**Date :** [AAAA-MM-JJ]  
**Auteur :** [Nom/Pseudo]

## 1. Contexte

Quel problème résolvons-nous ? Quels facteurs l'affectent (objectifs métier, dette technique, budget) ?
**Contraintes :**

- [Contrainte 1]
- [Contrainte 2]

## 2. Décision

Un énoncé court de la décision. La thèse principale.

## 3. Détails techniques et mécanismes

_Section libre. Décrivez les éléments d'implémentation, structures de données, détails de protocole ou fonctionnalités clés du framework._

- [Listes, descriptions d'API, schémas de données]
- [Visualisation Mermaid (recommandée pour les interactions complexes)]

## 4. Alternatives envisagées

### 4.1. [Option 1]

- **Avantages :** ...
- **Inconvénients :** ...
- **Décision :** [Rejetée/Envisagée] (raison courte).

## 5. Conséquences et risques

### Points positifs (Avantages)

- En quoi cela aide-t-il le système/l'équipe ?

### Points négatifs / Risques (Inconvénients/Risques)

- Quels inconvénients acceptons-nous ? Quelles sont les menaces ?
- **Atténuation :** Comment allons-nous gérer les risques ?

## 6. Historique des révisions

- **[Date] :** [Description du changement] ([Auteur])
- **[Date] :** [Ex. : Statut modifié en Accepté] ([Auteur])

Numérotation des ADR

ADR-001 : Architecture initiale du système
ADR-002 : Sélection de base de données pour l'analyse
ADR-003 : Stratégie d'authentification
...

Workflow de statut

Proposé → Accepté → Implémenté
    ↓
Rejeté

Accepté → Déprécié → Remplacé par ADR-XXX

Bonnes pratiques

  1. Rédigez des ADR pour les décisions significatives : Tous les choix ne nécessitent pas un ADR.
  2. Documentez les alternatives : Montrez que vous avez envisagé des options.
  3. Soyez honnête sur les compromis : Chaque décision a des inconvénients.
  4. Soyez concis : 1 à 2 pages maximum.
  5. Mettez à jour le statut : Marquez les ADR dépréciés/remplacés.
  6. Lieze les ADR connexes : Créez des traces de décisions.
  7. Incluez des suivis : Actions avec responsables.
  8. Visualisez : Utilisez des diagrammes Mermaid pour montrer l'architecture et les flux.
  9. Écrivez pour les futurs lecteurs qui manquent de contexte actuel.
  10. Soyez honnête sur les compromis (chaque choix a des inconvénients).

Modèles courants

Pour la sélection de technologies :

  • Mettez l'accent sur les capacités techniques par rapport aux exigences.
  • Incluez des benchmarks de performance si disponibles.
  • Documentez le niveau d'expertise de l'équipe.
  • Tenez compte de la complexité opérationnelle.

Pour les changements architecturaux :

  • Incluez la stratégie de migration dans les conséquences.
  • Documentez l'impact sur la rétrocompatibilité.
  • Tenez compte de l'impact sur la vélocité de l'équipe pendant la transition.
  • Notez les plans de surveillance et de retour arrière.

Pour les normes et conventions :

  • Incluez des exemples de la norme en pratique.
  • Documentez les exceptions ou les échappatoires.
  • Tenez compte des mécanismes d'application.
  • Notez les implications en matière d'éducation/onboarding.

Pour les dépréciations :

  • Mettez le statut sur « Déprécié » ou « Remplacé ».
  • Lien vers l'ADR remplaçant.
  • Documentez le calendrier de fin de vie.
  • Incluez un guide de migration.

Anti-patrons

❌ Trop détaillé : ADR de 10 pages que personne ne lit. ❌ Aucune alternative : On dirait que la décision était prédéterminée. ❌ Conséquences manquantes : Ignorer les inconvénients. ❌ Aucun responsable : Personne n'est responsable. ❌ Statut obsolète : Anciens ADR marqués comme « Proposé ».

Liste de vérification pour la révision

  • Énoncé clair du problème dans le Contexte.
  • La décision est explicitement énoncée.
  • 2+ alternatives envisagées.
  • Compromis évalués honnêtement.
  • Conséquences (positives et négatives) documentées.
  • Risques identifiés avec atténuations.
  • Responsable de la décision assigné.
  • Actions de suivi avec échéances.
  • Le statut est à jour.

Liste de vérification de sortie

  • Document ADR créé.
  • Le Contexte explique le problème.
  • La décision est clairement énoncée.
  • 2 à 3 alternatives documentées.
  • Section Compromis remplie.
  • Conséquences listées (positives et négatives).
  • Risques identifiés avec atténuations.
  • Date et responsables de la décision.
  • Actions de suivi assignées.
  • Le statut est défini.

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

rbikbov/frontend-starter

Проверка фронтенд-кода и документации на «нейрослоп» перед коммитом, PR или публикацией репозитория: остатки генераторов, мёртвые и недоделанные опции, утверждения в README и комментариях, не подтверждённые кодом, маркетинговый тон и эмодзи, лишние абстракции, хрупкая обработка ошибок, персональные данные в логах, несуществующие классы стилей. Использовать, когда просят проверить код или репозиторий «на слоп», подготовить проект к публикации или показу, сделать ревью кода, написанного с помощью ИИ, или перед тем как закоммитить собственную большую правку.

rbikbov/frontend-starter

Процесс разработки фичи с агентом: PRD с Non-Goals → компактная спецификация → задачи по одной на коммит → read-only исследование → tracer bullet → сборка с тестом сначала → независимое ревью субагентом → проверка в браузере. Использовать, когда просят сделать фичу, экран, пользовательский сценарий или заметное изменение поведения; когда нужно написать PRD, спецификацию или разбить работу на задачи; когда работа больше одного коммита. Не использовать для опечаток и однострочных правок.

rbikbov/frontend-starter

Авторизация и сессия во фронтенде на Next.js (App Router): где хранить токены, BFF на route handlers с HttpOnly-cookie, refresh токена без гонок, определение «не авторизован» (включая GraphQL, который отвечает 200), проверки в proxy.ts и Data Access Layer, безопасный редирект после входа, выход без утечки данных прошлого пользователя, токены в ссылках сброса пароля, формы входа и восстановления. Использовать, когда проектируешь или пишешь вход, регистрацию, восстановление пароля, защищённые страницы, API-клиент с refresh-токеном, или ревьюишь такой код.

rbikbov/frontend-starter

Старт нового фронтенд-проекта на Next.js (App Router) + TypeScript: фундамент, который закладывается до первой фичи. Использовать, когда нужно: создать проект с нуля; решить, нужны ли Next.js, монорепо, BFF, микрофронтенды; разложить FSD поверх роутинга Next; завести строгий TS, линтер границ, env-конфиг, модель ошибок и API-клиент, тесты, git-хуки, CI, каркас README; навести порядок в молодом проекте после генератора.

Skills associés

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community