Conrad Schulz
9838c7a0b3
- 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
76 lines
2.5 KiB
Markdown
76 lines
2.5 KiB
Markdown
# GitHub Copilot – Project Instructions
|
||
|
||
## Project
|
||
<!-- TODO: Beschreibe das Projekt in 1-2 Sätzen -->
|
||
|
||
## Stack
|
||
<!-- TODO: Sprachen, Frameworks, wichtige Tools -->
|
||
- Language:
|
||
- Framework:
|
||
- Database:
|
||
- Infrastructure:
|
||
|
||
## Architecture
|
||
<!-- TODO: Relevante Architekturentscheidungen -->
|
||
- Pattern (MVC / Hexagonal / Event-driven / ...):
|
||
- Key constraints:
|
||
- ADR location: `docs/adr/`
|
||
|
||
## Conventions
|
||
<!-- TODO: Projekt-spezifische Konventionen -->
|
||
- 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 (README, API docs, ADR if applicable)
|
||
- [ ] Commit message follows Conventional Commits
|
||
- [ ] No dead code, no TODOs left behind (or tracked as issues)
|
||
|
||
## Testing Strategy
|
||
<!-- TODO: Anpassen auf das Projekt -->
|
||
- 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
|
||
|
||
## Non-Functional Requirements
|
||
<!-- TODO: Anpassen -->
|
||
- Response time:
|
||
- Availability:
|
||
- Data retention:
|