---
name: add-knowledge-from-repo
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 Projektordner>"
user-invocable: true
---

# Repository Knowledge And Application Update

## Purpose

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 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 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 in the analysis report, not in the Knowledge Base; limit attributed implementation facts to functionality directly observable in the project contents. Do not 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. Do not invent missing dates or state in the Knowledge Base that a period is commit-backed.
- 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. 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. 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. 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

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 project source, 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.

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. Keep evidence provenance out of Knowledge Base content: do not write phrases such as `belegt durch eigene Commits`, `Commit-Historie`, `Git-Historie`, `laut Nutzerangabe`, or equivalent wording. Use evidence only to decide which factual claims are admissible; report the evidence basis separately in the final response when useful.

### 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 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.
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.