update Skill to not only read git repos but plain project folders as well

.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. For Git-less projects, state that the period is not specified and label user-confirmed authorship explicitly.
 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.