[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CVKF9MVFPHBH3W2D5ETEB6":3,"skill-same:01M6CVKF9MVFPHBH3W2D5ETEB6":68},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":43,"repositoryHtmlUrl":44,"repositoryHomepageUrl":6,"ownerHtmlUrl":45,"ownerBlogUrl":46,"ownerDescription":6,"updatedAt":47,"install":48,"resources":61},"01M6CVKF9MVFPHBH3W2D5ETEB6","projectgrade",null,"Grade student project repositories based on Git commits, GitHub Issues, and Pull Requests. Use when the user says \"projectgrade\", \"grade the project\", \"bewerte das Projekt\", \"Projektarbeit benoten\", or asks for a holistic grading of a collaborative repository from inside it, based on commits, issues, reviews and PRs. Do not use for per-lesson assignments (use repograde) or for knowledge-check exams (use knowledge-assessment).","georgernstgraf\u002Fopencode-helpers","georgernstgraf","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F115418377?v=4","01M6CVHJ34JS0CF98EFFN0FZ76","Georg Graf SPG","01M6CVHJ7VV5VK6RXY62SR0NE2",1,"MIT","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Fprojectgrade\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33],"pull","commits","issues","execution","pull requests","opencode","github","git","github issues","education","project","student","git commits","repositories","requests","2026-11-10 10:12:30",false,"---\nname: projectgrade\ndescription: Grade student project repositories based on Git commits, GitHub Issues, and Pull Requests. Use when the user says \"projectgrade\", \"grade the project\", \"bewerte das Projekt\", \"Projektarbeit benoten\", or asks for a holistic grading of a collaborative repository from inside it, based on commits, issues, reviews and PRs. Do not use for per-lesson assignments (use repograde) or for knowledge-check exams (use knowledge-assessment).\nlicense: MIT\ncompatibility: opencode\nmetadata:\n  category: education\n  scope: execution\n---\n\n# Projectgrade Skill\n\n## Purpose\n\nThis skill grades student Git repositories for collaborative project work where\nstudents contribute via branches, Pull Requests, and GitHub Issues. It evaluates\ncode contributions (via Git commits), issue management (creation, editing,\ncommenting, quality), pull request activity (creation, reviews, merging), and\nfurther measurable contributions (wiki, CI\u002FCD, testing, documentation, project\nmanagement).\n\nUnlike `repograde`, this skill does NOT use assignments (Aufgaben) or the\nassignment discovery sources.\nStudent identification is derived exclusively from Git commit email addresses,\nthen mapped to student names via the uploadthing database.\n\n## Output Language: MANDATORY GERMAN\n\nFollow the `grading-shared` **Output Language** rule: natural German with proper\nUTF-8 umlauts (ä, ö, ü, ß), never English.\n\n## Dependencies\n\nThis skill relies on `grading-shared` for: Anrede-Gate (`anrede.txt`), email formulas,\nsecond-person address rules, database lookup, email JSON structure,\nrepository analysis protocol, and reporting protocol.\n\n## Differences from repograde\n\n- Invoked from INSIDE the project Git repository (not from a local folder).\n- No assignment discovery required (project grading, not per-lesson assignments).\n- Evaluates GitHub Issues participation and Pull Request activity.\n- Student identification from Git commit emails only.\n- Issue quality, PR reviews, and collaboration factor into grading.\n- Single project mode (no bulk grading).\n- Holistic assessment approach (no rigid numeric weights).\n\n## Execution Context\n\nThis skill is invoked directly as a skill (no standalone command). It MUST be\ninvoked from within the Git repository being evaluated. Calling this skill from\noutside a Git repository is an error.\n\nThe skill grades a single collaborative project repository where multiple\nstudents contribute via branches, Pull Requests, and GitHub Issues by:\n1. Verifying we are inside a Git repository (error if not).\n2. Using `git pull` to ensure the latest version is checked out.\n3. Inspecting the repository content and Git history for grading.\n4. Querying GitHub API for issue and PR metadata (creation, edits, comments, reviews, merges).\n5. Detecting further measurable contributions (wiki, CI\u002FCD, tests, docs, project management).\n6. Mapping contributor email addresses to student names via uploadthing.db.\n\n## Input\n\n- `--gh-token`: GitHub token for API access (optional, defaults to environment).\n\nBehavior:\n\n- This skill operates on the current Git repository (CWD must be a Git repo).\n- No repository path argument is needed; we are already inside the project.\n\n## Protocol\n\n1. Verify we are in a Git repository. If not, STOP IMMEDIATELY with error.\n2. Run `git pull` to verify latest version is checked out.\n3. Run `git status` to check for uncommitted changes. If found, stop immediately.\n4. Derive the output stem from `basename \"$(git rev-parse --show-toplevel)\"` or\n   the current directory name.\n5. Extract all unique contributor email addresses from git commits.\n6. Query the uploadthing database to map emails to student names.\n7. Analyze repository contributions (see Repository Analysis section).\n8. Analyze GitHub Issues participation (see Issue Analysis section).\n9. Analyze Pull Request activity (see Pull Request Analysis section).\n10. Detect further measurable contributions (see Further Contributions section).\n11. Apply holistic grading philosophy (see Holistic Grading Philosophy section).\n12. Generate `\u003Cbasename>_grading.md` as the repository grading report in German.\n13. Generate `\u003Cbasename>_email.json` as a JSON array with student entries,\n    following `grading-shared` structure and using German body text.\n\n## Repository Analysis\n\nInspect repository content directly from within the current Git repository.\n\n### Pre-Grading Verification\n\nBefore inspecting repository content, verify repository state:\n\n1. Verify we are inside a Git repository:\n   ```bash\n   git rev-parse --is-inside-work-tree\n   ```\n   If this returns `false` or errors, STOP IMMEDIATELY and report to user.\n2. Run `git pull` to ensure latest version is checked out.\n3. Run `git status` to check for uncommitted changes.\n4. If uncommitted changes exist, STOP IMMEDIATELY and report to user.\n5. If pull fails or reports errors, STOP IMMEDIATELY and report to user.\n\n### Git Commit Analysis\n\nExtract all unique contributor email addresses:\n\n```bash\ngit log --all --format='%ae' | sort -u\n```\n\nFor each contributor, collect commit statistics:\n\n```bash\ngit log --all --author='\u003Cemail>' --format='%H' | wc -l  # commit count\ngit log --all --author='\u003Cemail>' --format='' --numstat | awk '{added+=$1; deleted+=$2} END {print added, deleted}'\n```\n\n### Branch Analysis\n\n- Enumerate all branches: `git branch -a`\n- Count commits per branch per author.\n- Identify significant non-main branch contributions.\n- Note branch naming patterns and merge activity.\n\n#### Deleted Branch Recovery\n\n**IMPORTANT:** `git branch -a` only shows currently existing branches. Branches\nused for Pull Requests are frequently deleted after merge. The grading MUST\naccount for contributions made on branches that no longer exist.\n\nRecovery methods:\n\n1. **Merge commit history**: Commits from deleted branches remain in the Git\n   history and are fully attributable via `git log --all`. Commit attribution\n   is unaffected by branch deletion.\n   ```bash\n   git log --all --merges --format='%H %P'  # show merge commits and parents\n   ```\n2. **GitHub PR API**: Pull Requests retain their source branch name and author\n   even after the branch is deleted. Use:\n   ```\n   GET \u002Frepos\u002F{owner}\u002F{repo}\u002Fpulls?state=all\n   ```\n   Each PR record contains `head.ref` (source branch name), `user.login`\n   (creator), and `merged_by.login` — all preserved regardless of branch\n   deletion.\n3. **GitHub commit association**: For any commit SHA, the GitHub API can reveal\n   which PR introduced it:\n   ```\n   GET \u002Frepos\u002F{owner}\u002F{repo}\u002Fcommits\u002F{sha}\u002Fpulls\n   ```\n\nWhen attributing work to students, always cross-reference Git commits with PR\nhistory to ensure no contributions from deleted branches are missed.\n\n### Per-commit Inspection\n\nFor significant commits, inspect actual changes:\n\n- `git show --stat --summary \u003Csha>`\n- `git show --format=fuller --unified=3 \u003Csha>`\n\nUse diff content to identify substantive vs superficial work:\n- substantive: meaningful implementation, debugging, refactoring, feature work.\n- superficial: formatting-only, whitespace, trivial renames, auto-generated files.\n\n## Issue Analysis\n\nThis skill evaluates GitHub Issues participation as a key grading factor.\n\n### Issue Discovery\n\nUse GitHub API to fetch repository issues:\n\n```\nGET \u002Frepos\u002F{owner}\u002F{repo}\u002Fissues\nGET \u002Frepos\u002F{owner}\u002F{repo}\u002Fissues\u002F{issue_number}\u002Fcomments\nGET \u002Frepos\u002F{owner}\u002F{repo}\u002Fissues\u002F{issue_number}\u002Fevents\n```\n\n### Issue Attribution by Email\n\nGitHub API returns `user.login` (username), not email. To attribute issues to\nstudents:\n\n1. Extract all unique email addresses from Git commits.\n2. For each commit author email, query GitHub API to find their username:\n   ```\n   GET \u002Fsearch\u002Fusers?q=\u003Cemail>+in:email\n   ```\n3. Or use commit author name and compare to GitHub usernames cautiously:\n   - Names often differ from usernames.\n   - Prefer email-based matching for accuracy.\n4. Map issue activity to student emails via the username lookup.\n\n### Issue Quality Rubric\n\nEvaluate issue quality based on:\n\n- **Title clarity**: Descriptive, specific, actionable.\n- **Description completeness**: Steps to reproduce, expected vs actual behavior.\n- **Code examples**: Minimal reproducible examples provided.\n- **Screenshots\u002Flogs**: Supporting evidence for bug reports.\n- **Labels**: Appropriate categorization (bug, enhancement, question).\n- **Response to feedback**: Updates based on maintainer comments.\n\nQuality Rating (1-5):\n  5 = Exceptional: Complete, clear, with reproducible examples.\n  4 = Good: Well-described with most relevant details.\n  3 = Average: Adequate description but missing some context.\n  2 = Below Average: Vague, incomplete, or poorly structured.\n  1 = Poor: No clear description or incorrectly filed.\n\n## Pull Request Analysis\n\nThis skill evaluates Pull Request activity as a key collaboration indicator.\n\n### PR Discovery\n\nUse GitHub API to fetch all Pull Requests and their metadata:\n\n```\nGET \u002Frepos\u002F{owner}\u002F{repo}\u002Fpulls?state=all\nGET \u002Frepos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Freviews\nGET \u002Frepos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Fcomments\nGET \u002Frepos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Fcommits\n```\n\n### PR Attribution\n\nMap PRs to students using the same email-to-username lookup as Issue Analysis.\nPRs contain `user.login` (creator), `merged_by.login` (merger), and review\nauthors — all resolved to student emails via the GitHub username mapping.\n\n### Per-student PR Metrics\n\nFor each contributing student, collect:\n\n- **PRs created**: total count, broken down by state (open \u002F merged \u002F closed without merge).\n- **PRs merged**: successfully integrated contributions.\n- **Reviews given**: count by type (approved \u002F changes requested \u002F commented).\n- **PR comments**: inline code review comments on others' PRs.\n- **Review responsiveness**: time between review feedback and author's response.\n- **Commits per PR**: volume of work per PR (distinguish large features from typo fixes).\n\n### PR Quality Rubric\n\nEvaluate PR quality based on:\n\n- **Description completeness**: Context, motivation, linked issues, screenshots for UI changes.\n- **Code review quality**: When reviewing others' PRs — constructive, specific, helpful suggestions.\n- **Responsiveness to feedback**: Timely and thorough responses to review comments on own PRs.\n- **Branch management**: Clean commit history, meaningful commit messages, appropriately scoped changes.\n- **Linked issues**: PRs that reference or close related issues.\n\n### Merge Status Evaluation\n\n- **Merged PRs**: Successfully integrated — strong indicator of accepted contribution quality.\n- **Closed (not merged) PRs**: Investigate reason — may indicate learning process, rejected approaches,\n  or superseded by other work. Do not automatically penalize; consider context.\n- **Open PRs**: Pending review — note as work in progress.\n\n## Further Contributions\n\nBeyond commits, issues, and PRs, detect and list additional measurable\ncontributions for each student. These are presented descriptively in the\ngrading report — not scored numerically.\n\n### Detection Methods\n\n| Contribution | Detection Method |\n|---|---|\n| **Wiki edits** | GitHub Wiki is a separate Git repo; check `GET \u002Frepos\u002F{owner}\u002F{repo}\u002Fcontents\u002Fdocs\u002F` or wiki commit history. |\n| **GitHub Discussions** | GraphQL API: `Discussion` and `DiscussionComment` nodes. |\n| **Project board management** | `GET \u002Frepos\u002F{owner}\u002F{repo}\u002Fprojects` + cards\u002Fcolumns (or v2 Projects via GraphQL). |\n| **Milestone management** | `GET \u002Frepos\u002F{owner}\u002F{repo}\u002Fmilestones` — creation and due-date setting. |\n| **Label taxonomy** | `GET \u002Frepos\u002F{owner}\u002F{repo}\u002Flabels` — custom labels created; also check issue label assignments. |\n| **Releases \u002F tagging** | `GET \u002Frepos\u002F{owner}\u002F{repo}\u002Freleases` — release notes, version management. |\n| **CI\u002FCD setup** | Commits touching `.github\u002Fworkflows\u002F`, `Makefile`, `Dockerfile`, `docker-compose.yml`. |\n| **Testing** | Commits touching test files (`*_test.*`, `*.spec.*`, `tests\u002F`, `__tests__\u002F`) — recognized separately from feature code. |\n| **Documentation** | Commits touching `*.md`, `docs\u002F`, `README*` — separate from code contributions. |\n| **Merge conflict resolution** | Merge commits with multiple parents; inspect diff for manual resolution effort. |\n| **Dependency management** | Commits touching `package.json`, `Cargo.toml`, `requirements.txt`, `pom.xml`, etc. |\n| **Configuration \u002F tooling** | Commits touching `.editorconfig`, `.eslintrc*`, `.prettierrc*`, `tsconfig.json`, etc. |\n\n### Attribution\n\nAll contributions detected via commits are automatically attributed via the\nemail-based student mapping. Contributions detected via GitHub API (wiki,\ndiscussions, project boards) use the same username-to-email lookup as issues\nand PRs.\n\n## Student Identification\n\n### Email Extraction\n\nExtract all unique commit author emails:\n\n```bash\ngit log --all --format='%ae' | sort -u\n```\n\n### Database Lookup\n\nQuery uploadthing.db for student identification:\n\n```sql\nSELECT email, name, klasse FROM users WHERE email IN (email_list)\n```\n\nDatabase path: `\u002Fhome\u002Fgeorg\u002FOneDrive\u002Fuploadthing.db`\n\n### Address Style\n\nUse the `grading-shared` **Anrede-Gate**: read `\u003Csubject>-T\u002F\u003Ckohorte>\u002Fanrede.txt`\nwith `read-anrede.sh`. A missing or invalid file stops the run — never derive\nthe address style from the class name.\n\n### Unmatched Students\n\nIf an email cannot be matched in the database, follow the `grading-shared`\n**Missing Email Address Handling (CRITICAL)** protocol: stop before generating\nthe email payload, report every unresolved name to the user, and wait for the\ndatabase to be updated. Do not invent contact data and do not emit `null`\n`mailto` values.\n\n## Holistic Grading Philosophy\n\nThis skill uses a holistic, descriptive assessment approach rather than rigid\nnumeric weights. The goal is to produce a transparent, comprehensive listing\nof each student's contributions that supports intuitive evaluation and\nindividual discussion.\n\n### Core Principles\n\n1. **Comprehensive listing first**: For each student, list ALL factual\n   contributions — commits, issues, PRs, reviews, wiki edits, CI\u002FCD setup,\n   tests, documentation, project management, and any other measurable work.\n2. **Estimated time investment**: Intuitively estimate hours invested based on\n   the volume and quality of contributions. This is a rough assessment, not\n   a precise calculation.\n3. **Different contribution styles are equally valued**: Some students contribute\n   more through code, others through issues, reviews, documentation, or project\n   management. All forms of meaningful contribution are recognized.\n4. **Diligence rating**: Assess as `high`, `medium`, or `low` based on:\n   - Regular commit frequency (not just bursts at deadlines).\n   - Consistent involvement throughout the project duration.\n   - Quality of changes (substantive vs. superficial).\n   - Proper branch management and PR workflow.\n   - Engagement in reviews and discussions.\n5. **Not fully objective — and that is acceptable**: This assessment cannot be\n   100% objective. Transparency of listed contributions compensates. The\n   grading report provides the factual basis for individual conversations.\n6. **Individual discussion**: The report is designed to support one-on-one\n   conversations with students. List contributions factually so that both\n   teacher and student can discuss the assessment.\n\n### Qualitative Aids\n\nThe following are used as qualitative reference points, NOT as numeric score inputs:\n\n- **Substantive vs. superficial work** distinction (from per-commit inspection).\n- **Issue Quality Rubric** (1-5 scale, used descriptively).\n- **PR Quality Rubric** (used descriptively).\n- **Commit message quality** (clear, descriptive messages vs. generic ones).\n- **Contribution spread** (evenly distributed vs. clustered at deadlines).\n\n## Outputs\n\n- `\u003Cbasename>_grading.md` in German.\n- `\u003Cbasename>_email.json` as a JSON array following `grading-shared` rules and using German body text.\n\n## Grading Report Structure\n\nThe mandatory `\u003Cbasename>_grading.md` structure is in\n[REPORT-FORMAT.md](.\u002FREPORT-FORMAT.md).\n\n## Email and Database Rules\n\nAlways use `grading-shared` for:\n\n- class-to-address-style mapping.\n- greeting and closing formulas.\n- gender fallback protocol.\n- database lookup using `\u002Fhome\u002Fgeorg\u002FOneDrive\u002Fuploadthing.db`.\n- email payload structure and paragraph preservation.\n\n## Constraints\n\n- This skill MUST be invoked from within a Git repository (the project being evaluated).\n- If not inside a Git repository, STOP IMMEDIATELY with an error.\n- If uncommitted changes exist in the repository, STOP IMMEDIATELY.\n- Do not commit changes or modify repository history.\n- All grading content must use second-person address (Sie or Du) in German.\n- Never use third-person references to the student.\n- Student identification comes from Git commit emails only.\n- Issue and PR attribution prefers email over username for accuracy.\n- Grade all project contributors, not just code authors.\n- Account for contributions on branches that have since been deleted.\n- Pair programming and mentoring contributions are invisible to Git — the\n  driver's commit is attributed, not the navigator. Note where such\n  contributions are suspected but unmeasurable.\n- Offline coordination (Slack, verbal discussion, external research) cannot\n  be detected. The grading report should acknowledge this limitation.\n- Use pure AI evaluation; never write scripts to automate project assessment.\n\n## Done when\n\n- [ ] Verified inside the project Git repository, `git pull` run and a clean\n  `git status`; any of these failing stopped the run.\n- [ ] `anrede.txt` read via `read-anrede.sh`; a missing or invalid file stopped\n  the run before any output was written.\n- [ ] Every contributor email extracted and matched in `uploadthing.db`;\n  unresolved names reported and the email payload held back.\n- [ ] Evidence collected for commits, deleted branches (merge history plus PR\n  API), issues, PR reviews and further contributions.\n- [ ] `\u003Cbasename>_grading.md` written in German in the\n  [REPORT-FORMAT.md](.\u002FREPORT-FORMAT.md) structure, listing every contributor's\n  work.\n- [ ] `\u003Cbasename>_email.json` written in German with one payload per graded\n  student, consistent with the report.\n- [ ] Repository left unmodified: no commit, no history change, no issue or PR\n  written.\n","# Projectgrade Skill\n\n## Purpose\n\nThis skill grades student Git repositories for collaborative project work where\nstudents contribute via branches, Pull Requests, and GitHub Issues. It evaluates\ncode contributions (via Git commits), issue management (creation, editing,\ncommenting, quality), pull request activity (creation, reviews, merging), and\nfurther measurable contributions (wiki, CI\u002FCD, testing, documentation, project\nmanagement).\n\nUnlike `repograde`, this skill does NOT use assignments (Aufgaben) or the\nassignment discovery sources.\nStudent identification is derived exclusively from Git commit email addresses,\nthen mapped to student names via the uploadthing database.\n\n## Output Language: MANDATORY GERMAN\n\nFollow the `grading-shared` **Output Language** rule: natural German with proper\nUTF-8 umlauts (ä, ö, ü, ß), never English.\n\n## Dependencies\n\nThis skill relies on `grading-shared` for: Anrede-Gate (`anrede.txt`), email formulas,\nsecond-person address rules, database lookup, email JSON structure,\nrepository analysis protocol, and reporting protocol.\n\n## Differences from repograde\n\n- Invoked from INSIDE the project Git repository (not from a local folder).\n- No assignment discovery required (project grading, not per-lesson assignments).\n- Evaluates GitHub Issues participation and Pull Request activity.\n- Student identification from Git commit emails only.\n- Issue quality, PR reviews, and collaboration factor into grading.\n- Single project mode (no bulk grading).\n- Holistic assessment approach (no rigid numeric weights).\n\n## Execution Context\n\nThis skill is invoked directly as a skill (no standalone command). It MUST be\ninvoked from within the Git repository being evaluated. Calling this skill from\noutside a Git repository is an error.\n\nThe skill grades a single collaborative project repository where multiple\nstudents contribute via branches, Pull Requests, and GitHub Issues by:\n1. Verifying we are inside a Git repository (error if not).\n2. Using `git pull` to ensure the latest version is checked out.\n3. Inspecting the repository content and Git history for grading.\n4. Querying GitHub API for issue and PR metadata (creation, edits, comments, reviews, merges).\n5. Detecting further measurable contributions (wiki, CI\u002FCD, tests, docs, project management).\n6. Mapping contributor email addresses to student names via uploadthing.db.\n\n## Input\n\n- `--gh-token`: GitHub token for API access (optional, defaults to environment).\n\nBehavior:\n\n- This skill operates on the current Git repository (CWD must be a Git repo).\n- No repository path argument is needed; we are already inside the project.\n\n## Protocol\n\n1. Verify we are in a Git repository. If not, STOP IMMEDIATELY with error.\n2. Run `git pull` to verify latest version is checked out.\n3. Run `git status` to check for uncommitted changes. If found, stop immediately.\n4. Derive the output stem from `basename \"$(git rev-parse --show-toplevel)\"` or\n   the current directory name.\n5. Extract all unique contributor email addresses from git commits.\n6. Query the uploadthing database to map emails to student names.\n7. Analyze repository contributions (see Repository Analysis section).\n8. Analyze GitHub Issues participation (see Issue Analysis section).\n9. Analyze Pull Request activity (see Pull Request Analysis section).\n10. Detect further measurable contributions (see Further Contributions section).\n11. Apply holistic grading philosophy (see Holistic Grading Philosophy section).\n12. Generate `\u003Cbasename>_grading.md` as the repository grading report in German.\n13. Generate `\u003Cbasename>_email.json` as a JSON array with student entries,\n    following `grading-shared` structure and using German body text.\n\n## Repository Analysis\n\nInspect repository content directly from within the current Git repository.\n\n### Pre-Grading Verification\n\nBefore inspecting repository content, verify repository state:\n\n1. Verify we are inside a Git repository:\n   ```bash\n   git rev-parse --is-inside-work-tree\n   ```\n   If this returns `false` or errors, STOP IMMEDIATELY and report to user.\n2. Run `git pull` to ensure latest version is checked out.\n3. Run `git status` to check for uncommitted changes.\n4. If uncommitted changes exist, STOP IMMEDIATELY and report to user.\n5. If pull fails or reports errors, STOP IMMEDIATELY and report to user.\n\n### Git Commit Analysis\n\nExtract all unique contributor email addresses:\n\n```bash\ngit log --all --format='%ae' | sort -u\n```\n\nFor each contributor, collect commit statistics:\n\n```bash\ngit log --all --author='\u003Cemail>' --format='%H' | wc -l  # commit count\ngit log --all --author='\u003Cemail>' --format='' --numstat | awk '{added+=$1; deleted+=$2} END {print added, deleted}'\n```\n\n### Branch Analysis\n\n- Enumerate all branches: `git branch -a`\n- Count commits per branch per author.\n- Identify significant non-main branch contributions.\n- Note branch naming patterns and merge activity.\n\n#### Deleted Branch Recovery\n\n**IMPORTANT:** `git branch -a` only shows currently existing branches. Branches\nused for Pull Requests are frequently deleted after merge. The grading MUST\naccount for contributions made on branches that no longer exist.\n\nRecovery methods:\n\n1. **Merge commit history**: Commits from deleted branches remain in the Git\n   history and are fully attributable via `git log --all`. Commit attribution\n   is unaffected by branch deletion.\n   ```bash\n   git log --all --merges --format='%H %P'  # show merge commits and parents\n   ```\n2. **GitHub PR API**: Pull Requests retain their source branch name and author\n   even after the branch is deleted. Use:\n   ```\n   GET \u002Frepos\u002F{owner}\u002F{repo}\u002Fpulls?state=all\n   ```\n   Each PR record contains `head.ref` (source branch name), `user.login`\n   (creator), and `merged_by.login` — all preserved regardless of branch\n   deletion.\n3. **GitHub commit association**: For any commit SHA, the GitHub API can reveal\n   which PR introduced it:\n   ```\n   GET \u002Frepos\u002F{owner}\u002F{repo}\u002Fcommits\u002F{sha}\u002Fpulls\n   ```\n\nWhen attributing work to students, always cross-reference Git commits with PR\nhistory to ensure no contributions from deleted branches are missed.\n\n### Per-commit Inspection\n\nFor significant commits, inspect actual changes:\n\n- `git show --stat --summary \u003Csha>`\n- `git show --format=fuller --unified=3 \u003Csha>`\n\nUse diff content to identify substantive vs superficial work:\n- substantive: meaningful implementation, debugging, refactoring, feature work.\n- superficial: formatting-only, whitespace, trivial renames, auto-generated files.\n\n## Issue Analysis\n\nThis skill evaluates GitHub Issues participation as a key grading factor.\n\n### Issue Discovery\n\nUse GitHub API to fetch repository issues:\n\n```\nGET \u002Frepos\u002F{owner}\u002F{repo}\u002Fissues\nGET \u002Frepos\u002F{owner}\u002F{repo}\u002Fissues\u002F{issue_number}\u002Fcomments\nGET \u002Frepos\u002F{owner}\u002F{repo}\u002Fissues\u002F{issue_number}\u002Fevents\n```\n\n### Issue Attribution by Email\n\nGitHub API returns `user.login` (username), not email. To attribute issues to\nstudents:\n\n1. Extract all unique email addresses from Git commits.\n2. For each commit author email, query GitHub API to find their username:\n   ```\n   GET \u002Fsearch\u002Fusers?q=\u003Cemail>+in:email\n   ```\n3. Or use commit author name and compare to GitHub usernames cautiously:\n   - Names often differ from usernames.\n   - Prefer email-based matching for accuracy.\n4. Map issue activity to student emails via the username lookup.\n\n### Issue Quality Rubric\n\nEvaluate issue quality based on:\n\n- **Title clarity**: Descriptive, specific, actionable.\n- **Description completeness**: Steps to reproduce, expected vs actual behavior.\n- **Code examples**: Minimal reproducible examples provided.\n- **Screenshots\u002Flogs**: Supporting evidence for bug reports.\n- **Labels**: Appropriate categorization (bug, enhancement, question).\n- **Response to feedback**: Updates based on maintainer comments.\n\nQuality Rating (1-5):\n  5 = Exceptional: Complete, clear, with reproducible examples.\n  4 = Good: Well-described with most relevant details.\n  3 = Average: Adequate description but missing some context.\n  2 = Below Average: Vague, incomplete, or poorly structured.\n  1 = Poor: No clear description or incorrectly filed.\n\n## Pull Request Analysis\n\nThis skill evaluates Pull Request activity as a key collaboration indicator.\n\n### PR Discovery\n\nUse GitHub API to fetch all Pull Requests and their metadata:\n\n```\nGET \u002Frepos\u002F{owner}\u002F{repo}\u002Fpulls?state=all\nGET \u002Frepos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Freviews\nGET \u002Frepos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Fcomments\nGET \u002Frepos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Fcommits\n```\n\n### PR Attribution\n\nMap PRs to students using the same email-to-username lookup as Issue Analysis.\nPRs contain `user.login` (creator), `merged_by.login` (merger), and review\nauthors — all resolved to student emails via the GitHub username mapping.\n\n### Per-student PR Metrics\n\nFor each contributing student, collect:\n\n- **PRs created**: total count, broken down by state (open \u002F merged \u002F closed without merge).\n- **PRs merged**: successfully integrated contributions.\n- **Reviews given**: count by type (approved \u002F changes requested \u002F commented).\n- **PR comments**: inline code review comments on others' PRs.\n- **Review responsiveness**: time between review feedback and author's response.\n- **Commits per PR**: volume of work per PR (distinguish large features from typo fixes).\n\n### PR Quality Rubric\n\nEvaluate PR quality based on:\n\n- **Description completeness**: Context, motivation, linked issues, screenshots for UI changes.\n- **Code review quality**: When reviewing others' PRs — constructive, specific, helpful suggestions.\n- **Responsiveness to feedback**: Timely and thorough responses to review comments on own PRs.\n- **Branch management**: Clean commit history, meaningful commit messages, appropriately scoped changes.\n- **Linked issues**: PRs that reference or close related issues.\n\n### Merge Status Evaluation\n\n- **Merged PRs**: Successfully integrated — strong indicator of accepted contribution quality.\n- **Closed (not merged) PRs**: Investigate reason — may indicate learning process, rejected approaches,\n  or superseded by other work. Do not automatically penalize; consider context.\n- **Open PRs**: Pending review — note as work in progress.\n\n## Further Contributions\n\nBeyond commits, issues, and PRs, detect and list additional measurable\ncontributions for each student. These are presented descriptively in the\ngrading report — not scored numerically.\n\n### Detection Methods\n\n| Contribution | Detection Method |\n|---|---|\n| **Wiki edits** | GitHub Wiki is a separate Git repo; check `GET \u002Frepos\u002F{owner}\u002F{repo}\u002Fcontents\u002Fdocs\u002F` or wiki commit history. |\n| **GitHub Discussions** | GraphQL API: `Discussion` and `DiscussionComment` nodes. |\n| **Project board management** | `GET \u002Frepos\u002F{owner}\u002F{repo}\u002Fprojects` + cards\u002Fcolumns (or v2 Projects via GraphQL). |\n| **Milestone management** | `GET \u002Frepos\u002F{owner}\u002F{repo}\u002Fmilestones` — creation and due-date setting. |\n| **Label taxonomy** | `GET \u002Frepos\u002F{owner}\u002F{repo}\u002Flabels` — custom labels created; also check issue label assignments. |\n| **Releases \u002F tagging** | `GET \u002Frepos\u002F{owner}\u002F{repo}\u002Freleases` — release notes, version management. |\n| **CI\u002FCD setup** | Commits touching `.github\u002Fworkflows\u002F`, `Makefile`, `Dockerfile`, `docker-compose.yml`. |\n| **Testing** | Commits touching test files (`*_test.*`, `*.spec.*`, `tests\u002F`, `__tests__\u002F`) — recognized separately from feature code. |\n| **Documentation** | Commits touching `*.md`, `docs\u002F`, `README*` — separate from code contributions. |\n| **Merge conflict resolution** | Merge commits with multiple parents; inspect diff for manual resolution effort. |\n| **Dependency management** | Commits touching `package.json`, `Cargo.toml`, `requirements.txt`, `pom.xml`, etc. |\n| **Configuration \u002F tooling** | Commits touching `.editorconfig`, `.eslintrc*`, `.prettierrc*`, `tsconfig.json`, etc. |\n\n### Attribution\n\nAll contributions detected via commits are automatically attributed via the\nemail-based student mapping. Contributions detected via GitHub API (wiki,\ndiscussions, project boards) use the same username-to-email lookup as issues\nand PRs.\n\n## Student Identification\n\n### Email Extraction\n\nExtract all unique commit author emails:\n\n```bash\ngit log --all --format='%ae' | sort -u\n```\n\n### Database Lookup\n\nQuery uploadthing.db for student identification:\n\n```sql\nSELECT email, name, klasse FROM users WHERE email IN (email_list)\n```\n\nDatabase path: `\u002Fhome\u002Fgeorg\u002FOneDrive\u002Fuploadthing.db`\n\n### Address Style\n\nUse the `grading-shared` **Anrede-Gate**: read `\u003Csubject>-T\u002F\u003Ckohorte>\u002Fanrede.txt`\nwith `read-anrede.sh`. A missing or invalid file stops the run — never derive\nthe address style from the class name.\n\n### Unmatched Students\n\nIf an email cannot be matched in the database, follow the `grading-shared`\n**Missing Email Address Handling (CRITICAL)** protocol: stop before generating\nthe email payload, report every unresolved name to the user, and wait for the\ndatabase to be updated. Do not invent contact data and do not emit `null`\n`mailto` values.\n\n## Holistic Grading Philosophy\n\nThis skill uses a holistic, descriptive assessment approach rather than rigid\nnumeric weights. The goal is to produce a transparent, comprehensive listing\nof each student's contributions that supports intuitive evaluation and\nindividual discussion.\n\n### Core Principles\n\n1. **Comprehensive listing first**: For each student, list ALL factual\n   contributions — commits, issues, PRs, reviews, wiki edits, CI\u002FCD setup,\n   tests, documentation, project management, and any other measurable work.\n2. **Estimated time investment**: Intuitively estimate hours invested based on\n   the volume and quality of contributions. This is a rough assessment, not\n   a precise calculation.\n3. **Different contribution styles are equally valued**: Some students contribute\n   more through code, others through issues, reviews, documentation, or project\n   management. All forms of meaningful contribution are recognized.\n4. **Diligence rating**: Assess as `high`, `medium`, or `low` based on:\n   - Regular commit frequency (not just bursts at deadlines).\n   - Consistent involvement throughout the project duration.\n   - Quality of changes (substantive vs. superficial).\n   - Proper branch management and PR workflow.\n   - Engagement in reviews and discussions.\n5. **Not fully objective — and that is acceptable**: This assessment cannot be\n   100% objective. Transparency of listed contributions compensates. The\n   grading report provides the factual basis for individual conversations.\n6. **Individual discussion**: The report is designed to support one-on-one\n   conversations with students. List contributions factually so that both\n   teacher and student can discuss the assessment.\n\n### Qualitative Aids\n\nThe following are used as qualitative reference points, NOT as numeric score inputs:\n\n- **Substantive vs. superficial work** distinction (from per-commit inspection).\n- **Issue Quality Rubric** (1-5 scale, used descriptively).\n- **PR Quality Rubric** (used descriptively).\n- **Commit message quality** (clear, descriptive messages vs. generic ones).\n- **Contribution spread** (evenly distributed vs. clustered at deadlines).\n\n## Outputs\n\n- `\u003Cbasename>_grading.md` in German.\n- `\u003Cbasename>_email.json` as a JSON array following `grading-shared` rules and using German body text.\n\n## Grading Report Structure\n\nThe mandatory `\u003Cbasename>_grading.md` structure is in\n[REPORT-FORMAT.md](.\u002FREPORT-FORMAT.md).\n\n## Email and Database Rules\n\nAlways use `grading-shared` for:\n\n- class-to-address-style mapping.\n- greeting and closing formulas.\n- gender fallback protocol.\n- database lookup using `\u002Fhome\u002Fgeorg\u002FOneDrive\u002Fuploadthing.db`.\n- email payload structure and paragraph preservation.\n\n## Constraints\n\n- This skill MUST be invoked from within a Git repository (the project being evaluated).\n- If not inside a Git repository, STOP IMMEDIATELY with an error.\n- If uncommitted changes exist in the repository, STOP IMMEDIATELY.\n- Do not commit changes or modify repository history.\n- All grading content must use second-person address (Sie or Du) in German.\n- Never use third-person references to the student.\n- Student identification comes from Git commit emails only.\n- Issue and PR attribution prefers email over username for accuracy.\n- Grade all project contributors, not just code authors.\n- Account for contributions on branches that have since been deleted.\n- Pair programming and mentoring contributions are invisible to Git — the\n  driver's commit is attributed, not the navigator. Note where such\n  contributions are suspected but unmeasurable.\n- Offline coordination (Slack, verbal discussion, external research) cannot\n  be detected. The grading report should acknowledge this limitation.\n- Use pure AI evaluation; never write scripts to automate project assessment.\n\n## Done when\n\n- [ ] Verified inside the project Git repository, `git pull` run and a clean\n  `git status`; any of these failing stopped the run.\n- [ ] `anrede.txt` read via `read-anrede.sh`; a missing or invalid file stopped\n  the run before any output was written.\n- [ ] Every contributor email extracted and matched in `uploadthing.db`;\n  unresolved names reported and the email payload held back.\n- [ ] Evidence collected for commits, deleted branches (merge history plus PR\n  API), issues, PR reviews and further contributions.\n- [ ] `\u003Cbasename>_grading.md` written in German in the\n  [REPORT-FORMAT.md](.\u002FREPORT-FORMAT.md) structure, listing every contributor's\n  work.\n- [ ] `\u003Cbasename>_email.json` written in German with one payload per graded\n  student, consistent with the report.\n- [ ] Repository left unmodified: no commit, no history change, no issue or PR\n  written.\n",{"name":5,"license":15,"metadata":39,"description":7,"compatibility":24},{"scope":22,"category":28},"main","adef05bd2193559aced970b8591fc8182a916301","skills\u002Fprojectgrade",0,"https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf","https:\u002F\u002Fwww.spengergasse.at\u002F","2026-11-11 16:51:38",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add georgernstgraf\u002Fopencode-helpers --skill projectgrade",{"tool":54,"command":55},"bunx","bunx skills add georgernstgraf\u002Fopencode-helpers --skill projectgrade",{"tool":57,"command":58},"pnpm","pnpm dlx skills add georgernstgraf\u002Fopencode-helpers --skill projectgrade","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Fprojectgrade\u002FSKILL.md",true,[62],{"path":63,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":66,"sourceHtmlUrl":67},"REPORT-FORMAT.md","REFERENCE","参考文档",1671,"https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Fprojectgrade\u002FREPORT-FORMAT.md",[69,87,112,125,137,161],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":80,"publishedAt":34},"01M6CVKZ762FN4SW18V26P65TD","teach","Teach the user a new skill or concept, within this workspace.","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Fteach\u002FSKILL.md",[75],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000039","教师与教育","PROFESSION","适用职业",[71,81,82,83,84,85,86],"false","new","concept","user","new skill","workspace",{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":34},"01M6CVKVT6ZVYN2XPESS5EGDKE","sync-upstream-skills","Re-transplant owned skills from their mattpocock upstream after a git pull, applying upstream content changes while preserving opencode-native frontmatter. Also checks for duplicate skill names and dangling cross-skill references. Use when the user says \"sync skills\", \"refresh from upstream\", \"pull matt's skills\", \"sync upstream\", \"update the transplanted skills\", or wants to bring the owned transplanted skills up to date. Do not use to add or rename a transplanted skill — that stays manual.","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Fsync-upstream-skills\u002FSKILL.md",[],[94,95,96,97,19,98,99,24,100,101,102,103,104,105,26,106,107,108,109,84,110,111],"sync","upstream","sync upstream","sync upstream skills","references","refresh","duplicate skill","up","duplicate","frontmatter","native","changes","when","re","for","bring","content","use",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":34},"01M6CVKNEPEY1WA7E5FWQ85NJW","repograde","Grade student repositories with optional date filtering in single-repo or bulk mode. Use when the user says \"repograde\", \"grade the repos\", \"grade this repo since \u003Cdate>\", \"bewerte die Abgaben\", \"korrigiere die Repos\", or asks for a repo grading run over a class folder or a single student repository. Do not use for project grading with issues and PRs (use projectgrade) or for knowledge-check exams (use knowledge-assessment).","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Frepograde\u002FSKILL.md",[],[114,119,120,32,121,30,28,24,122,22,123,124],"with","mode","single","filtering","repo","bulk",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":34},"01M6CVKA8J284DZTBE7QRN45SG","lehrplan","Richtet österreichische HTL-Unterrichts-Repositorien ein und pflegt sie — drei Kernaufgaben: das gesetzliche Lehrplan-Material eines Ausbildungszweigs (z. B. WII, WIT, KIF) aus dem RIS beschaffen inklusive jährlichem Novellen-Check, den Lehrplan eines konkreten Gegenstands aus dem Gesetz extrahieren (mit Erläuterung pro Lernziel: was der Inhalt tatsächlich IST, plus praktische Anwendungen), und Semesterpläne interaktiv entwerfen. Use when der Nutzer 'Lehrplan', 'Unterrichtsvorbereitung prüfen', 'Lehrplan auf Novellen prüfen', 'RIS sync', 'Gesetzesmaterial holen', 'Lehrplan extrahieren', 'Jahrespläne neu ziehen', 'Erläuterungen ergänzen', 'Semesterplan erstellen\u002Füberarbeiten' oder 'Einheiten erstellen' sagt, oder wenn in einem Repo gearbeitet wird, das der lehrplan\u002F-Konvention folgt. Do not use for Prepared Lessons (create-lesson), Aufgaben im Kohortenordner (homework) oder Wissensüberprüfungen (knowledge-exam).","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Flehrplan\u002FSKILL.md",[],[127,132,133,134,135,94,136,28,123,24],"curriculum","drei","material","pro","check",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":148,"publishedAt":34},"01M6CVK6QMR16MSMS2MRG097GV","knowledge-persistence","Persist session context into the structured docs\u002Fai knowledge files (OKF bundle; committed and pushed at the end). Use when the user says \"remember\", \"merk dir das\", \"save context\", \"persist knowledge\" or \"update knowledge file\", at a session checkpoint, or when an observation in this session contradicts docs\u002Fai\u002F or AGENTS.md. Do not use for reading the knowledge files at session start — that is plain bootstrapping.","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Fknowledge-persistence\u002FSKILL.md",[143],{"categoryNo":144,"categoryName":145,"taxonomyType":146,"taxonomyTypeDesc":147},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[149,150,151,152,24,153,154,155,156,157,158,159,160],"knowledge","persistence","knowledge persistence","docs","documentation","workflow","files","session context","session","context","structured","persist",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":168,"publishedAt":34},"01M6CVK3ED9F94R65AD5PG0RRH","knowledge-exam","Generate German knowledge-check exams and solution files from the taught material (class Git history + WebUntis Lehrstoff). Use when the user says \"Wissensüberprüfung erstellen\", \"Knowledge-Check generieren\", \"Prüfung schreiben\", \"create the knowledge check\", \"generate a mini-exam\" or \"make the exam for class X\", or asks for exam questions plus solutions from what was actually taught. Do not use for grading submissions (knowledge-assessment) or for assignments in the class folder (homework).","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Fknowledge-exam\u002FSKILL.md",[167],{"categoryNo":144,"categoryName":145,"taxonomyType":146,"taxonomyTypeDesc":147},[169,170,149,136,134,28,155,26,171,24,172,173],"exam","knowledge exam","generate","history","german"]