pdate skill damit er nicht immer die Belege mit aufschreibt

.github/skills/add-knowledge-from-repo/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: add-knowledge-from-repo
-description: "Use when given a local Git repository folder path to extract verifiable application-relevant facts, update knowledge/projects.md, knowledge/roles.md, and knowledge/technologies.md, then tailor letters/coverletter.tex and letters/cv.tex. Triggers: analyze Git repository for applications, import repository knowledge, update application knowledge base, derive CV or cover letter facts from a repository."
+description: "Use when given a local software-project folder to extract verifiable application-relevant facts, update knowledge/projects.md, knowledge/roles.md, and knowledge/technologies.md, then tailor letters/coverletter.tex and letters/cv.tex. Supports Git repositories and Git-less project folders when authorship is explicitly confirmed. Triggers: analyze Git repository for applications, import repository knowledge, update application knowledge base, derive CV or cover letter facts from a repository."
-argument-hint: "<Pfad zum lokalen Git-Repository>"
+argument-hint: "<Pfad zum lokalen Projektordner>"
 user-invocable: true
 ---
 
@@ -9,14 +9,16 @@ user-invocable: true
 
 ## Purpose
 
-Turn evidence from one local Git repository into precise, reusable application facts. Given a repository folder path, this skill maintains the three Markdown knowledge-base files and then incorporates the newly verified, role-relevant facts into both current application documents in `letters/`.
+Turn evidence from one local software project into precise, reusable application facts. Given a project folder path, this skill maintains the three Markdown knowledge-base files and then incorporates the newly verified, role-relevant facts into both current application documents in `letters/`.
 
-Use this only for local repositories whose contents and Git history are available in the workspace or can be read locally.
+Use this for local project folders whose contents are available in the workspace or can be read locally. Git history is additional evidence when available, not a prerequisite for source-based facts.
 
 ## Non-Negotiable Evidence Rules
 
 - Treat repository contents, documentation, configuration, tests, and Git history as evidence, not as permission to infer unrecorded responsibilities.
-- Count Git commits as evidence of the applicant's contribution only when the author name is one of: `Rob Tranquillo`, `RobTranquillo`, `Tranquillo`, `trnq1ll0`, `Rob`, `rob`, `Robert`, or `Robert Wartenberg`.
+- Count Git commits as evidence of the applicant's contribution only when the author name or email exactly matches one of: `Rob Tranquillo`, `RobTranquillo`, `rob.tranquillo@gmx.de`, `Tranquillo`, `trnq1ll0`, `rw@boogiedev.net`, `Rob`, `rob`, `Robert`, `Robert Wartenberg`.
+- A Git-less project folder may support Knowledge Base facts when the user explicitly confirms that the project or the relevant work is their own. Record this provenance precisely as `eigene Entwicklung laut Nutzerangabe`; limit attributed implementation facts to functionality directly observable in the project contents. Do not claim commit-backed authorship, infer a date range, or assign an employment context from the folder alone.
+- Without qualifying commits or an explicit user confirmation of authorship, describe only the project contents and do not attribute implementation work to the applicant.
 - Derive a date range only from qualifying commits. State it as commit-backed only when appropriate; do not invent missing dates.
 - Distinguish private, voluntary, freelance, and professional contexts exactly as supported by evidence. If the context is unknown, describe it as a repository or project without assigning a role.
 - Do not overstate technology depth. Tie each technology to its concrete use, project, and observed complexity.
@@ -26,14 +28,15 @@ Use this only for local repositories whose contents and Git history are availabl
 
 ### 1. Establish Scope And Inspect The Repository
 
-1. Confirm that the supplied path exists and identify whether it is a Git worktree.
+1. Confirm that the supplied path exists and identify whether it is a Git worktree. If it is not, determine whether the user has explicitly confirmed authorship before attributing project work.
 2. Read the repository's README, contribution notes, build files, dependency manifests, configuration, tests, documentation, and the relevant source directories. Prefer focused searches over broad dumps.
 3. For Git worktrees, inspect:
    - remotes and current branch;
    - the author-filtered commit history, including commit dates and changed files;
    - relevant file history or diffs for non-obvious implementation details.
-4. Identify facts in five categories: purpose, concrete implementation, technical challenges, implemented solutions, and technologies.
+4. For Git-less project folders with explicit user-confirmed authorship, inspect the same source evidence but record the missing Git history and do not derive dates from filesystem metadata.
-5. Before editing, state a local, falsifiable summary of the strongest evidence and a check that could invalidate it.
+5. Identify facts in five categories: purpose, concrete implementation, technical challenges, implemented solutions, and technologies.
+6. Before editing, state a local, falsifiable summary of the strongest evidence and a check that could invalidate it.
 
 ### 2. Reconcile The Knowledge Base
 
@@ -45,7 +48,7 @@ Read all three files before making changes:
 
 Then update them in this order:
 
-1. **Projects:** Add or extend one project entry with repository source, evidence-backed period, context, challenges, and solutions.
+1. **Projects:** Add or extend one project entry with project source, evidence-backed period where available, context, challenges, and solutions.
 2. **Roles:** Add or extend a role only where its context and responsibilities are supported. Avoid a role entry when the repository cannot substantiate one.
 3. **Technologies:** Add or extend individual technology entries. For every technology, include complexity, concrete usage, and the project/context.
 
@@ -56,7 +59,7 @@ Maintain existing headings, German language, and factual bullet style. Merge wit
 After updating all three Knowledge-Base files, update both files below. This is required when the repository produces at least one new, verified fact relevant to the current application.
 
 1. Read `letters/coverletter.tex`, `letters/cv.tex`, and the shared document entry points `latex/coverletter.tex` and `latex/cv.tex`.
-2. Determine the target role from the current cover letter. Select only newly documented facts that support this role and can be defended from repository evidence.
+2. Determine the target role from the current cover letter. Select only newly documented facts that support this role and can be defended from project based evidence.
 3. Update `letters/coverletter.tex` with one or two concise, concrete examples that connect the new facts to the target role. Clearly label private work as private where relevant.
 4. Update `letters/cv.tex` with concise, recruiter-scannable evidence, such as a suitable skills entry or a project-related bullet. Do not add a duplicate role merely to force the fact into the CV.
 5. Update both documents in the same run. Do not update only the Knowledge Base or only one letter when relevant new facts exist.

knowledge/projects.md

@@ -81,3 +81,19 @@ Jedes Projekt/Kontext besteht aus einem Link bzw Quell, einer Beschreibung, den
 - Kontext: Früher 3D-Prototyp eines Falling-Block-Spiels in Rust.
 - Herausforderungen: Aufbau einer 3D-Szene, zeitgesteuerte Bewegung eines Spielsteins, Verarbeitung von Gamepad-Eingaben und Begrenzung der Bewegung auf das Spielfeld.
 - Lösungen: 3D-Fenster, Kamera, Plattform und Würfel mit `kiss3d`; Zustandsmodell über eine `BrickPos`-Struktur; zeitgesteuertes Fallen mit `Instant` und `Duration`; Gamepad-Abfrage über `stick`; Begrenzung der X-, Y- und Z-Koordinaten durch eine eigene Funktion; erneutes Erzeugen eines Würfels beim Erreichen des Spielfeldbodens.
+
+## ChipAcademy AR-Viewer-PackageBuilder
+
+- Zeitraum: 2020
+- Quelle: lokales Unity-Arbeitsverzeichnis `ChipAcademy/ARViewer Package`, `ChipAcademy/BackendConnector` und `ChipAcademy/Backend/Scripts`.
+- Kontext: Unity-PackageBuilder für konfigurierbare AR-Lernszenen und deren Bereitstellung im AR Viewer.
+- Herausforderungen: Wiederverwendbare Konfiguration von 3D-Modellen und Interaktionen; plattformspezifische Bereitstellung von Szeneninhalten; Abbildung von Lern- und Prüfungsinteraktionen mit Text-, Bild-, Video- und Animationsmarkern.
+- Lösungen: Unity-Editor-Menüs zum Erzeugen von AssetBundles für Android, Windows und iOS sowie zum Export des Builder-Pakets; `ScriptableObject` zur Konfiguration von Modell, Markern und Cross-Section-Darstellung; Laufzeitlogik für Lern- und Prüfungsmodus, Schrittsequenzen, Videoanzeige und Zuordnungsinteraktionen; Drupal-8.7.7-Backend mit XML-Endpunkt für Szenenmetadaten, Bild- und Beschreibungsdaten sowie plattformspezifische AssetBundle-URLs.
+
+## VR-Training für EnviaM-Umspannwerk
+
+- Zeitraum: Dezember 2019 bis Juli 2022
+- Quelle: `vr-bits/EnviaM_Umspannwerk`.
+- Kontext: Unity-VR-Anwendung zur Vermittlung von Abläufen in einem Umspannwerk.
+- Herausforderungen: Geführte und prüfbare Arbeitsschritte mit unterschiedlichen Schwierigkeitsgraden; realistische Rückmeldung von Spannungszuständen; zuverlässige Teleportation und GUI bei Szenenwechseln.
+- Lösungen: Integration von SteamVR, OpenVR, Oculus und VRTK; StepManager-basierte Schrittsteuerung mit Tutorial- und Testmodus; Zustandsmodell für Schalterverriegelungen und Spannungsprüfung einschließlich LED- und Display-Rückmeldung; Fehlererkennung für falsche Verriegelungen; asynchrones Laden und Entladen von Szenen sowie Teleportation mit konfigurierbarem Bildschirm-Übergang.

knowledge/roles.md

@@ -20,7 +20,7 @@ Enthält alle Rollen in denen ich schon Tätig war
 - Unternehmen: vrbits GmbH
 - Zeitraum: seit 2019
 - Ort: Leipzig
-- Tätigkeiten: Konzeption, Entwicklung und Betreuung komplexer interaktiver VR-, AR- und Flat-3D-Anwendungen; plattformübergreifende Entwicklung; Integration von SDKs, Schnittstellen, Datenformaten und Services; Aufbau und Pflege von CI-Pipelines; Performance-Optimierung.
+- Tätigkeiten: Konzeption, Entwicklung und Betreuung komplexer interaktiver VR-, AR- und Flat-3D-Anwendungen; plattformübergreifende Entwicklung; Integration von SDKs, Schnittstellen, Datenformaten und Services; Aufbau und Pflege von CI-Pipelines; Performance-Optimierung; Entwicklung von AR-Viewer mit konfigurierbaren Lerninteraktionen, plattformspezifischen Unity-AssetBundles und Drupal-XML-Schnittstelle für Szenenmetadaten; Implementierung eines Unity-VR-Trainings für Umspannwerksabläufe mit Schrittsteuerung, Spannungsprüfung, Fehlererkennung und SteamVR-gestützter Navigation.
 
 ### Freelance Full-Stack Developer
 

knowledge/technologies.md

@@ -8,7 +8,8 @@ Jede Technologie wird einzeln genannt und enthält das Level der verwendeten Kom
 
 - Komplexität: Komplexe, interaktive Anwendungen und plattformübergreifende Produktentwicklung.
 - Einsatz: Konzeption, Entwicklung und Betreuung von mehr als 20 VR-, AR- und Flat-3D-Anwendungen; Multi-Target-Entwicklung aus gemeinsamen Unity-Codebasen für XR, Web und Mobile; Client-Server-Kommunikation und Performance-Optimierung.
-- Kontext: vrbits GmbH, seit 2019.
+- Zusätzlicher Einsatz: Konfigurierbare AR-Lernszenen mit Lern- und Prüfungsmodus, Schrittsequenzen, Medienanzeige und Zuordnungsinteraktionen im ChipAcademy AR-Viewer-PackageBuilder.
+- Kontext: vrbits GmbH, seit 2019, sowie ChipAcademy AR-Viewer
 
 ### OpenXR, Meta Quest SDK, Mindport VR Builder, Needle Engine und 3D Vista
 
@@ -16,6 +17,36 @@ Jede Technologie wird einzeln genannt und enthält das Level der verwendeten Kom
 - Einsatz: Entwicklung von VR-Trainings, 3D-Visualisierungen und virtuellen Showrooms für unterschiedliche Zielsysteme.
 - Kontext: vrbits GmbH.
 
+### Unity AR Foundation, ARCore und ARKit
+
+- Komplexität: Erstellung plattformübergreifender AR-Inhalte innerhalb eines Unity-Projekts.
+- Einsatz: Abhängigkeiten AR-Viewer für die Bereitstellung konfigurierbarer AR-Lernszenen.
+- Projekt: ChipAcademy AR-Viewer
+
+### Unity AssetBundles, ScriptableObjects und UnityEditor
+
+- Komplexität: Konfigurierbare 3D-Inhalte und plattformspezifische Distribution aus einem Unity-Projekt.
+- Einsatz: Editor-Menüs zum Erzeugen von AssetBundles für Android, Windows und iOS sowie zum Export eines Unity-Pakets; `ScriptableObject` für Modelle, Marker, Overlays und Cross-Section-Einstellungen.
+- Projekt: ChipAcademy AR-Viewer
+
+### SteamVR, OpenVR, Oculus und VRTK
+
+- Komplexität: VR-Interaktion und Navigation für eine mehrszenige Trainingsanwendung.
+- Einsatz: Integration von SteamVR, OpenVR, Oculus und VRTK; erzwungene Teleportation mit konfigurierbarem Blink-Übergang sowie Controller- und Teleportationslogik in der Intro-Szene.
+- Projekt: VR-Training für EnviaM-Umspannwerk von Dezember 2019 bis Juli 2022.
+
+### Unity Package Manager und vrbits StepManager
+
+- Komplexität: Wiederverwendbare Paketabhängigkeiten und zustandsbasierte Schrittsteuerung für eine Trainingsanwendung.
+- Einsatz: Umstellung des StepManager von einer lokalen Paketquelle auf ein Git-Repository; Tutorial- und Testmodus sowie Laden des nächsten Arbeitsschritts über den StepManager.
+- Projekt: VR-Training für EnviaM-Umspannwerk im April und Juli 2022.
+
+### Drupal 8.7 und XML-Schnittstellen
+
+- Komplexität: Bereitstellung von Inhalts- und Metadaten für eine AR-Anwendung.
+- Einsatz: Drupal-8.7.7-Backend mit XML-Endpunkt; Übertragung von Szenen-UUIDs, Anbieter-, Revisions- und Zeitinformationen, Titeln, Beschreibungen, Bildern sowie iOS- und Android-AssetBundle-URLs an den Unity-AR-Viewer.
+- Projekt: ChipAcademy AR-Viewer
+
 ### Android und iOS
 
 - Komplexität: Mobile Zielplattformen innerhalb plattformübergreifender Unity-Projekte.