announce-article

name	announce-article
description	Generate the release announcement package for a finished blog article — Google-Sheet row fields plus three LinkedIn-post variants — and print everything to the terminal as copy-ready templates. Final, terminal step in the article pipeline.
argument-hint	[path-to-article] [optional: personal-motivation hint]
allowed-tools	Read, Glob, Grep, Bash

Article Announcement Skill

Generate the release-package templates for a published article: $ARGUMENTS

Layout reference: the full pipeline is specified in .claude/article-pipeline.md. This skill runs after enrich-article and after the article is published/merged. It produces no files — its only output is terminal-printed copy-ready templates the user pastes into the tracking Google Sheet and LinkedIn.

You are the announcement formulator at the end of the article chain. The article is already shipped. Your job is to deliver two artifacts to the terminal:

1. The full set of fields for the tracking Google Sheet row corresponding to this article.
2. Three LinkedIn-post variants in German, each with a different rhetorical energy.

You also remind the user of the manual sheet operations the read-only Drive integration cannot perform (row background colour, etc.).

Configuration

• Tracking Google Sheet: https://docs.google.com/spreadsheets/d/1jwMQbM04LHy4VERCqqKU4GZKave65MN0PzjIkGbqezM/edit
  • Columns: Topic | Title | Key Focus | Keywords | Publishing Date | Category | Comments | Post deutsch
  • Released rows get a green background — the user does this manually.
• Published article URL pattern: https://docs.opencqrs.com/blog/{slug}/
• Site base: docs.opencqrs.com

Workflow

Step 1: Locate the Article

1. If $ARGUMENTS contains a path to a markdown file under mkdocs/docs/blog/posts/, use it.
2. Otherwise, list the most recent posts under mkdocs/docs/blog/posts/ (sorted by date desc) and ask which one to announce.
3. Read the article file.

Step 2: Extract Metadata

From the article's frontmatter, extract:

• title
• date
• slug
• categories (often two: a topic category like Event Sourcing and a series category)
• tags

From the article body, also identify:

• The central named concept the article introduces (often appears in section headings and the lede — e.g. Process Version Pinning, Lazy Enrichment, Subject Conditions).
• The core question the article answers (often stated in the opening paragraphs).
• One or two bullet-worthy facts about the solution — usually mirrored in the article's tldr/summary or in the "What You Have Learned" section.

If a session folder .article-work/{date}-{slug}/ exists, scan brief.md and enrichment-notes.md for additional context (especially personal motivation, audience-question anecdotes, or framing hints the article itself does not spell out).

Step 3: Construct the Published URL

https://docs.opencqrs.com/blog/{slug}/

The slug comes from the article frontmatter, not from the file path.

Step 4: Generate the Sheet Row

Produce a copy-ready block with these fields, in this exact order, each in its own fenced code block under a clear label:

• Topic — one or two sentences describing what the article is about, suited for the planning sheet (not the article opener). Strip any padding from the existing topic entry if rewriting.
• Title — verbatim from the frontmatter.
• Key Focus — one tight paragraph (1–2 sentences) summarising the central insight. Avoid duplicate clauses — if the existing sheet cell has been copy-pasted from the brief, produce a clean, dedupe'd version.
• Keywords — verbatim from tags, comma-separated, lower-case as written.
• Publishing Date — frontmatter date, formatted DD.MM.YYYY.
• Category — comma-separated list from frontmatter categories, same order as in the article.
• Comments — leave empty unless there is something genuinely worth noting (open follow-up, special caveat). Default: (leer).

Step 5: Generate Three LinkedIn-Post Variants

Each variant follows the same structural template, but with a different opener energy:

• Variant A — Rhetorical-question hook. Open with a direct question to the reader that names the broader phenomenon the article addresses. Example: "Wie geht eure Software eigentlich damit um, dass Geschäftsprozesse langlaufend und evolutionär sind?"
• Variant B — Declarative observation. Open with a punchy statement of the underlying tension. Example: "In klassischen Systemen ist eine Datenänderung ein Skript. In Event Sourcing ist sie eine Frage der Architektur."
• Variant C — Counter-intuitive claim or surprise. Open with something that mildly contradicts expectation, making the reader want to know why. Example: "Veränderung ist im Event Sourcing kein Bug, sondern Teil des Modells."

All three then share the same downstream structure:

1. Personal/contextual paragraph — why this article matters, broad relevance, ES-elegance note. Roughly 1–2 sentences. If the user supplied a personal-motivation hint in $ARGUMENTS, weave it in. Otherwise, default to: "Auf diesen Artikel habe ich mich besonders gefreut. Das Thema trifft viele, die heute moderne Software bauen — und er zeigt einmal mehr, wie sauber sich komplexe Probleme mit Event Sourcing lösen lassen."
2. Problem-to-solution bridge sentence — names the central concept (Step 2) as the article's proposal. Example: "Wenn sich die Geschäftslogik selbst ändert — nicht nur ihre Datenstruktur —, stellt sich für jede laufende Instanz die Frage: nach welchen Regeln läuft sie weiter? Process Version Pinning gibt eine saubere Antwort:"
3. Three bullet points with semantic emojis (see Style Rules below). Each bullet is one short concrete claim about how the solution works, no jargon-stacking.
4. Wrap-up sentence — one line that summarises what the pattern buys you.
5. Link — 👉 https://docs.opencqrs.com/blog/{slug}/
6. Hashtags — article tags converted to PascalCase hashtags PLUS the stable brand/tech set: #EventSourcing #CQRS #SoftwareArchitecture #OpenSource #OpenCQRS #DigitalFrontiers #Kotlin #SpringBoot. Article tags first, then the stable set. Deduplicate.

Style Rules (apply to ALL variants)

These rules encode lessons learned from prior post iterations — follow them strictly:

• Knackig, präzise, kürzer. A LinkedIn post is not a blog summary. If a sentence does not advance reader understanding or invitation, cut it.
• No 🔹 bullets. Use semantic emojis that match the bullet content. Examples that have worked:
  • 📌 for pinning / anchoring concepts
  • 📘 for a ruleset / strategy / encoded policy
  • 🕰️ for time, durability, "auch Jahre später"
  • 📦 for self-contained units / packages
  • 🧩 for composability / fitting in
  • 🔒 for invariants / immutability
  • ⚙️ for mechanisms / processing
  • ♾️ for indefinite continuation Pick what fits the actual claim. Never pad with generic emojis.
• No Denglish mid-sentence. Established technical terms (Event Sourcing, CQRS, Upcasting, Process Version Pinning, Strategy, Ruleset) stay in English as named noun phrases, embedded in clean German grammar. Do NOT write "Wenn sich Business Logic in Event-Sourced Systems ändert" — that's English vocabulary on German scaffolding. DO write "Wenn sich die Geschäftslogik selbst ändert" and treat Process Version Pinning as a proper noun for the concept.
• No assumed cross-article context. A LinkedIn post must stand on its own. Do not reference "Upcasting from the previous article" unless you also explicitly say "first part of the series". Better: rephrase the problem so the named concept introduces itself.
• Personal voice is welcome, anecdotal scaffolding is not. A line like "Auf diesen Artikel habe ich mich besonders gefreut" works because it is short and declarative. Long talk-Q&A setups feel forced unless the user supplies a real one.
• No mistaken claims. Avoid sweeping statements like "klassische Migration hilft nicht" — they are usually too sharp and easy to disprove. State the shape of the problem (e.g. "jede laufende Instanz braucht eine Antwort darauf, unter welchen Regeln sie weiterläuft") and let the article's solution speak.
• Hashtag hygiene. Article tags first (PascalCase), then the stable set. No more than ~10 total. Keep them informative, not decorative.

Length target

Each variant should fit comfortably above the LinkedIn "see more" fold for a typical reader. As a heuristic: opener ≤ 2 short lines; personal paragraph ≤ 2 lines; bridge ≤ 2 lines; 3 bullets; one wrap-up line; link; hashtags. If a variant exceeds that envelope, tighten.

Step 6: Manual Operations Checklist

After the templates, print a short Manual Operations checklist reminding the user of what cannot be automated through the read-only Drive integration:

• Set the article's row background colour to green (released indicator).
• Paste the Post deutsch cell with the chosen variant.
• Verify Category, Topic, Key Focus, Keywords cells against the templates — overwrite if drifted.
• If the article belongs to a series, double-check the series ordering above the row matches the article positions.

Step 7: Output Format

Print to the terminal in this order, using markdown headings so the user can scan:

# Announcement Package — {Article Title}

## Sheet Row (copy-paste cell by cell)
... seven labelled code blocks, one per field ...

## LinkedIn Post — Variant A (Rhetorical question)

(post body in a fenced block)

## LinkedIn Post — Variant B (Declarative observation)

(post body)

## LinkedIn Post — Variant C (Counter-intuitive)

(post body)

## Manual Operations
- [ ] ...

Each variant goes inside its own fenced code block so the user can copy the whole thing with one click — do not insert the emojis as raw characters that confuse the code block; just include them inline.

End-State

You finish the chain. There is no handoff. The user copies what they need into the sheet and into LinkedIn. If they want a different variant set later, they re-invoke this skill — it is idempotent and reads the published article as ground truth.

If the user asks you to refine a variant (different hook, different bullet wording, different emoji set), do so directly in the conversation — do not rerun the full skill.