| name | wiki-draft |
| description | Erstelle einen Content-Entwurf (Blog, Newsletter, Briefing) auf Basis des Wiki-Wissens. |
| version | 1.0.0 |
| metadata | {"hermes":{"tags":["wiki","content","writing"],"category":"wiki","requires_toolsets":["terminal"]}} |
wiki-draft
Erstelle einen Content-Entwurf auf Basis des Wiki-Wissens.
When to Use
- User will einen Blogartikel, ein Briefing oder LinkedIn-Post schreiben
- User sagt "schreib mir einen Artikel über...", "erstelle ein Briefing zu..." o.ä.
Procedure
-
Thema und Format klären — Falls nicht eindeutig, kurz nachfragen. Mögliche Formate: blog, newsletter, briefing, linkedin, slides.
-
Wiki durchsuchen — wiki/index.md lesen, relevante Seiten identifizieren und lesen. Besonders wiki/synthesis/ und wiki/trends/ prüfen.
-
Template laden — Passendes Template aus content/templates/ laden:
content/templates/blog.md für Blogartikel
content/templates/newsletter.md für Newsletter
content/templates/briefing.md für Briefings
- Für LinkedIn/Slides: freie Form
-
Entwurf schreiben — In content/drafts/ mit Frontmatter:
---
title: "Titel des Contents"
format: blog
based_on: [wiki/trends/thema.md, wiki/topics/thema.md]
created: YYYY-MM-DD
status: draft
---
Dateiname: YYYY-MM-DD-kurztitel.md
-
User informieren — Entwurf dem User zeigen, auf Stellen hinweisen die Review brauchen.
-
⛔ Log schreiben — Eintrag in wiki/log.md:
## [YYYY-MM-DD] draft | Titel des Contents
- Format: blog
- Basiert auf: wiki/trends/..., wiki/topics/...
- Gespeichert: content/drafts/YYYY-MM-DD-kurztitel.md
Pitfalls
- Entwürfe immer in
content/drafts/, nie direkt in content/published/
- Immer das Wiki als Basis nutzen, nicht frei erfinden
- Quellenverweise einbauen wo möglich
- Tonalität an die Zielgruppe anpassen
- Log-Eintrag NIEMALS vergessen
Verification
⛔ BEVOR du den Workflow als abgeschlossen meldest:
- Entwurf existiert in
content/drafts/
- Entwurf hat korrektes Frontmatter mit
based_on-Verweisen
wiki/log.md hat einen Draft-Eintrag
- Erst dann dem User Abschluss melden.