diff --git a/.github/skills/add-knowledge-from-repo/SKILL.md b/.github/skills/add-knowledge-from-repo/SKILL.md new file mode 100644 index 0000000..1811de3 --- /dev/null +++ b/.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: "" +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.