pdate skill damit er nicht immer die Belege mit aufschreibt

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

@@ -17,9 +17,9 @@ Use this for local project folders whose contents are available in the workspace
 
 - 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 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.
+- 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. State it as commit-backed only when appropriate; do not invent missing dates.
+- 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.
@@ -48,18 +48,18 @@ Read all three files before making changes:
 
 Then update them in this order:
 
-1. **Projects:** Add or extend one project entry with project source, evidence-backed period where available, context, challenges, and solutions. For Git-less projects, state that the period is not specified and label user-confirmed authorship explicitly.
+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.
+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 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.