ankitg12/agent-skills

Blog — Jekyll + GitHub Pages

Repository: ~/repos/github.com/<du>/<du>.github.io Engine: Jekyll + GitHub Pages, Theme: minima Branch: master → wird bei Push automatisch deployed Index: Blog-Index-Notizdatei führen (z. B. ~/notes/blog.md) — nach jedem Beitrag aktualisieren

Hinweis — Kein lokaler Jekyll-Build nötig. GitHub baut serverseitig.

---

⚠️ Harte Regel: Keine Arbeitgeberinformationen

Fügen Sie NIEMALS in einen Beitrag ein:

• Interne Tools, Systeme, Codenamen oder Infrastruktur Ihres Arbeitgebers
• Interne Projektnamen, Teamnamen, Organisationsstruktur oder Roadmapdetails
• Kundennamen, Partnernamen oder Vertragsdetails
• Interne Tickets, Wikiseiten oder Meetinginhalte
• Gehalt, Personalplanung, Budget oder Geschäftskennzahlen

Schreiben Sie über Techniken, Tools und Muster — nicht darüber, wo Sie arbeiten oder was Ihr Arbeitgeber ausliefert. Fragen Sie im Zweifel den Benutzer vor der Veröffentlichung.

---

Arbeitsablauf

1. Beitrag schreiben

_posts/YYYY-MM-DD-slug-hier.md

Frontmatter:

---
layout: post
title: "Ihr Titel hier"
date: YYYY-MM-DD
categories: ai agents produktivität   # Leerzeichen-getrennt
series: "AI coding agent productivity"   # weglassen, wenn nicht Teil einer Serie
---

2. Stil

• Mit dem Problem beginnen, nicht mit der Lösung
• Ein konkreter Einleitungssatz — kein „In diesem Beitrag werde ich …"
• Codeblöcke für alles Ausführbare
• Tabellen für Vergleiche
• Enden mit einem ## Quellen-Abschnitt, der auf Repos/Referenzen verlinkt
• Keine LLM-Füllwörter — schreiben wie eine README
• @wort als \@wort escapen, um Typst-Zitierfehler zu vermeiden, falls jemals ein PDF benötigt wird

Wählen Sie einen gut bewerteten veröffentlichten Beitrag im Blog aus und verwenden Sie ihn als Referenz für Ton und Dichte.

3. JEDEN Link vor dem Veröffentlichen überprüfen (nicht überspringen)

Das Zitieren von URLs aus dem Gedächtnis führt zu 404-Fehlern. Überprüfen Sie zuerst den HTTP-Status jedes Links:

for u in "https://example.com/a" "https://example.com/b"; do
  echo "$(curl -sS -L -o /dev/null -w '%{http_code}' "$u")  $u"
done

Jeder Link MUSS vor dem Commit 200 (oder 301/302 zu einem gültigen Ziel) zurückgeben. Das ist günstiger, als einen toten Link auszuliefern und ihn zu reparieren, nachdem der Benutzer ihn bemerkt.

4. Committen und pushen

cd ~/repos/github.com/<du>/<du>.github.io
git add _posts/YYYY-MM-DD-slug.md
git commit -m "post: <titel>"
git push   # GitHub Pages deployed automatisch in ~60s

5. Index aktualisieren

Fügen Sie eine Zeile zur ## Beiträge-Tabelle in der Blog-Index-Notizdatei hinzu (neueste zuerst) und hängen Sie den Beitrag an die Zeile ## Aktive Serie an, falls er zu einer Serie gehört:

| YYYY-MM-DD | Titel | `category/pfad/YYYY/MM/DD/slug.html` |

Die URL folgt Jekylls permalink-Muster, abgeleitet aus categories + date + slug.

6. Überprüfen, ob der Beitrag wirklich live ist (nicht überspringen)

Ein erfolgreicher Pages-Build bedeutet NICHT, dass der Beitrag live ist — Jekyll verwirft zukünftige Beiträge stillschweigend. Curlen Sie die echte URL, nachdem der Build abgeschlossen ist:

base="https://<du>.github.io"; slug="/CATEGORY/PFAD/YYYY/MM/DD/slug.html"
curl -sS -L -o /dev/null -w "%{http_code}\n" "$base$slug"   # muss 200 sein
curl -sS -L "$base/" | grep -o 'slug[^"]*html' | head -1     # muss auf der Startseite erscheinen

Wenn es 404 zurückgibt, der Build aber erfolgreich war, liegt es fast sicher an der Future-Date-Falle unten.

---

Schutzmaßnahmen für veröffentlichte Beiträge

• Bewahren Sie die ursprüngliche Erzählung und hängen Sie ein klar gekennzeichnetes Update an, es sei denn, der Benutzer fordert explizit eine Neufassung an.
• HTTP-Checks nur für neu hinzugefügte oder geänderte URLs durchführen; veröffentlichte, unveränderte Links nicht wiederholt prüfen, es sei denn, eine Linküberprüfung wird angefordert.
• Nach dem Push überprüfen, ob die veröffentlichte echte URL HTTP 200 zurückgibt.

---

Tipps

• Führen Sie einen ## TODO-Abschnitt in der Blog-Index-Notizdatei für Entwurfsideen; überprüfen Sie ihn, bevor Sie von Grund auf neu beginnen
• Wenn der Beitrag einen vorherigen Beitrag fortsetzt oder widerspricht, verlinken Sie ihn mit {% post_url YYYY-MM-DD-slug %}
• Frühmorgendliches Veröffentlichen + Future-Date-Falle: Jekyll interpretiert ein datumsloses date: YYYY-MM-DD als Mitternacht in der Site-Zeitzone und verwirft Beiträge stillschweigend, die in der Zukunft datiert sind. Bevor _config.yml eine explizite timezone:-Zeile hatte, wurde ein um 04:00 Uhr Ortszeit geschriebener Beitrag als Mitternacht UTC gelesen = ~1h in der Zukunft → verworfen, bis UTC aufgeholt hatte. Setzen Sie timezone: in _config.yml und ENTFERNEN Sie es NICHT. Wenn ein frühmorgendlicher Beitrag nach einem erfolgreichen Build immer noch 404 zurückgibt, fügen Sie eine explizite Zeit im Frontmatter hinzu (date: YYYY-MM-DD 04:00:00 +0530).