ktg-plugin-marketplace/plugins/linkedin-thought-leadership/docs/brief-fullspektrum-innholdsmotor.md
Kjell Tore Guttormsen 098726d397 docs(linkedin): Voyage executable plan for v2.0.0 build (21 sessions)
Production plan for lifting LTL v1.2.0 -> v2.0.0 (full-spectrum content
engine + /linkedin:newsletter + render migration + net-fewer commands/agents).

- docs/voyage-build/{brief.md,plan.md}: Voyage project dir. plan.md = 21 steps
  (S1..S20+S1a), each with a per-step Manifest. Validator: valid, 0 warnings.
- docs/{brief,plan}-fullspektrum-innholdsmotor.md + voyage-build-brief.md:
  the directional brief, hardened fasit (authoritative WHAT), and Voyage input.
- Built via /trekplan: confirmatory swarm verified the fasit against real files
  (13 corrections folded in); scope-guardian ALIGNED; plan-critic REPLAN ->
  revised (3 blockers + 5/6 major + 4/5 minor closed).
- plan.html (annotation surface) left untracked: regenerable via annotate.mjs.

Next: /trekexecute --fg --project docs/voyage-build (fresh session) -> S1.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-26 21:38:52 +02:00

8.7 KiB

Brief — LTL som fullspektrum LinkedIn-innholdsmotor (idé → publisering)

Til: linkedin-thought-leadership-pluginens utviklingsrepo. Skrevet: 2026-05-26, etter produksjon av den første kronikkserien (Seres-serien, 6 deler). Type: retningsbrief — beslutningsgrunnlag før planlegging/bygging. Selvstendig (kan leses uten annen kontekst).


1. Hva vi skal oppnå

Løft LTL fra en kortform-fokusert plugin til den komplette motoren for ALT LinkedIn-innhold, fra idé til publisering — inkludert nyhetsbrev/langform, som i dag er pluginens svakeste område.

Én plugin skal eie hele kjeden: idé → research → utkast → faktasjekk → review → hook/distribusjon → planlegging → publisering → analyse — for alle formater: posts, carousels, reaksjoner, video, og nyhetsbrev-editions.

Begrunnelsen: scopet er LinkedIn. Da hører nyhetsbrev hjemme i LTL (det ER et LinkedIn-native format), sømmene mot en separat plugin koster mer enn de gir, og brukeren bruker uansett LTL for alt LinkedIn.


2. Kontekst: hvor dette innholdet lages

~/repos/maskinrommet er det private, lokale repoet der ALT innhold produseres. Der brukes LTL-pluginen til all innholdsproduksjon. Arbeidsdelingen:

  • maskinrommet = arbeidsbenken (innhold, serier, og en delt tools/-mappe med deterministiske render-skript: build-linkedin.mjs → POST.html, build-carousel.mjs, build-html.mjs annoterbar HTML, build-pdf.mjs avis-PDF).
  • LTL = verktøyet/hjernen som driver produksjonen i det repoet.
  • dette LTL-repoet = der selve plugin-utviklingen skjer. Erfaringene kommer fra maskinrommet; endringene gjøres her.

Render-skriptene i maskinrommet/tools/ er den mekaniske utføreren som LTL-pipelinen kaller. «LTL eier prosessen» krever ikke at LTL hoster render-skriptet — se åpen beslutning C.


3. Live-status (baseline å bygge for)

Nyhetsbrevet Maskinrommet er etablert på LinkedIn:

  • Første post ute, 30 abonnenter, 6 nyhetsbrev i pipen (Seres-serien, ferdig produsert).
  • Publisering er manuell (LinkedIn har ingen API for newsletter/long-form), men kan native-planlegges.

Dette er en reell, kjørende kadens — ikke en hypotese. Forbedringene skal støtte å produsere de neste seriene raskere og med samme kvalitet.


4. Erfaringsgrunnlag: hva en kronikk faktisk krever

Seres-serien (6 kronikker, ~10 sesjoner) avdekket at langform-produksjon ikke er «skriving» — det er en research- og adversarial-review-pipeline. Den faktiske flyten som ga kvalitet:

  1. Brief — vinkel, tenkt stemme, målgruppe-personaer (med primær), nøkkelpoeng, tone, leder-takeaway.
  2. Research — flere parallelle, avgrensede mandater → verifiserte notater.
  3. Faktasjekk-sweep — risikosortert (🔴/🟡/🟢), parallelle WebSearch-agenter, «hver påstand skyldig til motbevist». Fanget ~13 feil — flere som egne research-filer hadde bommet på.
  4. Skriving — dramaturgisk rekkefølge, multi-sesjon med vedlikeholdt HANDOVER.
  5. Konsistens + kvalitet — på tvers av tekstene (gjentakelser, tone, premiss→konklusjon-bue).
  6. Persona-/audience-sweep FØR lås — 3 definerte leser-juryer leser read-only, primær trumfer. («Lander poenget?»). Kjørt til konvergens (LØST/DELVIS/IKKE per flagg).
  7. Hook-/konverterings-gate — egen persona-gate på distribusjons-teksten: «ville DU klikket?», hold tilbake leveransen (tall/case/grep), ikke konklusjonen.
  8. Lås → leveranse — POST.html «alt på ett sted» (dato, hook, hashtags, første kommentar, cover-caption, brødtekst som rik tekst).

De tre suksessfaktorene: front-loadet kontekst, skreddersydd annoteringsverktøy, vedlikeholdt single-source HANDOVER før hver kontekst-reset.

Største prosessfeil å unngå: persona-sweep ble kjørt ETTER lås → måtte åpne låste tekster. Den generaliserte malen MÅ ha persona-sweep FØR lås.


5. Byggeprinsipp: løft Voyage-mønstrene, ikke fork dem

Denne pipelinen mapper nesten 1:1 på Voyage-pluginen (trekbrief → trekresearch → trekplan → trekexecute → trekreview, med parallelle agenter + adversarielle reviewere + multi-sesjon).

Men IKKE fork Voyage og IKKE reimplementer den blindt. Voyage er kode-spesifikk (file:line, kode-reviewere, RULE_CATALOGUE). Løft i stedet mønstrene inn i LTL som et nytt langform-/ nyhetsbrev-spor ved siden av de eksisterende kortform-kommandoene:

  • faset pipeline med parallelle research-agenter
  • faktasjekk-sweep som eget steg
  • multi-persona adversarial jury (leser-personaer erstatter kode-reviewere; primær trumfer)
  • multi-sesjons-kontinuitet (HANDOVER-mønster)

Delte agenter, variabel intensitet: research- og faktasjekk-agentene skal kunne kalles på lav intensitet fra en kortform-post som siterer ett tall, og full sweep fra et nyhetsbrev. Voice og hook-gate deles på tvers — aldri to systemer.

Voyage er referanse/inspirasjon, ikke en avhengighet å vedlikeholde.


6. Hva LTL allerede har (ikke bygg på nytt)

  • Skrive-workflows for kortform: /linkedin:post (vinkel→draft→kvalitet→refinement), /linkedin:pipeline (idé→draft→optimer→planlegg→engasjer→publiser→analyse), batch, react, quick, carousel, video, templates.
  • Voice-system (config/user-profile.local.md, voice-samples, voice-trainer-agent).
  • Hook-/optimaliserings-støtte (content-optimizer, differentiation-checker).
  • Planlegging/sporing/analyse (calendar, publish, import, report; queue.json; state-fil).
  • 16 agenter, fler-stegs-kommandoer, REMEMBER-kontinuitet — arkitekturen kan være vert for et tyngre pipeline-spor.

7. Gapet å fylle (LTLs svake punkt = langform/nyhetsbrev)

  1. Langform-/nyhetsbrev-pipeline som eget kommandospor (idé→publisering for editions, ikke bare posts).
  2. Research-orkestrering — parallelle mandater, verifiserte notater.
  3. Faktasjekk-sweep — risikosortert, kildekritisk, verifiseringslogg, «skyldig til motbevist».
  4. Multi-persona adversarial review FØR lås — konfigurerbare leser-juryer, primær trumfer, konvergens-loop til rent JA.
  5. Multi-sesjons-kontinuitet — HANDOVER-mønster for produksjon som spenner flere økter.
  6. Nyhetsbrev-leveranse — edition-format (POST.html-stil «alt på ett sted»), delingstekst-system, ferskvare-flagg for tidssensitive tall, native planlegging.
  7. Annoteringssteg — integrer annoterbar review-HTML i flyten (render bor i maskinrommet/tools).

8. Åpne beslutninger (landes før bygging i dette repoet)

  • A. Pipeline som nye kommandoer vs. utvidelse av pipeline. Eget /linkedin:longform/:newsletter- spor, eller utvid eksisterende pipeline med en «long-form»-modus?
  • B. Agent-deling. Bygges research/faktasjekk/persona-jury som nye delte agenter brukt på variabel intensitet av både kort- og langform? (Anbefalt.)
  • C. Render-eierskap. Forblir build-linkedin.mjs/build-carousel.mjs i maskinrommet/tools/ (LTL kaller dem), eller flyttes LinkedIn-render inn i pluginen? (Anbefalt: bli i tools/ — render-familien deler fonts/identitet; pluginen holdes lean.)
  • D. Personasett. Defineres leser-personaene per prosjekt (fra målgruppen) eller som gjenbrukbare profiler i config?
  • E. Faktasjekk-omfang. Eget steg, eller integrert i research + review?

8b. Merknad: brukeren trenger onboarding i pluginen

Brukeren kjenner ikke pluginen sin godt ennå og vil «ta ut potensialet». Tilby tidlig i LTL-sesjonen: /linkedin (oversikt over alle kommandoer) + /linkedin:setup (personaliserings-score + fyll inn voice-samples/case/rammeverk/demografi/profil). Personalisering er nøkkelen — voice-matching, differensiering og hook-gate avhenger av ekte innmatede data.

9. Referanser (i ~/repos/maskinrommet og memory)

  • Plan (supersedes-kandidat): ~/repos/maskinrommet/planer/2026-05-26-kronikk-voyage-companion.md — skrevet før denne retningen (foreslo separat companion). Behold som historikk; denne briefen er gjeldende retning.
  • Erfaringskatalog: produsert i sesjon 2026-05-26 (16 prosessfaser, suksessfaktorer, friksjon, verktøy).
  • HANDOVER: ~/repos/maskinrommet/serier/silvija-seres-motsvar/HANDOVER.md (§3 leveranse, §4 regler, §5 metode).
  • Memory (~/.claude/projects/-Users-ktg-repos-svv/memory/): project_kronikk_produksjonsprosess.md (Voyage-mapping, persona-sweep-FØR-lås, kalibrering), project_maskinrommet_newsletter.md, project_kronikk_faktasjekk_sweep.md, feedback_dokumentprosjekt_suksessfaktorer.md, feedback_hook_post_persona_gate.md, feedback_persona_audience_sweep.md, feedback_use_linkedin_plugin.md, feedback_post_html_single_sheet.md.