Agent-Anweisungen — mseemann.io

Diese Datei wird von AI-Coding-Agents automatisch als Kontext gelesen. Kopiere sie in den Repo-Root. Tool-abhängig ggf. zusätzlich als CLAUDE.md (Claude Code) oder .cursorrules (Cursor) spiegeln — gleicher Inhalt.

Du bearbeitest die persönliche Beratungs-Website von Michael Seemann (mseemann.io), eine Jekyll-/GitHub-Pages-Seite. Es gibt ein verbindliches Design System. Halte dich strikt daran — auch bei kleinen Änderungen.

Vor jeder Aufgabe lesen

1. site-build/HANDOFF-Briefing.md — die abhakbare Definition of Done. Maßgeblich.
2. readme.md (Design System) — die volle Begründung zu Farbe, Type, Motion, Voice.
3. Token-Quelle: Block „TOKENS” oben in css/main.scss.

Harte Regeln (nicht verhandelbar)

• Nur semantische Tokens. Niemals Raw-Hex, rgb(), Pixel-Farben oder Fremd-Fonts im Code. Immer var(--accent), var(--surface-base), var(--text-body), var(--font-sans) … Neue Werte zuerst als Token in main.scss definieren, dann verwenden.
• Beide Themes pflegen. Jedes Token ist doppelt definiert: dunkel in :root, hell in :root[data-theme="light"]. Wer eines anlegt, pflegt beide Werte.
• Kein zweites Framework. Hell/Dunkel läuft über das data-theme-Attribut + den Vanilla- Toggle in assets/js/theme.js. Kein React, kein jQuery, kein neuer Build-Step.
• Kein Google-Fonts-<link>. Inter + JetBrains Mono sind self-hosted (assets/fonts/).
• Front-Matter erhalten. Die --- oben in css/main.scss müssen drinbleiben (Jekyll/Sass).
• Liquid statt Hardcode. Texte/Links als Jekyll::Drops::SiteDrop-Variablen lassen.

Marke in einem Satz

Dunkles Navy, Teal als Akzent (--accent-bright = Highlights, --accent = Aktionen), Inter- Type, 960px-Lesespalte, Cards mit Teal-Accent-Edge + Teal-Glow-Hover, Teal→Violett-Gradient nur als geclippter Text.

Sprache & Tonalität

Deutsch, formelles „Sie”, Ich-Form, pragmatisch-senior. Keine Emojis. Einziges wiederkehrendes Glyph: „→” — jeder Link/CTA endet darauf.

GitHub-Workflow (verbindlich)

Branch-Strategie

• Niemals direkt auf master pushen. master ist geschützt.
• Branch-Name: feature/issue-<nr>-<slug> (z. B. feature/issue-12-contact-form)
• Ein Issue = ein Branch = ein PR.

Ablauf pro Aufgabe

1. Issue-Nummer aus dem GitHub-Ticket lesen.
2. Feature-Branch anlegen: git checkout -b feature/issue-<nr>-<slug>
3. Änderungen umsetzen.
4. Lokal prüfen (siehe „Vor dem Commit”).
5. Commit mit Referenz: git commit -m "fix #<nr>: <beschreibung>"
6. Branch pushen: git push -u origin <branch>
7. PR erstellen: gh pr create --title "…" --body "…" --reviewer mseemann
8. CI abwarten — Stylelint + Jekyll Build müssen grün sein.
9. Nach Review-Approval: Merge über GitHub-UI oder gh pr merge --squash.

Commit-Format

<typ>: <kurzbeschreibung> (fix #<nr>)

[optionaler Body]

Co-Authored-By: Claude Sonnet <noreply@anthropic.com>

Typen: feat, fix, style, refactor, docs, chore

Vor dem Commit

• npm run lint:css läuft ohne Fehler.
• Jekyll-Build lokal geprüft (Docker, siehe readme.md).
• Beide Themes geprüft (hell + dunkel) — kein Aufblitzen, kein gebrochenes Layout.
• Die Definition of Done unten in HANDOFF-Briefing.md durchgegangen.