projectgrade

Files (2)

• REPORT-FORMAT.md
• SKILL.md

SKILL.md (first lines)

# Projectgrade Skill

## Purpose

This skill grades student Git repositories for collaborative project work where
students contribute via branches, Pull Requests, and GitHub Issues. It evaluates
code contributions (via Git commits), issue management (creation, editing,
commenting, quality), pull request activity (creation, reviews, merging), and
further measurable contributions (wiki, CI/CD, testing, documentation, project
management).

Unlike `repograde`, this skill does NOT use assignments (Aufgaben) or the
assignment discovery sources.
Student identification is derived exclusively from Git commit email addresses,
then mapped to student names via the uploadthing database.

## Output Language: MANDATORY GERMAN

Follow the `grading-shared` **Output Language** rule: natural German with proper
UTF-8 umlauts (ä, ö, ü, ß), never English.

## Dependencies

This skill relies on `grading-shared` for: address style, email formulas,
second-person address rules, database lookup, email JSON structure,
repository analysis protocol, and reporting protocol.

## Differences from repograde

- Invoked from INSIDE the project Git repository (not from a local folder).
- No assignment discovery required (project grading, not per-lesson assignments).
- Evaluates GitHub Issues participation and Pull Request activity.
- Student identification from Git commit emails only.
- Issue quality, PR reviews, and collaboration factor into grading.
- Single project mode (no bulk grading).
- Holistic assessment approach (no rigid numeric weights).

## Execution Context

This skill is invoked directly as a skill (no standalone command). It MUST be
invoked from within the Git repository being evaluated. Calling this skill from
outside a Git repository is an error.

The skill grades a single collaborative project repository where multiple
students contribute via branches, Pull Requests, and GitHub Issues by:
1. Verifying we are inside a Git repository (error if not).
2. Using `git pull` to ensure the latest version is checked out.
3. Inspecting the repository content and Git history for grading.
4. Querying GitHub API for issue and PR metadata (creation, edits, comments, reviews, merges).
5. Detecting further measurable contributions (wiki, CI/CD, tests, docs, project management).
6. Mapping contributor email addresses to student names via uploadthing.db.

## Input

- `--gh-token`: GitHub token for API access (optional, defaults to environment).

Behavior:

- This skill operates on the current Git repository (CWD must be a Git repo).
- No repository path argument is needed; we are already inside the project.

## Protocol

1. Verify we are in a Git repository. If not, STOP IMMEDIATELY with error.
2. Run `git pull` to verify latest version is checked out.
3. Run `git status` to check for uncommitted changes. If found, stop immediately.
4. Derive the output stem from `basename "$(git rev-parse --show-toplevel)"` or
   the current directory name.
5. Extract all unique contributor email addresses from git commits.
6. Query the uploadthing database to map emails to student names.
7. Analyze repository contributions (see Repository Analysis section).
8. Analyze GitHub Issues participation (see Issue Analysis section).
9. Analyze Pull Request activity (see Pull Request Analysis section).
10. Detect further measurable contributions (see Further Contributions section).
11. Apply holistic grading philosophy (see Holistic Grading Philosophy section).
12. Generate `<basename>_grading.md` as the repository grading report in German.
13. Generate `<basename>_email.json` as a JSON array with student entries,
    following `grading-shared` structure and using German body text.

## Repository Analysis

Inspect repository content directly from within the current Git repository.

### Pre-Grading Verification

Before inspecting repository content, verify repository state:

1. Verify we are inside a Git repository:
   ```bash
   git rev-parse --is-inside-work-tree
   ```
   If this returns `false` or errors, STOP IMMEDIATELY and report to user.
2. Run `git pull` to ensure latest version is checked out.
3. Run `git status` to check for uncommitted changes.
4. If uncommitted changes exist, STOP IMMEDIATELY and report to user.
5. If pull fails or reports errors, STOP IMMEDIATELY and report to user.

### Git Commit Analysis

Extract all unique contributor email addresses:

```bash
git log --all --format='%ae' | sort -u
```

For each contributor, collect commit statistics:

```bash
git log --all --author='<email>' --format='%H' | wc -l  # commit count
git log --all --author='<email>' --format='' --numstat | awk '{added+=$1; deleted+=$2} END {print added, deleted}'
```

### Branch Analysis

- Enumerate all branches: `git branch -a`
- Count commits per branch per author.
- Identify significant non-main branch contributions.
- Note branch naming patterns and merge activity.

From georgernstgraf/opencode-helpers, MIT.

More from georgernstgraf/opencode-helpers