Conrad Schulz 9838c7a0b3 feat: initial copilot workspace setup

- User settings.json with 9 senior-dev behavior rules
- 9 prompt files: requirements, architecture, new-feature, code-review,
  debug, refactor, write-tests, done-check, docker
- git-templates for .github/ and .vscode/ auto-copy on git init
- deploy.sh (macOS/bash) and deploy.fish (Linux/fish) scripts
- copilot-bootstrap.fish for existing/cloned repos

2026-05-29 08:19:50 +00:00

2.1 KiB

Raw Blame History

mode

description

tools

agent

Requirements Engineering Workshop – User Stories, ACs und NFRs erarbeiten

codebase

Requirements Engineering Workshop

Ausgangspunkt: ${input:raw_request:Was wurde grob angefragt oder gewünscht?}

Führe einen strukturierten Requirements-Workshop durch. Stelle Rückfragen wo nötig, aber arbeite so weit wie möglich mit dem vorhandenen Kontext.

1. Problem Statement

Problem: Was ist das eigentliche Problem, das gelöst werden soll? Betroffene Nutzer: Wer hat dieses Problem? Aktueller Workaround: Wie lösen Nutzer das Problem heute? Impact: Was passiert wenn wir es nicht lösen?

2. User Stories

Erstelle User Stories im Format:

Als [Rolle] möchte ich [Aktion/Feature], damit [geschäftlicher Nutzen].

Identifiziere: Wer sind die Nutzer-Rollen in diesem System?

3. Acceptance Criteria

Für jede User Story: konkrete, testbare, unambiguöse ACs.

Format: Given [Vorbedingung], When [Aktion], Then [Erwartetes Ergebnis]

Checkliste für gute ACs:

Eindeutig – nur eine mögliche Interpretation
Testbar – kann automatisch oder manuell verifiziert werden
Vollständig – Happy Path + wichtigste Error-Cases abgedeckt
Kein "wie" – ACs beschreiben WAS, nicht WIE

4. Non-Functional Requirements

Kategorie	Anforderung	Messbar?
Performance	z.B. Response <200ms bei 100 concurrent users
Security	z.B. Auth erforderlich, keine PII in Logs
Availability	z.B. 99.9% uptime, <1h RTO
Scalability	z.B. skaliert bis 10.000 Einträge ohne Perf-Degradation
Maintainability	z.B. neue Entwickler können in <1h onboarden

5. Out of Scope (explizit)

Was wird explizit nicht gebaut (jetzt):

6. Open Questions & Risiken

Offene Fragen die vor dem Start beantwortet werden müssen:

Bekannte Risiken:

7. Definition of Ready

Dieser Task ist ready to start wenn:

Alle ACs klar und unambiguös
NFRs definiert
Scope abgegrenzt
Open Questions geklärt
Architektureller Ansatz skizziert

2.1 KiB Raw Blame History Unescape Escape