@damiangilgonzalez/harness 1.3.7

package/skills/compose-multiplatform/references/ios-interop.md

@@ -0,0 +1,91 @@
+# iOS interop — bridge patterns
+
+Read this before writing any iOS-specific Compose interop. iOS is **Stable** in Compose Multiplatform since 1.8.0 (May 2025). Two directions: native views inside shared Compose, and shared Compose inside SwiftUI.
+
+## 1. Native UIKit view inside shared Compose — `UIKitView`
+
+`UIKitView` (and `UIKitViewController` for a whole controller) takes a `factory` lambda that builds the native object. Run on the main thread; size it with the Compose `modifier`.
+
+```kotlin
+// iosMain
+import androidx.compose.ui.viewinterop.UIKitView
+import platform.MapKit.MKMapView
+
+@Composable
+fun NativeMap(modifier: Modifier = Modifier) {
+    UIKitView(
+        factory = { MKMapView() },
+        modifier = modifier.fillMaxSize(),
+        update = { mapView -> /* mutate mapView on state change */ },
+    )
+}
+```
+
+## 2. Native view factory via a common interface + Koin (preferred)
+
+Keep the shared screen platform-agnostic. Define the contract in `commonMain`, implement it in `iosMain`, inject with Koin. The common `@Composable` never imports `platform.*`.
+
+```kotlin
+// commonMain
+interface NativeViewFactory {
+    @Composable
+    fun MapView(modifier: Modifier)
+}
+
+@Composable
+fun MapScreen(factory: NativeViewFactory = koinInject()) {
+    factory.MapView(Modifier.fillMaxSize())
+}
+```
+
+```kotlin
+// iosMain
+class IosNativeViewFactory : NativeViewFactory {
+    @Composable
+    override fun MapView(modifier: Modifier) {
+        UIKitView(factory = { MKMapView() }, modifier = modifier)
+    }
+}
+// bind in a platformModule: single<NativeViewFactory> { IosNativeViewFactory() }
+```
+
+Why an interface over a raw `expect @Composable`: the Android/desktop targets get their own implementation (or a no-op), and you can fake it in `commonTest`.
+
+## 3. Shared Compose inside a SwiftUI app — `ComposeUIViewController`
+
+Expose a factory from `iosMain`, then wrap it in a SwiftUI `UIViewControllerRepresentable`.
+
+```kotlin
+// iosMain
+import androidx.compose.ui.window.ComposeUIViewController
+
+fun MainViewController() = ComposeUIViewController { App() }
+```
+
+```swift
+// iosApp (SwiftUI)
+import SwiftUI
+import shared
+
+struct ComposeView: UIViewControllerRepresentable {
+    func makeUIViewController(context: Context) -> UIViewController {
+        MainViewControllerKt.MainViewController()
+    }
+    func updateUIViewController(_ vc: UIViewController, context: Context) {}
+}
+
+struct ContentView: View {
+    var body: some View { ComposeView().ignoresSafeArea(.all) }
+}
+```
+
+## 4. ViewModel lifecycle on iOS
+
+`androidx.lifecycle.ViewModel` runs in `commonMain`, but iOS has **no built-in `ViewModelStoreOwner`**, so nothing clears the VM for you.
+
+- Inside a Compose-hosted screen, obtain VMs with `koinViewModel { }` (from `koin-compose-viewmodel`) — they are scoped to the Compose nav entry and cleared correctly.
+- When a Kotlin VM must be observed from *SwiftUI* (not a Compose host), use **KMP-ObservableViewModel** so SwiftUI sees `@Published`-style updates, and clear it from the SwiftUI view's lifecycle.
+
+## 5. Camera / system APIs
+
+Same pattern: a common `interface` (`CameraController`, `SecureStorage`) with an `iosMain` impl using `platform.AVFoundation` / Keychain, injected via Koin. Reserve raw `expect`/`actual` for tiny, untestable leaves (device name, locale).

package/skills/compose-multiplatform/references/project-setup.md

@@ -0,0 +1,96 @@
+# Project setup — Gradle, source sets, module layouts
+
+Full setup for the 2026 default KMP structure. Floors: CMP 1.11.0 (Jetpack Compose 1.11.1), Kotlin 2.1.0+ (2.2.20 recommended), K2 mandatory since CMP 1.8.0, AGP 9.0.
+
+## Version catalog (`gradle/libs.versions.toml`)
+
+```toml
+[versions]
+kotlin = "2.2.20"
+compose = "1.11.0"
+agp = "9.0.0"
+androidx-lifecycle = "2.9.0"
+koin = "4.0.0"
+navigation = "2.9.0"
+
+[plugins]
+kotlinMultiplatform = { id = "org.jetbrains.kotlin.multiplatform", version.ref = "kotlin" }
+composeMultiplatform = { id = "org.jetbrains.compose", version.ref = "compose" }
+composeCompiler = { id = "org.jetbrains.kotlin.plugin.compose", version.ref = "kotlin" }
+androidLibrary = { id = "com.android.library", version.ref = "agp" }
+
+[libraries]
+lifecycle-viewmodel = { module = "org.jetbrains.androidx.lifecycle:lifecycle-viewmodel", version.ref = "androidx-lifecycle" }
+navigation-compose = { module = "org.jetbrains.androidx.navigation:navigation-compose", version.ref = "navigation" }
+koin-core = { module = "io.insert-koin:koin-core", version.ref = "koin" }
+koin-compose-viewmodel = { module = "io.insert-koin:koin-compose-viewmodel", version.ref = "koin" }
+```
+
+## `shared/build.gradle.kts`
+
+```kotlin
+plugins {
+    alias(libs.plugins.kotlinMultiplatform)
+    alias(libs.plugins.composeMultiplatform)
+    alias(libs.plugins.composeCompiler)
+    alias(libs.plugins.androidLibrary)
+}
+
+kotlin {
+    androidTarget()
+    jvm("desktop")
+    listOf(iosArm64(), iosSimulatorArm64()).forEach { it.binaries.framework { baseName = "shared" } }
+    // wasmJs { browser() }  // Beta — enable to pilot Web only
+
+    sourceSets {
+        commonMain.dependencies {
+            implementation(compose.runtime)
+            implementation(compose.foundation)
+            implementation(compose.material3)
+            implementation(compose.components.resources)   // generated Res accessors
+            implementation(libs.lifecycle.viewmodel)
+            implementation(libs.navigation.compose)
+            implementation(libs.koin.core)
+            implementation(libs.koin.compose.viewmodel)
+        }
+        androidMain.dependencies { implementation(compose.preview) }
+    }
+}
+```
+
+## Source-set hierarchy
+
+```text
+commonMain
+├── androidMain
+├── desktopMain (jvm)
+├── wasmJsMain (Beta)
+└── iosMain (intermediate)
+    ├── iosArm64
+    └── iosSimulatorArm64
+```
+
+Use the intermediate `iosMain` for code shared by both iOS targets; only drop to `iosArm64`/`iosSimulatorArm64` for arch-specific cinterop.
+
+## Module-layout variants
+
+- **Mobile-only:** `shared` + `androidApp` + `iosApp`.
+- **+ Desktop:** add `desktopApp` (`./gradlew :desktopApp:run`).
+- **+ Web (Beta):** add `webApp` with the `wasmJs` target; do not promise parity.
+- **Mixed native UI:** split `shared` into **`sharedLogic`** (all platforms, no Compose UI) + **`sharedUI`** (CMP platforms only). Native screens depend on `sharedLogic`; shared screens live in `sharedUI`.
+- **+ Server:** add a root **`core`** module consumed by both clients and a JVM/Ktor server.
+
+## Scaffolding
+
+- New project: **kmp.new** or the Kotlin Multiplatform wizard (IntelliJ IDEA 2025.2.2+ / Android Studio Otter 2025.2.1+ with the KMP plugin).
+- Existing Android app: Android Studio **Shared Module Template** (added May 2025) adds a KMP `shared` module in place.
+
+## AGP 9.0 migration notes
+
+The new default structure aligns with AGP 9.0. When migrating from the old single `composeApp` module: extract shared `@Composable`s/VMs into a `shared` library module, turn `composeApp` into a thin `androidApp` host that calls `setContent { App() }`, and move the iOS framework export into `shared`.
+
+## Packaging
+
+- Desktop: `./gradlew :desktopApp:packageDistributionForCurrentOS` (dmg/msi/deb). Needs **JDK 17+** for `jpackage`; desktop runtime floor is JDK 11+.
+- iOS: archive the `iosApp` Xcode project (App Store signing is `swift-ios` territory).
+- Web (Beta): `./gradlew :webApp:wasmJsBrowserDistribution`.

package/skills/compose-multiplatform/scripts/verify.sh

@@ -0,0 +1,123 @@
+#!/usr/bin/env bash
+# verify.sh — static, read-only checks for a Compose Multiplatform / KMP project.
+# No Gradle/Xcode run required. Exits 0 on a clean OR empty target (no false failure).
+#
+# Usage: verify.sh [PROJECT_DIR]   (default: current directory)
+#
+# Hard failures (exit 1): missing commonMain when KMP is present, orphaned `expect`
+# (no matching `actual`), platform import leaking into commonMain.
+# Warnings (still exit 0): Kotlin < 2.1.0, missing Compose plugin.
+
+set -uo pipefail
+
+ROOT="${1:-.}"
+FAIL=0
+WARN=0
+
+note()  { printf '  %s\n' "$1"; }
+ok()    { printf 'PASS  %s\n' "$1"; }
+bad()   { printf 'FAIL  %s\n' "$1"; FAIL=1; }
+warn()  { printf 'WARN  %s\n' "$1"; WARN=1; }
+
+if [ ! -d "$ROOT" ]; then
+  echo "verify.sh: '$ROOT' is not a directory" >&2
+  exit 2
+fi
+
+# Locate commonMain source dirs (KMP marker). Ignore build output dirs.
+# Portable to bash 3.2 (macOS) — no mapfile.
+COMMON_DIRS=()
+while IFS= read -r d; do
+  [ -n "$d" ] && COMMON_DIRS+=("$d")
+done < <(find "$ROOT" -type d -name commonMain \
+  -not -path '*/build/*' -not -path '*/.gradle/*' 2>/dev/null)
+
+# Detect whether this looks like a KMP/CMP project at all.
+HAS_KMP=0
+if [ "${#COMMON_DIRS[@]}" -gt 0 ]; then HAS_KMP=1; fi
+if grep -rqsl 'org.jetbrains.kotlin.multiplatform\|org.jetbrains.compose' \
+     "$ROOT" --include='*.kts' --include='*.toml' 2>/dev/null; then HAS_KMP=1; fi
+
+if [ "$HAS_KMP" -eq 0 ]; then
+  echo "verify.sh: no KMP/CMP project detected under '$ROOT' — nothing to check."
+  exit 0
+fi
+
+# 1) commonMain must exist.
+if [ "${#COMMON_DIRS[@]}" -eq 0 ]; then
+  bad "no commonMain source set found (a shared module is the core of CMP)"
+else
+  ok "commonMain present (${#COMMON_DIRS[@]} found)"
+fi
+
+# 2) Every `expect` in commonMain needs a matching `actual` somewhere.
+#    Match on the declared symbol name to catch orphans cheaply.
+ORPHANS=0
+for cm in ${COMMON_DIRS[@]+"${COMMON_DIRS[@]}"}; do
+  # collect expect declarations: fun/class/val/var/object/interface
+  while IFS= read -r decl; do
+    [ -z "$decl" ] && continue
+    name="$decl"
+    if grep -rqs "actual[[:space:]].*\b${name}\b" "$ROOT" \
+         --include='*.kt' 2>/dev/null \
+         | grep -qv "commonMain" 2>/dev/null; then
+      :
+    elif grep -rs "actual[[:space:]]" "$ROOT" --include='*.kt' 2>/dev/null \
+           | grep -q "\b${name}\b"; then
+      :
+    else
+      bad "orphaned expect '${name}' has no matching actual in any platform source set"
+      ORPHANS=$((ORPHANS+1))
+    fi
+  done < <(grep -rhsoE '^[[:space:]]*expect[[:space:]]+(fun|class|val|var|object|interface)[[:space:]]+[A-Za-z_][A-Za-z0-9_]*' \
+             "$cm" --include='*.kt' 2>/dev/null \
+             | sed -E 's/.*(fun|class|val|var|object|interface)[[:space:]]+([A-Za-z_][A-Za-z0-9_]*).*/\2/')
+done
+[ "$ORPHANS" -eq 0 ] && ok "no orphaned expect declarations"
+
+# 3) Compose plugin + Kotlin version.
+if grep -rqs 'org.jetbrains.compose' "$ROOT" \
+     --include='*.kts' --include='*.toml' 2>/dev/null; then
+  ok "Compose Multiplatform plugin (org.jetbrains.compose) present"
+else
+  warn "Compose Multiplatform plugin (org.jetbrains.compose) not found"
+fi
+
+KVER=$(grep -rhsoE 'kotlin[^=]*=[[:space:]]*"?([0-9]+\.[0-9]+\.[0-9]+)' \
+         "$ROOT" --include='*.toml' --include='*.kts' 2>/dev/null \
+         | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | sort -V | tail -1)
+if [ -n "$KVER" ]; then
+  MAJ=${KVER%%.*}; REST=${KVER#*.}; MIN=${REST%%.*}
+  if [ "$MAJ" -gt 2 ] || { [ "$MAJ" -eq 2 ] && [ "$MIN" -ge 1 ]; }; then
+    ok "Kotlin $KVER (>= 2.1.0 K2 floor)"
+  else
+    warn "Kotlin $KVER is below 2.1.0 — CMP 1.8+ requires K2 (Kotlin 2.1.0+); bump to 2.2.x"
+  fi
+else
+  warn "could not detect a Kotlin version in version catalog / build scripts"
+fi
+
+# 4) No platform-only imports leaking into commonMain.
+FORBIDDEN='^import[[:space:]]+(android\.|androidx\.activity|platform\.UIKit|platform\.Foundation|java\.awt|javax\.swing|org\.w3c\.dom)'
+LEAKS=0
+for cm in ${COMMON_DIRS[@]+"${COMMON_DIRS[@]}"}; do
+  while IFS= read -r line; do
+    [ -z "$line" ] && continue
+    bad "platform import in commonMain: $line"
+    LEAKS=$((LEAKS+1))
+  done < <(grep -rhsnE "$FORBIDDEN" "$cm" --include='*.kt' 2>/dev/null)
+done
+[ "$LEAKS" -eq 0 ] && ok "commonMain free of platform-only imports"
+
+echo "----"
+if [ "$FAIL" -ne 0 ]; then
+  echo "RESULT: FAIL"
+  exit 1
+fi
+if [ "$WARN" -ne 0 ]; then
+  echo "RESULT: PASS (with warnings)"
+else
+  echo "RESULT: PASS"
+fi
+echo "(Optional: if ./gradlew exists, ':shared:compileKotlinMetadata' compiles the common metadata.)"
+exit 0

package/skills/content-engine/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: content-engine
+description: "Use when a content operation needs a SYSTEM: a dated editorial calendar built top-down from pillars, plus the stage gates, briefs, WIP limits and 1:10 atomization plan that move each slot to publish-ready. NOT writing the pieces (that is `article-writing`), NOT publishing them (that is `social-publisher`), NOT keyword research (that is `seo-geo`)."
+tags: [content, editorial-calendar, content-pipeline, repurposing, marketing-ops]
+recommends: [brand-voice, seo-geo, social-publisher, article-writing, video-shorts, newsletter, automation-flows]
+origin: risco
+---
+
+# Content Engine — The Calendar and the Pipeline That Feeds It
+
+*The factory floor and the production schedule, not the words off any single station.* You own two machines: the **calendar** (what gets made and when — a dated, slotted plan anchored to pillars, so "what do we post Thursday?" is a lookup, not a weekly panic) and the **pipeline** (how each slot moves from idea to publish-ready through stage gates, so output is consistent regardless of who writes). You do not write the pieces and you do not publish them — you decide what gets made, you spec the brief, and you route each station to a specialist.
+
+Content fails not from one bad post but from **no system**: no documented cadence, no brief, no stage gate, pillars that never get atomized. ~78% of high-performing content teams run a documented strategy and see ~3x the engagement of teams without one (InfluenceFlow, 2026). This skill is that system.
+
+## Ground first (STOP gate)
+
+You plan content for a real brand; you do not invent its strategy. Before building anything, read what already exists.
+
+1. Read the brand study and pillars from `docs/` (the project wiki). If the project uses the harness convention, that is `docs/wiki/` — see `../harness/SKILL.md`.
+2. **If voice/tone is missing → STOP.** Route the user to `brand-voice` to codify do/don't words and voice samples. Do not invent a voice; a calendar built on a guessed voice produces off-brand drafts at every station.
+3. **If pillars/clusters/keywords are missing → STOP for the research half.** Route topic-cluster and keyword work to `seo-geo`. You consume pillars and clusters; you do not derive them from search data — that is its job.
+4. Persist the calendar of record under `docs/wiki/content/` and raw inputs (interviews, exports) under `docs/raw/content/`. *Why: the calendar must be a durable artifact of record, not a chat message that scrolls away.*
+5. Cite what you grounded in (e.g. "pillars from `docs/wiki/brand-study.md`"). If you grounded in nothing, say so and stop.
+
+## Build the calendar
+
+**Build top-down, slot last.** Personas → Pillars → Clusters → Assets, in that order. The calendar is derived from this architecture; it is never a bottom-up pile of "post ideas." Bottom-up calendars are the #1 failure mode — they have no theme, no leverage, and no reason any given post exists. *Why this one is absolute: structure makes topic choice a lookup, not a creative emergency every Monday.*
+
+**Four-layer architecture (counts are defaults, state them):**
+
+| Layer | Count | What it is |
+|---|---|---|
+| Personas | 2–4 | who you are writing for |
+| Pillars | 4–6 | durable themes you own; fewer is too narrow, more dilutes effort |
+| Clusters | 3–5 per pillar | sub-topics under each pillar |
+| Assets | concrete | the actual dated formats (the slots) |
+
+*Why 4–6 pillars: calendars anchor to pillars so topic choice is structural. Below 4 you are too narrow to sustain a cadence; above 6 effort scatters and no theme compounds (Entasher 2025-11-29; InfluenceFlow 2026).*
+
+**Cadence baseline (sustainable, the default you propose):**
+
+- ~1 **flagship** piece / month — a guide, report, or webinar; the thing you atomize.
+- 4–8 **supporting** posts / week.
+- ~1 **proof** piece / month — case study or result.
+
+Consistency for 6–12 months beats a one-month sprint. The real constraint is *creating*, not posting — brands already averaged ~9.5 social posts/day across networks in 2024 (Kontent.ai). The pipeline exists to relieve creation, not posting.
+
+**Slot-mix rule (encode these as allocation defaults):**
+
+- **70 / 20 / 10**: ~70% evergreen, ~20% timely/seasonal, ~10% experimental.
+- Leave **20–30% of slots OPEN** for reactive content — do not fully pre-fill the calendar.
+- Budget **15–25% of weekly capacity for UPDATING** existing winners, not only net-new.
+
+*Why: a 100%-planned calendar with zero slack cannot react and rots into a graveyard; never refreshing winners throws away your highest-ROI slots (InfluenceFlow 2026).*
+
+**Decision table — cadence by team size** (a real branch, so the table earns its place):
+
+| Team | Flagship | Supporting | Atomize per flagship | WIP cap |
+|---|---|---|---|---|
+| Solo | 1 / 6–8 wks | 3–4 / wk | 5–7 derivatives | 1–2 in flight |
+| Small (2–5) | 1 / mo | 4–6 / wk | ≥10 derivatives | 3–4 in flight |
+| Multi-stakeholder | 1–2 / mo | 6–8 / wk | ≥10 + paid cutdowns | 5–6, gated by owner |
+
+Slot schema — emit the calendar as CSV (one row per slot) so `scripts/verify.sh` can lint it:
+
+```csv
+date,pillar,cluster,format,owner,stage,brief_link,atomization,mix
+2026-07-07,Onboarding,activation-checklist,flagship-guide,ana,brief,docs/wiki/content/briefs/onboarding-guide.md,planned,evergreen
+2026-07-09,Onboarding,activation-checklist,linkedin-post,ana,idea,,,evergreen
+2026-07-15,Trends,q3-benchmarks,reactive-open,,idea,,,timely
+```
+
+`mix` is one of `evergreen|timely|experimental` (plus leave `reactive-open` slots with empty owner). Full column docs + a filled example live in `references/brief-and-pipeline.md`.
+
+## The brief
+
+A slot **cannot leave the `idea` stage without a brief.** One canonical brief format means consistent output regardless of who writes it. The brief is a `.md` page in the `docs/wiki/` OKF v0.1 bundle: its YAML frontmatter carries a non-empty `type: content-brief` (plus the OKF-recommended `title`/`description`/`tags`/`timestamp`) alongside the domain fields below, and any body cross-references use standard markdown links, never wikilinks. Required fields (inline minimum):
+
+- **objective** — the one outcome this piece drives.
+- **persona** — which of the 2–4 you target.
+- **pillar / cluster** — where it sits in the architecture.
+- **angle** — the specific take (not the topic).
+- **format** — flagship-guide / linkedin-post / video-short / newsletter-issue / …
+- **owner** — the human accountable for the slot.
+- **target keyword** — handed off from `seo-geo`, not invented here.
+- **success metric** — how you will know it worked.
+- **atomization intent** — for flagships, the derivative count and target channels.
+
+Full template with a filled example → `references/brief-and-pipeline.md`. *Why one brief: the brief is where "AI is a station, not the author" gets enforced — a human sets objective, angle, and what "good" is before a draft exists.*
+
+## The pipeline: stages + gate
+
+`idea → brief → draft → edit → atomize → publish-ready`. Each stage has an entry gate (what must be true to enter) and an exit gate (what must be true to leave). Run the gates as a checklist — this is a real branch, so the checklist earns its place:
+
+- **idea → brief:** slot exists in the calendar with a pillar/cluster assigned. Exit: brief written and owner set.
+- **brief → draft:** brief complete, target keyword present, voice reference linked. Exit: a draft exists.
+- **draft → edit:** draft hits the brief's format and angle. Exit: edited against the brief and the voice guide.
+- **edit → atomize:** flagship has a passing edit. Exit: atomization plan filled (≥ derivative count). Non-flagships skip to publish-ready.
+- **atomize → publish-ready:** derivatives are planned and routed. Exit: every asset has an owner and a destination.
+
+**WIP limits matter more than throughput.** Cap in-flight slots per the team-size table; pulling a new idea before finishing the last one is how the calendar becomes a graveyard.
+
+**AI is a station, not the author.** Use AI for research, outlines, drafts, repurposing, and angle-testing. Humans decide which pillars matter, which stories to tell, and what "good" is. Voice is grounded via `brand-voice`, never invented (Entasher 2025-11-29).
+
+## Atomization (1:10)
+
+Every flagship carries an atomization plan, not just a publish date. Aim for **≥10 distinct derivatives** per flagship — repurposing yields ~3–5x reach, ~60% less creation time, and 94% of B2B marketers say it extends content ROI (DigitalApplied 2026-01-16).
+
+Three phases:
+
+1. **Audit** — pick the high-value source by traffic / intent / conversion.
+2. **Atomize** — extract the reusable atoms: stats, quotes, frameworks, how-to steps, case studies.
+3. **Reformat** — reassemble atoms into platform-**native** formats, each adapted to its destination's length and language. Channel-native, never copy-paste: LinkedIn = numbered insights + an engagement question; an X thread = a bold hook in tweet 1, links back in the final tweet.
+
+The derivative menu, a worked 1→10 example, and per-channel Bad→Good rewrites live in `references/atomization.md`.
+
+**Route the derivatives, do not write or ship them:** each derivative goes to its specialist (`../article-writing/SKILL.md`, `newsletter`, `video-shorts`); the **act of shipping** goes to `social-publisher`; wiring publish/atomize into a cron or webhook flow goes to `automation-flows`.
+
+## Handoffs — who owns what
+
+| Ask | Owner |
+|---|---|
+| Write the long-form article body | `../article-writing/SKILL.md` |
+| Write the newsletter issue copy | `newsletter` |
+| Write/schedule/queue posts to platforms (the act of publishing) | `social-publisher` |
+| Script/storyboard a short-form video | `video-shorts` |
+| Keyword research, topic clustering, schema | `seo-geo` |
+| Codify tone, do/don't words, voice samples | `brand-voice` |
+| Landing/launch/web-page conversion copy | `../marketing/SKILL.md` |
+| One-off reminders / scheduling meetings | `calendar-scheduling` |
+| Automate publish/atomize as a cron/webhook flow | `automation-flows` |
+
+The tell: if the ask is **the system that decides what gets made, when, and how it moves**, it is here. If the ask is **producing one artifact** or **the act of distributing**, it is a sibling.
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails | Do instead |
+|---|---|---|
+| Bottom-up calendar (pile of post ideas) | no theme, no leverage, no reason a post exists | derive slots from Personas→Pillars→Clusters |
+| Slot with no brief | output drifts per author; can't enforce voice | block exit from `idea` until brief is complete |
+| Flagship with no atomization plan | 1:10 leverage left on the floor | require an atomization plan to leave `edit` |
+| Inventing brand voice | off-brand at every station | STOP, route to `brand-voice` |
+| AI as author | nobody owns angle, story, or "good" | AI is a station; humans set objective and bar |
+| Calendar-as-graveyard | slots planned but never pulled | enforce WIP limits; pull, don't pile |
+| 100%-planned, zero slack | can't react to anything timely | leave 20–30% of slots open |
+| Net-new only, never updating | discards highest-ROI winners | budget 15–25% capacity for updates |
+| Copy-paste cross-posting | each channel punishes non-native content | reformat per channel (`references/atomization.md`) |
+| >7 pillars | effort scatters, no theme compounds | hold to 4–6 |
+
+## Verify
+
+`scripts/verify.sh path/to/calendar.csv` lints an emitted calendar: required columns present, every `stage` is a valid pipeline state, every flagship row has a `brief_link` and an `atomization` plan, and it warns on mix sanity (>80% evergreen, or 0% reactive/open). It is read-only and exits 0 on a clean or empty target — it gates structure, not whether the plan is good.

package/skills/content-engine/evals/README.md

@@ -0,0 +1,17 @@
+# Evals — content-engine
+
+`cases.yaml` is read by the repo's standard eval harness. The `should_trigger` and
+`should_not_trigger` cases check routing discrimination: each `should_trigger` prompt
+must select this skill (including the non-obvious "turn this pillar post into everything"
+atomization-plan case, the symptom-only "our content is chaos" case, and the Spanish
+phrasing), while each `should_not_trigger` prompt must route to the named sibling
+(`article-writing`, `social-publisher`, `seo-geo`, `brand-voice`, `calendar-scheduling`)
+rather than here — they guard the description's boundary between *the system* and
+*producing/distributing one artifact*. The single `capability` case is rubric-graded,
+not auto-scored: have the skill build the 4-person B2B SaaS Q3 calendar+pipeline and
+check the output against the `must_include` list (grounded in docs, 4–6 pillars,
+cadence baseline, slot-mix, a CSV artifact, briefs, stage gates, a ≥10 atomization plan,
+and everything routed out). Run it through whatever runner the skills repo uses. For the
+CSV-artifact subset you can sanity-check a real calendar with
+`../scripts/verify.sh path/to/calendar.csv` — it lints columns, stages, flagship
+brief/atomization, and mix sanity, but does not judge whether the plan is good.

package/skills/content-engine/evals/cases.yaml

@@ -0,0 +1,62 @@
+skill: content-engine
+
+# Prompts that MUST load `content-engine`. The skill owns the editorial CALENDAR
+# (built top-down from pillars) and the production PIPELINE that moves slots through
+# stages, plus the atomization PLAN. It does NOT write the pieces (article-writing,
+# newsletter, video-shorts), publish them (social-publisher), do keyword/cluster
+# research (seo-geo), or codify voice (brand-voice).
+should_trigger:
+  - prompt: "Build me a content calendar for next quarter."
+    why: "Core calendar ask — a dated, slotted editorial plan is exactly what this skill produces."
+
+  - prompt: "Set up our content production pipeline with a brief template and stages."
+    why: "Core pipeline ask — stage gates, the canonical brief, and WIP limits are the skill's second machine."
+
+  - prompt: "Turn this pillar blog post into everything — plan all the derivatives and where each goes."
+    why: "Non-obvious: looks like a writing ask but it's the atomization PLAN and routing (1:10), not the writing — owned here, then routed out."
+
+  - prompt: "móntame un calendario de contenidos y un pipeline para el equipo."
+    why: "Spanish phrasing for 'build me a content calendar and a pipeline for the team' — the core calendar+pipeline request."
+
+  - prompt: "Our content is chaos, nobody knows what to post when — give us a system."
+    why: "Non-obvious symptom phrasing with no calendar/pipeline word; the cure (documented cadence + stage gate + calendar of record) is exactly this skill."
+
+  - prompt: "What should we post and when? Define our pillars and cadence for the next quarter."
+    why: "Pillar definition + cadence + the dated plan is the top-down calendar build this skill owns."
+
+should_not_trigger:
+  - prompt: "Write the actual 1,500-word blog post about user activation."
+    route_to: article-writing
+    why: "Producing one long-form artifact is article-writing; content-engine writes the brief and owns the slot, not the prose."
+
+  - prompt: "Schedule and publish these posts to LinkedIn and X this week."
+    route_to: social-publisher
+    why: "The act of distributing/queuing to platforms is social-publisher; content-engine plans the slot, it does not ship it."
+
+  - prompt: "Do keyword research and build the topic clusters for our SEO."
+    route_to: seo-geo
+    why: "Keyword/cluster research and ranking strategy decide inputs the calendar consumes; that research is seo-geo, not the calendar."
+
+  - prompt: "Define our brand tone of voice and a do/don't word list."
+    route_to: brand-voice
+    why: "Codifying voice/tone and sample words is brand-voice; content-engine grounds in that artifact, it does not create it."
+
+  - prompt: "Remind me to post every Tuesday at 9am."
+    route_to: calendar-scheduling
+    why: "A one-off recurring reminder is calendar-scheduling, not an editorial calendar built from pillars."
+
+capability:
+  - scenario: >
+      We're a 4-person B2B SaaS team. We have a brand study and content pillars in
+      docs but no calendar and no pipeline. Build a Q3 editorial calendar and a
+      production pipeline.
+    must_include:
+      - "Grounds in the docs brand study and pillars (or STOPs and routes to brand-voice / seo-geo if missing) before building"
+      - "Uses 4–6 pillars mapped to 3–5 clusters each, top-down (no bottom-up pile of post ideas)"
+      - "Applies the cadence baseline: ~1 flagship/month + 4–8 supporting/week + ~1 proof/month"
+      - "Honors the slot-mix rule: ~70/20/10, 20–30% slots left open/reactive, 15–25% capacity for updates"
+      - "Emits a CSV calendar artifact with the required columns (date,pillar,cluster,format,owner,stage,brief_link,atomization,mix)"
+      - "Provides a canonical brief per flagship slot (objective, persona, pillar/cluster, angle, format, owner, target keyword, success metric, atomization intent)"
+      - "Defines the pipeline stages with entry/exit gates and WIP limits matched to a small (2–5) team"
+      - "Includes an atomization plan of ≥10 derivatives per flagship, each routed to the correct sibling"
+      - "Routes writing to article-writing/newsletter/video-shorts and shipping to social-publisher — nothing is written or published in-skill"

package/skills/content-engine/references/atomization.md

@@ -0,0 +1,81 @@
+# Reference — Atomization (1 flagship → 10 derivatives)
+
+Offloaded detail for `content-engine`. The body states the 3 phases and the rule; this
+is the derivative menu, a worked 1→10 example, and per-channel Bad→Good rewrites.
+
+**Leverage:** aim for ≥10 distinct derivatives per flagship. Repurposing yields ~3–5x
+reach, ~60% less creation time, and 94% of B2B marketers say it extends content ROI
+(DigitalApplied, "Content Repurposing: One Piece, Ten Formats", 2026-01-16).
+
+## The three phases
+
+1. **Audit** — pick the source by traffic / search intent / conversion, not by recency.
+   Atomize your proven winners, not your latest post.
+2. **Atomize** — extract reusable atoms: **stats**, **quotes**, **frameworks**,
+   **how-to steps**, **case studies**. Each atom can seed several derivatives.
+3. **Reformat** — reassemble atoms into platform-**native** formats. Adapt length and
+   language to the destination; never paste the same text everywhere.
+
+## Derivative menu (with length specs)
+
+| # | Derivative | Source atoms | Length / spec | Routed to |
+|---|---|---|---|---|
+| 1 | LinkedIn insight post | one framework + one stat | 1,200–1,800 chars, ends in a question | `social-publisher` (copy: `marketing`) |
+| 2 | LinkedIn carousel | how-to steps | 6–10 slides, one idea/slide | `social-publisher` |
+| 3 | X / thread | hook + 4–6 steps | tweet 1 = bold hook, last tweet links back | `social-publisher` |
+| 4 | Short-form video | one how-to step | 20–45s vertical, hook in 2s | `video-shorts` |
+| 5 | Short-form video #2 | a surprising stat | 20–45s vertical | `video-shorts` |
+| 6 | Newsletter section | the full framework | 200–400 words + CTA | `newsletter` |
+| 7 | Quote graphic | one quote | single image, attributed | `social-publisher` |
+| 8 | Infographic | stats + steps | one tall image | `social-publisher` |
+| 9 | Email nurture beat | one objection handled | 80–150 words | `newsletter` |
+| 10 | Internal-link / FAQ update | a how-to step | added to a related article | `article-writing` |
+
+(Beyond 10: paid cutdowns, a webinar segment, a SlideShare — for multi-stakeholder teams.)
+
+## Worked 1 → 10 example
+
+**Flagship:** "The SaaS User-Activation Checklist" (guide, ~2,000 words, pillar Onboarding).
+
+1. LinkedIn post: "We watched 50 trials. The 3 setup steps teams skip — and the
+   activation hit each one costs. Which do you skip?" (framework + stat)
+2. LinkedIn carousel: the 8-step checklist, one step per slide.
+3. X thread: hook "Most trials die in week one. Here's the autopsy 🧵", steps 2–7,
+   final tweet → the guide.
+4. Short #1: "The one setup step 60% of teams skip" (single step, 30s).
+5. Short #2: "Activated users retain 4x longer" (the stat, 25s).
+6. Newsletter section: the full 8-step framework + "get the checklist" CTA.
+7. Quote graphic: "Activation is a week-one problem, not a month-three one."
+8. Infographic: the 8 steps + the retention stat as one tall image.
+9. Email nurture beat: handle "we don't have time to onboard" objection.
+10. FAQ/internal-link update: add "What is user activation?" answer to the pricing page,
+    linking the guide.
+
+## Per-channel native adaptation — Bad → Good
+
+**LinkedIn**
+
+- Bad: paste the guide's intro paragraph verbatim with a link.
+- Good: "3 setup steps most teams skip in week one:" → numbered insights → "Which one
+  is your team guilty of?" Native = scannable + an engagement question.
+
+**X / thread**
+
+- Bad: one tweet with the headline and a link.
+- Good: tweet 1 is a bold standalone hook; the thread delivers the steps; the final
+  tweet links back. Native = the hook earns the click before the link appears.
+
+**Short-form video**
+
+- Bad: a 3-minute screen recording reading the guide.
+- Good: 25–45s, hook in the first 2 seconds, ONE step, captions on. Native = one idea,
+  vertical, no warm-up.
+
+**Newsletter**
+
+- Bad: dump the whole 2,000-word guide into the email.
+- Good: one framework + your take + a single CTA to the full guide. Native = a curated
+  beat, not a re-host.
+
+The rule across all four: **reformat to the channel's language and length, never
+copy-paste.** Copy-paste cross-posting is an anti-pattern (see `../SKILL.md`).