cschulz/rd13_copilot_setup
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
rd13_copilot_setup/git-templates/.github/copilot-instructions.md
Conrad Schulz fb1a01ba78 fix: review-findings behoben (7 Punkte) 
1. pre-commit: --no-verify Kommentar entfernt
2. pre-commit: .copilot-no-docs Opt-out fuer Check 2 (Doku-Pflicht)
3. .copilot-no-docs angelegt (Setup-Repo = reines Script/Config-Repo)
4. copilot-instructions.md: _session.md Suffix in Agent-History Sektion korrigiert
5. history.prompt.md: Datumsvariablen explizit + Append-Verhalten korrigiert
6. copilot-bootstrap.sh: Hinweis auf git copilot-update fuer Hook-Updates
7. Orphan-Stub 2026-06-02_master_55fee83.md geloescht
2026-06-02 11:13:34 +00:00

5.7 KiB
Raw Blame History

GitHub Copilot – Project Instructions

⚡ Agent Session Protocol (MANDATORY)

Diese Sektion hat höchste Priorität und darf nicht ignoriert werden.

Session START – Bevor du irgendetwas tust:

  1. Lies history/summary/PROJECT_CONTEXT.md (falls vorhanden)
  2. Verstehe den aktuellen Projektzustand bevor du anfängst

Session END – Führe /history im Copilot Chat aus um die Session abzuschließen:

  1. Erstelle history/prompts/YYYY-MM-DD_kurzbeschreibung_session.md mit vollständigem Log Dateiformat zwingend: Suffix _session.md — der post-commit Hook erkennt daran das Agent-Log und hängt den Git-Block automatisch an statt eine neue Datei zu erstellen.
  2. Aktualisiere history/summary/PROJECT_CONTEXT.md mit dem neuen Projektstand
  3. Stage beide Dateien: git add history/

Kein Bypass. Kein Vergessen. Kein "mache ich beim nächsten Mal". Die History ist das Gedächtnis des Projekts. Hinweis: Das Erstellen der Session-Datei erfordert expliziten Aufruf via /history.

⛔ Verbotene Aktionen (NIEMALS ausführen)

  • git commit --no-verify – Der pre-commit Quality Gate darf NIEMALS umgangen werden. Wenn der Hook fehlschlägt: Problem beheben (Tests schreiben, Doku aktualisieren, Context aktualisieren). Einzige Ausnahme: Der User fordert es explizit und begründet es.
  • git push --force – Nie force-pushen ohne explizite Anweisung des Users.
  • Secrets in Code – Keine Passwörter, API-Keys, Tokens in Dateien.

Project

Stack

  • Language:
  • Framework:
  • Database:
  • Infrastructure:

Architecture

  • Pattern (MVC / Hexagonal / Event-driven / ...):
  • Key constraints:
  • ADR location: docs/adr/

Project Structure Conventions

Persistent Data (/data/)

  • Alle persistenten Service-Daten gehören in /data/<service-name>/ (Repo-Root)
  • Nie Daten-Dateien committen – /data/ ist vollständig gitignored
  • Einen Unterordner pro Service (z.B. data/postgres/, data/redis/, data/uploads/)
  • Erforderliche Unterordner in docs/ADMIN.md dokumentieren

Agent History (/history/)

  • Vollständige Konversationen → history/prompts/YYYY-MM-DD_beschreibung_session.md (Suffix _session.md zwingend – post-commit Hook erkennt daran das Agent-Log)
  • Komprimierter Kontext → history/summary/PROJECT_CONTEXT.md (committed, immer aktuell halten!)
  • Beim Start einer neuen Session: history/summary/PROJECT_CONTEXT.md zuerst lesen
  • Am Ende jeder Session: beide Dateien committen
  • Copilot Chat: /history → History loggen + Summary aktualisieren

Documentation (3 Zielgruppen – alle 3 müssen existieren)

Datei Zielgruppe Inhalt
docs/USER.md Endnutzer Features, How-To, FAQ – keine technischen Details
docs/ADMIN.md Administratoren Deployment, Konfiguration, Monitoring, Backup
docs/MAINTAINER.md Entwickler Architektur, ADRs, Konventionen, Erweiterung

Regel: Jede bedeutende Änderung muss mindestens eine dieser Dateien aktualisieren. Der pre-commit Hook prüft dies automatisch.

Conventions

  • Branch naming: feat/<ticket>-description, fix/<ticket>-description
  • Commit format: Conventional Commits (feat|fix|chore|docs|refactor|test|ci)
  • File structure:
  • Naming:

Engineering Process

Before starting any task

  1. Clarify requirements – user story + acceptance criteria vorhanden?
  2. Impact analysis – welche bestehenden Komponenten sind betroffen?
  3. Architecture check – passt die geplante Lösung zur bestehenden Architektur?
  4. Test strategy – wie wird das Feature getestet?

Definition of Ready (DoR)

A task can only be started when:

  • Acceptance criteria are clear and unambiguous
  • Non-functional requirements defined (performance, security, scalability)
  • Architectural approach agreed upon
  • No unresolved external blockers

Definition of Done (DoD)

A task is only done when ALL of the following are true:

  • Code implements the acceptance criteria
  • Unit tests written and passing
  • Integration tests (where applicable) passing
  • No linter / type errors
  • No secrets or credentials in code
  • OWASP Top 10 reviewed
  • Relevant documentation updated: docs/USER.md and/or docs/ADMIN.md and/or docs/MAINTAINER.md
  • Alle 3 Zielgruppen-Dokumente vorhanden (docs/USER.md, docs/ADMIN.md, docs/MAINTAINER.md)
  • Persistente Daten liegen ausschließlich in /data/<service>/ (nie woanders)
  • history/summary/PROJECT_CONTEXT.md aktualisiert
  • Commit message follows Conventional Commits
  • No dead code, no TODOs left behind (or tracked as issues)
  • pre-commit Quality Gate bestanden (oder Bypass bewusst begründet)

Testing Strategy

  • Framework:
  • Coverage target: ≥ 80% (critical paths: 100%)
  • Test pyramid: unit > integration > e2e
  • Test location: tests/ mirroring source structure

Security

  • No secrets in code or config files – use environment variables
  • Validate all inputs at system boundaries
  • Principle of least privilege for all permissions
  • Dependency vulnerabilities: check before adding new deps

Documentation Standards

  • Code comments: explain WHY, not WHAT
  • Public APIs: always documented
  • Architecture decisions: write ADR in docs/adr/ (template: docs/adr/000-template.md)
  • CHANGELOG.md: update with every release
  • 3-Zielgruppen-Regel: USER.md (Endnutzer) + ADMIN.md (Ops) + MAINTAINER.md (Dev) – immer alle 3 pflegen

Non-Functional Requirements

  • Response time:
  • Availability:
  • Data retention: