Spec-Driven Prompts

[rdmueller]

Dieses Repository hat klein angefangen und muss mal überarbeitet werden.
Ein README.adoc reicht nicht mehr aus. Es braucht eine Visualisierung und eine ansprechende Website, die es aber einfach ermöglicht neue semantische Anker vorzuschlagen (Issues). Wird nur ein Anker (Begriff) vorgeschlagen, ist der erste Schritt über Copilot zu analysieren, ob es wirklich ein semantischer Anker ist und das Issue muss entsprechend umgeschrieben werden. Der nächste Schritt ist es, den semantischen Anker über Github Copilot eintragen zu lassen.
Bezüglich der Visualisierung würde ich gerne erstmal die Kategorisierung entsprechend MECE überprüfen und ggf. neu erstellen. Ich denke auch, dass eine Gruppierung der Kategorien nach Rolle (z.B. Software-Entwickler, Architekt, Produkt Owner etc. Auch Rollen ausserhab der IT) für User Sinn machen könnte.
Die Website muss zweisprachig EN/DE sein und Dark/Light mode unterstützen und responsive sein. Auswahl der Sprache und Light/Dark wird im Browser persistiert. Eine Dokumentation wird als AsciiDoc aus dem Repository gezogen und in der Website über asciidoctor.js gerendert.
Hast Du Fragen dazu?

[rdmueller]

für die CLaude.md:

Specification Conventions

Use Cases (01_use_cases.adoc)

• PlantUML Activity Diagrams for each use case
• Structure: Akteure, Vorbedingungen, Ablauf, Nachbedingungen, Fehlerszenarien

API Specification (02_api_specification.adoc)

• OpenAPI-style in AsciiDoc format
• Data models as JSON schemas with descriptions
• Endpoints grouped by API category (Navigation, Content Access, Manipulation, Meta-Information)

Acceptance Criteria (03_acceptance_criteria.adoc)

• Gherkin format (Given-When-Then)
• Grouped by feature/use case
• German language

Component Specifications (e.g., 04_markdown_parser.adoc)

• Scope and limitations (what it does NOT do)
• Data models as Python dataclasses
• Acceptance criteria with Gherkin scenarios
• Interface definition

Architecture Decision Records (ADRs)

• Nygard format: Status, Context, Decision, Consequences
• Pugh Matrix for each decision comparing alternatives
• Located in src/docs/arc42/chapters/09_architecture_decisions.adoc

[rdmueller]

Der nächste Schritt ist es, entlang der Spec unter Berücksichtigung der Architektur entsprechende Github Issues zur Implementierung der Spec zu erstellen.

[rdmueller]

Worktrees: ja, notiere die Vorgehensweise bitte in der CLAUDE.md und fange an. Suche Dir die wichtigsten Issues raus, analysiere sie und ergänze Deine Analyse im
Issue. Setze dann die Issues um und verwende dafür responsible-vibe-mcp , wo sinnvoll