add skill to add new data into knowledge base from a git repo

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

@@ -0,0 +1,78 @@
+---
+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."
+argument-hint: "<Pfad zum lokalen Git-Repository>"
+user-invocable: true
+---
+
+# Repository Knowledge And Application Update
+
+## 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/`.
+
+Use this only for local repositories whose contents and Git history are available in the workspace or can be read locally.
+
+## 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`.
+- 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.
+- Record uncertainty and open questions instead of resolving them through assumptions.
+
+## Workflow
+
+### 1. Establish Scope And Inspect The Repository
+
+1. Confirm that the supplied path exists and identify whether it is a Git worktree.
+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.
+5. Before editing, state a local, falsifiable summary of the strongest evidence and a check that could invalidate it.
+
+### 2. Reconcile The Knowledge Base
+
+Read all three files before making changes:
+
+- `knowledge/projects.md`
+- `knowledge/roles.md`
+- `knowledge/technologies.md`
+
+Then update them in this order:
+
+1. **Projects:** Add or extend one project entry with repository source, evidence-backed period, 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.
+
+Maintain existing headings, German language, and factual bullet style. Merge with an existing entry when the repository or project is already present; do not duplicate facts across entries unnecessarily. Do not modify unrelated Knowledge Base statements.
+
+### 3. Update Both Application Documents
+
+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.
+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.
+6. Avoid repetition between the documents: use the cover letter for relevance and context, and the CV for compact evidence and technologies.
+7. Preserve the separation of concerns: edit content only in `letters/coverletter.tex` and `letters/cv.tex`. Do not put firm-specific wording in `latex/`, and do not modify `latex/awesome-cv.cls` or other shared template files for content changes.
+8. If no new fact is relevant to the current target role, leave both letter files unchanged and state that decision with the evidence-based reason.
+
+### 4. Validate The Knowledge Base And Application
+
+1. Run Markdown diagnostics for each modified file in `knowledge/`.
+2. Run `git diff --check` in the application repository.
+3. Run `make coverletter cv` from the application repository after changing either file in `letters/`.
+4. Report whether both PDFs were generated successfully. If the build fails, fix only errors caused by the touched content; otherwise report the unrelated failure without changing unrelated files.
+
+## Quality Bar
+
+The resulting Knowledge Base, cover letter, and CV must be defensible in an interview: every new claim should be traceable to the examined repository, qualifying Git history, existing Knowledge Base facts, the job advertisement, or an explicit user statement.
+
+Make the smallest focused edits needed. Do not erase user changes, rewrite unrelated entries, or modify generated build artifacts.