Communitygithub.com

rbikbov/frontend-starter

Erstellt Architecture Decision Records (ADRs) zur Dokumentation wichtiger technischer Entscheidungen mit Kontext, Alternativen, Abwägungen, Konsequenzen und Entscheidungsträgern. Verwenden Sie es, um „Architekturentscheidungen

Was ist frontend-starter?

Diese Fertigkeit hilft Entwicklern und Architekten dabei, Architecture Decision Records (ADRs) zu erstellen und zu verwalten. ADRs sind kurze Dokumente, die wichtige technische Entscheidungen in Softwareprojekten festhalten. Die Fertigkeit stellt eine strukturierte Vorlage bereit, die Kontext, Alternativen, Konsequenzen und Entscheidungsträger umfasst, sowie Best Practices, um sicherzustellen, dass jede Entscheidung klar begründet und nachvollziehbar ist. Sie enthält Anleitungen zur Nummerierung von ADRs, zum Status-Workflow (vom Vorschlag bis zur Ablösung) und zur Integration von Diagrammen (z. B. Mermaid), um komplexe Interaktionen zu visualisieren. Die Fertigkeit ist plattformunabhängig und kann in jedem Projekt verwendet werden, das eine strukturierte Dokumentation von Architekturentscheidungen erfordert. Sie adressiert häufige Anti-Patterns wie zu detaillierte Dokumente oder fehlende Alternativen und bietet eine Checkliste zur Qualitätssicherung. Der Schwerpunkt liegt auf Verständlichkeit für zukünftige Leser und ehrlicher Abwägung von Vor- und Nachteilen – ideal für Teams, die ihre Entscheidungsprozesse transparenter und nachvollziehbarer gestalten möchten.

Funktioniert mit✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/rbikbov/frontend-starter/tree/HEAD/.claude/skills/adr-writer
Original anzeigen→Alle Skills durchsuchen

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Dokumentation

ADR-Autor

Dokumentieren Sie Architekturentscheidungen mit klarem Kontext, Alternativen und Konsequenzen. Schreiben Sie auf Deutsch.

ADR-Vorlage

# ADR-[Nummer]: [Kurzer Entscheidungstitel]

**Status:** [Vorgeschlagen | Akzeptiert | Veraltet | Ersetzt durch ADR-XXX]  
**Datum:** [JJJJ-MM-TT]  
**Autor:** [Name/Handle]

## 1. Kontext

Welches Problem lösen wir? Welche Faktoren beeinflussen es (Geschäftsziele, technische Schulden, Budget)?
**Einschränkungen:**

- [Einschränkung 1]
- [Einschränkung 2]

## 2. Entscheidung

Eine kurze Aussage zur Entscheidung. Die Hauptthese.

## 3. Technische Details und Mechanismen

_Abschnitt mit freiem Format. Beschreiben Sie Implementierungsdetails, Datenstrukturen, Protokolldetails oder wichtige Framework-Funktionen._

- [Listen, API-Beschreibungen, Datenschemata]
- [Mermaid-Visualisierung (empfohlen für komplexe Interaktionen)]

## 4. Alternativen in Betracht gezogen

### 4.1. [Option 1]

- **Vorteile:** ...
- **Nachteile:** ...
- **Entscheidung:** [Abgelehnt/Erwogen] (kurzer Grund).

## 5. Konsequenzen und Risiken

### Positiv (Vorteile)

- Wie hilft dies dem System/Team?

### Negativ / Risiken (Nachteile/Risiken)

- Welche Nachteile akzeptieren wir? Welche Gefahren gibt es?
- **Minderung:** Wie gehen wir mit den Risiken um?

## 6. Änderungshistorie

- **[Datum]**: [Beschreibung der Änderung] ([Autor])
- **[Datum]**: [Z. B.: Status auf Akzeptiert geändert] ([Autor])

ADR-Nummerierung

ADR-001: Initiale Systemarchitektur
ADR-002: Datenbankauswahl für Analysen
ADR-003: Authentifizierungsstrategie
...

Status-Workflow

Vorgeschlagen → Akzeptiert → Implementiert
    ↓
Abgelehnt

Akzeptiert → Veraltet → Ersetzt durch ADR-XXX

Best Practices

  1. ADRs für signifikante Entscheidungen schreiben: Nicht jede Wahl benötigt einen ADR
  2. Alternativen dokumentieren: Zeigen Sie, dass Sie Optionen in Betracht gezogen haben
  3. Ehrlich bei Kompromissen sein: Jede Entscheidung hat Nachteile
  4. Kurz halten: Maximal 1–2 Seiten
  5. Status aktualisieren: Veraltete/Ersetzte ADRs kennzeichnen
  6. Verwandte ADRs verlinken: Entscheidungspfade erstellen
  7. Nachbereitungen einfügen: Aufgaben mit Verantwortlichen
  8. Visualisieren: Mermaid-Diagramme verwenden, um Architektur und Abläufe darzustellen
  9. Für zukünftige Leser schreiben, die den aktuellen Kontext nicht kennen
  10. Ehrlich bei Kompromissen sein (jede Wahl hat Nachteile)

Häufige Muster

Für Technologieauswahl:

  • Fokus auf technische Fähigkeiten im Vergleich zu Anforderungen
  • Leistungsbenchmarks einfügen, falls verfügbar
  • Team-Expertise-Level dokumentieren
  • Betriebskomplexität berücksichtigen

Für Architekturänderungen:

  • Migrationsstrategie in Konsequenzen einbeziehen
  • Auswirkungen auf Abwärtskompatibilität dokumentieren
  • Auswirkungen auf Teamgeschwindigkeit während des Übergangs berücksichtigen
  • Überwachungs- und Rollback-Pläne notieren

Für Standards und Konventionen:

  • Beispiele des Standards in der Praxis einfügen
  • Ausnahmen oder Notausgänge dokumentieren
  • Durchsetzungsmechanismen berücksichtigen
  • Auswirkungen auf Schulung/Onboarding notieren

Für Veraltungen:

  • Status auf „Veraltet“ oder „Ersetzt durch“ setzen
  • Link zum ersetzenden ADR
  • Sonnenuntergangszeitplan dokumentieren
  • Migrationsleitfaden einfügen

Anti-Patterns

❌ Zu detailliert: 10-seitige ADRs, die niemand liest ❌ Keine Alternativen: Sieht aus, als ob die Entscheidung vorherbestimmt war ❌ Fehlende Konsequenzen: Nachteile ignorieren ❌ Kein Verantwortlicher: Niemand ist rechenschaftspflichtig ❌ Veralteter Status: Alte ADRs als „Vorgeschlagen“ markiert

Überprüfungs-Checkliste

  • Klare Problemstellung im Kontext
  • Entscheidung ist explizit formuliert
  • 2+ Alternativen in Betracht gezogen
  • Kompromisse ehrlich bewertet
  • Konsequenzen (positiv und negativ) dokumentiert
  • Risiken mit Minderungen identifiziert
  • Entscheidungsverantwortlicher zugewiesen
  • Nachbereitungsaufgaben mit Fristen
  • Status ist aktuell

Ausgabe-Checkliste

  • ADR-Dokument erstellt
  • Kontext erklärt das Problem
  • Entscheidung klar formuliert
  • 2–3 Alternativen dokumentiert
  • Abschnitt zu Kompromissen ausgefüllt
  • Konsequenzen aufgelistet (positiv & negativ)
  • Risiken mit Minderungen identifiziert
  • Entscheidungsdatum und Verantwortliche
  • Nachbereitungsaufgaben zugewiesen
  • Status gesetzt

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; навести порядок в молодом проекте после генератора.

Verwandte Skills

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