Shared configuration and protocols for all grading workflows
This skill provides centralized configuration for all grading workflows, ensuring consistent email formatting, address styles, second-person address throughout all grading content, and database access across different assessment types.
All student-facing content (grading reports, feedback, email bodies) MUST be written in natural German with proper UTF-8 umlauts (ä, ö, ü, ß). Never use English for content intended for students.
Import this skill at the beginning of any grading-related skill or command. Reference the sections below for consistent behavior.
Determine formal vs informal address based on class identifier:
| Class | Address Style |
|---|---|
2ahwii | Informal |
3ahwii | Informal |
5ahwii | Informal |
4aaif | Informal |
| All others | Formal |
When processing student data:
UPPER(klasse).Repository directory names follow the convention Lastname Firstname. The last
word is always the first name; everything before it is the last name. This
applies to compound last names as well.
Parsing rule: Split the basename on spaces → parts[0:-1] = last name,
parts[-1] = first name.
| Repository Basename | Last Name | First Name |
|---|---|---|
Umlauf Ellen | Umlauf | Ellen |
Quintero Castañeda Nicolas | Quintero Castañeda | Nicolas |
Prodanovic Jovana | Prodanovic | Jovana |
Wahringer Tobias | Wahringer | Tobias |
Leeb Samuel | Leeb | Samuel |
Zore Elsner Marija | Zore Elsner | Marija |
Wrong vs Correct — Formal salutation:
❌ Sehr geehrte Frau Ellen, ← used first name as last name
✅ Sehr geehrte Frau Umlauf, ← correct last name
❌ Sehr geehrter Herr Nicolas, ← used first name as last name
✅ Sehr geehrter Herr Quintero Castañeda, ← correct compound last name
❌ Sehr geehrter Herr Tobias, ← used first name as last name
✅ Sehr geehrter Herr Wahringer, ← correct last name
Wrong vs Correct — Informal salutation:
❌ Liebe Umlauf, ← used last name as first name
✅ Liebe Ellen, ← correct first name
❌ Lieber Quintero Castañeda, ← used last name as first name
✅ Lieber Nicolas, ← correct first name
Formal Address (uses last name — see Name Parsing section above):
Sehr geehrte Frau [Last Name],Sehr geehrter Herr [Last Name],Guten Tag [First Name] [Last Name],Informal Address (uses first name — the last word in the basename):
Liebe [First Name], or Lieber [First Name],Liebe [First Name],Lieber [First Name],Guten Tag [First Name] [Last Name],Concrete examples:
| Basename | Gender | Formal Greeting | Informal Greeting |
|---|---|---|---|
Umlauf Ellen | F | Sehr geehrte Frau Umlauf, | Liebe Ellen, |
Quintero Castañeda Nicolas | M | Sehr geehrter Herr Quintero Castañeda, | Lieber Nicolas, |
Wahringer Tobias | M | Sehr geehrter Herr Wahringer, | Lieber Tobias, |
Formal Address:
Mit freundlichen Grüßen,
Georg Graf
Informal Address:
Lieben Gruß,
Georg Graf
Gender is determined from the first name (the last word in the repository basename). Do NOT use the full basename string for gender lookup.
When gender is not clear from the first name:
Guten Tag [First Name] [Last Name],ALL grading content must address the student directly in the second person, matching the email salutation style. This applies to:
*_grading.md files (repograde, knowledge-assessment, projectgrade)EMAIL.json| Style | Pronoun | Verb Conjugation | Example |
|---|---|---|---|
| Formal (Sie) | Sie | 3rd person plural formal | "Sie haben die Aufgabe gut gelöst" |
| Informal (Du) | Du | 2nd person informal | "Du hast die Aufgabe gut gelöst" |
Formal Address (Sie) - Wrong ❌:
Der Student hat die Aufgabe gut gelöst. Er hat sich bemüht.
Formal Address (Sie) - Correct ✅:
Sie haben die Aufgabe gut gelöst. Sie haben sich bemüht.
Informal Address (Du) - Wrong ❌:
Der Schüler hat die Aufgabe gut gelöst. Er hat sich bemüht.
Informal Address (Du) - Correct ✅:
Du hast die Aufgabe gut gelöst. Du hast dich bemüht.
When student gender cannot be determined:
Guten Tag [First Name] [Last Name],Before finalizing any grading output, verify:
| Database | Path | Purpose |
|---|---|---|
| UploadThing | /home/georg/OneDrive/uploadthing.db | Repository grading |
| Vacuum | vacuum.db (current directory) | Knowledge-check grading (must exist at start; error if missing) |
Table: users
| Column | Description |
|---|---|
email | Student email address |
name | Full student name |
klasse | Class identifier |
WHERE UPPER(klasse) = UPPER(?).email and klasse columns.klasse to determine address style.vacuum.db is missing at start, stop immediately with error.When generating EMAIL.json, if any student's email address cannot be found in
the database, the workflow MUST stop before generating the file.
EMAIL.json.Die folgenden Schüler/innen konnten nicht in der Datenbank gefunden werden:
- [Name 1]
- [Name 2]
- ...
Bitte aktualisieren Sie die Datenbank und starten Sie den Vorgang erneut.
EMAIL.json when ALL students have valid email
addresses.[
{
"mailto": "[email protected]",
"subject": "[Subject based on context]",
"body": "[Full personalized assessment in German]"
}
]
The body field often contains multi-paragraph German text with newlines, quotes,
and special characters. Improper escaping is the most common cause of broken
email JSON files. The following rules MUST be followed:
All JSON string values must be valid JSON. Newlines inside the body
field must use the escaped sequence \n (two characters: backslash, n), NOT
literal line breaks. Double quotes must be escaped as \", backslashes as \\,
and tabs as \t.
No literal newlines inside JSON string values. A file like this is INVALID:
"body": "Sehr geehrte Frau Huber,
Sie haben die Aufgabe gut gelöst."
The correct form is:
"body": "Sehr geehrte Frau Huber,\n\nSie haben die Aufgabe gut gelöst."
Validate before writing. Every *_email.json file must parse successfully
with a standard JSON parser. After writing, verify with:
python3 -c "import json; json.load(open('FILE_email.json'))"
Use programmatic JSON writing. When writing *_email.json or EMAIL.json,
prefer using a proper JSON serializer (e.g., json.dump() in Python) over
string interpolation or template construction. This guarantees correct escaping
of all special characters automatically.
Georg Graf.Shared pre-grading verification and analysis steps for all repository-based
grading skills (repograde, projectgrade).
Before inspecting repository content, verify repository state:
git pull to ensure latest version is checked out.git status to check for uncommitted changes.For every relevant commit, inspect actual changes with commands equivalent to:
git show --stat --summary <sha>git show --format=fuller --unified=3 <sha>Use diff content, not filenames alone, to identify what the student worked on.
Detect technical topics from the diffs and distinguish substantive work from superficial edits.
Consider common patterns across JavaScript, Java, C#, SQL, CSS, HTML, and general programming constructs.
main, but highlight significant non-main branch work.high, medium, or low.Shared homework source discovery for repograde and projectgrade.
Homework assignments may exist in multiple locations. The grading skill MUST
discover and merge all sources into a unified homework list before matching
against student commits.
_class Symlink (Preferred)Check for a _class symlink in the CWD. If it exists, follow it and look for
homework inside the linked class folder.
Check for Hausübungen.md inside _class/ (may also be a symbolic link;
follow symlinks when reading).
If found, parse it using the Semantic Date Extraction rules below.
_classScan _class/ for subdirectories matching the pattern <YYYY-MM-DD>_<topic>.
For each matching directory, check if Hausübung.md exists inside it.
If found:
2026-03-21_promises
→ date 2026-03-21). No German date parsing needed.(iso_date, topic, content).Check for a Hausübungen.md file directly in the CWD (may be a symbolic link;
follow symlinks when reading). This is the old symlink-to-single-file approach.
If found, parse it using the Semantic Date Extraction rules below.
You MUST perform a thorough semantic analysis of the entire file.
Many agents fail at this step because they:
Required steps:
## Hausübung vom 18. FebruarAbgabe bis 25. FebruarZeitraum: 10.-18. Märznächste Woche, in 2 Wochen (convert to absolute)[(iso_date, topic, content), ...].Date patterns to recognize:
| Pattern | Example | Extraction |
|---|---|---|
vom DD. Monat | vom 18. Februar | 2026-02-18 (infer year) |
vom DD. Monat YYYY | vom 18. Februar 2026 | 2026-02-18 |
DD.MM.YYYY | 18.02.2026 | 2026-02-18 |
bis DD. Monat | Abgabe bis 25. Februar | 2026-02-25 (deadline) |
Zeitraum: DD.-DD. Monat | Zeitraum: 10.-18. März | 2026-03-10 to 2026-03-18 |
Month name mapping:
Januar = 01 Juli = 07
Februar = 02 August = 08
März = 03 September = 09
April = 04 Oktober = 10
Mai = 05 November = 11
Juni = 06 Dezember = 12
When year is not explicit, infer from the grading context or cross-reference with commit dates.
Common Failure Pattern (AVOID THIS):
❌ WRONG: Read Hausübungen.md, see first entry is "vom 18. Februar",
requested date is 2026-02-10, conclude "no matching homework"
✅ CORRECT: Parse ALL entries, find "vom 10. Februar" (matches),
"vom 18. Februar" (after cutoff), "vom 25. Februar" (after cutoff)
Scan the CWD itself for subdirectories matching <YYYY-MM-DD>_<topic> that
contain Hausübung.md. This covers per-lesson homework without a _class
symlink.
Shared concurrency and directory handling for repograde bulk mode.
When enumerating student repositories, exclude:
_class (homework symlink)_ (underscore prefix). (dot prefix)These excluded directories are NOT student repositories and must never be graded.
<basename>_grading.md plus <basename>_email.json.EMAIL.json.After all subagents finish, the master workflow must:
*_email.json files.EMAIL.json following the Email JSON Structure rules above.All grading email bodies MUST be clear ASCII text. This section defines the exact structure and formatting rules for every email body generated by any grading skill.
Email bodies are plain ASCII text with one exception: code blocks with
backtick fences (e.g., sql ... ) for short source-code snippets that
help illustrate a grading point.
Forbidden in email bodies:
##, ###, etc.)**...**)*...*)- item or * item)---)Allowed in email bodies:
Used by repograde skill (single-repo and bulk mode). The email body follows
this exact paragraph order:
Greeting — per Greeting Formulas section above.
Opening sentence (address style dependent):
Ich habe Ihre Hausübungen, welche im Zeitraum vom [Start-Datum] bis zum [End-Datum] aufgegeben waren, durchgesehen.Ich habe deine Hausübungen, welche im Zeitraum vom [Start-Datum] bis zum [End-Datum] aufgegeben waren, durchgesehen.Commit summary — Two to three sentences summarizing the commits discovered in the student's repository during the grading period. Mention overall activity, approximate number of substantive commits, and any notable patterns (gaps, bursts, consistent work).
Homework overview — A concise list of all homework assignments, each in one to two sentences. Format:
HÜ1: [Topic/content summary in 1-2 sentences]
HÜ2: [Topic/content summary in 1-2 sentences]
Use "HÜ" as abbreviation for "Hausübung". Number sequentially.
Per-homework evaluation — For each homework assignment, provide a detailed discussion and evaluation on a 0–100% scale. Each evaluation is a separate paragraph covering:
Coverage / timeliness summary — One short paragraph summarizing overall homework coverage and whether submissions were on time, late, partial, or missing where relevant.
Recommendations and praise — A warm, genuine paragraph with improvement suggestions and subtle praise. See Praise Guidelines below.
Final score summary — One short paragraph containing the final weighted
result in the form Endbewertung: XX/100 (XX%).
Closing — per Closing Formulas section above.
Keep email length reasonably consistent across students. Do not omit one of the paragraph groups above simply because a repository is weaker or stronger; if evidence is limited, say so briefly and continue with the same structure.
Used by knowledge-assessment skill. Same plain-text rule applies.
Greeting — per Greeting Formulas section above.
Opening sentence (address style dependent):
Ich habe Ihre Wissensüberprüfung vom [Datum] durchgesehen.Ich habe deine Wissensüberprüfung vom [Datum] durchgesehen.Score summary — Total points achieved out of total possible points.
Question-by-question analysis — Plain text paragraphs discussing strengths and weaknesses in specific questions.
Recommendations and praise — Same guidelines as homework emails.
Solutions note — Ich habe die Datei mit den korrekten Lösungen in das Git-Repository hochgeladen.
Closing — per Closing Formulas section above.
Praise must be subtle and understated. Never effusive, never over the top.
Good praise examples:
Bad praise examples (DO NOT USE):
The tone should feel like a calm, observant teacher noting genuine strengths without exaggeration. Let the facts speak for themselves. When a student did something well, state it matter-of-factly.
Sehr geehrte Frau Huber,
Ich habe Ihre Hausübungen, welche im Zeitraum vom 4. März bis zum
18. März aufgegeben waren, durchgesehen.
In Ihrem Repository habe ich insgesamt 12 Commits in diesem Zeitraum
gefunden. Die Arbeit war regelmäßig verteilt, mit einem deutlichen
Schwerpunkt in der ersten Woche. Die meisten Änderungen betrafen
SQL-Skripte und Datenbank-Schema-Dateien.
HÜ1: Erstellung einer SQL-Datenbank mit CREATE TABLE und INSERT
statements für ein Bibliotheksverwaltungssystem.
HÜ2: Implementierung von JOIN-Operationen zwischen den Tabellen
der Bibliotheksdatenbank.
HÜ1 – Bibliotheksdatenbank:
Sie haben die Tabellenstruktur sauber entworfen und die
Fremdschlüsselbeziehungen korrekt definiert. Die INSERT-Statements
decken die wesentlichen Daten ab. Bei der Tabelle "Ausleihe" hätte
das Rückgabedatum als nullable Spalte definiert werden sollen, da
ein Buch zum Zeitpunkt der Ausleihe noch nicht zurückgegeben sein
muss. Bewertung: 80%.
HÜ2 – JOIN-Operationen:
```sql
SELECT b.Titel, a.Name
FROM Buecher b
JOIN BuchAutor ba ON b.BuchID = ba.BuchID
JOIN Autoren a ON ba.AutorID = a.AutorID;
Dieser Dreifach-Join ist korrekt umgesetzt. Die Alias-Namen sind sinnvoll gewählt. Bei der LEFT JOIN-Aufgabe fehlt jedoch die Berücksichtigung von Büchern ohne Ausleihe – hier wäre ein LEFT JOIN statt des INNER JOIN nötig gewesen. Bewertung: 65%.
Insgesamt zeigen Ihre Abgaben ein solides Grundverständnis der relationalen Datenbankkonzepte. Es empfiehlt sich, die Unterschiede zwischen den JOIN-Typen (INNER, LEFT, RIGHT) noch einmal anhand praktischer Beispiele nachzuvollziehen. Die Tabellenstruktur der Bibliotheksdatenbank ist Ihnen gut gelungen.
Beide Hausübungen waren erkennbar abgegeben. Die erste Aufgabe war weitgehend vollständig, bei der zweiten Aufgabe gab es inhaltliche Lücken bei einzelnen JOIN-Varianten.
Insgesamt ist eine solide Grundlage erkennbar. Es lohnt sich, die Behandlung unvollständiger Ergebniszeilen bei LEFT JOINs noch gezielt zu üben.
Endbewertung: 73/100 (73%)
Mit freundlichen Grüßen,
Georg Graf
### Example: Informal Homework Email Body
Lieber Thomas,
Ich habe deine Hausübungen, welche im Zeitraum vom 4. März bis zum 18. März aufgegeben waren, durchgesehen.
In deinem Repository habe ich 8 Commits gefunden, die meisten davon in der zweiten Woche. Du hast dich intensiv mit den SQL-Themen auseinandergesetzt.
HÜ1: Erstellung einer SQL-Datenbank mit CREATE TABLE und INSERT statements für ein Bibliotheksverwaltungssystem. HÜ2: Implementierung von JOIN-Operationen zwischen den Tabellen der Bibliotheksdatenbank.
HÜ1 – Bibliotheksdatenbank:
Du hast die Tabellen korrekt erstellt und die Beziehungen sauber modelliert. Die Datentypen sind durchgehend passend gewählt. Die Index-Definitionen fehlen allerdings vollständig – bei einer Bibliotheksdatenbank mit Suchanfragen auf Titel und Autor wären Indizes sinnvoll. Bewertung: 75%.
HÜ2 – JOIN-Operationen:
Die einfachen JOINs hast du zuverlässig implementiert. Bei den komplexeren Abfragen mit Unterabfragen gibt es noch Unsicherheiten. Die Lösung für "Alle Autoren mit mehr als 3 Büchern" verwendet einen korrekten Ansatz, die Gruppierung ist aber nicht ganz vollständig. Bewertung: 60%.
Insgesamt eine ordentliche Leistung. Es wäre hilfreich, wenn du die JOIN-Typen noch einmal wiederholst – besonders die Fälle, in denen ein LEFT JOIN nötig ist. Die Grundlagen sitzen, und mit etwas mehr Übung bei den komplexeren Abfragen wirst du noch sicherer.
Beide Hausübungen sind erkennbar bearbeitet. Bei der zweiten Aufgabe zeigen sich aber noch Lücken bei den komplexeren Abfragen.
Insgesamt ist das eine brauchbare Arbeitsgrundlage. Wenn du die Unterschiede der JOIN-Typen noch sicherer anwenden kannst, wird die Qualität der Lösungen deutlich steigen.
Endbewertung: 68/100 (68%)
Lieben Gruß,
Georg Graf
## Reporting Protocol
All grading content must be written in German and address the student directly
in the second person (Sie or Du based on class). See the Second-Person Address
section above for pronoun usage and examples.
The `*_grading.md` files may use full Markdown formatting (headers, bold,
tables, lists). Only the email body in `*_email.json` is restricted to plain
text per the Email Body Format section above.
Reports should include, where applicable:
- repository overview
- homework-by-homework summary
- topic coverage
- per-commit technical analysis
- non-main branch activity
- activity over time
- inactive gaps
- diligence assessment
- final evaluation with `Endbewertung: XX/100`
When a consuming skill defines an exact mandatory report template, that template
overrides any looser interpretation of this Reporting Protocol. In such cases,
agents and subagents MUST follow the exact heading names, order, and section
scope defined by the consuming skill and MUST NOT improvise alternative report
structures.
## Output Expectations
This skill provides configuration and shared protocols. Consuming skills