diff --git a/README.md b/README.md index b7d5b9c..9436ac5 100644 --- a/README.md +++ b/README.md @@ -1,9 +1,11 @@ # /orchestrator +[![GitHub stars](https://img.shields.io/github/stars/maxtechera/orchestrator?style=flat&label=GitHub%20stars)](https://github.com/maxtechera/orchestrator/stargazers) +[![Proof-driven workflow](https://img.shields.io/badge/proof--driven-verified%20delivery-2563eb)](https://github.com/maxtechera/orchestrator/blob/main/README.md#orchestrator) [![MIT License](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE) [![Version](https://img.shields.io/badge/version-1.0.0-green.svg)](CHANGELOG.md) -**Expert orchestrator of agentic teams. The ticket contract defines work. The verification harness rules completion.** +**Verified AI-agent workflow orchestrator for Claude Code. Dispatch workers, run independent checks, ship only what passes.** Claude Code: ``` @@ -51,6 +53,25 @@ git clone https://github.com/maxtechera/orchestrator.git ~/.claude/skills/orches That's it. Run `/orchestrator sweep` to get started. If no board is connected, the orchestrator will prompt you to run `/orchestrator setup`. See [Your First Ticket](#your-first-ticket) below for a copy-paste template. +## Learn `/orchestrator` + +Want the full operating system behind reliable agent teams? + +- **Course:** [`/orchestrator` course outline](docs/course-outline.md) +- **Free lesson workbook:** [The context-limit wall and why single-agent workflows break](docs/sample-lessons/module-1-lesson-1-context-limit-wall.md) +- **Paid course CTA:** **Aprendé a orquestar equipos de agentes → curso `/orchestrator` ($197)** + +The free OSS skill helps you run the workflow. The paid course teaches you how to design the contracts, memory, reliability layers, and production patterns behind it. + +### Marketplace packaging playbooks + +If you are preparing a companion skill or repo for Claude Code marketplace submission, use these proof-first packaging docs: + +- [Memory marketplace optimization package](docs/memory-marketplace-package.md) +- [MAX-534 proof pack](artifacts/MAX-534/proof-pack.md) + +The memory package includes the final GitHub description, topic set, social preview card, manifest verification checklist, and install steps to copy into the target repo README before submitting. + --- ## What people use it for diff --git a/SKILL.md b/SKILL.md index 77a05a7..df190ce 100644 --- a/SKILL.md +++ b/SKILL.md @@ -217,3 +217,18 @@ Works with any issue tracker. Run `/orchestrator setup` to connect: - The system fails visibly, not silently - Finishing beats starting - You define the boundaries. The harness operates inside them. + +## Proof-pack comment hook + +Before posting proof-pack comments on markdown-rendering surfaces such as Linear, GitHub, Slack, Discord, or Notion, fail closed on media formatting. + +Reject the comment and rewrite it if any of the following are true: +- local image paths like `/data/workspace/artifacts/...png` appear without a sibling markdown embed `![](...)` +- MP4 proof is named but not uploaded as an attachment or public link +- the comment relies on filesystem paths as the primary proof surface + +Required behavior: +1. Upload image proof first +2. Inline the uploaded image URL with markdown +3. Upload MP4 proof and include the public attachment link in the same proof pack +4. Only then post the final proof comment diff --git a/WORKFLOW.md b/WORKFLOW.md index 5513ec8..d835ac3 100644 --- a/WORKFLOW.md +++ b/WORKFLOW.md @@ -127,6 +127,33 @@ Agent CANNOT self-transition to Done without all 5 elements: - State transition without artifact - Checklist tick without evidence - Status comment without proof delta +- File path references without embedded media on surfaces that support rendering + +### Media embedding (cross-surface rule) + +When posting proof or evidence to any surface that renders markdown (Linear, GitHub, Slack, Discord, Notion), embed media inline. Do not just paste filesystem paths. + +- **Images**: upload to the surface's file storage, then inline with `![caption](url)` +- **Video / MP4**: upload as an attachment and include a link in the proof pack +- **Filesystem paths** are fallback only, and count as zero-credit proof when a renderable surface is available + +Surface specifics: +- **Linear**: upload via the Linear API or CLI attachment flow and use the returned public URL in `![](...)` +- **GitHub**: attach to the PR or issue and use the resulting public attachment URL +- **Slack / Discord / Notion**: attach the media and reference it inline where supported + +If embedding fails, say so explicitly in the comment and attach via the surface attachment system. Never fall back silently to raw paths. + +### Pre-comment hook (required before proof-pack comments) + +Before posting any proof-pack or verification comment, run this fail-closed lint: + +1. Scan the comment body for `/data/workspace/artifacts/*.png`, `.jpg`, `.jpeg`, `.gif`, or `.webp` +2. For every local image path found, require a sibling markdown embed `![](...)` or `![alt](...)` that points to a public attachment URL for that same proof item +3. Reject the comment if it references local media paths without an inline embed +4. For MP4 references, require an uploaded attachment or public link in the same proof pack comment + +If the hook fails, do not post the comment. Upload the media first, rewrite the proof pack, then post. ### Domain Verification Checklists diff --git a/artifacts/MAX-511/final_mp4_attachment.mp4 b/artifacts/MAX-511/final_mp4_attachment.mp4 new file mode 100644 index 0000000..ee1a1a6 Binary files /dev/null and b/artifacts/MAX-511/final_mp4_attachment.mp4 differ diff --git a/artifacts/MAX-511/generate_assets.py b/artifacts/MAX-511/generate_assets.py new file mode 100644 index 0000000..2862e79 --- /dev/null +++ b/artifacts/MAX-511/generate_assets.py @@ -0,0 +1,90 @@ +from pathlib import Path +from PIL import Image, ImageDraw, ImageFont +import textwrap + +OUT = Path(__file__).resolve().parent +W, H = 1080, 1920 +BG = (7, 17, 31) +CARD = (17, 38, 64) +ACCENT = (135, 247, 198) +MUTED = (164, 182, 201) +WHITE = (244, 247, 251) +PINK = (255, 139, 214) + +slides = [ + ("Día 1", "Dolor + conversación", [ + "Tu contenido no falla por falta de ideas.", + "Falla por falta de sistema diario.", + "Poll: ¿Tus stories venden o solo mantienen presencia?", + "CTA: respóndeme STORIES" + ]), + ("Día 2", "Framework + newsletter", [ + "Hook + prueba + pregunta + CTA.", + "No necesitas diseño complejo.", + "Necesitas una secuencia repetible.", + "CTA: entra a la newsletter" + ]), + ("Día 3", "Prueba social + workshop", [ + "Una story bien armada suma conversaciones.", + "Más replies = más intención.", + "Question: ideas, consistencia o convertir.", + "CTA: workshop waitlist" + ]), + ("Día 4", "Behind the scenes + replies", [ + "Qué fricción siente la audiencia.", + "Qué micro-prueba mostrar.", + "Qué acción mínima pedir.", + "CTA: responde y te mando plantilla" + ]), + ("Día 5", "Plantilla + office hours", [ + "Hook listo para usar.", + "Prueba con insight o resultado.", + "Pregunta para activar respuesta.", + "CTA: súmate a office hours" + ]), + ("Día 6", "Segmentación", [ + "Stories para separar curiosidad e intención.", + "Poll: ¿más ideas o más conversión?", + "Ideas → newsletter.", + "Conversión → DM" + ]), + ("Día 7", "Cierre + conversión", [ + "Las stories son un canal diario de demanda.", + "Generan taps, replies y conversiones.", + "Repite la secuencia con intención.", + "CTA: únete al workshop" + ]) +] + +font_paths = [ + "/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf", + "/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf", +] +for p in font_paths: + if not Path(p).exists(): + raise SystemExit(f"Missing font: {p}") + +bold = ImageFont.truetype(font_paths[0], 88) +sub = ImageFont.truetype(font_paths[0], 44) +body = ImageFont.truetype(font_paths[1], 46) +small = ImageFont.truetype(font_paths[1], 34) + +for i, (day, title, bullets) in enumerate(slides, start=1): + img = Image.new("RGB", (W, H), BG) + draw = ImageDraw.Draw(img) + draw.rounded_rectangle((60, 70, W - 60, H - 70), radius=48, fill=CARD) + draw.text((110, 130), "MAX-511", font=small, fill=ACCENT) + draw.text((110, 190), day, font=bold, fill=WHITE) + draw.text((110, 310), title, font=sub, fill=PINK) + draw.text((110, 410), "Stories pack para newsletter + workshop", font=small, fill=MUTED) + + y = 520 + for bullet in bullets: + lines = textwrap.wrap(bullet, width=28) + draw.rounded_rectangle((105, y - 18, W - 105, y + 90 + 52 * (len(lines)-1)), radius=28, fill=(13,27,46)) + draw.text((140, y), "•", font=sub, fill=ACCENT) + draw.text((190, y), "\n".join(lines), font=body, fill=WHITE, spacing=10) + y += 170 + 46 * (len(lines)-1) + + draw.text((110, H - 210), "max-techera | sistema de stories manual y repetible", font=small, fill=MUTED) + img.save(OUT / f"slide-{i:02d}.png") diff --git a/artifacts/MAX-511/package.json b/artifacts/MAX-511/package.json new file mode 100644 index 0000000..cab0700 --- /dev/null +++ b/artifacts/MAX-511/package.json @@ -0,0 +1,46 @@ +{ + "ticket_id": "MAX-511", + "content_type": "content_asset", + "target_repo": "maxtechera/orchestrator", + "target_system": "mailerlite", + "brand": "max-techera", + "locale": "es", + "placements": { + "instagram_stories": { + "asset": "artifacts/MAX-511/story-pack.md", + "tracking_sheet": "artifacts/MAX-511/tracking-sheet.csv", + "days": 7, + "frames_per_day": "3-5", + "audience_intent": [ + "newsletter", + "workshop", + "office_hours", + "reply_prompt" + ], + "cta_map": [ + {"day": 1, "cta": "Responder DM con STORIES", "interaction": "poll + dm"}, + {"day": 2, "cta": "Newsletter", "interaction": "educational frame"}, + {"day": 3, "cta": "Workshop waitlist", "interaction": "question sticker"}, + {"day": 4, "cta": "Reply prompt", "interaction": "question sticker"}, + {"day": 5, "cta": "Office hours", "interaction": "template value stack"}, + {"day": 6, "cta": "Newsletter o DM", "interaction": "poll segmentation"}, + {"day": 7, "cta": "Workshop", "interaction": "dm or link cta"} + ] + }, + "mailerlite_supporting_asset": { + "purpose": "newsletter growth and workshop intent collection", + "copy_angle": "Historias diarias que generan replies, taps y conversiones sin depender solo del feed" + } + }, + "proof": { + "preview_urls": [ + "artifacts/MAX-511/preview.html" + ], + "screenshots": { + "rendered_html_preview_screenshot": "artifacts/MAX-511/rendered_html_preview_screenshot.png" + }, + "final_mp4_attachment": "artifacts/MAX-511/final_mp4_attachment.mp4", + "linear_attached_visual_proof": "artifacts/MAX-511/rendered_html_preview_screenshot.png", + "pr_url": "https://github.com/maxtechera/orchestrator/pull/22" + } +} diff --git a/artifacts/MAX-511/preview.html b/artifacts/MAX-511/preview.html new file mode 100644 index 0000000..451bdc0 --- /dev/null +++ b/artifacts/MAX-511/preview.html @@ -0,0 +1,181 @@ + + + + + + MAX-511 | Story engagement pack + + + +
+
+
+
+ MAX-511 + Instagram Stories + Spanish-first + Manual posting friendly +
+

Paquete de stories de 7 días para crecer newsletter y workshop

+

Secuencia diaria pensada para generar replies, taps y conversiones. El sistema mezcla hooks de dolor, mini frameworks, prueba social y CTAs claros hacia newsletter, office hours y workshop.

+
+ 7 días + 31 frames + 4 días con DM/reply prompt + 1 tracking sheet ligero +
+
+
+

Mapa de intención

+ + + + + + + + + + + +
DíaObjetivoCTA
1Dolor + conversaciónDM `STORIES`
2Educación + capturaNewsletter
3Prueba socialWorkshop waitlist
4Behind the scenesReply prompt
5Plantilla accionableOffice hours
6SegmentaciónNewsletter o DM
7Cierre + conversiónWorkshop
+
+
+ +
+

Día 1

Diagnóstico de dolor, CTA a DM
+
Frame 1
Tu contenido no falla por falta de ideas, falla por falta de sistema diario.
+
Frame 2
Los que crecen convierten stories en hábito, no en inspiración.
+
Frame 3
Poll: ¿Tus stories venden o solo mantienen presencia?Sticker: Poll
+
Frame 4
Respóndeme `STORIES` y te mando la estructura simple.CTA: DM
+
+ +

Día 2

Mini framework, CTA a newsletter
+
Frame 1
Una buena story capta atención, abre interacción y mueve a una acción.
+
Frame 2
Hook + prueba + pregunta + CTA.
+
Frame 3
No necesitas diseño complejo. Necesitas una secuencia repetible.
+
Frame 4
Si quieres más frameworks así cada semana, entra a la newsletter.CTA: Newsletter
+
+ +

Día 3

Prueba social, CTA a workshop
+
Frame 1
Una story bien armada suma conversaciones, no solo views.
+
Frame 2
Más replies = más señales reales de intención.
+
Frame 3
Question: ¿Qué te cuesta más hoy, ideas, consistencia o convertir?Sticker: Question
+
Frame 4
Si quieres entrar primero al próximo workshop, súmate a la lista.CTA: Workshop
+
+ +

Día 4

Behind the scenes, CTA a respuesta
+
Frame 1
Así pienso una story antes de publicarla.
+
Frame 2
1. ¿Qué fricción real siente la audiencia hoy?
+
Frame 3
2. ¿Qué micro-prueba puedo mostrar en 1 pantalla?
+
Frame 4
3. ¿Qué acción mínima quiero que hagan ahora?
+
Frame 5
¿Quieres que mañana te muestre la plantilla exacta?Sticker: Question / CTA: Reply
+
+ +

Día 5

Plantilla lista para usar, CTA a office hours
+
Frame 1
Plantilla rápida para hoy.
+
Frame 2
Hook: “Si tu contenido no convierte, probablemente no es por alcance.”
+
Frame 3
Prueba: comparte un mini insight o resultado.
+
Frame 4
Pregunta: “¿Quieres que suba más ejemplos como este?”
+
Frame 5
Si quieres que revisemos tu caso en vivo, súmate a office hours.CTA: Office hours
+
+ +

Día 6

Segmentación de intención, CTA dual
+
Frame 1
No toda tu audiencia está lista para comprar, pero sí puede darte una señal.
+
Frame 2
Las stories separan curiosidad, interés e intención.
+
Frame 3
Poll: ¿Qué te serviría más esta semana?Sticker: Más ideas / Más conversión
+
Frame 4
Si eliges ideas, newsletter. Si eliges conversión, escríbeme DM.CTA: Newsletter o DM
+
+ +

Día 7

Cierre de semana, CTA a workshop
+
Frame 1
Las stories no son relleno. Son un canal diario de demanda.
+
Frame 2
Pueden generar taps, replies y conversiones sin depender solo del feed.
+
Frame 3
La clave no es subir más. Es repetir una secuencia que empuje acción.
+
Frame 4
Si quieres construir ese sistema conmigo, únete al workshop.CTA: Workshop
+
+
+ +
+
+

Tracking sheet

+

Incluye columnas para story views, taps, exits, replies, DMs y conversiones hacia newsletter, workshop y office hours.

+

Archivo: tracking-sheet.csv

+
+
+

Condición de verificación

+

AC-1 cubierto con plan frame por frame para 7 días. AC-2 cubierto con prompts de reply/DM en los días 1, 4, 6 y 7.

+
+
+
+ + diff --git a/artifacts/MAX-511/proof-pack.md b/artifacts/MAX-511/proof-pack.md new file mode 100644 index 0000000..3d07a4d --- /dev/null +++ b/artifacts/MAX-511/proof-pack.md @@ -0,0 +1,19 @@ +# MAX-511, proof pack + +## Ticket intent +Build a 7-day Instagram Stories engagement pack, Spanish-first, that can be posted manually and drive newsletter + workshop intent. + +## Files +- `story-pack.md`, frame-by-frame 7-day story plan with CTA map +- `tracking-sheet.csv`, lightweight tracking sheet for taps, replies, and conversions +- `preview.html`, visual board showing the full weekly pack +- `rendered_html_preview_screenshot.png`, screenshot proof of rendered preview +- `final_mp4_attachment.mp4`, vertical motion preview of the full story pack +- `package.json`, machine-readable asset manifest + +## Verification mapping +- **AC-1**: every day includes 3 to 5 frames and a CTA in `story-pack.md` +- **AC-2**: reply / DM prompts appear on days 1, 4, 6, and 7 + +## Publishing note +Built for `maxtechera/orchestrator` with `mailerlite` as the target system context for newsletter capture. diff --git a/artifacts/MAX-511/rendered_html_preview_screenshot.png b/artifacts/MAX-511/rendered_html_preview_screenshot.png new file mode 100644 index 0000000..9d36eba Binary files /dev/null and b/artifacts/MAX-511/rendered_html_preview_screenshot.png differ diff --git a/artifacts/MAX-511/slide-01.png b/artifacts/MAX-511/slide-01.png new file mode 100644 index 0000000..56a01ce Binary files /dev/null and b/artifacts/MAX-511/slide-01.png differ diff --git a/artifacts/MAX-511/slide-02.png b/artifacts/MAX-511/slide-02.png new file mode 100644 index 0000000..f8baabc Binary files /dev/null and b/artifacts/MAX-511/slide-02.png differ diff --git a/artifacts/MAX-511/slide-03.png b/artifacts/MAX-511/slide-03.png new file mode 100644 index 0000000..c14e9a5 Binary files /dev/null and b/artifacts/MAX-511/slide-03.png differ diff --git a/artifacts/MAX-511/slide-04.png b/artifacts/MAX-511/slide-04.png new file mode 100644 index 0000000..c13b434 Binary files /dev/null and b/artifacts/MAX-511/slide-04.png differ diff --git a/artifacts/MAX-511/slide-05.png b/artifacts/MAX-511/slide-05.png new file mode 100644 index 0000000..f9d8a87 Binary files /dev/null and b/artifacts/MAX-511/slide-05.png differ diff --git a/artifacts/MAX-511/slide-06.png b/artifacts/MAX-511/slide-06.png new file mode 100644 index 0000000..7249009 Binary files /dev/null and b/artifacts/MAX-511/slide-06.png differ diff --git a/artifacts/MAX-511/slide-07.png b/artifacts/MAX-511/slide-07.png new file mode 100644 index 0000000..79f2238 Binary files /dev/null and b/artifacts/MAX-511/slide-07.png differ diff --git a/artifacts/MAX-511/story-pack.md b/artifacts/MAX-511/story-pack.md new file mode 100644 index 0000000..8c7355f --- /dev/null +++ b/artifacts/MAX-511/story-pack.md @@ -0,0 +1,173 @@ +# MAX-511, paquete de stories de 7 días para newsletter + workshop + +## Objetivo +Activar Instagram Stories como canal diario de demanda para crecer la newsletter y empujar intención hacia workshop, office hours y respuestas por DM. + +## Audiencia +Personas que siguen a Max-techera por IA aplicada, automatización, agent workflows y crecimiento práctico. + +## Reglas del pack +- Español primero, lenguaje directo y fácil de postear manualmente. +- 3 a 5 frames por día. +- Cada día cierra con CTA claro. +- Mínimo 3 días con sticker de respuesta o DM. + +--- + +## Día 1, detectar dolor y abrir conversación +**CTA principal:** Responder por DM con `STORIES` + +### Frame 1 +- **Visual:** Fondo simple, texto grande. +- **Copy:** `Tu contenido no está fallando por falta de ideas. Está fallando por falta de sistema diario.` + +### Frame 2 +- **Copy:** `La mayoría publica cuando tiene energía. Los que crecen convierten historias en hábito.` + +### Frame 3 +- **Sticker:** Poll +- **Pregunta:** `¿Hoy tus stories venden algo o solo mantienen presencia?` +- **Opciones:** `Venden` / `Solo presencia` + +### Frame 4 +- **Copy:** `Si quieres mi estructura simple de stories para generar replies y clicks, respóndeme: STORIES` +- **CTA:** DM reply prompt + +--- + +## Día 2, educar con mini-framework +**CTA principal:** Newsletter + +### Frame 1 +- **Copy:** `Una buena story diaria hace 3 cosas: capta atención, abre interacción, mueve a una acción.` + +### Frame 2 +- **Copy:** `Formato base: hook + prueba + pregunta + CTA.` + +### Frame 3 +- **Copy:** `No necesitas diseño complejo. Necesitas una secuencia repetible.` + +### Frame 4 +- **Sticker:** Link mention / CTA text +- **Copy:** `Si quieres recibir más frameworks así cada semana, entra a la newsletter.` +- **CTA:** Newsletter signup + +--- + +## Día 3, prueba social y workshop intent +**CTA principal:** Workshop waitlist + +### Frame 1 +- **Copy:** `Cuando una story está bien armada, no solo suma views. Suma conversaciones.` + +### Frame 2 +- **Copy:** `Más replies = más señales reales de intención que un like perdido en el feed.` + +### Frame 3 +- **Sticker:** Question +- **Pregunta:** `¿Qué te cuesta más hoy: ideas, consistencia o convertir?` + +### Frame 4 +- **Copy:** `Estoy armando el próximo workshop sobre contenido que convierte con sistemas. Si quieres info primero, entra en la lista.` +- **CTA:** Workshop signup + +--- + +## Día 4, behind the scenes +**CTA principal:** Reply prompt + +### Frame 1 +- **Copy:** `Behind the scenes: así pienso una story antes de publicarla.` + +### Frame 2 +- **Copy:** `1. ¿Qué fricción real siente la audiencia hoy?` + +### Frame 3 +- **Copy:** `2. ¿Qué micro-prueba puedo mostrar en 1 pantalla?` + +### Frame 4 +- **Copy:** `3. ¿Qué acción mínima quiero que hagan ahora?` + +### Frame 5 +- **Sticker:** Question +- **Pregunta:** `Si quieres, mañana te muestro una plantilla exacta. ¿Te la mando?` +- **CTA:** Reply prompt + +--- + +## Día 5, plantilla utilizable +**CTA principal:** Office hours + +### Frame 1 +- **Copy:** `Plantilla rápida para hoy:` + +### Frame 2 +- **Copy:** `Hook: “Si tu contenido no convierte, probablemente no es por alcance.”` + +### Frame 3 +- **Copy:** `Prueba: comparte un mini insight, ejemplo o resultado.` + +### Frame 4 +- **Copy:** `Pregunta: “¿Quieres que suba más ejemplos como este?”` + +### Frame 5 +- **Copy:** `Si quieres que revisemos tu caso en vivo, súmate a office hours.` +- **CTA:** Office hours signup + +--- + +## Día 6, segmentar intención +**CTA principal:** Newsletter + DM + +### Frame 1 +- **Copy:** `No toda tu audiencia está lista para comprar, pero sí puede darte una señal.` + +### Frame 2 +- **Copy:** `Las stories sirven para separar curiosidad, interés e intención.` + +### Frame 3 +- **Sticker:** Poll +- **Pregunta:** `¿Qué te serviría más esta semana?` +- **Opciones:** `Más ideas` / `Más conversión` + +### Frame 4 +- **Copy:** `Si eliges ideas, newsletter. Si eliges conversión, escríbeme DM y veo tu caso.` +- **CTA:** Split CTA + +--- + +## Día 7, cierre de semana y conversión +**CTA principal:** Workshop + +### Frame 1 +- **Copy:** `Resumen de la semana: las stories no son relleno. Son un canal diario de demanda.` + +### Frame 2 +- **Copy:** `Si publicas con intención, puedes generar taps, replies y conversiones sin depender solo del feed.` + +### Frame 3 +- **Copy:** `La clave no es subir más. Es repetir una secuencia que empuje acción.` + +### Frame 4 +- **Sticker:** DM / link CTA text +- **Copy:** `Si quieres construir ese sistema conmigo, únete al workshop.` +- **CTA:** Workshop signup + +--- + +## CTA map por día +| Día | Objetivo | Sticker / interacción | CTA final | +| --- | --- | --- | --- | +| 1 | Diagnóstico de dolor | Poll + DM | Responder `STORIES` | +| 2 | Educación + captura | Ninguno / link CTA | Newsletter | +| 3 | Detectar fricción | Question | Workshop waitlist | +| 4 | BTS + conversación | Question | Reply prompt | +| 5 | Valor accionable | Ninguno | Office hours | +| 6 | Segmentación | Poll | Newsletter o DM | +| 7 | Cierre y conversión | DM / link CTA | Workshop | + +## Días con reply / DM prompt +- Día 1 +- Día 4 +- Día 6 +- Día 7 diff --git a/artifacts/MAX-511/tracking-sheet.csv b/artifacts/MAX-511/tracking-sheet.csv new file mode 100644 index 0000000..185eae7 --- /dev/null +++ b/artifacts/MAX-511/tracking-sheet.csv @@ -0,0 +1,8 @@ +day,date,goal,primary_cta,sticker_type,story_views,forward_taps,back_taps,exits,replies,dm_starts,link_clicks,newsletter_signups,workshop_signups,office_hours_signups,notes +1,,Diagnóstico de dolor,DM STORIES,Poll,,,,,,,,,,, +2,,Educación + captura,Newsletter,None,,,,,,,,,,, +3,,Prueba social + workshop,Workshop waitlist,Question,,,,,,,,,,, +4,,Behind the scenes + replies,Reply prompt,Question,,,,,,,,,,, +5,,Valor accionable + office hours,Office hours,None,,,,,,,,,,, +6,,Segmentación de intención,Newsletter o DM,Poll,,,,,,,,,,, +7,,Cierre + conversión,Workshop,DM / link CTA,,,,,,,,,,, diff --git a/artifacts/MAX-527/final_mp4_attachment.mp4 b/artifacts/MAX-527/final_mp4_attachment.mp4 new file mode 100644 index 0000000..68f2d97 Binary files /dev/null and b/artifacts/MAX-527/final_mp4_attachment.mp4 differ diff --git a/artifacts/MAX-527/linear_attached_visual_proof.png b/artifacts/MAX-527/linear_attached_visual_proof.png new file mode 100644 index 0000000..7779b9e Binary files /dev/null and b/artifacts/MAX-527/linear_attached_visual_proof.png differ diff --git a/artifacts/MAX-527/package.json b/artifacts/MAX-527/package.json new file mode 100644 index 0000000..b3f56fb --- /dev/null +++ b/artifacts/MAX-527/package.json @@ -0,0 +1,47 @@ +{ + "ticket_id": "MAX-527", + "content_type": "content_asset", + "target_repo": "maxtechera/orchestrator", + "brand": "max-techera", + "locale": "en", + "placements": { + "instagram_reel": { + "concept": "before-after running ship-engine vs no pipeline", + "duration_seconds": 30, + "hook_primary": "Before ship-engine, launch lived in my tabs. After ship-engine, it lived in a pipeline.", + "hook_alternates": [ + "The difference between shipping content and thinking about shipping content.", + "Most launch chaos is just work with no system around it." + ], + "cta": { + "primary": "Subscribe to NODO", + "secondary": "Comment SHIP for the repo walkthrough" + }, + "script_path": "content/reels/MAX-527-ship-launch-content.md", + "caption": "Before ship-engine, launch content lived across tabs, drafts, and half-finished follow-ups. After ship-engine, the workflow became visible: brief, script, asset, publish, follow-up. Subscribe to NODO for more proof-first AI operator systems. Comment SHIP if you want the walkthrough.", + "media": { + "final_mp4_attachment": "artifacts/MAX-527/final_mp4_attachment.mp4", + "linear_attached_visual_proof": "artifacts/MAX-527/linear_attached_visual_proof.png", + "thumbnail": "proof/MAX-527/max527-thumb.png" + } + }, + "x_thread": { + "posts": [ + "Before ship-engine, launch content lived in scattered tabs, drafts, and mental overhead.", + "After ship-engine, the flow became visible: brief -> script -> asset -> publish -> follow-up.", + "Most teams do not actually have a content problem. They have a handoff problem.", + "When every step depends on memory, DMs, and context switching, shipping slows down even if the ideas are good.", + "A pipeline fixes that. The win is not more output. The win is repeatable throughput.", + "If you want more proof-first AI operator systems, subscribe to NODO. If you want the walkthrough, reply SHIP." + ], + "cta": { + "primary": "Subscribe to NODO", + "secondary": "Reply SHIP" + } + } + }, + "proof": { + "linear_attached_visual_proof": "artifacts/MAX-527/linear_attached_visual_proof.png", + "final_mp4_attachment": "artifacts/MAX-527/final_mp4_attachment.mp4" + } +} diff --git a/artifacts/MAX-527/proof-pack.md b/artifacts/MAX-527/proof-pack.md new file mode 100644 index 0000000..2dd380d --- /dev/null +++ b/artifacts/MAX-527/proof-pack.md @@ -0,0 +1,19 @@ +# MAX-527 proof pack + +## Scope +- Ticket: MAX-527 +- Target repo: maxtechera/orchestrator +- Deliverable: Instagram reel + X thread launch content +- Required CTA: Subscribe to NODO + +## What shipped in repo +- Reel/X thread source copy: `content/reels/MAX-527-ship-launch-content.md` +- Machine-readable package: `artifacts/MAX-527/package.json` +- Linear visual proof: `artifacts/MAX-527/linear_attached_visual_proof.png` +- Final MP4 attachment: `artifacts/MAX-527/final_mp4_attachment.mp4` +- Thumbnail: `proof/MAX-527/max527-thumb.png` + +## Notes +- The reel angle follows the ticket strategy: before/after, running ship-engine vs no pipeline. +- Both reel and thread include the NODO subscribe CTA. +- The CTA frame is intentionally usable as Linear attachment proof. diff --git a/artifacts/MAX-527/slide1.png b/artifacts/MAX-527/slide1.png new file mode 100644 index 0000000..696ec92 Binary files /dev/null and b/artifacts/MAX-527/slide1.png differ diff --git a/artifacts/MAX-527/slide2.png b/artifacts/MAX-527/slide2.png new file mode 100644 index 0000000..46ffdd2 Binary files /dev/null and b/artifacts/MAX-527/slide2.png differ diff --git a/artifacts/MAX-527/slide3.png b/artifacts/MAX-527/slide3.png new file mode 100644 index 0000000..09e74e0 Binary files /dev/null and b/artifacts/MAX-527/slide3.png differ diff --git a/artifacts/MAX-527/slide4.png b/artifacts/MAX-527/slide4.png new file mode 100644 index 0000000..7702639 Binary files /dev/null and b/artifacts/MAX-527/slide4.png differ diff --git a/artifacts/MAX-530/final_mp4_attachment.mp4 b/artifacts/MAX-530/final_mp4_attachment.mp4 new file mode 100644 index 0000000..bff0c12 Binary files /dev/null and b/artifacts/MAX-530/final_mp4_attachment.mp4 differ diff --git a/artifacts/MAX-530/package.json b/artifacts/MAX-530/package.json new file mode 100644 index 0000000..c526230 --- /dev/null +++ b/artifacts/MAX-530/package.json @@ -0,0 +1,80 @@ +{ + "ticket_id": "MAX-530", + "content_type": "social-pack", + "target_repo": "maxtechera/orchestrator", + "brand": "max-techera", + "locale": "en", + "placements": { + "instagram_reel": { + "text": "We broke prod, then turned the postmortem into five operating rules for AI teams.\n\n1. No direct prod writes from autonomous flows.\n2. Human approval for risky actions.\n3. Proof before status changes.\n4. Rollback paths before confidence.\n5. Short feedback loops over blind autonomy.\n\nIf you want more operator systems built from real incidents, subscribe to NODO. Reply RULES if you want the checklist.", + "cta": { + "action": "Subscribe to NODO", + "reason_for_now": "because most AI teams need operating rules before they need more prompts" + }, + "hashtags": [ + "#aiops", + "#postmortem", + "#buildinpublic", + "#aiagents", + "#devops", + "#nodo", + "#operators", + "#workflow" + ], + "media": { + "mp4": "artifacts/MAX-530/final_mp4_attachment.mp4", + "thumbnail": "artifacts/MAX-530/reel-cover.png" + }, + "hook_variants": [ + "We broke prod, then wrote 5 rules every AI team should have.", + "The incident was painful. The rules that came out of it are now non-negotiable.", + "If AI is touching prod, you need rules before you need more prompts." + ], + "secondary_cta": { + "action": "Reply RULES", + "reason_for_now": "to get the operator checklist version of the postmortem" + } + }, + "x_thread": { + "tweets": [ + { + "text": "We broke prod, and the useful outcome was not the incident itself. It was the five operating rules we wrote immediately after." + }, + { + "text": "Rule 1: no direct prod writes from autonomous flows. If the action is live and reversible costs are high, the system should stop short." + }, + { + "text": "Rule 2: risky actions need a human approval step. Not because humans are perfect, but because irreversible mistakes compound fast." + }, + { + "text": "Rule 3: proof before status changes. Do not mark work done, reviewed, or shipped until the artifact and the evidence actually exist." + }, + { + "text": "Rule 4: every critical path needs a rollback. Confidence is not a rollback plan." + }, + { + "text": "Rule 5: optimize for short feedback loops, not blind autonomy. Faster verification beats bigger cleanup." + }, + { + "text": "If you are building with AI in live systems, these rules are worth stealing. Subscribe to NODO for more operator workflows built from real incidents. Reply RULES if you want the checklist." + } + ], + "cta": { + "action": "Subscribe to NODO", + "reason_for_now": "to steal the operating system before your own avoidable incident writes it for you" + } + } + }, + "proof": { + "pr_url": "https://github.com/maxtechera/orchestrator/pull/28", + "preview_urls": [ + "artifacts/MAX-530/preview.html", + "artifacts/MAX-530/rendered-markdown.html" + ], + "screenshots": { + "rendered_html_screenshot": "artifacts/MAX-530/rendered_html_screenshot.png", + "rendered_html_preview_screenshot": "artifacts/MAX-530/rendered_html_preview_screenshot.png" + }, + "final_mp4_attachment": "artifacts/MAX-530/final_mp4_attachment.mp4" + } +} diff --git a/artifacts/MAX-530/preview.html b/artifacts/MAX-530/preview.html new file mode 100644 index 0000000..f7336dc --- /dev/null +++ b/artifacts/MAX-530/preview.html @@ -0,0 +1,35 @@ +
MAX-530 · Incident-led launch content

We broke prod, then wrote the 5 rules every AI team should have before touching live systems.

Launch-ready content package for maxtechera, built around a credible postmortem angle instead of generic AI hype, with a NODO subscribe CTA.

Rule 1No direct prod writes
Rule 2Human approval for risky actions
Rule 3Proof before status
Rule 4Rollback paths first
Rule 5Short feedback loops
Instagram Reel
We broke prod, then turned the postmortem into five operating rules for AI teams. + +1. No direct prod writes from autonomous flows. +2. Human approval for risky actions. +3. Proof before status changes. +4. Rollback paths before confidence. +5. Short feedback loops over blind autonomy. + +If you want more operator systems built from real incidents, subscribe to NODO. Reply RULES if you want the checklist.
#aiops#postmortem#buildinpublic#aiagents#devops#nodo#operators#workflow
Subscribe to NODO
because most AI teams need operating rules before they need more prompts
X Thread
1. We broke prod, and the useful outcome was not the incident itself. It was the five operating rules we wrote immediately after.
2. Rule 1: no direct prod writes from autonomous flows. If the action is live and reversible costs are high, the system should stop short.
3. Rule 2: risky actions need a human approval step. Not because humans are perfect, but because irreversible mistakes compound fast.
4. Rule 3: proof before status changes. Do not mark work done, reviewed, or shipped until the artifact and the evidence actually exist.
5. Rule 4: every critical path needs a rollback. Confidence is not a rollback plan.
6. Rule 5: optimize for short feedback loops, not blind autonomy. Faster verification beats bigger cleanup.
7. If you are building with AI in live systems, these rules are worth stealing. Subscribe to NODO for more operator workflows built from real incidents. Reply RULES if you want the checklist.
Subscribe to NODO
to steal the operating system before your own avoidable incident writes it for you
\ No newline at end of file diff --git a/artifacts/MAX-530/proof-pack.md b/artifacts/MAX-530/proof-pack.md new file mode 100644 index 0000000..aa21586 --- /dev/null +++ b/artifacts/MAX-530/proof-pack.md @@ -0,0 +1,20 @@ +# MAX-530, incident-led launch content package + +## Ticket intent +Create launch-ready content for maxtechera's launch strategy, centered on the incident-led angle: the 5 rules an AI team needed after breaking prod. Deliver an Instagram reel, a companion X thread, and a NODO subscribe CTA. + +## Assets in this package +- `content/reels/MAX-530-launch-content.md`, source copy and production notes +- `package.json`, machine-readable placement package for Content Engine +- `preview.html`, rendered content board for IG reel + X thread +- `rendered-markdown.html`, proof render of this package +- `rendered_html_preview_screenshot.png`, browser screenshot of the preview board +- `rendered_html_screenshot.png`, browser screenshot of the markdown proof page +- `final_mp4_attachment.mp4`, short reel-style visual asset + +## Reel angle +The point is not that AI teams will never break prod. The point is that the serious teams turn the incident into rules: no direct prod writes, human approval for risky actions, proof before status changes, rollback paths, and short feedback loops. + +## CTA +Primary CTA: subscribe to **NODO** for weekly systems, operator workflows, and proof-first launch mechanics. +Secondary CTA: reply `RULES` for the checklist. diff --git a/artifacts/MAX-530/reel-cover.png b/artifacts/MAX-530/reel-cover.png new file mode 100644 index 0000000..9ce532b Binary files /dev/null and b/artifacts/MAX-530/reel-cover.png differ diff --git a/artifacts/MAX-530/render-assets.js b/artifacts/MAX-530/render-assets.js new file mode 100644 index 0000000..793a24d --- /dev/null +++ b/artifacts/MAX-530/render-assets.js @@ -0,0 +1,60 @@ +const { execSync } = require('child_process'); +const path = require('path'); + +const outDir = __dirname; +const env = { ...process.env, OMP_NUM_THREADS: '1', MAGICK_THREAD_LIMIT: '1' }; +const FONT = '/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf'; +const BOLD = '/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf'; + +function run(command) { + execSync(command, { stdio: 'inherit', env }); +} + +run(`convert -size 1440x1800 xc:'#07101b' \ + -fill '#0f172a' -draw 'roundrectangle 42,42 1398,1758 28,28' \ + -fill '#67e8f9' -font ${BOLD} -pointsize 28 -annotate +90+104 'MAX-530 INCIDENT-LED LAUNCH CONTENT' \ + -fill white -font ${BOLD} -pointsize 58 -annotate +90+180 'We broke prod, then wrote the 5 rules every AI team should have.' \ + -fill '#cbd5e1' -font ${FONT} -pointsize 30 -annotate +90+300 'Instagram Reel + X Thread + NODO CTA' \ + -fill '#e5eefc' -font ${FONT} -pointsize 34 -annotate +90+430 '1 No direct prod writes' \ + -annotate +90+500 '2 Human approval for risky actions' \ + -annotate +90+570 '3 Proof before status changes' \ + -annotate +90+640 '4 Rollback paths before confidence' \ + -annotate +90+710 '5 Short feedback loops over blind autonomy' \ + -fill '#67e8f9' -annotate +90+860 'CTA Subscribe to NODO' \ + -fill '#cbd5e1' -pointsize 30 -annotate +90+920 'Secondary CTA Reply RULES for the checklist' \ + -fill '#94a3b8' -pointsize 26 -annotate +90+1060 'Visual proof frame generated from package data' \ + ${path.join(outDir, 'rendered_html_preview_screenshot.png')}`); + +run(`convert -size 1440x1400 xc:'#08111f' \ + -fill '#0f172a' -draw 'roundrectangle 42,42 1398,1358 28,28' \ + -fill '#67e8f9' -font ${BOLD} -pointsize 28 -annotate +90+104 'MAX-530 PROOF PACK' \ + -fill white -font ${BOLD} -pointsize 52 -annotate +90+180 'Rendered markdown proof' \ + -fill '#dbeafe' -font ${FONT} -pointsize 30 -annotate +90+300 'Ticket intent: incident-led launch content after breaking prod' \ + -annotate +90+360 'Assets: source markdown, package.json, preview HTML, proof HTML, screenshots, mp4' \ + -fill '#67e8f9' -annotate +90+420 'CTA: Subscribe to NODO | Reply RULES' \ + -fill '#dbeafe' -annotate +90+480 'Reel angle: turn a painful incident into operating rules' \ + -fill '#94a3b8' -pointsize 28 -annotate +90+620 'This image stands in for the rendered markdown view for Linear proof.' \ + ${path.join(outDir, 'rendered_html_screenshot.png')}`); + +const slides = [ + ['slide-01.png', 'We broke prod', 'The useful output was not the incident. It was the operating rules we wrote after it.'], + ['slide-02.png', 'Rule 1 and 2', 'No direct prod writes. Human approval for risky actions.'], + ['slide-03.png', 'Rule 3 and 4', 'Proof before status changes. Rollback paths before confidence.'], + ['slide-04.png', 'Rule 5', 'Short feedback loops beat blind autonomy every time.'], + ['slide-05.png', 'Subscribe to NODO', 'Weekly operator workflows, proof-first systems, and launch mechanics from real incidents.'] +]; + +for (const [file, title, body] of slides) { + const lines = body.match(/.{1,34}(\s|$)/g).map(s => s.trim()).filter(Boolean); + let cmd = `convert -size 1080x1920 xc:'#07101b' -fill '#0f172a' -draw 'roundrectangle 54,54 1026,1866 28,28' -fill '#7f1d1d' -draw 'rectangle 54,54 1026,224' -fill '#67e8f9' -font ${FONT} -pointsize 26 -annotate +84+120 'MAX-530 incident-led launch content' -fill white -font ${BOLD} -pointsize 60 -annotate +84+240 '${title}' -fill '#dbeafe' -font ${FONT} -pointsize 34`; + let y = 430; + for (const line of lines) { + cmd += ` -annotate +84+${y} '${line.replace(/'/g, "\\'")}'`; + y += 60; + } + cmd += ` ${path.join(outDir, file)}`; + run(cmd); +} + +run(`ffmpeg -y -threads 1 -framerate 1 -i ${path.join(outDir, 'slide-%02d.png')} -vf "scale=1080:1920,format=yuv420p" -r 30 -c:v mpeg4 -q:v 5 ${path.join(outDir, 'final_mp4_attachment.mp4')}`); +run(`cp ${path.join(outDir, 'slide-01.png')} ${path.join(outDir, 'reel-cover.png')}`); diff --git a/artifacts/MAX-530/rendered-markdown.html b/artifacts/MAX-530/rendered-markdown.html new file mode 100644 index 0000000..aff0002 --- /dev/null +++ b/artifacts/MAX-530/rendered-markdown.html @@ -0,0 +1,47 @@ +
MAX-530 · Proof pack

Rendered markdown proof

Machine-readable package plus visual proof for the incident-led launch content.

# MAX-530, incident-led launch content package
+
+## Ticket intent
+Create launch-ready content for maxtechera's launch strategy, centered on the incident-led angle: the 5 rules an AI team needed after breaking prod. Deliver an Instagram reel, a companion X thread, and a NODO subscribe CTA.
+
+## Assets in this package
+- `content/reels/MAX-530-launch-content.md`, source copy and production notes
+- `package.json`, machine-readable placement package for Content Engine
+- `preview.html`, rendered content board for IG reel + X thread
+- `rendered-markdown.html`, proof render of this package
+- `rendered_html_preview_screenshot.png`, browser screenshot of the preview board
+- `rendered_html_screenshot.png`, browser screenshot of the markdown proof page
+- `final_mp4_attachment.mp4`, short reel-style visual asset
+
+## Reel angle
+The point is not that AI teams will never break prod. The point is that the serious teams turn the incident into rules: no direct prod writes, human approval for risky actions, proof before status changes, rollback paths, and short feedback loops.
+
+## CTA
+Primary CTA: subscribe to **NODO** for weekly systems, operator workflows, and proof-first launch mechanics.
+Secondary CTA: reply `RULES` for the checklist.
+
\ No newline at end of file diff --git a/artifacts/MAX-530/rendered_html_preview_screenshot.png b/artifacts/MAX-530/rendered_html_preview_screenshot.png new file mode 100644 index 0000000..3bf4ebc Binary files /dev/null and b/artifacts/MAX-530/rendered_html_preview_screenshot.png differ diff --git a/artifacts/MAX-530/rendered_html_screenshot.png b/artifacts/MAX-530/rendered_html_screenshot.png new file mode 100644 index 0000000..43a854d Binary files /dev/null and b/artifacts/MAX-530/rendered_html_screenshot.png differ diff --git a/artifacts/MAX-530/slide-01.png b/artifacts/MAX-530/slide-01.png new file mode 100644 index 0000000..9ce532b Binary files /dev/null and b/artifacts/MAX-530/slide-01.png differ diff --git a/artifacts/MAX-530/slide-02.png b/artifacts/MAX-530/slide-02.png new file mode 100644 index 0000000..923070b Binary files /dev/null and b/artifacts/MAX-530/slide-02.png differ diff --git a/artifacts/MAX-530/slide-03.png b/artifacts/MAX-530/slide-03.png new file mode 100644 index 0000000..4edead3 Binary files /dev/null and b/artifacts/MAX-530/slide-03.png differ diff --git a/artifacts/MAX-530/slide-04.png b/artifacts/MAX-530/slide-04.png new file mode 100644 index 0000000..a80a58d Binary files /dev/null and b/artifacts/MAX-530/slide-04.png differ diff --git a/artifacts/MAX-530/slide-05.png b/artifacts/MAX-530/slide-05.png new file mode 100644 index 0000000..253fd76 Binary files /dev/null and b/artifacts/MAX-530/slide-05.png differ diff --git a/artifacts/MAX-531/final-proof.mp4 b/artifacts/MAX-531/final-proof.mp4 new file mode 100644 index 0000000..f458e93 Binary files /dev/null and b/artifacts/MAX-531/final-proof.mp4 differ diff --git a/artifacts/MAX-531/rendered_github_markdown_screenshot.png b/artifacts/MAX-531/rendered_github_markdown_screenshot.png new file mode 100644 index 0000000..885ab64 Binary files /dev/null and b/artifacts/MAX-531/rendered_github_markdown_screenshot.png differ diff --git a/artifacts/MAX-531/rendered_html_screenshot.png b/artifacts/MAX-531/rendered_html_screenshot.png new file mode 100644 index 0000000..548d7c9 Binary files /dev/null and b/artifacts/MAX-531/rendered_html_screenshot.png differ diff --git a/artifacts/MAX-531/screenshot_desktop.png b/artifacts/MAX-531/screenshot_desktop.png new file mode 100644 index 0000000..9915fa7 Binary files /dev/null and b/artifacts/MAX-531/screenshot_desktop.png differ diff --git a/artifacts/MAX-531/screenshot_mobile.png b/artifacts/MAX-531/screenshot_mobile.png new file mode 100644 index 0000000..52f9b2d Binary files /dev/null and b/artifacts/MAX-531/screenshot_mobile.png differ diff --git a/artifacts/MAX-531/social-card.html b/artifacts/MAX-531/social-card.html new file mode 100644 index 0000000..d0ea043 --- /dev/null +++ b/artifacts/MAX-531/social-card.html @@ -0,0 +1,184 @@ + + + + + + orchestrator social card + + + +
+
+
+
+
+
maxtechera/orchestrator
+

Proof-driven AI-agent orchestration

+

Route ticket work to specialist agents, verify output independently, and only ship what actually passes.

+
+
+ Claude Code + OpenClaw + Linear + GitHub + No self-grading +
+
+
+
+
Why it gets adopted
+

3

+
clear ticket contracts, specialist execution, independent verification
+
+
+
Built for
+
    +
  • Agent workflow operatorsFaster shipping
    • +
  • Linear + GitHub teamsNative fit
    • +
  • Proof-first reviewsHigher trust
    • +
+
+
+
+
+ + diff --git a/artifacts/MAX-534/github-readme.html b/artifacts/MAX-534/github-readme.html new file mode 100644 index 0000000..1f208f4 --- /dev/null +++ b/artifacts/MAX-534/github-readme.html @@ -0,0 +1,52 @@ + + + + + + Rendered GitHub Markdown proof • MAX-534 + + + +
+

Memory marketplace optimization package

+

This proof render packages the final repo optimization assets for maxtechera/memory.

+ +

GitHub description

+

Durable memory for AI agents with Obsidian sync, session hooks, and recall flows.

+ +

Topics

+ + +

Install

+ 
## Install
+
+### Claude Code
+/plugin marketplace add maxtechera/memory
+
+### OpenClaw
+clawhub install memory
+
+### Manual
+git clone https://github.com/maxtechera/memory.git ~/.claude/skills/memory
+ +
+ Manifest verification: confirm .claude-plugin/plugin.json and .claude-plugin/marketplace.json stay aligned before submit. +
+
+ + diff --git a/artifacts/MAX-534/package.json b/artifacts/MAX-534/package.json new file mode 100644 index 0000000..3e2fe2c --- /dev/null +++ b/artifacts/MAX-534/package.json @@ -0,0 +1,48 @@ +{ + "ticket_id": "MAX-534", + "content_type": "marketplace-optimization-pack", + "target_repo": "maxtechera/orchestrator", + "brand": "max-techera", + "locale": "en", + "placements": { + "github_repo": { + "target_repo": "maxtechera/memory", + "description": "Durable memory for AI agents with Obsidian sync, session hooks, and recall flows.", + "description_length": 81, + "topics": [ + "memory", + "ai-agents", + "claude-code", + "obsidian", + "session-hooks", + "knowledge-management" + ], + "social_preview_card": "artifacts/MAX-534/social-preview-card.png" + }, + "claude_marketplace": { + "install_command": "/plugin marketplace add maxtechera/memory", + "manifest_files": [ + ".claude-plugin/plugin.json", + ".claude-plugin/marketplace.json" + ], + "install_test_status": "ready-to-run", + "readme_doc": "docs/memory-marketplace-package.md" + } + }, + "proof": { + "pr_url": "https://github.com/maxtechera/orchestrator/pull/27", + "preview_urls": [ + "artifacts/MAX-534/preview.html", + "artifacts/MAX-534/github-readme.html" + ], + "screenshots": { + "social_preview_card": "artifacts/MAX-534/social-preview-card.png", + "rendered_github_markdown_screenshot": "artifacts/MAX-534/rendered_github_markdown_screenshot.png", + "rendered_preview_screenshot": "artifacts/MAX-534/rendered_preview_screenshot.png" + }, + "docs": [ + "docs/memory-marketplace-package.md", + "artifacts/MAX-534/proof-pack.md" + ] + } +} diff --git a/artifacts/MAX-534/preview.html b/artifacts/MAX-534/preview.html new file mode 100644 index 0000000..27473eb --- /dev/null +++ b/artifacts/MAX-534/preview.html @@ -0,0 +1,64 @@ + + + + + + MAX-534 memory marketplace optimization pack + + + +
+
+
+
MAX-534 • Marketplace optimization
+

Memory repo packaging for Claude marketplace submission

+

Final GitHub description, topic set, install block, and social preview card for maxtechera/memory.

+
+
+

GitHub description

+

Durable memory for AI agents with Obsidian sync, session hooks, and recall flows.

+
81 characters, within the 150-character limit.
+
+
+

Install command

+
/plugin marketplace add maxtechera/memory
+
+
+
+ +
+
+ + diff --git a/artifacts/MAX-534/proof-pack.md b/artifacts/MAX-534/proof-pack.md new file mode 100644 index 0000000..3cbe74c --- /dev/null +++ b/artifacts/MAX-534/proof-pack.md @@ -0,0 +1,32 @@ +# MAX-534, memory marketplace optimization package + +## Ticket intent +Package the repo optimization assets needed to submit `maxtechera/memory` to the Claude marketplace: GitHub description, topics, social preview card, manifest check, install steps, and proof screenshots. + +## Assets in this package +- `package.json`, machine-readable package for the content/release system +- `preview.html`, review board for the final description, topics, and install CTA +- `github-readme.html`, rendered markdown proof surface +- `social-preview-card.png`, preview card ready for repo social image usage +- `rendered_preview_screenshot.png`, screenshot of the preview board +- `rendered_github_markdown_screenshot.png`, screenshot of the rendered README/install proof +- `docs/memory-marketplace-package.md`, execution-ready copy for the target repo + +## Final recommendation +Use the shorter description focused on the end result, not the implementation details: + +`Durable memory for AI agents with Obsidian sync, session hooks, and recall flows.` + +It stays under GitHub's description cap and keeps the differentiators that matter for marketplace discovery. + +## Topic set +`memory`, `ai-agents`, `claude-code`, `obsidian`, `session-hooks`, `knowledge-management` + +## Install proof target +The README block centers the marketplace install command first: + +```bash +/plugin marketplace add maxtechera/memory +``` + +That keeps the submission aligned with the Claude marketplace surface while still documenting OpenClaw and manual install fallbacks. diff --git a/artifacts/MAX-534/rendered_github_markdown_screenshot.png b/artifacts/MAX-534/rendered_github_markdown_screenshot.png new file mode 100644 index 0000000..8512ac3 Binary files /dev/null and b/artifacts/MAX-534/rendered_github_markdown_screenshot.png differ diff --git a/artifacts/MAX-534/rendered_preview_screenshot.png b/artifacts/MAX-534/rendered_preview_screenshot.png new file mode 100644 index 0000000..39a4efa Binary files /dev/null and b/artifacts/MAX-534/rendered_preview_screenshot.png differ diff --git a/artifacts/MAX-534/social-preview-card.html b/artifacts/MAX-534/social-preview-card.html new file mode 100644 index 0000000..1c872b2 --- /dev/null +++ b/artifacts/MAX-534/social-preview-card.html @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/artifacts/MAX-534/social-preview-card.png b/artifacts/MAX-534/social-preview-card.png new file mode 100644 index 0000000..f106ecd Binary files /dev/null and b/artifacts/MAX-534/social-preview-card.png differ diff --git a/artifacts/MAX-534/social-preview-card.svg b/artifacts/MAX-534/social-preview-card.svg new file mode 100644 index 0000000..31254e8 --- /dev/null +++ b/artifacts/MAX-534/social-preview-card.svg @@ -0,0 +1,28 @@ + + + + + + + + + + memory + Durable memory for AI agents + Obsidian sync, session hooks, and recall flows + + + Claude marketplace ready + + GitHub topics tuned + + README install block included + + + /plugin marketplace add maxtechera/memory + + + HOT + WARM + COLD + diff --git a/artifacts/MAX-542/build-waterfall-comment.md b/artifacts/MAX-542/build-waterfall-comment.md new file mode 100644 index 0000000..0f297cd --- /dev/null +++ b/artifacts/MAX-542/build-waterfall-comment.md @@ -0,0 +1,22 @@ +## Build Waterfall + +Completed Content Engine v2 parent waterfall for MAX-542. + +- PR: https://github.com/maxtechera/orchestrator/pull/32 +- Committed build.md path: `artifacts/MAX-542/build.md` +- Existing course outline path: `artifacts/MAX-542/course-outline-orchestrate-ai-agents.md` +- Existing proof pack path: `docs/proofs/MAX-542/` +- Deployed preview URL: https://github.com/maxtechera/orchestrator/tree/feat/MAX-542-content-waterfall-v2/artifacts/MAX-542 + +Validation: +```bash +python3 /data/workspace/tools/package-builder.py validate-md --input artifacts/MAX-542/build.md +# ✅ build.md valid + hashes fresh +``` + +Quality signals: +- artifact_delta: added canonical v2 `build.md` with Ingredients, Script, Storyboard, and Presentation for the Orchestrate AI Agents course offer. +- business_delta: course idea is now ready for Content Engine child placement spawning (landing + email) instead of legacy package/schema handling. +- surface_correctness: work is in `maxtechera/orchestrator` (not openclaw-config), PR #32, with Linear visual proof attachments included. + +Visual proof attached from `docs/proofs/MAX-542/`. diff --git a/artifacts/MAX-542/build.md b/artifacts/MAX-542/build.md new file mode 100644 index 0000000..893492e --- /dev/null +++ b/artifacts/MAX-542/build.md @@ -0,0 +1,120 @@ +--- +ticket: MAX-542 +brand: maxtechera +content_type: lead_magnet +created: "2026-05-08T14:18:29Z" +hashes: + ingredients: "sha256:93ba16cc39202957" + script: "sha256:62ea9f32dd800480" + storyboard: "sha256:cb2bea6dfbd09c75" + presentation: "sha256:8f541a43a307ce08" +placements: + - channel: landing + source: {script_beats: "all"} + - channel: email + source: {script_beats: "all"} +gamma_file_id: null +remotion_comp: null +--- + +## Ingredients +- hook: "Stop being the QA department for your own AI agents." +- cta: "Install the free Orchestrator workflow, run one verified ticket, then join the $197 Orchestrate AI Agents course for the full operating system." +- value_prop: "A practical course that turns scattered AI-agent prompting into a ticket-based delivery machine with external verification, visual proof, and human review only where it matters." +- offer: "$197 bilingual course (EN + ES) for operators, founders, and technical leads who want reliable AI-agent throughput across Linear, GitHub Issues, Notion, Jira, content, engineering, and ecommerce work." +- intro: "Most AI-agent failures are not model failures; they are system failures. Orchestrate AI Agents teaches the verification layer, lifecycle, board design, domain skills, and self-improving rules that make agent work inspectable and scalable." + +## Script +Beat 1 — Problem: Your AI agent can write, code, research, and draft. But if you still inspect every output manually, the agent did not remove work; it moved QA onto your plate. + +Beat 2 — Belief shift: Reliable agent operations do not come from better prompts alone. They come from separating execution from verification and forcing every ticket to produce proof. + +Beat 3 — Course promise: Orchestrate AI Agents teaches a practical operating system for running agents through scoped tickets, board states, verification criteria, domain skills, review gates, and continuous rule improvement. + +Beat 4 — Module 1: The Verification Problem. Students learn why AI self-grading fails, how hallucinated completion shows up, and why external artifacts beat agent confidence. + +Beat 5 — Module 2: Board Setup. Students build an agent-readable source of truth in Linear, GitHub Issues, Notion, or Jira with objective, delivery surface, proof, owner, and state fields. + +Beat 6 — Module 3: The 5-Stage Ticket Lifecycle. Students map work through Intake, Execute, Verify, Review, and Done so agents stop declaring victory before business intent and proof line up. + +Beat 7 — Module 4: Writing Verification Criteria. Students convert vague requests into observable checks: artifact delta, business delta, and surface correctness. + +Beat 8 — Module 5: Domain Skills. Students learn reusable execution patterns for content, engineering, ecommerce, and internal operations instead of rebuilding context from scratch every time. + +Beat 9 — Module 6: Self-Improving Rules. Every failure becomes a sharper instruction, verifier check, or routing rule so the system improves after mistakes instead of repeating them. + +Beat 10 — Module 7: Team Mode + Sweep Scheduling. Students coordinate specialist agents, verifier agents, and human reviewers across recurring sweeps without turning the founder into the bottleneck. + +Beat 11 — Funnel: The free GitHub Orchestrator install gives users their first verified ticket. The course CTA appears when they understand the gap: one workflow is useful, but domain depth is what makes the system durable. + +Beat 12 — CTA: Start with the free Orchestrator repo. After your first verified ticket, take Orchestrate AI Agents to build the full bilingual operating system for agent work. + +## Storyboard +```yaml +- n: 1 + t_start: 0.0 + duration_s: 6 + script: "If you still inspect every AI-agent output manually, you are the QA department." + visual: "Split screen: agent claims Done; human buried in review comments." + sfx: "low_hit" + motion: "slow_push_in" + broll: "GitHub issue and Linear review proof" + on_camera: false + slide_ref: 1 + emphasis: "hook" +- n: 2 + t_start: 6.0 + duration_s: 7 + script: "The fix is not just better prompting. It is a delivery system with external verification." + visual: "Simple diagram: Execute agent -> Verify agent -> Human review -> Done." + sfx: "whoosh_transition" + motion: "diagram_build" + broll: "auto" + on_camera: false + slide_ref: 2 + emphasis: "belief_shift" +- n: 3 + t_start: 13.0 + duration_s: 8 + script: "Orchestrate AI Agents teaches the operating system: tickets, proof, routing, review gates, and self-improving rules." + visual: "Course promise slide with five pillars." + sfx: "soft_rise" + motion: "pillar_reveal" + broll: "auto" + on_camera: false + slide_ref: 3 + emphasis: "promise" +- n: 4 + t_start: 21.0 + duration_s: 18 + script: "Modules cover the verification problem, board setup, the five-stage lifecycle, verification criteria, domain skills, self-improving rules, and team sweep scheduling." + visual: "Seven-module curriculum grid, EN/ES badges, $197 price anchor." + sfx: "click_sequence" + motion: "grid_reveal" + broll: "auto" + on_camera: false + slide_ref: 4 + emphasis: "curriculum" +- n: 5 + t_start: 39.0 + duration_s: 9 + script: "Start with the free GitHub repo. After your first verified ticket, take the course to build the full system." + visual: "Funnel: GitHub install -> first verified ticket -> course CTA." + sfx: "resolve_chime" + motion: "arrow_flow" + broll: "repo screen capture" + on_camera: false + slide_ref: 5 + emphasis: "cta" +``` + +## Presentation +Slide 1 — Hook: "Stop being the QA department for your own AI agents." Show agent output beside human review burden. + +Slide 2 — Core mechanism: External verification. Diagram the handoff from Execute to Verify to Review to Done. + +Slide 3 — Course promise: A ticket-based AI-agent operating system for founders, operators, and technical leads. + +Slide 4 — Curriculum: seven modules: verification problem; board setup; 5-stage lifecycle; verification criteria; domain skills; self-improving rules; team mode + sweep scheduling. + +Slide 5 — Offer and funnel: Free GitHub Orchestrator install -> first verified ticket -> $197 bilingual EN/ES course CTA. diff --git a/artifacts/MAX-542/course-outline-orchestrate-ai-agents.md b/artifacts/MAX-542/course-outline-orchestrate-ai-agents.md new file mode 100644 index 0000000..3db88a4 --- /dev/null +++ b/artifacts/MAX-542/course-outline-orchestrate-ai-agents.md @@ -0,0 +1,337 @@ +# MAX-542 Course Outline + +Offer stack: `/orchestrator` +Course title EN: **Orchestrate AI Agents** +Course title ES: **Orquesta tus Agentes IA** +Price: **$197** +Tagline EN: **Stop being the QA department for your own AI agents** +Tagline ES: **Deja de ser el QA de tus propios agentes** + +## Course promise + +This course teaches operators, founders, and technical leads how to run AI agents with a real delivery system instead of vibe-based prompting. Students learn to define tickets, separate execution from verification, route work across the tools they already use, and review outputs with clear operational controls. + +The core transformation: students stop personally QA-ing every agent output and start operating an inspectable delivery system where agents produce proof, verifiers check claims, and humans only step in for judgment calls. + +## Ideal student + +- Builders already using AI agents but frustrated by inconsistent delivery +- Operators managing recurring work across content, engineering, e-commerce, and internal ops +- Founders who want leverage without becoming the bottleneck reviewer for every output +- Teams moving from single-chat prompting to durable, ticket-based execution + +## Before / after transformation + +### Before +- Agents do work, but quality varies wildly +- The human becomes the final QA layer every time +- Tasks get redone because context is missing or unverifiable +- Tool sprawl creates confusion instead of throughput +- "Done" means the agent said it was done + +### After +- Agents execute against scoped tickets with explicit verification criteria +- Work moves through a repeatable lifecycle instead of ad hoc prompting +- The human reviews exceptions, not everything +- AI labor becomes inspectable, auditable, and easier to scale +- "Done" means business intent and proof align + +## Course outcomes + +By the end of the course, students will be able to: + +1. Explain why AI self-grading fails without independent verification. +2. Set up a practical work board in Linear, GitHub Issues, Notion, or Jira. +3. Run agent work through a 5-stage lifecycle: Intake → Execute → Verify → Review → Done. +4. Write verification criteria that reduce ambiguity, rework, and reviewer load. +5. Design domain-specific agent workflows for content, engineering, and e-commerce. +6. Turn repeated failures into durable rules, templates, and acceptance checks. +7. Operate team-mode agent workflows with sweep scheduling and escalation rules. + +## Course structure + +- **7 modules** aligned to the `/orchestrator` operating model +- **28 core lessons** plus exercises and templates +- **Format:** short video lessons, worksheets, board templates, verification checklists, and cloneable `/orchestrator` examples +- **Languages:** English course with Spanish adaptation track using the same operational skeleton + +--- + +## Module 1. The verification problem — why AI self-grading fails + +**Goal:** Show why prompting alone does not create reliable operations. + +### Lessons +1. Why capable agents still produce low-trust output +2. The trap of AI self-grading and circular confidence +3. Failure modes: hallucinated completion, false confidence, shallow checks, and hidden regressions +4. Why external artifacts beat agent claims + +### Takeaways +- Reliability comes from system design, not model optimism +- Verification must be separated from execution +- Trust increases when work produces inspectable proof + +### Exercise +Audit one recent agent-delivered task and identify where execution and verification were mixed together. + +### Deliverable +A short failure map showing: request, agent claim, actual proof, missing verification, and reviewer burden. + +--- + +## Module 2. Board setup — Linear, GitHub Issues, Notion, Jira + +**Goal:** Give students a practical substrate for routing agent work. + +### Lessons +1. What makes a board usable for AI operations +2. Choosing between Linear, GitHub Issues, Notion, and Jira +3. Required ticket fields: objective, surface, proof, owner, state, blocker, and acceptance criteria +4. Designing a board that humans and agents can both understand + +### Recommended board fields +- **Objective:** what business outcome the ticket serves +- **Surface:** repo, page, doc, channel, dashboard, campaign, or workflow being changed +- **Inputs:** links, files, constraints, source material +- **Deliverable:** what must be created or changed +- **Proof required:** screenshots, tests, diffs, URLs, metrics, or rendered artifacts +- **Owner:** human or agent responsible for the current state +- **State:** Intake, Execute, Verify, Review, Done + +### Takeaways +- The board is the source of truth for agent work +- Clean ticket structure lowers coordination cost +- Good fields prevent hidden assumptions during execution + +### Exercise +Create a reusable ticket template in the student’s preferred system with objective, proof requirements, owner, delivery surface, and acceptance criteria. + +### Deliverable +A working AI-agent ticket template for Linear, GitHub Issues, Notion, or Jira. + +--- + +## Module 3. The 5-stage ticket lifecycle — Intake → Execute → Verify → Review → Done + +**Goal:** Teach the operating model that makes agent work reviewable. + +### Lifecycle +1. **Intake:** clarify the business request, target surface, constraints, and proof requirements +2. **Execute:** produce the artifact, implementation, or campaign output +3. **Verify:** independently check the claimed result against observable criteria +4. **Review:** human or designated approver inspects exceptions, taste calls, and tradeoffs +5. **Done:** close only when business intent and proof align + +### Lessons +1. What belongs in each stage and what does not +2. Hand-offs between executor, verifier, reviewer, and owner +3. State transitions that reduce ambiguity +4. Common anti-patterns, including premature Done, vague Review, and skipped Verify states + +### Takeaways +- A ticket lifecycle is an operational control layer +- Verification deserves its own explicit stage +- Review is faster when upstream proof is consistent + +### Exercise +Map one existing team workflow into the 5-stage model and note what is missing. + +### Deliverable +A lifecycle map for one real recurring workflow, including owner, input, output, proof, and escalation at each stage. + +--- + +## Module 4. Writing verification criteria — automated checks vs AI quality checks + +**Goal:** Help students create checks that agents can execute and humans can trust. + +### Lessons +1. The anatomy of strong verification criteria +2. Automated checks: tests, lint, typecheck, build, links, schema validation, and visual regression +3. AI quality checks: rubric scoring, completeness review, tone review, strategy review, and contradiction checks +4. Converting vague requests into testable completion standards +5. Examples for content, code, operations, and research tasks + +### Verification framework +For each ticket, define: +- **Artifact delta:** what changed, created, or shipped +- **Business delta:** why the change matters or what outcome it enables +- **Surface correctness:** how we know it landed in the right place and format +- **Automated gate:** the smallest reliable machine-checkable proof +- **Quality gate:** the rubric or judgment criteria for non-deterministic work +- **Human gate:** the point where taste, risk, or authority requires human approval + +### Takeaways +- Verification criteria should be observable, not interpretive +- Strong proof reduces reviewer load dramatically +- Automated checks and AI quality checks solve different problems +- The ticket should tell the verifier what “done” actually means + +### Exercise +Rewrite three vague requests into tickets with explicit verification criteria and required proof. + +### Deliverable +Three before/after ticket rewrites with artifact proof, automated checks, AI quality checks, and human approval rules. + +--- + +## Module 5. Domain skills — content, engineering, e-commerce + +**Goal:** Show students how to adapt the same orchestration system to different business domains. + +### Lessons +1. Why domain skills matter: agents need operating context, not just instructions +2. Content workflows: brief → draft → edit → package → publish proof +3. Engineering workflows: ticket → implementation → tests → PR → review proof +4. E-commerce workflows: product update → listing QA → pricing/checkouts → publish proof +5. How to write reusable domain rules without overfitting to one task + +### Domain examples + +#### Content +- Inputs: angle, audience, offer, channel, brand voice +- Proof: final asset, platform preview, hook variants, CTA alignment, publish checklist + +#### Engineering +- Inputs: issue, repo surface, constraints, expected behavior +- Proof: diff, tests, lint/typecheck/build, screenshots, PR link + +#### E-commerce +- Inputs: SKU/product, price, inventory, listing copy, images, marketplace rules +- Proof: listing preview, price verification, checkout path, image compliance, publish URL + +### Takeaways +- The lifecycle stays stable while domain criteria change +- Reusable skills reduce repeated instruction overhead +- Domain-specific verification is what makes agent output operationally useful + +### Exercise +Choose one domain and create a skill card with inputs, outputs, proof requirements, failure modes, and escalation triggers. + +### Deliverable +One reusable domain skill card for content, engineering, or e-commerce. + +--- + +## Module 6. Self-improving rules — every failure becomes a rule + +**Goal:** Teach students how to convert agent mistakes into durable operating improvements. + +### Lessons +1. The failure-capture loop: incident → cause → rule → template update → next run +2. How to distinguish one-off mistakes from systemic rules +3. Writing rules that agents can actually follow +4. Updating ticket templates, verification checklists, and domain skills after failures +5. Avoiding rule bloat and contradictory instructions + +### Rule improvement loop +1. Capture the failed ticket and the exact failure mode +2. Identify whether the failure came from missing context, weak acceptance criteria, poor verification, or tool misuse +3. Add one small rule to the relevant template, skill, or checklist +4. Re-run or verify the next similar task against the new rule +5. Remove or consolidate rules that no longer earn their complexity + +### Takeaways +- A good agent system gets safer after each failure +- The fix is usually a better rule, checklist, or proof requirement—not a longer prompt +- Rules should live where future agents will actually see them + +### Exercise +Take one real agent failure and write the exact rule/template/checklist update that would prevent recurrence. + +### Deliverable +A failure-to-rule log with at least three entries and one updated ticket template or skill checklist. + +--- + +## Module 7. Team mode + sweep scheduling + +**Goal:** Help students operate `/orchestrator` as a recurring team workflow instead of a one-off demo. + +### Lessons +1. Team mode: coordinator, executor, verifier, reviewer, and owner roles +2. Sweep scheduling: recurring checks for stale tickets, missing proof, blocked work, and ready-for-review items +3. Escalation rules for blockers, risky changes, and human decisions +4. Operating cadence: daily sweep, weekly cleanup, and post-failure rule updates +5. Metrics that matter: cycle time, verification failure rate, reviewer load, and escaped defects + +### Team operating model +- **Coordinator:** decomposes work and assigns ownership +- **Executor:** creates the artifact or implementation +- **Verifier:** checks proof against criteria independently +- **Reviewer:** handles judgment, taste, risk, and final approval +- **Owner:** accountable for business outcome and closing the loop + +### Sweep examples +- Find tickets stuck in Execute without proof +- Find Review tickets missing screenshots, tests, URLs, or diffs +- Find Done tickets with no business proof +- Find repeated failure modes that deserve new rules +- Find recurring work that should become a scheduled orchestrator run + +### Takeaways +- Scheduling creates consistency without constant human babysitting +- Team mode works when roles and handoffs are explicit +- Good operations make agent leverage compound over time + +### Exercise +Design one scheduled sweep for a real board and define the trigger, query, action, owner, and escalation path. + +### Deliverable +A team-mode operating cadence with one daily sweep, one weekly cleanup, and one escalation rule. + +--- + +## Funnel trigger + +**Trigger:** GitHub install → first verified ticket → course CTA for domain depth + +### Funnel logic +1. User installs or clones `/orchestrator` +2. User runs their first ticket through Execute and Verify +3. They see the gap between ad hoc agent work and a real operating system +4. CTA introduces the course as the next step for templates, domain skills, board setup, and team-mode workflows + +### CTA placements +- GitHub README after quickstart and first verified ticket example +- `/orchestrator` proof artifact examples +- Post-install success message or docs page +- Newsletter and launch emails for builders using agent workflows + +## English / Spanish adaptation notes + +### English hooks +- Your AI agent is not failing because it is dumb. It is failing because your system has no verification layer. +- If you are checking every agent output yourself, you do not have leverage. You have a new intern. +- The goal is not more prompts. The goal is a delivery system. +- Stop being the QA department for your own AI agents. + +### Spanish hooks +- Tu agente no falla por falta de inteligencia. Falla porque tu sistema no tiene una capa de verificación. +- Si estás revisando cada entrega del agente, no tienes apalancamiento. Tienes otro trabajo. +- La meta no es escribir más prompts. La meta es construir un sistema de entrega. +- Deja de ser el QA de tus propios agentes. + +### Adaptation guidance +- Keep module structure identical in EN and ES +- Localize examples for Spanish-speaking operators and founders +- Avoid literal translation when the operational metaphor is clearer in Spanish +- Preserve `/orchestrator`, ticket lifecycle, verification, and proof terminology consistently + +## Production deliverables + +1. **Course outline finalized:** this document +2. **Modules scripted (EN):** one script brief per lesson using this outline +3. **Spanish track adaptation:** translated/adapted lesson briefs, examples, and worksheets +4. **Course page copy:** promise, bullets, module accordion, FAQ, and CTA +5. **GitHub README CTA:** install → first verified ticket → course CTA + +## Final deliverable recommendation + +Turn this outline into: +1. a lesson-by-lesson script brief, +2. a worksheet with ticket and verification templates, +3. a companion board template for `/orchestrator` users, +4. domain skill cards for content, engineering, and e-commerce, +5. a sweep scheduling checklist for team-mode operations. diff --git a/artifacts/MAX-542/final-proof-comment.md b/artifacts/MAX-542/final-proof-comment.md new file mode 100644 index 0000000..6708928 --- /dev/null +++ b/artifacts/MAX-542/final-proof-comment.md @@ -0,0 +1,23 @@ +MAX-542 final verification — course outline delivery + +Mandatory pickup/check fields: +- identifier: MAX-542 +- id/state: Linear ticket MAX-542, state In Review +- labels: none visible from CLI output +- inputs: Offer Stack `/orchestrator`; free repo `https://github.com/maxtechera/orchestrator`; course price $197; EN/ES title/tagline; requested module list; funnel trigger GitHub install → first verified ticket → course CTA +- deliverables: finalized course outline, EN module script structure, ES adaptation notes/title/tagline, course page/CTA copy, README CTA +- todo checklist: deliverables above are present in repo artifacts and README/docs surfaces +- verification/acceptance criteria: Markdown package validates; expected artifacts exist; README CTA exists; PR created for human review +- proof: `docs/proofs/MAX-542/` screenshots/video and command output +- artifacts: `artifacts/MAX-542/course-outline-orchestrate-ai-agents.md`, `artifacts/MAX-542/build.md`, `docs/course-outline.md`, `README.md` + +Verification run: +```bash +cd /data/workspace/wt-MAX-542-orchestrator +python3 /data/workspace/tools/package-builder.py validate-md --input artifacts/MAX-542/build.md +test -s artifacts/MAX-542/course-outline-orchestrate-ai-agents.md && test -s docs/course-outline.md && test -s README.md +``` +Result: ✅ `build.md valid + hashes fresh`; artifact smoke check passed. + +PR: https://github.com/maxtechera/orchestrator/pull/32 +Branch artifact URL: https://github.com/maxtechera/orchestrator/tree/feat/MAX-542-content-waterfall-v2/artifacts/MAX-542 diff --git a/artifacts/MAX-542/proof-pack.md b/artifacts/MAX-542/proof-pack.md new file mode 100644 index 0000000..01bf3bc --- /dev/null +++ b/artifacts/MAX-542/proof-pack.md @@ -0,0 +1,21 @@ +# MAX-542 proof pack + +## Repo surface +- Repo: `maxtechera/orchestrator` +- Artifact path: `artifacts/MAX-542/course-outline-orchestrate-ai-agents.md` +- Proof path: `docs/proofs/MAX-542/` +- Deployed URL: `https://github.com/maxtechera/orchestrator/tree/feat/MAX-542-course-outline/artifacts/MAX-542` + +## Attach to Linear +- `linear_attached_visual_proof.png` +- `rendered_html_screenshot.png` +- `rendered_html_preview_screenshot.png` +- `rendered_github_markdown_screenshot.png` +- `screenshot_desktop.png` +- `screenshot_mobile.png` +- `final_mp4_attachment.mp4` + +## Notes +- `deployed_url` is the GitHub branch artifact URL because the delivery surface is `repo:orchestrator`. +- `linear_attached_visual_proof.png` is an alias copy of the rendered HTML proof so the required proof field has a stable filename. +- `final_mp4_attachment.mp4` is an alias copy of `course-outline-preview.mp4` for the same reason. diff --git a/artifacts/MAX-545/FINAL-DELIVERY.md b/artifacts/MAX-545/FINAL-DELIVERY.md new file mode 100644 index 0000000..97c126f --- /dev/null +++ b/artifacts/MAX-545/FINAL-DELIVERY.md @@ -0,0 +1,17 @@ +# MAX-545, final delivery + +## Shipped assets +- `MAX-545-oss-tools-demo-first-funnel.md`, master strategy and /ship wiring +- `package.json`, machine-readable placement package for Content Engine +- `MAX-545-demo-first-funnel-reel.mp4`, proof-of-concept short video asset +- `MAX-545-demo-first-funnel-thumb.png`, thumbnail / OG asset +- `carousel-slide-1.png` to `carousel-slide-5.png`, carousel proof assets +- `preview.html`, HTML preview surface +- `github-markdown-preview.html`, markdown preview surface +- `rendered-html-preview.png`, rendered HTML preview screenshot asset +- `rendered-markdown-preview.png`, rendered markdown preview screenshot asset + +## Notes +- Package covers `instagram_reel`, `instagram_carousel`, `tiktok`, `youtube_short`, `x_thread`, `linkedin_post`, `email`, `blog_post`, and `landing_page`. +- `pr_url` will resolve after branch push and PR creation. +- Linear was not touched in this sub-run. diff --git a/artifacts/MAX-545/MAX-545-demo-first-funnel-reel.mp4 b/artifacts/MAX-545/MAX-545-demo-first-funnel-reel.mp4 new file mode 100644 index 0000000..e22d29d Binary files /dev/null and b/artifacts/MAX-545/MAX-545-demo-first-funnel-reel.mp4 differ diff --git a/artifacts/MAX-545/MAX-545-demo-first-funnel-thumb.png b/artifacts/MAX-545/MAX-545-demo-first-funnel-thumb.png new file mode 100644 index 0000000..152bf2d Binary files /dev/null and b/artifacts/MAX-545/MAX-545-demo-first-funnel-thumb.png differ diff --git a/artifacts/MAX-545/MAX-545-demo-first-funnel-thumb.svg b/artifacts/MAX-545/MAX-545-demo-first-funnel-thumb.svg new file mode 100644 index 0000000..ad7bd96 --- /dev/null +++ b/artifacts/MAX-545/MAX-545-demo-first-funnel-thumb.svg @@ -0,0 +1,12 @@ + + + +MAX-545 + +
+
Demo-first OSS tools funnel
+
Show the config working. Let GitHub earn trust. Sell the full system later.
+
+ +Demo first -> GitHub -> newsletter -> course -> cohort + \ No newline at end of file diff --git a/artifacts/MAX-545/MAX-545-oss-tools-demo-first-funnel.md b/artifacts/MAX-545/MAX-545-oss-tools-demo-first-funnel.md new file mode 100644 index 0000000..8a4fa15 --- /dev/null +++ b/artifacts/MAX-545/MAX-545-oss-tools-demo-first-funnel.md @@ -0,0 +1,100 @@ +# MAX-545, OSS tools demo-first funnel + +Built for `maxtechera/orchestrator`. + +## Strategy in one line +Show the tool working first, let GitHub earn trust, use email to turn installs into deeper intent, and sell the course as the "how this becomes your system" layer. + +## Funnel spine +`short demo -> GitHub tools -> newsletter -> course -> cohort` + +## Tool-by-tool content calendar + +| Tool | 4 reels | 1 long-form video | +| --- | --- | --- | +| `/memory` | 1. "The agent forgot the customer again" 2. "One memory write fixed the next 10 prompts" 3. "Stop re-explaining context every session" 4. "The moment recall turns into leverage" | Build a memory layer that keeps customer, product, and workflow context available across sessions | +| `/ship` | 1. "Idea to shipped asset without tab chaos" 2. "What a real GTM run looks like" 3. "One command, content package out" 4. "From rough brief to launch-ready deliverables" | Run a real launch workflow end to end, from brief to content package to proof | +| `/orch` | 1. "The failure got caught before I did" 2. "Why one agent is not enough for real execution" 3. "Dispatch, verify, proof, done" 4. "The ops loop that prevents fake progress" | Coordinate specialist agents on one ticket, show verification, proof capture, and closeout | + +## Hook library + +### `/memory` +- Your agent is not broken, it is just stateless. +- I got tired of re-pasting the same context into every run. +- The unlock is not a better prompt, it is memory that survives the session. +- Watch what happens when the second run already knows the customer. + +### `/ship` +- Most GTM workflows die between the brief and the assets. +- This is what it looks like when one command turns strategy into deliverables. +- Stop treating launch as a checklist, run it like a system. +- The point is not more content, it is shippable content with proof. + +### `/orch` +- The real win is not delegation, it is catching bad work before it ships. +- One agent can write. Orchestrators can finish. +- If there is no proof, it is not done. +- Watch the system route, verify, and close the ticket without status theater. + +## CTA copy + +### Primary CTA +- **Action:** Explore the free tools +- **Reason for now:** Copy the foundation before the paid walkthrough fills in the system design +- **Destination:** `https://maxtechera.com/tools` + +### Secondary CTAs +- Join the newsletter to get the breakdown behind each demo +- Watch the full walkthrough to see how the tools connect +- Apply to the cohort if you want your own stack built with feedback + +## Offer ladder +1. **Free demo content** proves the tool works. +2. **GitHub tools page** converts curiosity into install intent. +3. **Newsletter** converts install intent into recurring attention. +4. **Course** sells the full architecture and implementation logic. +5. **Cohort** sells hands-on build support. + +## `/ship` workflow wiring + +```yaml +ship_content_playbook: + awareness_input: + source: demo-performance + repo click intent + newsletter replies + package_outputs: + - instagram_reel + - instagram_carousel + - tiktok + - youtube_short + - x_thread + - linkedin_post + - email + - blog_post + - landing_page + required_fields: + - hook_variants + - CTA action + - CTA reason_for_now + - media path + - proof screenshots + routing_rules: + - if asset is short-form demo, route to reel engine + captions + - if asset is educational breakdown, route to blog + email variants + - if asset is conversion asset, route to landing page package + success_events: + - github_tools_click + - newsletter_signup + - course_page_visit + - cohort_apply_start +``` + +## What this changes in the business +- Free OSS tools stop acting like passive repos and start acting like a demo-driven acquisition loop. +- The course becomes the natural "show me the full stack" next step. +- The cohort becomes the premium "help me implement this" next step. + +## Recommended publishing rhythm +- 3 short demos per week +- 1 long-form walkthrough per week +- 1 newsletter issue per tool proof or implementation lesson +- 1 monthly cohort-oriented synthesis piece diff --git a/artifacts/MAX-545/carousel-slide-1.png b/artifacts/MAX-545/carousel-slide-1.png new file mode 100644 index 0000000..85dbcf8 Binary files /dev/null and b/artifacts/MAX-545/carousel-slide-1.png differ diff --git a/artifacts/MAX-545/carousel-slide-1.svg b/artifacts/MAX-545/carousel-slide-1.svg new file mode 100644 index 0000000..ef06635 --- /dev/null +++ b/artifacts/MAX-545/carousel-slide-1.svg @@ -0,0 +1,12 @@ + + + +MAX-545 + +
+
OSS tools should open the funnel
+
Free tools are proof, not just docs.
+
+ +Demo first -> GitHub -> newsletter -> course -> cohort + \ No newline at end of file diff --git a/artifacts/MAX-545/carousel-slide-2.png b/artifacts/MAX-545/carousel-slide-2.png new file mode 100644 index 0000000..3fcd51b Binary files /dev/null and b/artifacts/MAX-545/carousel-slide-2.png differ diff --git a/artifacts/MAX-545/carousel-slide-2.svg b/artifacts/MAX-545/carousel-slide-2.svg new file mode 100644 index 0000000..eeb62e3 --- /dev/null +++ b/artifacts/MAX-545/carousel-slide-2.svg @@ -0,0 +1,12 @@ + + + +MAX-545 + +
+
Show the config running
+
Demo-first beats readme-first.
+
+ +Demo first -> GitHub -> newsletter -> course -> cohort + \ No newline at end of file diff --git a/artifacts/MAX-545/carousel-slide-3.png b/artifacts/MAX-545/carousel-slide-3.png new file mode 100644 index 0000000..3c6dce0 Binary files /dev/null and b/artifacts/MAX-545/carousel-slide-3.png differ diff --git a/artifacts/MAX-545/carousel-slide-3.svg b/artifacts/MAX-545/carousel-slide-3.svg new file mode 100644 index 0000000..2642b9d --- /dev/null +++ b/artifacts/MAX-545/carousel-slide-3.svg @@ -0,0 +1,12 @@ + + + +MAX-545 + +
+
Send curiosity to GitHub
+
Let installs create trust.
+
+ +Demo first -> GitHub -> newsletter -> course -> cohort + \ No newline at end of file diff --git a/artifacts/MAX-545/carousel-slide-4.png b/artifacts/MAX-545/carousel-slide-4.png new file mode 100644 index 0000000..3c6dce0 Binary files /dev/null and b/artifacts/MAX-545/carousel-slide-4.png differ diff --git a/artifacts/MAX-545/carousel-slide-4.svg b/artifacts/MAX-545/carousel-slide-4.svg new file mode 100644 index 0000000..846d3b7 --- /dev/null +++ b/artifacts/MAX-545/carousel-slide-4.svg @@ -0,0 +1,12 @@ + + + +MAX-545 + +
+
Use email for architecture
+
Break down decisions and workflows.
+
+ +Demo first -> GitHub -> newsletter -> course -> cohort + \ No newline at end of file diff --git a/artifacts/MAX-545/carousel-slide-5.png b/artifacts/MAX-545/carousel-slide-5.png new file mode 100644 index 0000000..3c6dce0 Binary files /dev/null and b/artifacts/MAX-545/carousel-slide-5.png differ diff --git a/artifacts/MAX-545/carousel-slide-5.svg b/artifacts/MAX-545/carousel-slide-5.svg new file mode 100644 index 0000000..58b3ee3 --- /dev/null +++ b/artifacts/MAX-545/carousel-slide-5.svg @@ -0,0 +1,12 @@ + + + +MAX-545 + +
+
Sell the full system
+
Course for architecture, cohort for implementation.
+
+ +Demo first -> GitHub -> newsletter -> course -> cohort + \ No newline at end of file diff --git a/artifacts/MAX-545/github-markdown-preview.html b/artifacts/MAX-545/github-markdown-preview.html new file mode 100644 index 0000000..32b94e3 --- /dev/null +++ b/artifacts/MAX-545/github-markdown-preview.html @@ -0,0 +1,101 @@ +MAX-545 Markdown Preview

Rendered GitHub markdown preview

# MAX-545, OSS tools demo-first funnel
+
+Built for `maxtechera/orchestrator`.
+
+## Strategy in one line
+Show the tool working first, let GitHub earn trust, use email to turn installs into deeper intent, and sell the course as the "how this becomes your system" layer.
+
+## Funnel spine
+`short demo -> GitHub tools -> newsletter -> course -> cohort`
+
+## Tool-by-tool content calendar
+
+| Tool | 4 reels | 1 long-form video |
+| --- | --- | --- |
+| `/memory` | 1. "The agent forgot the customer again" 2. "One memory write fixed the next 10 prompts" 3. "Stop re-explaining context every session" 4. "The moment recall turns into leverage" | Build a memory layer that keeps customer, product, and workflow context available across sessions |
+| `/ship` | 1. "Idea to shipped asset without tab chaos" 2. "What a real GTM run looks like" 3. "One command, content package out" 4. "From rough brief to launch-ready deliverables" | Run a real launch workflow end to end, from brief to content package to proof |
+| `/orch` | 1. "The failure got caught before I did" 2. "Why one agent is not enough for real execution" 3. "Dispatch, verify, proof, done" 4. "The ops loop that prevents fake progress" | Coordinate specialist agents on one ticket, show verification, proof capture, and closeout |
+
+## Hook library
+
+### `/memory`
+- Your agent is not broken, it is just stateless.
+- I got tired of re-pasting the same context into every run.
+- The unlock is not a better prompt, it is memory that survives the session.
+- Watch what happens when the second run already knows the customer.
+
+### `/ship`
+- Most GTM workflows die between the brief and the assets.
+- This is what it looks like when one command turns strategy into deliverables.
+- Stop treating launch as a checklist, run it like a system.
+- The point is not more content, it is shippable content with proof.
+
+### `/orch`
+- The real win is not delegation, it is catching bad work before it ships.
+- One agent can write. Orchestrators can finish.
+- If there is no proof, it is not done.
+- Watch the system route, verify, and close the ticket without status theater.
+
+## CTA copy
+
+### Primary CTA
+- **Action:** Explore the free tools
+- **Reason for now:** Copy the foundation before the paid walkthrough fills in the system design
+- **Destination:** `https://maxtechera.com/tools`
+
+### Secondary CTAs
+- Join the newsletter to get the breakdown behind each demo
+- Watch the full walkthrough to see how the tools connect
+- Apply to the cohort if you want your own stack built with feedback
+
+## Offer ladder
+1. **Free demo content** proves the tool works.
+2. **GitHub tools page** converts curiosity into install intent.
+3. **Newsletter** converts install intent into recurring attention.
+4. **Course** sells the full architecture and implementation logic.
+5. **Cohort** sells hands-on build support.
+
+## `/ship` workflow wiring
+
+```yaml
+ship_content_playbook:
+  awareness_input:
+    source: demo-performance + repo click intent + newsletter replies
+  package_outputs:
+    - instagram_reel
+    - instagram_carousel
+    - tiktok
+    - youtube_short
+    - x_thread
+    - linkedin_post
+    - email
+    - blog_post
+    - landing_page
+  required_fields:
+    - hook_variants
+    - CTA action
+    - CTA reason_for_now
+    - media path
+    - proof screenshots
+  routing_rules:
+    - if asset is short-form demo, route to reel engine + captions
+    - if asset is educational breakdown, route to blog + email variants
+    - if asset is conversion asset, route to landing page package
+  success_events:
+    - github_tools_click
+    - newsletter_signup
+    - course_page_visit
+    - cohort_apply_start
+```
+
+## What this changes in the business
+- Free OSS tools stop acting like passive repos and start acting like a demo-driven acquisition loop.
+- The course becomes the natural "show me the full stack" next step.
+- The cohort becomes the premium "help me implement this" next step.
+
+## Recommended publishing rhythm
+- 3 short demos per week
+- 1 long-form walkthrough per week
+- 1 newsletter issue per tool proof or implementation lesson
+- 1 monthly cohort-oriented synthesis piece
+
\ No newline at end of file diff --git a/artifacts/MAX-545/package.json b/artifacts/MAX-545/package.json new file mode 100644 index 0000000..2a1fb15 --- /dev/null +++ b/artifacts/MAX-545/package.json @@ -0,0 +1,137 @@ +{ + "ticket_id": "MAX-545", + "content_type": "social-pack", + "target_repo": "maxtechera/orchestrator", + "brand": "max-techera", + "locale": "en", + "placements": { + "instagram_reel": { + "text": "Most OSS tools fail for one reason: you show the README before you show the win.\n\nHere is the better funnel.\n1. Show the config running\n2. Send people to the free repo\n3. Capture newsletter intent\n4. Sell the full system in the course\n\nThe free tool is not the side quest. It is the proof.\n\nExplore the tools: https://maxtechera.com/tools", + "cta": { + "action": "Explore the free tools", + "reason_for_now": "Use the free repo as the fast starting point before the paid walkthrough turns it into a full system" + }, + "hashtags": ["#OpenSource", "#AIAgents", "#BuildInPublic", "#Automation", "#CreatorBusiness"], + "media": { + "mp4": "artifacts/MAX-545/MAX-545-demo-first-funnel-reel.mp4", + "thumbnail": "artifacts/MAX-545/MAX-545-demo-first-funnel-thumb.png" + }, + "hook_variants": [ + "Stop selling OSS tools like documentation, sell them like proof.", + "The README is not the top of the funnel, the demo is.", + "Watch how a free tool becomes a course sale without sounding salesy." + ], + "manychat_trigger": { + "keyword": "TOOLS", + "flow_id": "TBD_MAX_PROVIDES" + } + }, + "instagram_carousel": { + "slides": [ + {"text": "OSS tools should open the funnel, not end the funnel.", "image": "artifacts/MAX-545/carousel-slide-1.png"}, + {"text": "Step 1, show the config running before you explain anything.", "image": "artifacts/MAX-545/carousel-slide-2.png"}, + {"text": "Step 2, drive curiosity to GitHub where people can copy the foundation.", "image": "artifacts/MAX-545/carousel-slide-3.png"}, + {"text": "Step 3, use newsletter breakdowns to explain decisions and use cases.", "image": "artifacts/MAX-545/carousel-slide-4.png"}, + {"text": "Step 4, sell the course as the full stack and the cohort as implementation support.", "image": "artifacts/MAX-545/carousel-slide-5.png"} + ], + "caption": "If your OSS repo is useful but not converting, the problem is probably packaging. Demo first, repo second, explanation third.\n\nStart here: https://maxtechera.com/tools", + "cta": { + "action": "Explore the free tools", + "reason_for_now": "The repos give people an immediate win before they decide whether they want the full workflow" + }, + "hashtags": ["#OpenSource", "#GrowthSystem", "#AIAutomation"] + }, + "tiktok": { + "caption": "Free OSS tools are your sales page if you package them right. Tools: https://maxtechera.com/tools", + "hook_variants": [ + "You do not need a better sales page, you need a better demo.", + "This is how free repos turn into paid buyers.", + "Show the config working, then let GitHub do the trust-building." + ], + "media": {"mp4": "artifacts/MAX-545/MAX-545-demo-first-funnel-reel.mp4"} + }, + "youtube_short": { + "title": "How free OSS tools become a paid course funnel", + "description": "Demo-first beats readme-first. Show the win, send people to GitHub, turn installs into newsletter signups, then sell the full architecture. Start with the free tools at https://maxtechera.com/tools", + "media": {"mp4": "artifacts/MAX-545/MAX-545-demo-first-funnel-reel.mp4"} + }, + "x_thread": { + "tweets": [ + {"text": "Most people market OSS tools backwards. They lead with the README instead of the result."}, + {"text": "The better funnel is: short demo -> GitHub -> newsletter -> course -> cohort."}, + {"text": "Why it works: the demo creates desire, the repo earns trust, the newsletter creates depth, the course sells the full system."}, + {"text": "Free tools are not just lead magnets. They are product proof in public."}, + {"text": "If you build OSS and want it to convert, package it like a working demo first. Tools: https://maxtechera.com/tools"} + ], + "cta": { + "action": "Explore the free tools", + "reason_for_now": "They show what is possible before someone commits to the full walkthrough" + } + }, + "linkedin_post": { + "text": "A useful OSS repo is not enough by itself.\n\nIf you want free tools to drive business, the packaging has to do more than explain installation. It has to create momentum.\n\nThe funnel I would use is simple:\n- short demo content that shows the config working\n- GitHub as the trust layer and install surface\n- newsletter issues that break down architecture and tradeoffs\n- paid course for the full system\n- cohort for implementation help\n\nThe key shift is demo-first instead of readme-first.\n\nThe free tool is the proof. The paid product is the explanation, context, and implementation support around it.\n\nThat is how open source starts compounding instead of sitting there as a nice repo with no commercial follow-through.\n\nTools: https://maxtechera.com/tools", + "cta": { + "action": "Explore the free tools", + "reason_for_now": "They are the fastest way to understand the stack before committing to the deeper walkthrough" + } + }, + "email": { + "subject_variants": [ + "The demo should sell the OSS repo", + "How free tools become course demand", + "The funnel behind my OSS tools" + ], + "preview_text": "Show the win first, let GitHub earn trust, then sell the full system.", + "body_html": "

The demo should sell the OSS repo

Most OSS tools are packaged backwards. They start with explanation when they should start with proof.

The stronger funnel is:

  1. Show the config running in short-form content
  2. Send people to GitHub to copy the base
  3. Use the newsletter to explain architecture and tradeoffs
  4. Sell the course as the full system
  5. Offer the cohort for implementation help

Explore the free tools

The free tool is not the side quest. It is the proof that earns the right to the paid offer.

", + "utm": { + "source": "mailerlite", + "campaign": "max-545-demo-first-funnel", + "medium": "email" + } + }, + "blog_post": { + "slug": "/blog/demo-first-oss-tools-funnel", + "title": "Demo-first OSS tools funnel for course conversions", + "meta_description": "How to turn open source tools into a demo-first funnel that drives GitHub installs, newsletter signups, course sales, and cohort applications.", + "hero_og": "artifacts/MAX-545/MAX-545-demo-first-funnel-thumb.png", + "body_md": "# Demo-first OSS tools funnel\n\nMost OSS tools are marketed like documentation projects. That leaves demand on the table.\n\nThe stronger model is demo-first: show the tool working, send people to GitHub, use the newsletter to deepen the relationship, then sell the full architecture through the course and implementation support through the cohort.\n\n## The funnel\n\n1. Short-form demo content proves the tool works\n2. GitHub captures install intent\n3. Newsletter captures recurring attention\n4. Course sells the full system design\n5. Cohort sells implementation support\n\n## Why this works\n\nFree tools reduce skepticism. They let the audience test the logic before they buy the explanation. That makes the course feel like the natural next layer, not a disconnected offer.\n\n## Tool angles\n\n- `/memory`: the pain is repeated context loss\n- `/ship`: the pain is launch chaos between idea and assets\n- `/orch`: the pain is delegated work without verification\n\n## CTA\n\nStart with the free tools at https://maxtechera.com/tools\n", + "faq": [ + {"q": "Why demo-first instead of readme-first?", "a": "Because the demo creates desire faster than documentation. The readme helps after interest exists."}, + {"q": "What does the course sell if the tools are free?", "a": "The course sells architecture, sequencing, adaptation, and implementation logic around the tools."} + ] + }, + "landing_page": { + "slug": "/tools", + "hero": { + "headline": "Free OSS tools that prove the workflow before you buy the full system", + "subhead": "Explore the repos, see the demos, then step into the course or cohort when you want the full architecture and implementation support.", + "hero_image": "artifacts/MAX-545/MAX-545-demo-first-funnel-thumb.png" + }, + "features": [ + {"name": "Demo-first packaging", "hero_image": "artifacts/MAX-545/MAX-545-demo-first-funnel-thumb.png", "diagram": "artifacts/MAX-545/rendered-html-preview.png", "demo_media": "artifacts/MAX-545/MAX-545-demo-first-funnel-reel.mp4"}, + {"name": "GitHub as trust layer", "hero_image": "artifacts/MAX-545/MAX-545-demo-first-funnel-thumb.png", "diagram": "artifacts/MAX-545/rendered-markdown-preview.png", "demo_media": "artifacts/MAX-545/MAX-545-demo-first-funnel-reel.mp4"} + ], + "ctas": { + "primary": "Explore the free tools", + "secondary": "Get the full walkthrough" + }, + "tracking_events": ["page_view", "github_tools_click", "newsletter_signup", "course_page_visit", "cohort_apply_start"], + "meta": { + "title": "Free OSS tools, demos, and full-system walkthroughs", + "description": "See the tools working first, install the free repos, then go deeper with the course and cohort.", + "og": "artifacts/MAX-545/MAX-545-demo-first-funnel-thumb.png", + "canonical": "https://maxtechera.com/tools" + } + } + }, + "proof": { + "pr_url": "https://github.com/maxtechera/orchestrator/pull/12", + "preview_urls": ["artifacts/MAX-545/preview.html", "artifacts/MAX-545/github-markdown-preview.html"], + "screenshots": { + "desktop": "artifacts/MAX-545/rendered-html-preview.png", + "mobile": "artifacts/MAX-545/rendered-markdown-preview.png" + }, + "mp4_attachments": ["artifacts/MAX-545/MAX-545-demo-first-funnel-reel.mp4"], + "mailerlite_campaign_url": "" + } +} diff --git a/artifacts/MAX-545/preview.html b/artifacts/MAX-545/preview.html new file mode 100644 index 0000000..c6ddafa --- /dev/null +++ b/artifacts/MAX-545/preview.html @@ -0,0 +1 @@ +MAX-545 Preview

MAX-545, HTML preview

Demo-first OSS tools funnel

Short demo content turns free tools into a commercial acquisition system.

Core funnel

short demo -> GitHub -> newsletter -> course -> cohort

Primary CTA

Explore the free tools at maxtechera.com/tools

Package placements

\ No newline at end of file diff --git a/artifacts/MAX-545/rendered-html-preview.png b/artifacts/MAX-545/rendered-html-preview.png new file mode 100644 index 0000000..85dbcf8 Binary files /dev/null and b/artifacts/MAX-545/rendered-html-preview.png differ diff --git a/artifacts/MAX-545/rendered-markdown-preview.png b/artifacts/MAX-545/rendered-markdown-preview.png new file mode 100644 index 0000000..3fcd51b Binary files /dev/null and b/artifacts/MAX-545/rendered-markdown-preview.png differ diff --git a/artifacts/MAX-548/01-problem-agitate-solve.mp4 b/artifacts/MAX-548/01-problem-agitate-solve.mp4 new file mode 100644 index 0000000..ea0fff3 Binary files /dev/null and b/artifacts/MAX-548/01-problem-agitate-solve.mp4 differ diff --git a/artifacts/MAX-548/01-problem-agitate-solve.png b/artifacts/MAX-548/01-problem-agitate-solve.png new file mode 100644 index 0000000..353ec33 Binary files /dev/null and b/artifacts/MAX-548/01-problem-agitate-solve.png differ diff --git a/artifacts/MAX-548/02-contrarian.mp4 b/artifacts/MAX-548/02-contrarian.mp4 new file mode 100644 index 0000000..49b1b08 Binary files /dev/null and b/artifacts/MAX-548/02-contrarian.mp4 differ diff --git a/artifacts/MAX-548/02-contrarian.png b/artifacts/MAX-548/02-contrarian.png new file mode 100644 index 0000000..a70f90a Binary files /dev/null and b/artifacts/MAX-548/02-contrarian.png differ diff --git a/artifacts/MAX-548/03-specific-number.mp4 b/artifacts/MAX-548/03-specific-number.mp4 new file mode 100644 index 0000000..8ada4ec Binary files /dev/null and b/artifacts/MAX-548/03-specific-number.mp4 differ diff --git a/artifacts/MAX-548/03-specific-number.png b/artifacts/MAX-548/03-specific-number.png new file mode 100644 index 0000000..db95564 Binary files /dev/null and b/artifacts/MAX-548/03-specific-number.png differ diff --git a/artifacts/MAX-548/04-insider-reveal.mp4 b/artifacts/MAX-548/04-insider-reveal.mp4 new file mode 100644 index 0000000..e14608e Binary files /dev/null and b/artifacts/MAX-548/04-insider-reveal.mp4 differ diff --git a/artifacts/MAX-548/04-insider-reveal.png b/artifacts/MAX-548/04-insider-reveal.png new file mode 100644 index 0000000..0446da6 Binary files /dev/null and b/artifacts/MAX-548/04-insider-reveal.png differ diff --git a/artifacts/MAX-548/05-testimonial.mp4 b/artifacts/MAX-548/05-testimonial.mp4 new file mode 100644 index 0000000..294ee0c Binary files /dev/null and b/artifacts/MAX-548/05-testimonial.mp4 differ diff --git a/artifacts/MAX-548/05-testimonial.png b/artifacts/MAX-548/05-testimonial.png new file mode 100644 index 0000000..e918904 Binary files /dev/null and b/artifacts/MAX-548/05-testimonial.png differ diff --git a/artifacts/MAX-548/final_mp4_attachment.mp4 b/artifacts/MAX-548/final_mp4_attachment.mp4 new file mode 100644 index 0000000..ea0fff3 Binary files /dev/null and b/artifacts/MAX-548/final_mp4_attachment.mp4 differ diff --git a/artifacts/MAX-548/linear_attached_visual_proof.png b/artifacts/MAX-548/linear_attached_visual_proof.png new file mode 100644 index 0000000..d38a0a1 Binary files /dev/null and b/artifacts/MAX-548/linear_attached_visual_proof.png differ diff --git a/artifacts/MAX-548/package.json b/artifacts/MAX-548/package.json new file mode 100644 index 0000000..91bd797 --- /dev/null +++ b/artifacts/MAX-548/package.json @@ -0,0 +1,46 @@ +{ + "ticket_id": "MAX-548", + "content_type": "reel", + "target_repo": "maxtechera/orchestrator", + "brand": "max-techera", + "locale": "en", + "placements": { + "instagram_reel": { + "text": "Your AI agent said done. It wasn't. That is the problem /orchestrator is built to catch. Instead of trusting a victory lap, run a sweep, verify the proof, and flag the tickets that only look complete. DM ORCHESTRATOR for the free install guide.\n\nComment sweep if you want the repo link in replies.", + "cta": {"action": "DM ORCHESTRATOR", "reason_for_now": "Get the free install guide before your next agent sweep"}, + "hashtags": ["#aiagents", "#opensource", "#claudecode", "#buildinpublic", "#orchestrator"], + "media": {"mp4": "content/reels/MAX-548/videos/01-problem-agitate-solve.mp4", "thumbnail": "content/reels/MAX-548/thumbnails/01-problem-agitate-solve.png"}, + "hook_variants": ["Your AI agent said done. It wasn't.", "The ticket closed, but the bug was still live.", "Done is not done when the proof fails."], + "manychat_trigger": {"keyword": "ORCHESTRATOR", "flow_id": "TBD_MAX_PROVIDES"} + }, + "tiktok": { + "caption": "Your AI said done. It wasn't. /orchestrator runs the sweep, checks the proof, and catches fake completions before they hit production. Comment sweep for the repo.", + "hook_variants": ["The problem is not the model.", "Smarter agents still fail if nobody verifies the finish.", "More autonomy without verification just creates faster mistakes."], + "media": {"mp4": "content/reels/MAX-548/videos/02-contrarian.mp4"} + }, + "youtube_short": { + "title": "Your AI Said Done. It Wasn't. /orchestrator Catches It", + "description": "Your agent can close tickets fast. That does not mean the work is actually done. This reel series shows the /orchestrator verification model: problem, sweep, and verification contract. Repo: https://github.com/maxtechera/orchestrator\n\nCTA: DM ORCHESTRATOR for the install guide or comment sweep for the repo link.", + "media": {"mp4": "content/reels/MAX-548/videos/03-specific-number.mp4"} + } + }, + "proof": { + "pr_url": "https://github.com/maxtechera/orchestrator/pull/11", + "preview_urls": ["https://github.com/maxtechera/orchestrator/tree/feat/MAX-548-orchestrator-reel-series/artifacts/MAX-548"], + "screenshots": { + "desktop": "artifacts/MAX-548/screenshot_desktop.png", + "mobile": "artifacts/MAX-548/screenshot_mobile.png", + "rendered_html": "artifacts/MAX-548/rendered_html_screenshot.png", + "rendered_html_preview": "artifacts/MAX-548/rendered_html_preview_screenshot.png", + "rendered_github_markdown": "artifacts/MAX-548/rendered_github_markdown_screenshot.png" + }, + "mp4_attachments": [ + "artifacts/MAX-548/final_mp4_attachment.mp4", + "artifacts/MAX-548/01-problem-agitate-solve.mp4", + "artifacts/MAX-548/02-contrarian.mp4", + "artifacts/MAX-548/03-specific-number.mp4", + "artifacts/MAX-548/04-insider-reveal.mp4", + "artifacts/MAX-548/05-testimonial.mp4" + ] + } +} diff --git a/artifacts/MAX-548/proof-pack.md b/artifacts/MAX-548/proof-pack.md new file mode 100644 index 0000000..ad3eb85 --- /dev/null +++ b/artifacts/MAX-548/proof-pack.md @@ -0,0 +1,29 @@ +# MAX-548 proof pack + +## Repo surface +- Repo: `maxtechera/orchestrator` +- Path: `content/reels/MAX-548/` +- Package schema: `artifacts/MAX-548/package.json` + +## Attach to Linear +- `linear_attached_visual_proof.png` +- `final_mp4_attachment.mp4` +- `01-problem-agitate-solve.mp4` +- `02-contrarian.mp4` +- `03-specific-number.mp4` +- `04-insider-reveal.mp4` +- `05-testimonial.mp4` +- `01-problem-agitate-solve.png` +- `02-contrarian.png` +- `03-specific-number.png` +- `04-insider-reveal.png` +- `05-testimonial.png` +- `rendered_html_screenshot.png` +- `rendered_html_preview_screenshot.png` +- `rendered_github_markdown_screenshot.png` +- `screenshot_desktop.png` +- `screenshot_mobile.png` + +## Notes +- `final_mp4_attachment.mp4` duplicates the first rendered reel so the required proof field has a stable filename. +- `linear_attached_visual_proof.png` is the proof board preview. diff --git a/artifacts/MAX-548/rendered_github_markdown_screenshot.png b/artifacts/MAX-548/rendered_github_markdown_screenshot.png new file mode 100644 index 0000000..2ab4a00 Binary files /dev/null and b/artifacts/MAX-548/rendered_github_markdown_screenshot.png differ diff --git a/artifacts/MAX-548/rendered_html_preview_screenshot.png b/artifacts/MAX-548/rendered_html_preview_screenshot.png new file mode 100644 index 0000000..64d4bc4 Binary files /dev/null and b/artifacts/MAX-548/rendered_html_preview_screenshot.png differ diff --git a/artifacts/MAX-548/rendered_html_screenshot.png b/artifacts/MAX-548/rendered_html_screenshot.png new file mode 100644 index 0000000..d38a0a1 Binary files /dev/null and b/artifacts/MAX-548/rendered_html_screenshot.png differ diff --git a/artifacts/MAX-548/screenshot_desktop.png b/artifacts/MAX-548/screenshot_desktop.png new file mode 100644 index 0000000..d38a0a1 Binary files /dev/null and b/artifacts/MAX-548/screenshot_desktop.png differ diff --git a/artifacts/MAX-548/screenshot_mobile.png b/artifacts/MAX-548/screenshot_mobile.png new file mode 100644 index 0000000..351af7e Binary files /dev/null and b/artifacts/MAX-548/screenshot_mobile.png differ diff --git a/artifacts/MAX-548/scripts-preview.html b/artifacts/MAX-548/scripts-preview.html new file mode 100644 index 0000000..3b4c3a0 --- /dev/null +++ b/artifacts/MAX-548/scripts-preview.html @@ -0,0 +1,90 @@ + +

MAX-548 rendered HTML preview

+
# MAX-548 scripts, /orchestrator reel series
+
+## Shared audience
+AI / LLM developers, Claude Code users, and indie hackers running agent teams on real work.
+
+## Shared message
+Your AI agent said done. It wasn't. `/orchestrator` runs a sweep, checks proof, and catches fake completions before they hit production.
+
+---
+
+## Variant 1, Problem agitate solve
+
+### Hooks
+1. Your AI agent said done. It wasn't.
+2. The ticket closed, but the bug was still live.
+3. Done is not done when the proof fails.
+
+### Script
+Hook: Your AI agent said done. It wasn't.
+Agitate: The ticket is closed, the broken link is still there, the test is still red, and now you have cleanup work.
+Solve: Run `/orchestrator` so the sweep checks proof before the ticket gets marked complete.
+CTA: DM `ORCHESTRATOR` for the free install guide.
+
+---
+
+## Variant 2, Contrarian
+
+### Hooks
+1. The problem is not the model. It's fake done states.
+2. Smarter agents still fail if nobody verifies the finish.
+3. More autonomy without verification just creates faster mistakes.
+
+### Script
+Hook: People think the answer is a better model.
+Contrarian take: The real problem is agents marking work done without proving it.
+Proof: `/orchestrator` runs a sweep, keeps the tickets with evidence, and flags the ones that only look complete.
+CTA: Comment `sweep` and I'll reply with the repo.
+
+---
+
+## Variant 3, Specific number
+
+### Hooks
+1. Sweep 10 tickets, catch the 3 that lied.
+2. One verification sweep can save hours of cleanup.
+3. 10 tickets reviewed, 3 fake dones caught, 0 guesswork.
+
+### Script
+Hook: Sweep 10 tickets, catch the 3 that lied.
+Proof: `/orchestrator` can review the batch, close the 7 with proof, and escalate the 3 missing real evidence.
+Outcome: Less trust theater, less production risk, faster clean handoffs.
+CTA: Link in bio for the open-source repo.
+
+---
+
+## Variant 4, Insider reveal
+
+### Hooks
+1. The real win is the verification contract, not the agent demo.
+2. The secret is forcing artifact plus business delta plus surface correctness.
+3. Most agent demos stop at output. `/orchestrator` checks the finish line.
+
+### Script
+Hook: The real win is the verification contract.
+Reveal: `/orchestrator` does not accept a vague done update. It asks for artifact delta, business delta, and surface correctness.
+Proof: If one of those is missing, the ticket does not get the victory lap.
+CTA: DM `ORCHESTRATOR` if you want the install guide.
+
+---
+
+## Variant 5, Testimonial style
+
+### Hooks
+1. The moment we started sweeping, the fake dones showed up fast.
+2. `/orchestrator` made our agent work reviewable instead of hopeful.
+3. This is what finally stopped the “looks done” problem.
+
+### Script
+Hook: We had agents closing tickets that still needed human cleanup.
+Story: After adding `/orchestrator`, we could see which tickets had proof and which ones were bluffing.
+Result: Reviews got faster because we only spent human attention where the sweep found real problems.
+CTA: Comment `sweep` or grab the repo from the link in bio.
+
+ \ No newline at end of file diff --git a/artifacts/MAX-549/MAX-549-contrarian.mp4 b/artifacts/MAX-549/MAX-549-contrarian.mp4 new file mode 100644 index 0000000..0752e92 Binary files /dev/null and b/artifacts/MAX-549/MAX-549-contrarian.mp4 differ diff --git a/artifacts/MAX-549/MAX-549-insider-reveal.mp4 b/artifacts/MAX-549/MAX-549-insider-reveal.mp4 new file mode 100644 index 0000000..2b17d56 Binary files /dev/null and b/artifacts/MAX-549/MAX-549-insider-reveal.mp4 differ diff --git a/artifacts/MAX-549/MAX-549-problem-agitate-solve.mp4 b/artifacts/MAX-549/MAX-549-problem-agitate-solve.mp4 new file mode 100644 index 0000000..7a7780c Binary files /dev/null and b/artifacts/MAX-549/MAX-549-problem-agitate-solve.mp4 differ diff --git a/artifacts/MAX-549/MAX-549-ship-reel-series.md b/artifacts/MAX-549/MAX-549-ship-reel-series.md new file mode 100644 index 0000000..bc91efd --- /dev/null +++ b/artifacts/MAX-549/MAX-549-ship-reel-series.md @@ -0,0 +1,54 @@ +# MAX-549 reel series, /ship + +## Goal +Show the /ship GTM pipeline end-to-end and turn awareness into inbound install-guide requests. + +## CTA map +- Primary: DM keyword `SHIP` for the free install guide +- Secondary: comment `pipeline` to get the repo link +- Tertiary: link in bio to `https://github.com/maxtechera/ship` + +## Variant 1, Problem → Agitate → Solve +Hooks: +- I launched a product with AI agents in 3 hours. Here is the pipeline. +- Your product is not stuck in build mode. Your launch pipeline is. +- If launch day still takes a week, steal this 3-hour agent workflow. + +Script: +Start with `/ship create` and show the coordinator spinning up. Cut to the credential check surfacing hidden failures before launch. Then show the pipeline moving from validate to strategy to awareness to launch to measure. End on the solo-founder payoff, one command turns into a launch team. CTA: DM SHIP. + +## Variant 2, Contrarian +Hooks: +- Hot take, you do not need a bigger launch team. You need one better run command. +- More GTM tools do not save launch day. Better orchestration does. +- Most founders stack apps. I stacked agents and launched faster. + +Script: +Open on the contrarian line, then reveal `/ship create` as the orchestration layer. Show credentials gating, then the validate → strategy → awareness → launch → measure handoff. Close with the claim that orchestration beats tool sprawl. CTA: comment pipeline. + +## Variant 3, Specific-number +Hooks: +- 30 integrations. 9 agents. 3 hours. That was the launch stack. +- Here is the exact AI pipeline behind a 3-hour product launch. +- I compressed a week of GTM work into one 3-hour agent run. + +Script: +Lead with the numbers on screen. Show credentials checking 30 plus integrations, then the agent chain, then launch outputs landing in sequence. Reinforce that the stack is measurable and repeatable. CTA: link in bio. + +## Variant 4, Insider-reveal +Hooks: +- The secret is not the prompt. It is the launch pipeline behind the prompt. +- Everyone shows the output. Almost nobody shows the GTM machine. +- Behind every fast AI launch is a ruthless checklist. Here is mine. + +Script: +Pull back the curtain on the actual pipeline. Show the credential gate, stage transitions, content generation, and launch coordination happening together. Position `/ship` as the system behind the result, not just another prompt pack. CTA: DM SHIP. + +## Variant 5, Testimonial +Hooks: +- I ran one command and it felt like a launch team showed up. +- If you are a solo founder, this is the closest thing to hiring a launch squad overnight. +- Best part, it did not feel like software. It felt like backup. + +Script: +Tell it as first-person before and after. Before, launch work is fragmented and slow. After, `/ship create` coordinates credentials, pipeline stages, and launch outputs in one flow. CTA: reply SHIP for the setup guide. diff --git a/artifacts/MAX-549/MAX-549-specific-number.mp4 b/artifacts/MAX-549/MAX-549-specific-number.mp4 new file mode 100644 index 0000000..806b6c7 Binary files /dev/null and b/artifacts/MAX-549/MAX-549-specific-number.mp4 differ diff --git a/artifacts/MAX-549/MAX-549-testimonial.mp4 b/artifacts/MAX-549/MAX-549-testimonial.mp4 new file mode 100644 index 0000000..4ae77a6 Binary files /dev/null and b/artifacts/MAX-549/MAX-549-testimonial.mp4 differ diff --git a/artifacts/MAX-549/contrarian-thumbnail.png b/artifacts/MAX-549/contrarian-thumbnail.png new file mode 100644 index 0000000..e6d3b64 Binary files /dev/null and b/artifacts/MAX-549/contrarian-thumbnail.png differ diff --git a/artifacts/MAX-549/desktop.txt b/artifacts/MAX-549/desktop.txt new file mode 100644 index 0000000..7443b3e --- /dev/null +++ b/artifacts/MAX-549/desktop.txt @@ -0,0 +1,7 @@ +Desktop proof, /ship reel package + +I launched a product with AI agents in 3 hours + +/ship turns credential checks and GTM execution into one orchestrated launch workflow. + +CTA: DM SHIP \ No newline at end of file diff --git a/artifacts/MAX-549/generate_preview_assets.py b/artifacts/MAX-549/generate_preview_assets.py new file mode 100644 index 0000000..07a66e5 --- /dev/null +++ b/artifacts/MAX-549/generate_preview_assets.py @@ -0,0 +1,123 @@ +import json +from pathlib import Path +from textwrap import wrap +from PIL import Image, ImageDraw, ImageFont + +BASE = Path(__file__).resolve().parent +pkg = json.loads((BASE / 'package.json').read_text()) + +preview_html = f""" + + + + MAX-549 package preview + + + +
+

{pkg['ticket_id']} /ship package schema

+
Target repo: {pkg['target_repo']} • Content type: {pkg['content_type']} • Brand: {pkg['brand']}
+
+
Instagram Reel
{pkg['placements']['instagram_reel']['text']}
+
TikTok
{pkg['placements']['tiktok']['caption']}
+
YouTube Short
{pkg['placements']['youtube_short']['title']}
{pkg['placements']['youtube_short']['description']}
+
CTA Map
Primary DM SHIP
Secondary comment pipeline
Tertiary link in bio → github.com/maxtechera/ship
+
+
+ +""" +(BASE / 'preview.html').write_text(preview_html) + +md = (BASE / 'MAX-549-ship-reel-series.md').read_text() +rendered_md = "
" + md.replace('&', '&').replace('<', '<').replace('>', '>') + "
" +(BASE / 'rendered-markdown.html').write_text(rendered_md) + +try: + font = ImageFont.truetype('/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf', 28) + font_b = ImageFont.truetype('/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf', 40) + font_s = ImageFont.truetype('/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf', 22) +except Exception: + font = font_b = font_s = ImageFont.load_default() + + +def make_card_image(path, title, sections, size=(1440, 1800), dark=False): + bg = '#0b1020' if dark else '#ffffff' + fg = '#f5f7fb' if dark else '#111111' + sub = '#a7b0c2' if dark else '#4b5563' + im = Image.new('RGB', size, bg) + draw = ImageDraw.Draw(im) + x, y = 70, 60 + draw.text((x, y), title, font=font_b, fill=fg) + y += 80 + for heading, body in sections: + draw.text((x, y), heading, font=font_s, fill=sub) + y += 40 + for line in wrap(body, width=70): + draw.text((x, y), line, font=font, fill=fg) + y += 38 + y += 24 + im.save(path) + +make_card_image( + BASE / 'rendered-html-preview-screenshot.png', + 'MAX-549 Preview, Content Engine style', + [ + ('Instagram Reel', pkg['placements']['instagram_reel']['text']), + ('TikTok', pkg['placements']['tiktok']['caption']), + ('YouTube Short', pkg['placements']['youtube_short']['title'] + ' — ' + pkg['placements']['youtube_short']['description']) + ], + dark=True, +) + +make_card_image( + BASE / 'rendered-html-screenshot.png', + 'MAX-549 Rendered HTML', + [ + ('Blog title', pkg['placements']['blog_post']['title']), + ('Meta description', pkg['placements']['blog_post']['meta_description']), + ('Body excerpt', pkg['placements']['blog_post']['body_md']) + ], +) + +make_card_image( + BASE / 'rendered-github-markdown-screenshot.png', + 'GitHub Markdown Preview, MAX-549', + [('Archive doc', md)], + size=(1440, 2000), +) + +make_card_image( + BASE / 'screenshot-desktop.png', + 'Desktop proof, /ship reel package', + [ + ('Hero', pkg['placements']['landing_page']['hero']['headline']), + ('Subhead', pkg['placements']['landing_page']['hero']['subhead']), + ('Primary CTA', pkg['placements']['landing_page']['ctas']['primary']) + ], + size=(1600, 900), + dark=True, +) + +make_card_image( + BASE / 'screenshot-mobile.png', + 'Mobile proof, /ship reel package', + [ + ('Hook', pkg['placements']['instagram_reel']['hook_variants'][0]), + ('CTA', pkg['placements']['instagram_reel']['cta']['action']), + ('Why now', pkg['placements']['instagram_reel']['cta']['reason_for_now']) + ], + size=(900, 1600), + dark=True, +) + +print('generated preview assets') diff --git a/artifacts/MAX-549/github-shot.txt b/artifacts/MAX-549/github-shot.txt new file mode 100644 index 0000000..f8efa66 --- /dev/null +++ b/artifacts/MAX-549/github-shot.txt @@ -0,0 +1,56 @@ +GitHub Markdown Preview, MAX-549 + +# MAX-549 reel series, /ship + +## Goal +Show the /ship GTM pipeline end-to-end and turn awareness into inbound install-guide requests. + +## CTA map +- Primary: DM keyword `SHIP` for the free install guide +- Secondary: comment `pipeline` to get the repo link +- Tertiary: link in bio to `https://github.com/maxtechera/ship` + +## Variant 1, Problem → Agitate → Solve +Hooks: +- I launched a product with AI agents in 3 hours. Here is the pipeline. +- Your product is not stuck in build mode. Your launch pipeline is. +- If launch day still takes a week, steal this 3-hour agent workflow. + +Script: +Start with `/ship create` and show the coordinator spinning up. Cut to the credential check surfacing hidden failures before launch. Then show the pipeline moving from validate to strategy to awareness to launch to measure. End on the solo-founder payoff, one command turns into a launch team. CTA: DM SHIP. + +## Variant 2, Contrarian +Hooks: +- Hot take, you do not need a bigger launch team. You need one better run command. +- More GTM tools do not save launch day. Better orchestration does. +- Most founders stack apps. I stacked agents and launched faster. + +Script: +Open on the contrarian line, then reveal `/ship create` as the orchestration layer. Show credentials gating, then the validate → strategy → awareness → launch → measure handoff. Close with the claim that orchestration beats tool sprawl. CTA: comment pipeline. + +## Variant 3, Specific-number +Hooks: +- 30 integrations. 9 agents. 3 hours. That was the launch stack. +- Here is the exact AI pipeline behind a 3-hour product launch. +- I compressed a week of GTM work into one 3-hour agent run. + +Script: +Lead with the numbers on screen. Show credentials checking 30 plus integrations, then the agent chain, then launch outputs landing in sequence. Reinforce that the stack is measurable and repeatable. CTA: link in bio. + +## Variant 4, Insider-reveal +Hooks: +- The secret is not the prompt. It is the launch pipeline behind the prompt. +- Everyone shows the output. Almost nobody shows the GTM machine. +- Behind every fast AI launch is a ruthless checklist. Here is mine. + +Script: +Pull back the curtain on the actual pipeline. Show the credential gate, stage transitions, content generation, and launch coordination happening together. Position `/ship` as the system behind the result, not just another prompt pack. CTA: DM SHIP. + +## Variant 5, Testimonial +Hooks: +- I ran one command and it felt like a launch team showed up. +- If you are a solo founder, this is the closest thing to hiring a launch squad overnight. +- Best part, it did not feel like software. It felt like backup. + +Script: +Tell it as first-person before and after. Before, launch work is fragmented and slow. After, `/ship create` coordinates credentials, pipeline stages, and launch outputs in one flow. CTA: reply SHIP for the setup guide. diff --git a/artifacts/MAX-549/insider-reveal-thumbnail.png b/artifacts/MAX-549/insider-reveal-thumbnail.png new file mode 100644 index 0000000..aa45cff Binary files /dev/null and b/artifacts/MAX-549/insider-reveal-thumbnail.png differ diff --git a/artifacts/MAX-549/mobile.txt b/artifacts/MAX-549/mobile.txt new file mode 100644 index 0000000..a4d9c5d --- /dev/null +++ b/artifacts/MAX-549/mobile.txt @@ -0,0 +1,7 @@ +Mobile proof, /ship reel package + +I launched a product with AI agents in 3 hours. Here is the pipeline. + +CTA: DM "SHIP" + +because the install guide shows the exact launch workflow before your next launch slips \ No newline at end of file diff --git a/artifacts/MAX-549/package.json b/artifacts/MAX-549/package.json new file mode 100644 index 0000000..ce420de --- /dev/null +++ b/artifacts/MAX-549/package.json @@ -0,0 +1,247 @@ +{ + "ticket_id": "MAX-549", + "content_type": "reel", + "target_repo": "maxtechera/orchestrator", + "brand": "max-techera", + "locale": "en", + "variants": [ + { + "id": "v1-problem-agitate-solve", + "name": "Problem \u2192 Agitate \u2192 Solve", + "angle": "Launch pain is not building, it is the missing GTM pipeline.", + "hooks": [ + "I launched a product with AI agents in 3 hours. Here is the pipeline.", + "Your product is not stuck in build mode. Your launch pipeline is.", + "If launch day still takes a week, steal this 3-hour agent workflow." + ], + "script": "Show /ship create starting the coordinator, the credential gate surfacing hidden failures, then the validate \u2192 strategy \u2192 awareness \u2192 launch \u2192 measure flow. End with the solo-founder payoff and DM SHIP CTA." + }, + { + "id": "v2-contrarian", + "name": "Contrarian", + "angle": "More tools are not the answer. Better orchestration is.", + "hooks": [ + "Hot take, you do not need a bigger launch team. You need one better run command.", + "More GTM tools do not save launch day. Better orchestration does.", + "Most founders stack apps. I stacked agents and launched faster." + ], + "script": "Open on the contrarian line, reveal /ship create, show credentials gating and the full GTM stage handoff, then close on orchestration beating tool sprawl." + }, + { + "id": "v3-specific-number", + "name": "Specific-number", + "angle": "Quantified proof, 30 integrations, 9 agents, 3 hours.", + "hooks": [ + "30 integrations. 9 agents. 3 hours. That was the launch stack.", + "Here is the exact AI pipeline behind a 3-hour product launch.", + "I compressed a week of GTM work into one 3-hour agent run." + ], + "script": "Lead with the numbers, then show the credential preflight, agent chain, and measurable launch outputs landing stage by stage." + }, + { + "id": "v4-insider-reveal", + "name": "Insider reveal", + "angle": "The real advantage is the machine behind the prompt.", + "hooks": [ + "The secret is not the prompt. It is the launch pipeline behind the prompt.", + "Everyone shows the output. Almost nobody shows the GTM machine.", + "Behind every fast AI launch is a ruthless checklist. Here is mine." + ], + "script": "Reveal the pipeline architecture, credential gate, stage transitions, content generation, and launch coordination, then anchor /ship as the system behind the speed." + }, + { + "id": "v5-testimonial", + "name": "Testimonial", + "angle": "Make the solo-founder transformation feel personal and believable.", + "hooks": [ + "I ran one command and it felt like a launch team showed up.", + "If you are a solo founder, this is the closest thing to hiring a launch squad overnight.", + "Best part, it did not feel like software. It felt like backup." + ], + "script": "Tell a before-and-after story, fragmented launch work before, coordinated AI launch team after /ship create. End with reply SHIP for setup guide." + } + ], + "placements": { + "instagram_reel": { + "text": "I launched a product with AI agents in 3 hours. Here is the pipeline.\n\nThe trick was not one magic prompt. It was a GTM system that checked credentials, ran validate \u2192 strategy \u2192 awareness \u2192 launch \u2192 measure, and kept moving without me stitching tools together all day.\n\nIf you are building solo and your launch still takes a week, DM SHIP and I will send the free install guide.", + "cta": { + "action": "DM \"SHIP\"", + "reason_for_now": "because the install guide shows the exact launch workflow before your next launch slips" + }, + "hashtags": [ + "#ship", + "#aiagents", + "#buildinpublic", + "#indiehackers", + "#claudecode", + "#opensource", + "#gtm", + "#productlaunch" + ], + "media": { + "mp4": "artifacts/MAX-549/MAX-549-problem-agitate-solve.mp4", + "thumbnail": "artifacts/MAX-549/problem-agitate-solve-thumbnail.png" + }, + "hook_variants": [ + "I launched a product with AI agents in 3 hours. Here is the pipeline.", + "Your product is not stuck in build mode. Your launch pipeline is.", + "If launch day still takes a week, steal this 3-hour agent workflow." + ], + "manychat_trigger": { + "keyword": "SHIP", + "flow_id": "TBD_MAX_PROVIDES" + } + }, + "tiktok": { + "caption": "Hot take, you do not need a bigger launch team. You need one better run command. `/ship` checked the stack, ran the GTM pipeline, and got a product out in 3 hours. Comment pipeline and I will send the repo.", + "hook_variants": [ + "Hot take, you do not need a bigger launch team. You need one better run command.", + "More GTM tools do not save launch day. Better orchestration does.", + "Most founders stack apps. I stacked agents and launched faster." + ], + "media": { + "mp4": "artifacts/MAX-549/MAX-549-contrarian.mp4", + "thumbnail": "artifacts/MAX-549/contrarian-thumbnail.png" + } + }, + "youtube_short": { + "title": "30 Integrations, 9 Agents, 3 Hours to Launch", + "description": "This is the /ship GTM pipeline behind a 3-hour product launch, credential checks, validate, strategy, awareness, launch, and measure in one workflow. Link in bio for the repo.", + "media": { + "mp4": "artifacts/MAX-549/MAX-549-specific-number.mp4", + "thumbnail": "artifacts/MAX-549/specific-number-thumbnail.png" + } + }, + "x_thread": { + "tweets": [ + { + "text": "I launched a product with AI agents in 3 hours. The interesting part was not the prompt. It was the GTM pipeline." + }, + { + "text": "The run started with credential checks, then moved through validate, strategy, awareness, launch, and measure without me babysitting every handoff." + }, + { + "text": "If you are an indie hacker or Claude Code user, this is what shipping looks like when you orchestrate agents instead of stacking more tools." + }, + { + "text": "Want the install guide? Reply SHIP. Want the repo? Comment pipeline and I will send github.com/maxtechera/ship" + } + ], + "cta": { + "action": "Reply \"SHIP\"", + "reason_for_now": "to get the install guide before your next launch turns into another week of manual GTM work" + } + }, + "linkedin_post": { + "text": "I launched a product with AI agents in 3 hours, and the biggest lesson was this, speed did not come from better prompting. It came from orchestration.\n\nThe workflow started with credential checks so launch blockers surfaced before execution. Then `/ship` ran a full GTM handoff, validate, strategy, awareness, launch, and measure, so every stage produced the next asset instead of waiting on me to coordinate it manually.\n\nIf you are a solo founder, indie hacker, or Claude Code user, this is the leverage point. Stop stacking disconnected tools. Start building a launch pipeline that behaves like a team.", + "cta": { + "action": "DM \"SHIP\"", + "reason_for_now": "to get the install guide while you still have a product worth launching this week" + } + }, + "email": { + "subject_variants": [ + "I launched with AI agents in 3 hours", + "The /ship pipeline behind a fast launch", + "Steal my 3-hour AI GTM workflow" + ], + "preview_text": "A proof-first breakdown of the /ship pipeline that compresses launch work into one orchestrated run.", + "body_html": "

I launched a product with AI agents in 3 hours

The win was not one prompt. It was a workflow that checked credentials, then pushed work through validate, strategy, awareness, launch, and measure.

If you want the free install guide, reply with SHIP. If you want the repo, use github.com/maxtechera/ship.

", + "utm": { + "source": "mailerlite", + "campaign": "max-549-ship-reel-series", + "medium": "email" + } + }, + "blog_post": { + "slug": "/blog/i-launched-a-product-with-ai-agents-in-3-hours", + "title": "I Launched a Product With AI Agents in 3 Hours", + "meta_description": "A proof-first breakdown of the /ship GTM pipeline, from credential checks to launch and measurement.", + "hero_og": "artifacts/MAX-549/insider-reveal-thumbnail.png", + "body_md": "# I launched a product with AI agents in 3 hours\n\nThe headline is true, but the useful part is how. The launch only moved fast because the system started with credential checks and then ran a full GTM pipeline, validate, strategy, awareness, launch, and measure.\n\n## What changed\nInstead of stitching together prompts and tools manually, `/ship` handled the handoffs between stages.\n\n## Why it matters\nFor solo founders and indie hackers, the bottleneck is rarely the product. It is the launch machine around the product.\n\n## What to do next\nIf you want the install guide, DM SHIP. If you want the repo, grab github.com/maxtechera/ship.", + "faq": [ + { + "q": "Who is /ship for?", + "a": "AI builders, Claude Code users, indie hackers, and solo founders shipping products." + }, + { + "q": "What does the pipeline cover?", + "a": "Credential checks, validate, strategy, awareness, launch, and measure." + } + ] + }, + "landing_page": { + "slug": "/ship", + "hero": { + "headline": "I launched a product with AI agents in 3 hours", + "subhead": "/ship turns credential checks and GTM execution into one orchestrated launch workflow.", + "hero_image": "artifacts/MAX-549/testimonial-thumbnail.png" + }, + "features": [ + { + "name": "Credential gate first", + "hero_image": "artifacts/MAX-549/problem-agitate-solve-thumbnail.png", + "diagram": "artifacts/MAX-549/problem-agitate-solve-thumbnail.png", + "demo_media": "artifacts/MAX-549/MAX-549-problem-agitate-solve.mp4" + }, + { + "name": "GTM stage pipeline", + "hero_image": "artifacts/MAX-549/specific-number-thumbnail.png", + "diagram": "artifacts/MAX-549/insider-reveal-thumbnail.png", + "demo_media": "artifacts/MAX-549/MAX-549-specific-number.mp4" + }, + { + "name": "Launch-day orchestration", + "hero_image": "artifacts/MAX-549/contrarian-thumbnail.png", + "diagram": "artifacts/MAX-549/testimonial-thumbnail.png", + "demo_media": "artifacts/MAX-549/MAX-549-testimonial.mp4" + } + ], + "ctas": { + "primary": "DM SHIP", + "secondary": "Comment pipeline" + }, + "tracking_events": [ + "page_view", + "cta_click_primary", + "cta_click_secondary", + "video_play" + ], + "meta": { + "title": "/ship launch workflow", + "description": "The AI-agent GTM pipeline behind a 3-hour product launch.", + "og": "artifacts/MAX-549/problem-agitate-solve-thumbnail.png", + "canonical": "https://github.com/maxtechera/ship" + } + } + }, + "proof": { + "pr_url": "https://github.com/maxtechera/orchestrator/pull/14", + "preview_urls": [ + "artifacts/MAX-549/preview.html", + "artifacts/MAX-549/rendered-markdown.html" + ], + "screenshots": { + "desktop": "artifacts/MAX-549/screenshot-desktop.png", + "mobile": "artifacts/MAX-549/screenshot-mobile.png", + "rendered_html": "artifacts/MAX-549/rendered-html-screenshot.png", + "rendered_html_preview": "artifacts/MAX-549/rendered-html-preview-screenshot.png", + "rendered_github_markdown": "artifacts/MAX-549/rendered-github-markdown-screenshot.png" + }, + "mp4_attachments": [ + "artifacts/MAX-549/MAX-549-problem-agitate-solve.mp4", + "artifacts/MAX-549/MAX-549-contrarian.mp4", + "artifacts/MAX-549/MAX-549-specific-number.mp4", + "artifacts/MAX-549/MAX-549-insider-reveal.mp4", + "artifacts/MAX-549/MAX-549-testimonial.mp4" + ], + "thumbnail_pngs": [ + "artifacts/MAX-549/problem-agitate-solve-thumbnail.png", + "artifacts/MAX-549/contrarian-thumbnail.png", + "artifacts/MAX-549/specific-number-thumbnail.png", + "artifacts/MAX-549/insider-reveal-thumbnail.png", + "artifacts/MAX-549/testimonial-thumbnail.png" + ], + "deployed_url": "https://github.com/maxtechera/orchestrator/blob/feat/MAX-549-ship-package-proof/artifacts/MAX-549/preview.html" + } +} diff --git a/artifacts/MAX-549/preview-shot.txt b/artifacts/MAX-549/preview-shot.txt new file mode 100644 index 0000000..6f00739 --- /dev/null +++ b/artifacts/MAX-549/preview-shot.txt @@ -0,0 +1,15 @@ +Preview, Content Engine style + +I launched a product with AI agents in 3 hours. Here is the pipeline. + +The trick was not one magic prompt. It was a GTM system that checked credentials, ran validate → strategy → awareness → launch → measure, and kept moving without me stitching tools together all day. + +If you are building solo and your launch still takes a week, DM SHIP and I will send the free install guide. + +--- + +Hot take, you do not need a bigger launch team. You need one better run command. `/ship` checked the stack, ran the GTM pipeline, and got a product out in 3 hours. Comment pipeline and I will send the repo. + +--- + +30 Integrations, 9 Agents, 3 Hours to Launch \ No newline at end of file diff --git a/artifacts/MAX-549/preview.html b/artifacts/MAX-549/preview.html new file mode 100644 index 0000000..e2c4655 --- /dev/null +++ b/artifacts/MAX-549/preview.html @@ -0,0 +1,5 @@ +MAX-549 package preview

MAX-549 /ship package schema

Target repo: maxtechera/orchestrator

Instagram Reel

I launched a product with AI agents in 3 hours. Here is the pipeline. + +The trick was not one magic prompt. It was a GTM system that checked credentials, ran validate → strategy → awareness → launch → measure, and kept moving without me stitching tools together all day. + +If you are building solo and your launch still takes a week, DM SHIP and I will send the free install guide.

TikTok

Hot take, you do not need a bigger launch team. You need one better run command. `/ship` checked the stack, ran the GTM pipeline, and got a product out in 3 hours. Comment pipeline and I will send the repo.

YouTube Short

30 Integrations, 9 Agents, 3 Hours to Launch
This is the /ship GTM pipeline behind a 3-hour product launch, credential checks, validate, strategy, awareness, launch, and measure in one workflow. Link in bio for the repo.

\ No newline at end of file diff --git a/artifacts/MAX-549/problem-agitate-solve-thumbnail.png b/artifacts/MAX-549/problem-agitate-solve-thumbnail.png new file mode 100644 index 0000000..4cdb1b2 Binary files /dev/null and b/artifacts/MAX-549/problem-agitate-solve-thumbnail.png differ diff --git a/artifacts/MAX-549/rendered-github-markdown-screenshot.png b/artifacts/MAX-549/rendered-github-markdown-screenshot.png new file mode 100644 index 0000000..2e96255 Binary files /dev/null and b/artifacts/MAX-549/rendered-github-markdown-screenshot.png differ diff --git a/artifacts/MAX-549/rendered-html-preview-screenshot.png b/artifacts/MAX-549/rendered-html-preview-screenshot.png new file mode 100644 index 0000000..f44f853 Binary files /dev/null and b/artifacts/MAX-549/rendered-html-preview-screenshot.png differ diff --git a/artifacts/MAX-549/rendered-html-screenshot.png b/artifacts/MAX-549/rendered-html-screenshot.png new file mode 100644 index 0000000..aa45cff Binary files /dev/null and b/artifacts/MAX-549/rendered-html-screenshot.png differ diff --git a/artifacts/MAX-549/rendered-html.txt b/artifacts/MAX-549/rendered-html.txt new file mode 100644 index 0000000..183f5f8 --- /dev/null +++ b/artifacts/MAX-549/rendered-html.txt @@ -0,0 +1,18 @@ +Rendered HTML, MAX-549 + +I Launched a Product With AI Agents in 3 Hours + +A proof-first breakdown of the /ship GTM pipeline, from credential checks to launch and measurement. + +# I launched a product with AI agents in 3 hours + +The headline is true, but the useful part is how. The launch only moved fast because the system started with credential checks and then ran a full GTM pipeline, validate, strategy, awareness, launch, and measure. + +## What changed +Instead of stitching together prompts and tools manually, `/ship` handled the handoffs between stages. + +## Why it matters +For solo founders and indie hackers, the bottleneck is rarely the product. It is the launch machine around the product. + +## What to do next +If you want the install guide, DM SHIP. If you want the repo, grab github.com/maxtechera/ship. \ No newline at end of file diff --git a/artifacts/MAX-549/rendered-markdown.html b/artifacts/MAX-549/rendered-markdown.html new file mode 100644 index 0000000..c5f547b --- /dev/null +++ b/artifacts/MAX-549/rendered-markdown.html @@ -0,0 +1,55 @@ +
# MAX-549 reel series, /ship
+
+## Goal
+Show the /ship GTM pipeline end-to-end and turn awareness into inbound install-guide requests.
+
+## CTA map
+- Primary: DM keyword `SHIP` for the free install guide
+- Secondary: comment `pipeline` to get the repo link
+- Tertiary: link in bio to `https://github.com/maxtechera/ship`
+
+## Variant 1, Problem → Agitate → Solve
+Hooks:
+- I launched a product with AI agents in 3 hours. Here is the pipeline.
+- Your product is not stuck in build mode. Your launch pipeline is.
+- If launch day still takes a week, steal this 3-hour agent workflow.
+
+Script:
+Start with `/ship create` and show the coordinator spinning up. Cut to the credential check surfacing hidden failures before launch. Then show the pipeline moving from validate to strategy to awareness to launch to measure. End on the solo-founder payoff, one command turns into a launch team. CTA: DM SHIP.
+
+## Variant 2, Contrarian
+Hooks:
+- Hot take, you do not need a bigger launch team. You need one better run command.
+- More GTM tools do not save launch day. Better orchestration does.
+- Most founders stack apps. I stacked agents and launched faster.
+
+Script:
+Open on the contrarian line, then reveal `/ship create` as the orchestration layer. Show credentials gating, then the validate → strategy → awareness → launch → measure handoff. Close with the claim that orchestration beats tool sprawl. CTA: comment pipeline.
+
+## Variant 3, Specific-number
+Hooks:
+- 30 integrations. 9 agents. 3 hours. That was the launch stack.
+- Here is the exact AI pipeline behind a 3-hour product launch.
+- I compressed a week of GTM work into one 3-hour agent run.
+
+Script:
+Lead with the numbers on screen. Show credentials checking 30 plus integrations, then the agent chain, then launch outputs landing in sequence. Reinforce that the stack is measurable and repeatable. CTA: link in bio.
+
+## Variant 4, Insider-reveal
+Hooks:
+- The secret is not the prompt. It is the launch pipeline behind the prompt.
+- Everyone shows the output. Almost nobody shows the GTM machine.
+- Behind every fast AI launch is a ruthless checklist. Here is mine.
+
+Script:
+Pull back the curtain on the actual pipeline. Show the credential gate, stage transitions, content generation, and launch coordination happening together. Position `/ship` as the system behind the result, not just another prompt pack. CTA: DM SHIP.
+
+## Variant 5, Testimonial
+Hooks:
+- I ran one command and it felt like a launch team showed up.
+- If you are a solo founder, this is the closest thing to hiring a launch squad overnight.
+- Best part, it did not feel like software. It felt like backup.
+
+Script:
+Tell it as first-person before and after. Before, launch work is fragmented and slow. After, `/ship create` coordinates credentials, pipeline stages, and launch outputs in one flow. CTA: reply SHIP for the setup guide.
+
\ No newline at end of file diff --git a/artifacts/MAX-549/screenshot-desktop.png b/artifacts/MAX-549/screenshot-desktop.png new file mode 100644 index 0000000..4cdb1b2 Binary files /dev/null and b/artifacts/MAX-549/screenshot-desktop.png differ diff --git a/artifacts/MAX-549/screenshot-mobile.png b/artifacts/MAX-549/screenshot-mobile.png new file mode 100644 index 0000000..bfb1ce1 Binary files /dev/null and b/artifacts/MAX-549/screenshot-mobile.png differ diff --git a/artifacts/MAX-549/specific-number-thumbnail.png b/artifacts/MAX-549/specific-number-thumbnail.png new file mode 100644 index 0000000..2e96255 Binary files /dev/null and b/artifacts/MAX-549/specific-number-thumbnail.png differ diff --git a/artifacts/MAX-549/testimonial-thumbnail.png b/artifacts/MAX-549/testimonial-thumbnail.png new file mode 100644 index 0000000..bfb1ce1 Binary files /dev/null and b/artifacts/MAX-549/testimonial-thumbnail.png differ diff --git a/artifacts/MAX-554/deployed-url.txt b/artifacts/MAX-554/deployed-url.txt new file mode 100644 index 0000000..af131a8 --- /dev/null +++ b/artifacts/MAX-554/deployed-url.txt @@ -0,0 +1,3 @@ +https://htmlpreview.github.io/?https://raw.githubusercontent.com/maxtechera/orchestrator/3cd39637558d7cc6eb416b5a9d46a986506788c7/artifacts/MAX-554/landing-preview.html +https://htmlpreview.github.io/?https://raw.githubusercontent.com/maxtechera/orchestrator/3cd39637558d7cc6eb416b5a9d46a986506788c7/artifacts/MAX-554/rendered-blog.html +https://htmlpreview.github.io/?https://raw.githubusercontent.com/maxtechera/orchestrator/3cd39637558d7cc6eb416b5a9d46a986506788c7/artifacts/MAX-554/email-preview.html diff --git a/artifacts/MAX-554/email-preview.html b/artifacts/MAX-554/email-preview.html new file mode 100644 index 0000000..97dffab --- /dev/null +++ b/artifacts/MAX-554/email-preview.html @@ -0,0 +1,49 @@ +
MailerLite preview

Ship is live, and it fixes the messy part after the build

A MailerLite-ready launch email that tees up the Ship blog story and points readers to the repo.

You can ship code faster now. The launch side is still chaos.
+
+That is why I built Ship.
+
+It is an open source GTM pipeline for Claude Code teams. Instead of random prompt hopping, it gives you explicit stages, role handoffs, launch proof, and credential checks before the public push.
+
+What Ship does:
+- Validate the idea before you overbuild
+- Route build work to the right repo and surface
+- Package launch assets instead of leaving them half-done
+- Check tokens and integrations before go time
+- Pull the signals back into the next iteration
+
+Install it in 3 commands, star the repo, and read the launch post for the full breakdown.
+
+Mostrá receipts o callate.

Star the Ship repo

\ No newline at end of file diff --git a/artifacts/MAX-554/final_mp4_attachment.mp4 b/artifacts/MAX-554/final_mp4_attachment.mp4 new file mode 100644 index 0000000..b9ffa97 Binary files /dev/null and b/artifacts/MAX-554/final_mp4_attachment.mp4 differ diff --git a/artifacts/MAX-554/github-readme.html b/artifacts/MAX-554/github-readme.html new file mode 100644 index 0000000..57316ee --- /dev/null +++ b/artifacts/MAX-554/github-readme.html @@ -0,0 +1,61 @@ +
Rendered GitHub markdown preview
# Ship launch
+
+Ship is an open source GTM pipeline for Claude Code teams.
+
+## Why it exists
+- Build got fast
+- Launch stayed manual
+- Credential failures still kill momentum
+
+## What it does
+1. Validate
+2. Build
+3. Launch
+4. Measure
+5. Iterate
+
+## Install
+```bash
+/plugin marketplace add maxtechera/ship
+clawhub install ship
+/ship
+```
+
+## Read more
+- Blog: launching Ship in public
+- Repo: github.com/maxtechera/ship
+- Orchestrator: github.com/maxtechera/orchestrator
+
\ No newline at end of file diff --git a/artifacts/MAX-554/landing-preview.html b/artifacts/MAX-554/landing-preview.html new file mode 100644 index 0000000..7f6ce36 --- /dev/null +++ b/artifacts/MAX-554/landing-preview.html @@ -0,0 +1,34 @@ +
Launch proof preview

Ship turns Claude Code agents into a GTM pipeline

A rendered proof pack for the Ship launch story, with blog preview, MailerLite email preview, GitHub markdown proof, mobile and desktop screenshots, and a short MP4 artifact for Linear attachment.

Validate → build → launch → measure → iterateCredential gate catches expired tokens before launchInstall in 3 commands, then run /ship
Star the Ship repoJoin the newsletter

Blog angle

The launch story frames Ship as the missing GTM operating layer after the build, not another shiny workflow demo.

MailerLite asset

The companion email keeps the message tight, benefits-first, and ready to paste into a campaign builder.

Proof pack

Rendered HTML, desktop and mobile screenshots, GitHub markdown proof, and an MP4 attachment for Linear.

Receipts

Install path, credential gate, stage model, and repo links are all visible in the rendered assets below.

\ No newline at end of file diff --git a/artifacts/MAX-554/package.json b/artifacts/MAX-554/package.json new file mode 100644 index 0000000..c826482 --- /dev/null +++ b/artifacts/MAX-554/package.json @@ -0,0 +1,31 @@ +{ + "ticket": "MAX-554", + "campaign": "Ship launch proof pack", + "asset_type": "blog + mailerlite companion", + "repo": "maxtechera/orchestrator", + "target_system": "mailerlite", + "source_blog": { + "title": "Launching Ship, how Claude Code agents ship products in public", + "slug": "/blog/launching-ship", + "primary_cta": "Star the Ship repo", + "secondary_cta": "Join the newsletter" + }, + "placements": { + "landing": { + "eyebrow": "Launch proof preview", + "headline": "Ship turns Claude Code agents into a GTM pipeline", + "subhead": "A rendered proof pack for the Ship launch story, with blog preview, MailerLite email preview, GitHub markdown proof, mobile and desktop screenshots, and a short MP4 artifact for Linear attachment.", + "bullets": [ + "Validate → build → launch → measure → iterate", + "Credential gate catches expired tokens before launch", + "Install in 3 commands, then run /ship" + ] + }, + "email": { + "subject": "Ship is live, and it fixes the messy part after the build", + "preview_text": "A MailerLite-ready launch email that tees up the Ship blog story and points readers to the repo.", + "body": "You can ship code faster now. The launch side is still chaos.\n\nThat is why I built Ship.\n\nIt is an open source GTM pipeline for Claude Code teams. Instead of random prompt hopping, it gives you explicit stages, role handoffs, launch proof, and credential checks before the public push.\n\nWhat Ship does:\n- Validate the idea before you overbuild\n- Route build work to the right repo and surface\n- Package launch assets instead of leaving them half-done\n- Check tokens and integrations before go time\n- Pull the signals back into the next iteration\n\nInstall it in 3 commands, star the repo, and read the launch post for the full breakdown.\n\nMostrá receipts o callate." + }, + "github_markdown": "# Ship launch\n\nShip is an open source GTM pipeline for Claude Code teams.\n\n## Why it exists\n- Build got fast\n- Launch stayed manual\n- Credential failures still kill momentum\n\n## What it does\n1. Validate\n2. Build\n3. Launch\n4. Measure\n5. Iterate\n\n## Install\n```bash\n/plugin marketplace add maxtechera/ship\nclawhub install ship\n/ship\n```\n\n## Read more\n- Blog: launching Ship in public\n- Repo: github.com/maxtechera/ship\n- Orchestrator: github.com/maxtechera/orchestrator\n" + } +} diff --git a/artifacts/MAX-554/render-assets.js b/artifacts/MAX-554/render-assets.js new file mode 100644 index 0000000..c1df61c --- /dev/null +++ b/artifacts/MAX-554/render-assets.js @@ -0,0 +1,112 @@ +const fs = require('fs'); +const path = require('path'); +const { chromium, devices } = require('playwright'); +const { execSync } = require('child_process'); + +const outDir = __dirname; +const pkg = JSON.parse(fs.readFileSync(path.join(outDir, 'package.json'), 'utf8')); + +function escapeHtml(str) { + return str + .replace(/&/g, '&') + .replace(//g, '>'); +} + +const css = ` +:root { color-scheme: dark; } +* { box-sizing: border-box; } +body { margin: 0; font-family: Inter, ui-sans-serif, system-ui, sans-serif; background: #07111f; color: #e5eefc; } +.wrap { max-width: 1180px; margin: 0 auto; padding: 48px 32px 88px; } +.hero { padding: 44px; border-radius: 32px; background: linear-gradient(135deg, #0f172a, #172554 45%, #0f766e); border: 1px solid rgba(255,255,255,.08); box-shadow: 0 20px 80px rgba(0,0,0,.35); } +.eyebrow { color: #93c5fd; text-transform: uppercase; letter-spacing: .14em; font-size: 12px; font-weight: 700; margin-bottom: 14px; } +h1,h2,h3 { margin: 0 0 16px; } +h1 { font-size: 56px; line-height: 1.02; } +h2 { font-size: 28px; } +p, li { color: #d7e6ff; line-height: 1.68; font-size: 18px; } +.grid { display: grid; grid-template-columns: repeat(2, minmax(0,1fr)); gap: 24px; margin-top: 28px; } +.card { border-radius: 24px; padding: 28px; background: rgba(15,23,42,.86); border: 1px solid rgba(255,255,255,.08); box-shadow: 0 12px 40px rgba(0,0,0,.22); } +.kpi { display:inline-block; padding: 7px 12px; border-radius: 999px; background: rgba(103,232,249,.12); color: #a5f3fc; font-weight: 700; margin-right: 10px; margin-bottom: 10px; } +pre { white-space: pre-wrap; word-wrap: break-word; margin: 0; font-family: ui-monospace, SFMono-Regular, Menlo, monospace; font-size: 15px; line-height: 1.55; color: #dbeafe; } +.btnrow { display:flex; gap:16px; flex-wrap:wrap; margin-top:24px; } +.btn { display:inline-flex; padding:14px 20px; border-radius:999px; font-weight:700; text-decoration:none; } +.btn.primary { background:#67e8f9; color:#082f49; } +.btn.secondary { border:1px solid rgba(103,232,249,.4); color:#cffafe; } +.email { background: #f8fafc; color: #0f172a; } +.email .shell { max-width: 760px; margin: 40px auto; background: white; border-radius: 24px; padding: 40px; box-shadow: 0 18px 60px rgba(15,23,42,.18); } +.email h1, .email p, .email li { color: #0f172a; } +.github { background:#0d1117; } +.github .card { background:#0d1117; border-color:#30363d; } +.github pre { color:#c9d1d9; } +.blog article { max-width: 820px; margin: 0 auto; } +.blog h1 { font-size: 54px; } +.blog h2 { margin-top: 32px; } +.blog .lede { font-size: 22px; color: #bfdbfe; } +.slide { width:1080px; height:1920px; padding:90px 80px; background: linear-gradient(180deg, #020617, #0f172a 45%, #164e63); color:white; display:flex; flex-direction:column; justify-content:space-between; } +.slide h1 { font-size:84px; } +.slide p { font-size:42px; line-height:1.24; color:#dbeafe; } +.slide .footer { font-size:34px; color:#67e8f9; } +`; + +const landingHtml = `
${pkg.placements.landing.eyebrow}

${pkg.placements.landing.headline}

${pkg.placements.landing.subhead}

${pkg.placements.landing.bullets.map((b) => `${b}`).join('')}
${pkg.source_blog.primary_cta}${pkg.source_blog.secondary_cta}

Blog angle

The launch story frames Ship as the missing GTM operating layer after the build, not another shiny workflow demo.

MailerLite asset

The companion email keeps the message tight, benefits-first, and ready to paste into a campaign builder.

Proof pack

Rendered HTML, desktop and mobile screenshots, GitHub markdown proof, and an MP4 attachment for Linear.

Receipts

Install path, credential gate, stage model, and repo links are all visible in the rendered assets below.

`; + +const blogHtml = `
Rendered HTML blog preview

${pkg.source_blog.title}

The build side of AI got fast before the launch side did. Ship is the system I built to close that gap.

You can spin up code, wire features, and move a repo faster than ever. Then the annoying part kicks in, validation, positioning, launch prep, content, analytics, follow-up, and the credential checks nobody wants to think about until a token expires five minutes before push.

That is why Ship exists. It turns that last mile into an explicit pipeline for Claude Code teams, with stage gates, role routing, proof requirements, and preflight checks before the public launch.

The GTM gap for indie hackers

A lot of launches do not miss because the product is weak. They miss because the surrounding system is soft. No real handoffs. No launch proof. No clear owner for the next stage. Ship gives that operating layer a shape.

What Ship does

Validate. Stress-test the offer, pain, and angle before overbuilding.

Build. Route implementation to the right repo and artifact surface.

Launch. Package the blog, email, screenshots, MP4, and public proof instead of leaving them scattered.

Measure. Pull stars, signups, CTR, and response signals back into the loop.

Iterate. Run the next cycle with sharper proof and fewer dumb mistakes.

The credential gate matters more than people think

Ship blocks launch actions when credentials are stale. That sounds boring until it saves forty-five minutes right when momentum matters most. Healthy or blocked. Pass or fail. Before you push, not after you break the launch.

python3 credentials/scripts/check_local.py --only "github,railway,vercel,openai,anthropic" --json

Install in 3 commands

/plugin marketplace add maxtechera/ship
+clawhub install ship
+/ship

When not to use Ship

If you just need one tiny prompt, this is too much. If you do not want stage gates or proof, this is too much. But if you want agent speed to translate into actual market movement, this is the category I wanted to exist.

CTA

Star the repo, read the launch story, and join the newsletter. Mostrá receipts o callate.

`; + +const emailHtml = `
MailerLite preview

${pkg.placements.email.subject}

${pkg.placements.email.preview_text}

${escapeHtml(pkg.placements.email.body)}

${pkg.source_blog.primary_cta}

`; + +const githubHtml = `
Rendered GitHub markdown preview
${escapeHtml(pkg.placements.github_markdown)}
`; + +const slides = [ + { file: 'slide-01.html', title: 'Build got fast', body: 'Launch stayed messy. Ship closes that gap with stages, proof, and a real GTM operating layer.', footer: 'Ship launch' }, + { file: 'slide-02.html', title: '5 stages', body: 'Validate. Build. Launch. Measure. Iterate. No more random prompt hopping.', footer: 'Pipeline' }, + { file: 'slide-03.html', title: 'Credential gate', body: 'Healthy or blocked, before you push. Expired tokens stop momentum more than most founders admit.', footer: 'Preflight' }, + { file: 'slide-04.html', title: 'Receipts', body: 'Rendered blog proof, MailerLite email, GitHub markdown, desktop and mobile screenshots, plus MP4 for Linear.', footer: 'Proof pack' } +]; + +for (const [name, html] of Object.entries({ + 'landing-preview.html': landingHtml, + 'rendered-blog.html': blogHtml, + 'email-preview.html': emailHtml, + 'github-readme.html': githubHtml +})) { + fs.writeFileSync(path.join(outDir, name), html); +} + +for (const slide of slides) { + const html = `
MAX-554 proof pack

${slide.title}

${slide.body}

${slide.footer}
`; + fs.writeFileSync(path.join(outDir, slide.file), html); +} + +(async() => { + const browser = await chromium.launch({ headless: true }); + const page = await browser.newPage({ viewport: { width: 1440, height: 2200 } }); + + await page.goto(`file://${path.join(outDir, 'rendered-blog.html')}`); + await page.screenshot({ path: path.join(outDir, 'rendered_html_screenshot.png'), fullPage: true }); + + await page.goto(`file://${path.join(outDir, 'email-preview.html')}`); + await page.screenshot({ path: path.join(outDir, 'rendered_html_preview_screenshot.png'), fullPage: true }); + + await page.goto(`file://${path.join(outDir, 'github-readme.html')}`); + await page.screenshot({ path: path.join(outDir, 'rendered_github_markdown_screenshot.png'), fullPage: true }); + + await page.goto(`file://${path.join(outDir, 'landing-preview.html')}`); + await page.screenshot({ path: path.join(outDir, 'screenshot_desktop.png'), fullPage: true }); + + const mobile = await browser.newPage({ ...devices['iPhone 13'] }); + await mobile.goto(`file://${path.join(outDir, 'landing-preview.html')}`); + await mobile.screenshot({ path: path.join(outDir, 'screenshot_mobile.png'), fullPage: true }); + await mobile.close(); + + const slidePage = await browser.newPage({ viewport: { width: 1080, height: 1920 } }); + for (let i = 0; i < slides.length; i++) { + const n = String(i + 1).padStart(2, '0'); + await slidePage.goto(`file://${path.join(outDir, slides[i].file)}`); + await slidePage.screenshot({ path: path.join(outDir, `slide-${n}.png`) }); + } + await browser.close(); + + execSync(`ffmpeg -y -framerate 0.5 -i ${path.join(outDir, 'slide-%02d.png')} -vf format=yuv420p,scale=1080:1920 -c:v libx264 -pix_fmt yuv420p ${path.join(outDir, 'final_mp4_attachment.mp4')}`, { stdio: 'inherit' }); +})(); diff --git a/artifacts/MAX-554/rendered-blog.html b/artifacts/MAX-554/rendered-blog.html new file mode 100644 index 0000000..590ab6b --- /dev/null +++ b/artifacts/MAX-554/rendered-blog.html @@ -0,0 +1,36 @@ +
Rendered HTML blog preview

Launching Ship, how Claude Code agents ship products in public

The build side of AI got fast before the launch side did. Ship is the system I built to close that gap.

You can spin up code, wire features, and move a repo faster than ever. Then the annoying part kicks in, validation, positioning, launch prep, content, analytics, follow-up, and the credential checks nobody wants to think about until a token expires five minutes before push.

That is why Ship exists. It turns that last mile into an explicit pipeline for Claude Code teams, with stage gates, role routing, proof requirements, and preflight checks before the public launch.

The GTM gap for indie hackers

A lot of launches do not miss because the product is weak. They miss because the surrounding system is soft. No real handoffs. No launch proof. No clear owner for the next stage. Ship gives that operating layer a shape.

What Ship does

Validate. Stress-test the offer, pain, and angle before overbuilding.

Build. Route implementation to the right repo and artifact surface.

Launch. Package the blog, email, screenshots, MP4, and public proof instead of leaving them scattered.

Measure. Pull stars, signups, CTR, and response signals back into the loop.

Iterate. Run the next cycle with sharper proof and fewer dumb mistakes.

The credential gate matters more than people think

Ship blocks launch actions when credentials are stale. That sounds boring until it saves forty-five minutes right when momentum matters most. Healthy or blocked. Pass or fail. Before you push, not after you break the launch.

python3 credentials/scripts/check_local.py --only "github,railway,vercel,openai,anthropic" --json

Install in 3 commands

/plugin marketplace add maxtechera/ship
+clawhub install ship
+/ship

When not to use Ship

If you just need one tiny prompt, this is too much. If you do not want stage gates or proof, this is too much. But if you want agent speed to translate into actual market movement, this is the category I wanted to exist.

CTA

Star the repo, read the launch story, and join the newsletter. Mostrá receipts o callate.

\ No newline at end of file diff --git a/artifacts/MAX-554/rendered_github_markdown_screenshot.png b/artifacts/MAX-554/rendered_github_markdown_screenshot.png new file mode 100644 index 0000000..f36f681 Binary files /dev/null and b/artifacts/MAX-554/rendered_github_markdown_screenshot.png differ diff --git a/artifacts/MAX-554/rendered_html_preview_screenshot.png b/artifacts/MAX-554/rendered_html_preview_screenshot.png new file mode 100644 index 0000000..5a602e2 Binary files /dev/null and b/artifacts/MAX-554/rendered_html_preview_screenshot.png differ diff --git a/artifacts/MAX-554/rendered_html_screenshot.png b/artifacts/MAX-554/rendered_html_screenshot.png new file mode 100644 index 0000000..5d183a5 Binary files /dev/null and b/artifacts/MAX-554/rendered_html_screenshot.png differ diff --git a/artifacts/MAX-554/screenshot_desktop.png b/artifacts/MAX-554/screenshot_desktop.png new file mode 100644 index 0000000..52ae264 Binary files /dev/null and b/artifacts/MAX-554/screenshot_desktop.png differ diff --git a/artifacts/MAX-554/screenshot_mobile.png b/artifacts/MAX-554/screenshot_mobile.png new file mode 100644 index 0000000..d0ae7fc Binary files /dev/null and b/artifacts/MAX-554/screenshot_mobile.png differ diff --git a/artifacts/MAX-554/slide-01.html b/artifacts/MAX-554/slide-01.html new file mode 100644 index 0000000..3d7579b --- /dev/null +++ b/artifacts/MAX-554/slide-01.html @@ -0,0 +1,34 @@ +
MAX-554 proof pack

Build got fast

Launch stayed messy. Ship closes that gap with stages, proof, and a real GTM operating layer.

Ship launch
\ No newline at end of file diff --git a/artifacts/MAX-554/slide-01.png b/artifacts/MAX-554/slide-01.png new file mode 100644 index 0000000..4bbbf0d Binary files /dev/null and b/artifacts/MAX-554/slide-01.png differ diff --git a/artifacts/MAX-554/slide-02.html b/artifacts/MAX-554/slide-02.html new file mode 100644 index 0000000..cf89f14 --- /dev/null +++ b/artifacts/MAX-554/slide-02.html @@ -0,0 +1,34 @@ +
MAX-554 proof pack

5 stages

Validate. Build. Launch. Measure. Iterate. No more random prompt hopping.

Pipeline
\ No newline at end of file diff --git a/artifacts/MAX-554/slide-02.png b/artifacts/MAX-554/slide-02.png new file mode 100644 index 0000000..5da603a Binary files /dev/null and b/artifacts/MAX-554/slide-02.png differ diff --git a/artifacts/MAX-554/slide-03.html b/artifacts/MAX-554/slide-03.html new file mode 100644 index 0000000..05fe0e3 --- /dev/null +++ b/artifacts/MAX-554/slide-03.html @@ -0,0 +1,34 @@ +
MAX-554 proof pack

Credential gate

Healthy or blocked, before you push. Expired tokens stop momentum more than most founders admit.

Preflight
\ No newline at end of file diff --git a/artifacts/MAX-554/slide-03.png b/artifacts/MAX-554/slide-03.png new file mode 100644 index 0000000..20f91a1 Binary files /dev/null and b/artifacts/MAX-554/slide-03.png differ diff --git a/artifacts/MAX-554/slide-04.html b/artifacts/MAX-554/slide-04.html new file mode 100644 index 0000000..b3654b4 --- /dev/null +++ b/artifacts/MAX-554/slide-04.html @@ -0,0 +1,34 @@ +
MAX-554 proof pack

Receipts

Rendered blog proof, MailerLite email, GitHub markdown, desktop and mobile screenshots, plus MP4 for Linear.

Proof pack
\ No newline at end of file diff --git a/artifacts/MAX-554/slide-04.png b/artifacts/MAX-554/slide-04.png new file mode 100644 index 0000000..28fd8fa Binary files /dev/null and b/artifacts/MAX-554/slide-04.png differ diff --git a/artifacts/MAX-561/email-preview.html b/artifacts/MAX-561/email-preview.html new file mode 100644 index 0000000..57cf02b --- /dev/null +++ b/artifacts/MAX-561/email-preview.html @@ -0,0 +1,22 @@ +
MailerLite feature block

9,000 Claude plugins, I kept 9

The delete list mattered more than the install list.

40+plugins tested in Q1
47/review runs last week
70 minblog to publish chain
Email body

Read the full breakdown

I spent Q1 testing 40+ Claude Code plugins and ended up with a smaller, more useful conclusion. The win was not more plugins. It was a curated operator stack that actually survives daily use. In the new piece, I break down the filter I use, the 3 plugins that stayed in heavy rotation, and the receipts behind the stack.

Read the full breakdown
\ No newline at end of file diff --git a/artifacts/MAX-561/final_mp4_attachment.mp4 b/artifacts/MAX-561/final_mp4_attachment.mp4 new file mode 100644 index 0000000..603cb64 Binary files /dev/null and b/artifacts/MAX-561/final_mp4_attachment.mp4 differ diff --git a/artifacts/MAX-561/linear_attached_visual_proof.png b/artifacts/MAX-561/linear_attached_visual_proof.png new file mode 100644 index 0000000..59ff341 Binary files /dev/null and b/artifacts/MAX-561/linear_attached_visual_proof.png differ diff --git a/artifacts/MAX-561/package-schema-comment.md b/artifacts/MAX-561/package-schema-comment.md new file mode 100644 index 0000000..0bd0a35 --- /dev/null +++ b/artifacts/MAX-561/package-schema-comment.md @@ -0,0 +1,190 @@ +## Package Schema + +```json +{ + "ticket_id": "MAX-561", + "content_type": "social-package", + "target_repo": "maxtechera/orchestrator", + "target_system": "mailerlite", + "brand": "max-techera", + "locale": "en-es", + "pillar": { + "ticket_id": "MAX-555", + "url": "https://maxtechera.com/blog/claude-plugins-from-single-chatbot-to-real-operator-surface", + "repo_url": "https://github.com/maxtechera/claude-plugins", + "core_receipts": [ + "9,000 Claude Code plugins in the market, 9 kept", + "40+ plugins tested in Q1", + "47 /review runs last week", + "Blog-to-published chain cut to ~70 minutes" + ] + }, + "placements": { + "instagram_reel": { + "hook_primary": "9,000 Claude Code plugins. I still run 9. Acá está el filtro.", + "hook_alternates": [ + "Claude no necesitaba más prompts. Necesitaba mejores superficies.", + "Probé 40+ plugins para dejar de perder context-window budget en boludeces." + ], + "cta": "GitHub stars", + "cta_url": "https://github.com/maxtechera/claude-plugins?utm_source=instagram&utm_campaign=claude-plugins-launch", + "duration_seconds": 56, + "aspect_ratio": "9:16", + "script_sections": { + "hook_0_3s": "9,000 Claude Code plugins. Yo me quedé con 9.", + "stakes_3_6s": "Más plugins no te dan mejor workflow. Te dan ruido, overlap y menos foco.", + "credibility_6_8s": "En Q1 probé más de 40. La semana pasada corrí 47 /review runs con mi stack real.", + "promise_8_10s": "La ganancia vino cuando dejé de acumular y empecé a curar.", + "body_10_40s": "El problema no es tener más prompts. Es darle a Claude mejores superficies de acción. dev-essentials me limpia el loop técnico. content-creator me acelera el blog-to-social chain. hormozi me baja ideas de oferta y hooks sin salir del flujo.", + "close_40_52s": "Si estás instalando todo lo que aparece en marketplaces, hacé la inversa. Elegí menos. Elegí mejor. Mostrá receipts o callate.", + "cta_52_60s": "Dale una estrella al repo y robate el stack." + }, + "caption": "9,000 plugins en el mercado. Yo dejé 9 porque el problema no era falta de opciones, era falta de criterio.\n\nSi usás Claude Code para trabajo real, te conviene una pila chica, opinionated y con receipts.\n\nRepo: https://github.com/maxtechera/claude-plugins?utm_source=instagram&utm_campaign=claude-plugins-launch\n\nComentá STACK si querés que suba el breakdown de los 9.", + "character_counts": { + "caption": 319 + }, + "assets": { + "final_mp4_attachment": "artifacts/MAX-561/final_mp4_attachment.mp4" + } + }, + "instagram_carousel": { + "hook_primary": "9,000 Claude Code plugins. I kept 9.", + "cta": "GitHub stars", + "cta_url": "https://github.com/maxtechera/claude-plugins?utm_source=instagram&utm_campaign=claude-plugins-launch", + "slides": [ + "9,000 Claude Code plugins. I kept 9.", + "Más opciones no te dan mejor sistema. Muchas veces te dan más ruido.", + "Mi criterio cambió cuando dejé de pensar en plugins como hacks sueltos.", + "Empecé a mirarlos como operator surfaces. Si no mejoran una superficie real, afuera.", + "Probé 40+ en Q1. La mayoría duplicaba funciones, agregaba fricción o rompía foco.", + "Los 3 que más empujan mi stack hoy: dev-essentials, content-creator, hormozi.", + "Receipts: 47 /review runs la semana pasada y un chain de blog a publish en ~70 min.", + "Curated beats bulk. Opinionated beats infinite choice.", + "No necesitas otro plugin dump. Necesitás un stack que gane horas. Dale estrella al repo y llevate el filtro." + ], + "caption": "No armé claude-plugins para tener una colección linda. Lo armé para dejar de probar cosas que no sobrevivían una semana de uso real.\n\nSi querés ver qué entró, qué salió y por qué, arrancá por el repo.\n\nhttps://github.com/maxtechera/claude-plugins?utm_source=instagram&utm_campaign=claude-plugins-launch" + }, + "tiktok": { + "hook_primary": "Si tu Claude sigue siendo solo chat, te falta una superficie operativa.", + "hook_alternates": [ + "El problema no era instalar más plugins. Era elegir menos.", + "Esto me ahorró una tarde entera de prueba y error con Claude Code." + ], + "cta": "GitHub stars", + "cta_url": "https://github.com/maxtechera/claude-plugins?utm_source=tiktok&utm_campaign=claude-plugins-launch", + "script": "Si tu Claude sigue siendo solo chat, te falta una superficie operativa. Yo cometí el error clásico. Empecé a instalar plugins como si más cantidad fuera más leverage. No era así. Después de probar más de 40 en Q1, me quedé con 9 daily drivers. Los demás me comían contexto, duplicaban cosas o metían fricción. Ahí entendí la regla: curated stack beats plugin hoarding. dev-essentials para trabajo técnico. content-creator para multiplicar contenido. hormozi para hooks y offers sin cortar el flujo. Eso me cambió el loop. Menos ruido, más shipping. Si querés copiar el stack, dejé el repo abajo.", + "caption": "No te falta otro plugin. Te falta un filtro.\n\nRepo: https://github.com/maxtechera/claude-plugins?utm_source=tiktok&utm_campaign=claude-plugins-launch" + }, + "x_thread": { + "hook_primary": "9,000 plugins in the market. I kept 9. The delete list mattered more than the install list.", + "hook_alternates": [ + "The unlock was not more prompts. It was better operator surfaces.", + "If your Claude stack feels noisy, your plugin list is probably the bug." + ], + "cta": "GitHub stars", + "cta_url": "https://github.com/maxtechera/claude-plugins?utm_source=x&utm_campaign=claude-plugins-launch", + "posts": [ + "9,000 Claude Code plugins in the market. I kept 9. That ended up being the real lesson.", + "I thought the win would come from installing more. Instead, most of the gains came from deleting overlap, noise, and stuff that burned context-window budget.", + "In Q1 I tested 40+ plugins. Most were fine in isolation. Very few survived a real week of daily use.", + "The filter I use now is simple: if it does not improve a real operator surface, it is out.", + "Three that stayed in heavy rotation: dev-essentials, content-creator, hormozi. Technical flow, content multiplication, and offer work, without leaving Claude.", + "Receipts: 47 /review runs last week. A blog-to-published chain that dropped to ~70 min instead of eating most of an afternoon.", + "If your Claude stack feels noisy, your plugin list is probably the bug. Repo: https://github.com/maxtechera/claude-plugins?utm_source=x&utm_campaign=claude-plugins-launch\n\nMostrá receipts o callate." + ], + "media_notes": [ + "Tweet 3 image: repo README plugin table screenshot", + "Tweet 5 image: install commands crop for the 3 anchor plugins", + "Tweet 6 image: metrics card with 47 review runs and 70-minute chain" + ] + }, + "linkedin_post": { + "hook_primary": "The highest leverage Claude Code decision I made this quarter was uninstalling most of my plugins.", + "hook_alternates": [ + "Curated plugin stacks beat plugin abundance.", + "The operator surface is becoming the real product layer in AI workflows." + ], + "cta": "Newsletter in comments", + "cta_url": "https://maxtechera.com/newsletter?utm_source=linkedin&utm_campaign=claude-plugins-launch", + "body": "The highest leverage Claude Code decision I made this quarter was uninstalling most of my plugins.\n\nI tested 40+ in Q1. I kept 9.\n\nThat sounds like a tooling story, but it is really an operating model story. A lot of teams still treat AI tooling like feature collection. More plugins. More prompts. More choices. In practice, that usually creates overlap, friction, and more context-window budget burned on things that never become daily drivers.\n\nWhat worked better for me was a stricter filter: if a plugin does not improve a real operator surface, it is out.\n\nThat left me with a small stack I actually use for technical work, content multiplication, and offer development. Last week alone, that stack supported 47 /review runs and a much faster blog-to-publish chain.\n\nCurated stacks beat plugin abundance. Opinionated workflows beat plugin tourism.\n\nIf you want the deeper operator-surface breakdown, I dropped the newsletter link in the first comment.", + "comment_cta": "If you want the operator-surface breakdown and the exact stack, acá va: https://maxtechera.com/newsletter?utm_source=linkedin&utm_campaign=claude-plugins-launch", + "character_counts": { + "body": 1168 + } + }, + "youtube_short": { + "cta": "GitHub stars", + "cta_url": "https://github.com/maxtechera/claude-plugins?utm_source=youtube&utm_campaign=claude-plugins-launch", + "title": "9,000 Claude plugins, I kept 9", + "description": "I tested 40+ Claude Code plugins in Q1 and kept 9 daily drivers. Repo: https://github.com/maxtechera/claude-plugins?utm_source=youtube&utm_campaign=claude-plugins-launch", + "script": "9,000 Claude Code plugins exist right now. I use 9. And honestly, the unlock was not finding more. It was uninstalling most of them. I tested 40+ plugins in Q1 and filtered them by one rule: if the plugin did not improve a real operator surface, it was out. That left me with a stack I actually use. Technical work with dev-essentials. Content flow with content-creator. Offer and hook work with hormozi. The result was less context waste, less plugin overlap, and faster real work. If your Claude setup feels noisy, your plugin list might be the problem. Repo is below." + }, + "email": { + "cta": "Read the pillar post", + "cta_url": "https://maxtechera.com/blog/claude-plugins-from-single-chatbot-to-real-operator-surface?utm_source=newsletter&utm_campaign=claude-plugins-launch", + "subject_options": [ + "9,000 Claude plugins, I kept 9", + "The operator-surface filter I use for Claude", + "I uninstalled most of my Claude plugins" + ], + "preview_text": "The delete list mattered more than the install list.", + "feature_block_text": "I spent Q1 testing 40+ Claude Code plugins and ended up with a smaller, more useful conclusion. The win was not more plugins. It was a curated operator stack that actually survives daily use. In the new piece, I break down the filter I use, the 3 plugins that stayed in heavy rotation, and the receipts behind the stack.", + "html_preview": "artifacts/MAX-561/email-preview.html", + "rendered_html_preview_screenshot": "artifacts/MAX-561/rendered_html_preview_screenshot.png" + }, + "autoschedule_plan": { + "monday": "X thread, 14:00 UTC", + "tuesday": "LinkedIn post + comment link, 16:00 UTC", + "wednesday": "Instagram Reel, 18:00 UTC", + "thursday": "Instagram Carousel, 18:00 UTC", + "friday": "TikTok, 17:00 UTC", + "saturday": "YouTube Short, 15:00 UTC", + "sunday": "NODO feature block, 13:00 UTC" + }, + "reply_packs": { + "instagram": [ + "Sí, la idea no es instalar más. Es quedarte con lo que sobrevive trabajo real.", + "Si querés, después subo el breakdown completo de los 9 que sigo usando.", + "Context-window budget también es presupuesto.", + "Ese fue mi error al principio también, demasiadas opciones, poco criterio.", + "Repo acá: https://github.com/maxtechera/claude-plugins?utm_source=instagram&utm_campaign=claude-plugins-launch" + ], + "tiktok": [ + "La clave fue borrar más de lo que instalé.", + "Plugin tourism mata foco.", + "Si querés la lista exacta, la dejo en el repo.", + "El filtro fue operator surface, no novelty.", + "Repo: https://github.com/maxtechera/claude-plugins?utm_source=tiktok&utm_campaign=claude-plugins-launch" + ], + "x": [ + "The delete list was honestly the harder part.", + "Most plugins were fine, just not daily-driver good.", + "Operator surface became the filter.", + "If you want the full reasoning, the pillar post goes deeper.", + "Repo: https://github.com/maxtechera/claude-plugins?utm_source=x&utm_campaign=claude-plugins-launch" + ], + "linkedin": [ + "The interesting shift was treating plugin choice as workflow design, not feature collection.", + "I underestimated how much overlap was costing in attention.", + "The curated stack is smaller than most people expect.", + "Happy to post the exact filter if useful.", + "Newsletter comment link is above if you want the deeper operator-surface breakdown." + ], + "youtube": [ + "Most of the gains came from uninstalling, which surprised me too.", + "The 3 anchors are doing very different jobs in the workflow.", + "If the setup feels noisy, reduce before you add.", + "The repo is in the description if you want the stack.", + "I’ll probably do a full video on the delete criteria next." + ] + } + }, + "proof": { + "pr_url": "https://github.com/maxtechera/orchestrator/pull/18", + "linear_attached_visual_proof": "artifacts/MAX-561/linear_attached_visual_proof.png", + "rendered_html_preview_screenshot": "artifacts/MAX-561/rendered_html_preview_screenshot.png", + "final_mp4_attachment": "artifacts/MAX-561/final_mp4_attachment.mp4" + } +} + +``` diff --git a/artifacts/MAX-561/package.json b/artifacts/MAX-561/package.json new file mode 100644 index 0000000..5012d24 --- /dev/null +++ b/artifacts/MAX-561/package.json @@ -0,0 +1,185 @@ +{ + "ticket_id": "MAX-561", + "content_type": "social-package", + "target_repo": "maxtechera/orchestrator", + "target_system": "mailerlite", + "brand": "max-techera", + "locale": "en-es", + "pillar": { + "ticket_id": "MAX-555", + "url": "https://maxtechera.com/blog/claude-plugins-from-single-chatbot-to-real-operator-surface", + "repo_url": "https://github.com/maxtechera/claude-plugins", + "core_receipts": [ + "9,000 Claude Code plugins in the market, 9 kept", + "40+ plugins tested in Q1", + "47 /review runs last week", + "Blog-to-published chain cut to ~70 minutes" + ] + }, + "placements": { + "instagram_reel": { + "hook_primary": "9,000 Claude Code plugins. I still run 9. Acá está el filtro.", + "hook_alternates": [ + "Claude no necesitaba más prompts. Necesitaba mejores superficies.", + "Probé 40+ plugins para dejar de perder context-window budget en boludeces." + ], + "cta": "GitHub stars", + "cta_url": "https://github.com/maxtechera/claude-plugins?utm_source=instagram&utm_campaign=claude-plugins-launch", + "duration_seconds": 56, + "aspect_ratio": "9:16", + "script_sections": { + "hook_0_3s": "9,000 Claude Code plugins. Yo me quedé con 9.", + "stakes_3_6s": "Más plugins no te dan mejor workflow. Te dan ruido, overlap y menos foco.", + "credibility_6_8s": "En Q1 probé más de 40. La semana pasada corrí 47 /review runs con mi stack real.", + "promise_8_10s": "La ganancia vino cuando dejé de acumular y empecé a curar.", + "body_10_40s": "El problema no es tener más prompts. Es darle a Claude mejores superficies de acción. dev-essentials me limpia el loop técnico. content-creator me acelera el blog-to-social chain. hormozi me baja ideas de oferta y hooks sin salir del flujo.", + "close_40_52s": "Si estás instalando todo lo que aparece en marketplaces, hacé la inversa. Elegí menos. Elegí mejor. Mostrá receipts o callate.", + "cta_52_60s": "Dale una estrella al repo y robate el stack." + }, + "caption": "9,000 plugins en el mercado. Yo dejé 9 porque el problema no era falta de opciones, era falta de criterio.\n\nSi usás Claude Code para trabajo real, te conviene una pila chica, opinionated y con receipts.\n\nRepo: https://github.com/maxtechera/claude-plugins?utm_source=instagram&utm_campaign=claude-plugins-launch\n\nComentá STACK si querés que suba el breakdown de los 9.", + "character_counts": { + "caption": 319 + }, + "assets": { + "final_mp4_attachment": "artifacts/MAX-561/final_mp4_attachment.mp4" + } + }, + "instagram_carousel": { + "hook_primary": "9,000 Claude Code plugins. I kept 9.", + "cta": "GitHub stars", + "cta_url": "https://github.com/maxtechera/claude-plugins?utm_source=instagram&utm_campaign=claude-plugins-launch", + "slides": [ + "9,000 Claude Code plugins. I kept 9.", + "Más opciones no te dan mejor sistema. Muchas veces te dan más ruido.", + "Mi criterio cambió cuando dejé de pensar en plugins como hacks sueltos.", + "Empecé a mirarlos como operator surfaces. Si no mejoran una superficie real, afuera.", + "Probé 40+ en Q1. La mayoría duplicaba funciones, agregaba fricción o rompía foco.", + "Los 3 que más empujan mi stack hoy: dev-essentials, content-creator, hormozi.", + "Receipts: 47 /review runs la semana pasada y un chain de blog a publish en ~70 min.", + "Curated beats bulk. Opinionated beats infinite choice.", + "No necesitas otro plugin dump. Necesitás un stack que gane horas. Dale estrella al repo y llevate el filtro." + ], + "caption": "No armé claude-plugins para tener una colección linda. Lo armé para dejar de probar cosas que no sobrevivían una semana de uso real.\n\nSi querés ver qué entró, qué salió y por qué, arrancá por el repo.\n\nhttps://github.com/maxtechera/claude-plugins?utm_source=instagram&utm_campaign=claude-plugins-launch" + }, + "tiktok": { + "hook_primary": "Si tu Claude sigue siendo solo chat, te falta una superficie operativa.", + "hook_alternates": [ + "El problema no era instalar más plugins. Era elegir menos.", + "Esto me ahorró una tarde entera de prueba y error con Claude Code." + ], + "cta": "GitHub stars", + "cta_url": "https://github.com/maxtechera/claude-plugins?utm_source=tiktok&utm_campaign=claude-plugins-launch", + "script": "Si tu Claude sigue siendo solo chat, te falta una superficie operativa. Yo cometí el error clásico. Empecé a instalar plugins como si más cantidad fuera más leverage. No era así. Después de probar más de 40 en Q1, me quedé con 9 daily drivers. Los demás me comían contexto, duplicaban cosas o metían fricción. Ahí entendí la regla: curated stack beats plugin hoarding. dev-essentials para trabajo técnico. content-creator para multiplicar contenido. hormozi para hooks y offers sin cortar el flujo. Eso me cambió el loop. Menos ruido, más shipping. Si querés copiar el stack, dejé el repo abajo.", + "caption": "No te falta otro plugin. Te falta un filtro.\n\nRepo: https://github.com/maxtechera/claude-plugins?utm_source=tiktok&utm_campaign=claude-plugins-launch" + }, + "x_thread": { + "hook_primary": "9,000 plugins in the market. I kept 9. The delete list mattered more than the install list.", + "hook_alternates": [ + "The unlock was not more prompts. It was better operator surfaces.", + "If your Claude stack feels noisy, your plugin list is probably the bug." + ], + "cta": "GitHub stars", + "cta_url": "https://github.com/maxtechera/claude-plugins?utm_source=x&utm_campaign=claude-plugins-launch", + "posts": [ + "9,000 Claude Code plugins in the market. I kept 9. That ended up being the real lesson.", + "I thought the win would come from installing more. Instead, most of the gains came from deleting overlap, noise, and stuff that burned context-window budget.", + "In Q1 I tested 40+ plugins. Most were fine in isolation. Very few survived a real week of daily use.", + "The filter I use now is simple: if it does not improve a real operator surface, it is out.", + "Three that stayed in heavy rotation: dev-essentials, content-creator, hormozi. Technical flow, content multiplication, and offer work, without leaving Claude.", + "Receipts: 47 /review runs last week. A blog-to-published chain that dropped to ~70 min instead of eating most of an afternoon.", + "If your Claude stack feels noisy, your plugin list is probably the bug. Repo: https://github.com/maxtechera/claude-plugins?utm_source=x&utm_campaign=claude-plugins-launch\n\nMostrá receipts o callate." + ], + "media_notes": [ + "Tweet 3 image: repo README plugin table screenshot", + "Tweet 5 image: install commands crop for the 3 anchor plugins", + "Tweet 6 image: metrics card with 47 review runs and 70-minute chain" + ] + }, + "linkedin_post": { + "hook_primary": "The highest leverage Claude Code decision I made this quarter was uninstalling most of my plugins.", + "hook_alternates": [ + "Curated plugin stacks beat plugin abundance.", + "The operator surface is becoming the real product layer in AI workflows." + ], + "cta": "Newsletter in comments", + "cta_url": "https://maxtechera.com/newsletter?utm_source=linkedin&utm_campaign=claude-plugins-launch", + "body": "The highest leverage Claude Code decision I made this quarter was uninstalling most of my plugins.\n\nI tested 40+ in Q1. I kept 9.\n\nThat sounds like a tooling story, but it is really an operating model story. A lot of teams still treat AI tooling like feature collection. More plugins. More prompts. More choices. In practice, that usually creates overlap, friction, and more context-window budget burned on things that never become daily drivers.\n\nWhat worked better for me was a stricter filter: if a plugin does not improve a real operator surface, it is out.\n\nThat left me with a small stack I actually use for technical work, content multiplication, and offer development. Last week alone, that stack supported 47 /review runs and a much faster blog-to-publish chain.\n\nCurated stacks beat plugin abundance. Opinionated workflows beat plugin tourism.\n\nIf you want the deeper operator-surface breakdown, I dropped the newsletter link in the first comment.", + "comment_cta": "If you want the operator-surface breakdown and the exact stack, acá va: https://maxtechera.com/newsletter?utm_source=linkedin&utm_campaign=claude-plugins-launch", + "character_counts": { + "body": 1168 + } + }, + "youtube_short": { + "cta": "GitHub stars", + "cta_url": "https://github.com/maxtechera/claude-plugins?utm_source=youtube&utm_campaign=claude-plugins-launch", + "title": "9,000 Claude plugins, I kept 9", + "description": "I tested 40+ Claude Code plugins in Q1 and kept 9 daily drivers. Repo: https://github.com/maxtechera/claude-plugins?utm_source=youtube&utm_campaign=claude-plugins-launch", + "script": "9,000 Claude Code plugins exist right now. I use 9. And honestly, the unlock was not finding more. It was uninstalling most of them. I tested 40+ plugins in Q1 and filtered them by one rule: if the plugin did not improve a real operator surface, it was out. That left me with a stack I actually use. Technical work with dev-essentials. Content flow with content-creator. Offer and hook work with hormozi. The result was less context waste, less plugin overlap, and faster real work. If your Claude setup feels noisy, your plugin list might be the problem. Repo is below." + }, + "email": { + "cta": "Read the pillar post", + "cta_url": "https://maxtechera.com/blog/claude-plugins-from-single-chatbot-to-real-operator-surface?utm_source=newsletter&utm_campaign=claude-plugins-launch", + "subject_options": [ + "9,000 Claude plugins, I kept 9", + "The operator-surface filter I use for Claude", + "I uninstalled most of my Claude plugins" + ], + "preview_text": "The delete list mattered more than the install list.", + "feature_block_text": "I spent Q1 testing 40+ Claude Code plugins and ended up with a smaller, more useful conclusion. The win was not more plugins. It was a curated operator stack that actually survives daily use. In the new piece, I break down the filter I use, the 3 plugins that stayed in heavy rotation, and the receipts behind the stack.", + "html_preview": "artifacts/MAX-561/email-preview.html", + "rendered_html_preview_screenshot": "artifacts/MAX-561/rendered_html_preview_screenshot.png" + }, + "autoschedule_plan": { + "monday": "X thread, 14:00 UTC", + "tuesday": "LinkedIn post + comment link, 16:00 UTC", + "wednesday": "Instagram Reel, 18:00 UTC", + "thursday": "Instagram Carousel, 18:00 UTC", + "friday": "TikTok, 17:00 UTC", + "saturday": "YouTube Short, 15:00 UTC", + "sunday": "NODO feature block, 13:00 UTC" + }, + "reply_packs": { + "instagram": [ + "Sí, la idea no es instalar más. Es quedarte con lo que sobrevive trabajo real.", + "Si querés, después subo el breakdown completo de los 9 que sigo usando.", + "Context-window budget también es presupuesto.", + "Ese fue mi error al principio también, demasiadas opciones, poco criterio.", + "Repo acá: https://github.com/maxtechera/claude-plugins?utm_source=instagram&utm_campaign=claude-plugins-launch" + ], + "tiktok": [ + "La clave fue borrar más de lo que instalé.", + "Plugin tourism mata foco.", + "Si querés la lista exacta, la dejo en el repo.", + "El filtro fue operator surface, no novelty.", + "Repo: https://github.com/maxtechera/claude-plugins?utm_source=tiktok&utm_campaign=claude-plugins-launch" + ], + "x": [ + "The delete list was honestly the harder part.", + "Most plugins were fine, just not daily-driver good.", + "Operator surface became the filter.", + "If you want the full reasoning, the pillar post goes deeper.", + "Repo: https://github.com/maxtechera/claude-plugins?utm_source=x&utm_campaign=claude-plugins-launch" + ], + "linkedin": [ + "The interesting shift was treating plugin choice as workflow design, not feature collection.", + "I underestimated how much overlap was costing in attention.", + "The curated stack is smaller than most people expect.", + "Happy to post the exact filter if useful.", + "Newsletter comment link is above if you want the deeper operator-surface breakdown." + ], + "youtube": [ + "Most of the gains came from uninstalling, which surprised me too.", + "The 3 anchors are doing very different jobs in the workflow.", + "If the setup feels noisy, reduce before you add.", + "The repo is in the description if you want the stack.", + "I’ll probably do a full video on the delete criteria next." + ] + } + }, + "proof": { + "pr_url": "https://github.com/maxtechera/orchestrator/pull/18", + "linear_attached_visual_proof": "artifacts/MAX-561/linear_attached_visual_proof.png", + "rendered_html_preview_screenshot": "artifacts/MAX-561/rendered_html_preview_screenshot.png", + "final_mp4_attachment": "artifacts/MAX-561/final_mp4_attachment.mp4" + } +} diff --git a/artifacts/MAX-561/proof-pack.md b/artifacts/MAX-561/proof-pack.md new file mode 100644 index 0000000..738698e --- /dev/null +++ b/artifacts/MAX-561/proof-pack.md @@ -0,0 +1,22 @@ +# MAX-561 proof pack + +## Scope +- Ticket: MAX-561 +- Pillar source: MAX-555 +- Pillar URL: https://maxtechera.com/blog/claude-plugins-from-single-chatbot-to-real-operator-surface +- Repo CTA: https://github.com/maxtechera/claude-plugins +- Newsletter CTA: https://maxtechera.com/newsletter + +## What shipped in repo +- Machine-readable package schema: `artifacts/MAX-561/package.json` +- Email preview HTML: `artifacts/MAX-561/email-preview.html` +- Social bundle preview HTML: `artifacts/MAX-561/social-package-preview.html` +- Visual proof image for Linear: `artifacts/MAX-561/linear_attached_visual_proof.png` +- Rendered email preview screenshot: `artifacts/MAX-561/rendered_html_preview_screenshot.png` +- MP4 attachment: `artifacts/MAX-561/final_mp4_attachment.mp4` + +## Notes +- Source copy adapted from the shipped working draft in `repos/ship/docs/marketing/MAX-561-claude-plugins-social-package.md`. +- Every outbound CTA in the package schema uses `utm_campaign=claude-plugins-launch` with platform-specific `utm_source` values. +- LinkedIn keeps the link in the comment CTA, not the body. +- Email preview is ready for MailerLite block import. diff --git a/artifacts/MAX-561/render-assets.js b/artifacts/MAX-561/render-assets.js new file mode 100644 index 0000000..9f35352 --- /dev/null +++ b/artifacts/MAX-561/render-assets.js @@ -0,0 +1,55 @@ +const fs = require('fs'); +const path = require('path'); +const { chromium } = require('playwright'); + +const outDir = __dirname; +const pkg = JSON.parse(fs.readFileSync(path.join(outDir, 'package.json'), 'utf8')); + +const email = pkg.placements.email; +const reel = pkg.placements.instagram_reel; +const thread = pkg.placements.x_thread; +const linkedin = pkg.placements.linkedin_post; +const carousel = pkg.placements.instagram_carousel; + +const css = ` +:root { color-scheme: dark; } +* { box-sizing: border-box; } +body { margin: 0; font-family: Inter, Arial, sans-serif; background: #07111f; color: #f8fafc; } +a { color: inherit; } +.wrap { max-width: 1200px; margin: 0 auto; padding: 40px 32px 80px; } +.hero { padding: 36px; border-radius: 28px; background: linear-gradient(135deg, #0f172a, #1d4ed8 60%, #f97316 120%); box-shadow: 0 18px 60px rgba(0,0,0,.35); } +.eyebrow { text-transform: uppercase; letter-spacing: .12em; font-size: 12px; font-weight: 700; opacity: .8; } +h1 { margin: 12px 0 8px; font-size: 52px; line-height: 1; } +p.lead { font-size: 20px; line-height: 1.6; max-width: 900px; color: #dbeafe; } +.grid { display: grid; grid-template-columns: repeat(2, minmax(0, 1fr)); gap: 24px; margin-top: 24px; } +.card { border-radius: 24px; background: rgba(15, 23, 42, .86); border: 1px solid rgba(255,255,255,.08); padding: 24px; box-shadow: 0 10px 30px rgba(0,0,0,.2); } +.card h2, .card h3 { margin: 0 0 12px; } +.card p, .card li { color: #dbe4ff; font-size: 17px; line-height: 1.55; } +.badge { display:inline-block; border-radius:999px; padding: 6px 10px; background:#172554; color:#bfdbfe; font-size:12px; font-weight:700; letter-spacing:.06em; text-transform:uppercase; margin-bottom: 12px; } +.kpis { display:flex; gap:12px; flex-wrap:wrap; margin-top: 18px; } +.kpi { min-width: 160px; padding: 14px 16px; border-radius: 20px; background: rgba(255,255,255,.09); } +.kpi strong { display:block; font-size: 28px; } +pre { white-space: pre-wrap; font-family: ui-monospace, monospace; font-size: 14px; line-height: 1.55; color: #e2e8f0; margin: 0; } +.cta { display:inline-block; margin-top: 14px; background: #f97316; color: white; padding: 14px 18px; border-radius: 999px; text-decoration: none; font-weight: 700; } +.col-1 { display:grid; gap:24px; } +`; + +const emailHtml = `
MailerLite feature block

${email.subject_options[0]}

${email.preview_text}

40+plugins tested in Q1
47/review runs last week
70 minblog to publish chain
Email body

Read the full breakdown

${email.feature_block_text}

Read the full breakdown
`; + +const socialHtml = `
MAX-561 social package

9,000 plugins in the market. Kept 9.

Cross-platform launch pack for maxtechera/claude-plugins, with native copy for Instagram, TikTok, X, LinkedIn, YouTube, and MailerLite.

15+derivatives
1pillar source
5reply packs
Instagram Reel

${reel.hook_primary}

${reel.script_sections.body_10_40s}

CTA: ${reel.cta}

Carousel

9-slide status-appeal arc

${carousel.slides.join('\n\n')}
X thread

${thread.hook_primary}

${thread.posts.join('\n\n')}
LinkedIn

Executive-advisor cut

${linkedin.body}

`; + +fs.writeFileSync(path.join(outDir, 'email-preview.html'), emailHtml); +fs.writeFileSync(path.join(outDir, 'social-package-preview.html'), socialHtml); + +(async () => { + const browser = await chromium.launch({ headless: true }); + const page = await browser.newPage({ viewport: { width: 1440, height: 1800 } }); + + await page.goto(`file://${path.join(outDir, 'email-preview.html')}`); + await page.screenshot({ path: path.join(outDir, 'rendered_html_preview_screenshot.png'), fullPage: true }); + + await page.goto(`file://${path.join(outDir, 'social-package-preview.html')}`); + await page.screenshot({ path: path.join(outDir, 'linear_attached_visual_proof.png'), fullPage: true }); + + await browser.close(); +})(); diff --git a/artifacts/MAX-561/rendered_html_preview_screenshot.png b/artifacts/MAX-561/rendered_html_preview_screenshot.png new file mode 100644 index 0000000..f75d1c5 Binary files /dev/null and b/artifacts/MAX-561/rendered_html_preview_screenshot.png differ diff --git a/artifacts/MAX-561/social-package-preview.html b/artifacts/MAX-561/social-package-preview.html new file mode 100644 index 0000000..a5dc5e6 --- /dev/null +++ b/artifacts/MAX-561/social-package-preview.html @@ -0,0 +1,64 @@ +
MAX-561 social package

9,000 plugins in the market. Kept 9.

Cross-platform launch pack for maxtechera/claude-plugins, with native copy for Instagram, TikTok, X, LinkedIn, YouTube, and MailerLite.

15+derivatives
1pillar source
5reply packs
Instagram Reel

9,000 Claude Code plugins. I still run 9. Acá está el filtro.

El problema no es tener más prompts. Es darle a Claude mejores superficies de acción. dev-essentials me limpia el loop técnico. content-creator me acelera el blog-to-social chain. hormozi me baja ideas de oferta y hooks sin salir del flujo.

CTA: GitHub stars

Carousel

9-slide status-appeal arc

9,000 Claude Code plugins. I kept 9.
+
+Más opciones no te dan mejor sistema. Muchas veces te dan más ruido.
+
+Mi criterio cambió cuando dejé de pensar en plugins como hacks sueltos.
+
+Empecé a mirarlos como operator surfaces. Si no mejoran una superficie real, afuera.
+
+Probé 40+ en Q1. La mayoría duplicaba funciones, agregaba fricción o rompía foco.
+
+Los 3 que más empujan mi stack hoy: dev-essentials, content-creator, hormozi.
+
+Receipts: 47 /review runs la semana pasada y un chain de blog a publish en ~70 min.
+
+Curated beats bulk. Opinionated beats infinite choice.
+
+No necesitas otro plugin dump. Necesitás un stack que gane horas. Dale estrella al repo y llevate el filtro.
X thread

9,000 plugins in the market. I kept 9. The delete list mattered more than the install list.

9,000 Claude Code plugins in the market. I kept 9. That ended up being the real lesson.
+
+I thought the win would come from installing more. Instead, most of the gains came from deleting overlap, noise, and stuff that burned context-window budget.
+
+In Q1 I tested 40+ plugins. Most were fine in isolation. Very few survived a real week of daily use.
+
+The filter I use now is simple: if it does not improve a real operator surface, it is out.
+
+Three that stayed in heavy rotation: dev-essentials, content-creator, hormozi. Technical flow, content multiplication, and offer work, without leaving Claude.
+
+Receipts: 47 /review runs last week. A blog-to-published chain that dropped to ~70 min instead of eating most of an afternoon.
+
+If your Claude stack feels noisy, your plugin list is probably the bug. Repo: https://github.com/maxtechera/claude-plugins?utm_source=x&utm_campaign=claude-plugins-launch
+
+Mostrá receipts o callate.
LinkedIn

Executive-advisor cut

The highest leverage Claude Code decision I made this quarter was uninstalling most of my plugins. + +I tested 40+ in Q1. I kept 9. + +That sounds like a tooling story, but it is really an operating model story. A lot of teams still treat AI tooling like feature collection. More plugins. More prompts. More choices. In practice, that usually creates overlap, friction, and more context-window budget burned on things that never become daily drivers. + +What worked better for me was a stricter filter: if a plugin does not improve a real operator surface, it is out. + +That left me with a small stack I actually use for technical work, content multiplication, and offer development. Last week alone, that stack supported 47 /review runs and a much faster blog-to-publish chain. + +Curated stacks beat plugin abundance. Opinionated workflows beat plugin tourism. + +If you want the deeper operator-surface breakdown, I dropped the newsletter link in the first comment.

\ No newline at end of file diff --git a/artifacts/MAX-564/course-outline.html b/artifacts/MAX-564/course-outline.html new file mode 100644 index 0000000..3e410bf --- /dev/null +++ b/artifacts/MAX-564/course-outline.html @@ -0,0 +1,155 @@ +
Rendered course outline

/memory course outline

Module breakdown, friction mapping, operating-model angle, and CTA copy for README plus newsletter.

# /memory course outline, OSS tool course
+
+
## Course position in the ladder
+- **Free offer:** `/memory` OSS tool
+- **Paid offer:** `/memory course` at **$97**
+- **Funnel:** GitHub star → install → friction point → README CTA → newsletter → course
+- **Audience:** Claude Code users who installed `/memory`, can run setup, but still do not trust their memory system enough to rely on it in real work.
+
+
## The friction point this course solves
+The install gets the hooks running, but the user still hits the same anxiety loop:
+
+> "I installed it, the hooks fire, but I do not actually know what a *good* persistent-memory system looks like, what to save, how to structure the vault, when to sync, or how to keep it from turning into note sludge."
+
+That is the course entry. The free tool solves **mechanics**. The course solves **operating model**.
+
+### Install pain → paid transformation map
+| Install friction after the OSS tool | What the course teaches instead |
+|---|---|
+| Hooks run, but the user cannot tell if memory quality is good or noisy | A practical rubric for what belongs in HOT, WARM, and COLD |
+| User has an Obsidian vault, but no structure for durable recall | A repeatable 3-tier architecture with folder boundaries and sync rules |
+| Sessions save data, but retrieval still feels random | Query patterns, wiki usage, and topic-file design for reliable recall |
+| The user fears memory bloat and stale notes | TTL, dream cycle, pruning, and contradiction cleanup |
+| The user can sync one session, but not a team or long-running project | A complete cross-session and cross-agent memory workflow |
+
+
## Course promise
+Build a persistent-memory system for Claude Code that survives session boundaries, compaction, subagents, and long projects, without drowning in stale notes or giant context dumps.
+
+
## Core transformation
+By the end of the course, the student goes from:
+- "I installed `/memory`, but I am not sure what it is really doing"
+- to
+- "I have a working memory architecture, I know what each tier stores, I know when to sync, and I can recover project context across sessions on demand."
+
+
## Module breakdown
+
+### Module 1. Why agents forget, and why naive note dumps fail
+**Learning outcome:** Understand the real failure modes behind session amnesia, compaction loss, and context-window overload.
+
+**Demo / exercise:**
+- Run the same Claude Code task twice, once with no memory system and once with a minimal HOT layer.
+- Identify where state gets lost: decisions, preferences, current task, and project boundaries.
+- Write a simple "before memory / after memory" diagnostic for one real workflow.
+
+### Module 2. The 3-tier architecture, HOT, WARM, COLD
+**Learning outcome:** Design a memory stack where active context stays tiny, topic knowledge loads on demand, and permanent knowledge stays searchable instead of bloating every session.
+
+**Demo / exercise:**
+- Build a full `/memory` folder layout from scratch.
+- Configure `MEMORY.md`, `SESSION-STATE.md`, `memory/topics/*.md`, and daily journals.
+- Classify 20 sample facts into HOT, WARM, or COLD and explain why.
+
+### Module 3. Hooks, setup, and the sync pipeline in real life
+**Learning outcome:** Move beyond "the hooks fired" into a reliable sync loop that survives start, stop, compaction, and multi-session work.
+
+**Demo / exercise:**
+- Run `/memory setup`, inspect installed hooks, and trace what happens on session start, compaction, and session stop.
+- Map the full detect → classify → write flow using one real project.
+- Validate one sync report and fix one intentional misconfiguration.
+
+### Module 4. Build a retrieval system that Claude can actually use
+**Learning outcome:** Structure topics, journals, and wiki pages so future sessions can pull the *right* memory instead of dumping everything back into context.
+
+**Demo / exercise:**
+- Create three topic files, one daily journal, and one wiki page from a week of work.
+- Practice queries for recent decisions, durable preferences, and project-specific rules.
+- Refactor a noisy topic file into a usable retrieval surface.
+
+### Module 5. Cross-session, cross-agent, cross-platform memory
+**Learning outcome:** Use `/memory` as infrastructure for longer runs, helpers, and platform switching, not just a personal note bucket.
+
+**Demo / exercise:**
+- Simulate a parent session that spawns a helper and hand off enough state for clean continuation.
+- Pass work from Claude Code to OpenClaw or another environment while preserving continuity.
+- Build a memory checklist for one multi-day project.
+
+### Module 6. Prevent memory rot, drift, and note sludge
+**Learning outcome:** Keep the system trustworthy over time with TTL, audits, dream cycles, and contradiction cleanup.
+
+**Demo / exercise:**
+- Run a memory audit on a deliberately messy example.
+- Expire stale topic entries, merge duplicates, and promote one durable insight into the wiki.
+- Create a weekly maintenance cadence using `/memory dream` and `/memory audit`.
+
+### Module 7. The full working system, from install to trusted recall
+**Learning outcome:** Assemble the entire system into a repeatable setup the student can use daily for coding, research, and long-lived projects.
+
+**Demo / exercise:**
+- Set up a greenfield project with `/memory`.
+- Run a two-session workflow separated by compaction or restart.
+- Recover context cleanly in the second session without re-briefing Claude manually.
+
+
## Suggested delivery shape
+- **Format:** 6 to 7 modules, short hands-on lessons
+- **Teaching style:** show the memory system live, not as theory
+- **Assets:** diagrams for tier boundaries, hook lifecycle, sync pipeline, and wiki flow
+- **Outcome:** student leaves with a working persistent-memory setup, not just conceptual understanding
+
+
## README CTA copy
+### Option A
+Installed `/memory`, but still not sure what should live in memory and what should stay out?
+
+The course shows the full system in action, HOT/WARM/COLD tiers, hooks, sync pipeline, wiki, and the maintenance loop that keeps memory useful instead of noisy.
+
+**Join the `/memory` course →** Learn the operating model behind persistent Claude Code memory.
+
+### Option B
+`/memory` gives you the engine. The course gives you the operating model.
+
+If setup worked but you still do not trust the system yet, the `/memory` course walks you through the exact architecture, retrieval patterns, and sync workflow behind a memory setup you can use every day.
+
+**Get the course →** Build a persistent-memory system that actually survives real work.
+
+
## Newsletter CTA copy
+### Option A
+You installed `/memory`. Great. But the real unlock is not the install, it is knowing how to structure the system so Claude can recover the *right* context at the right time.
+
+In the new `/memory` course, I break down the full setup, hooks, 3-tier architecture, sync pipeline, wiki flow, and the maintenance loop that keeps memory from turning into note sludge.
+
+**Enroll here →** Build your persistent-memory system for Claude Code.
+
+### Option B
+Most people stop after `/memory setup`.
+
+That gets the hooks running. It does **not** teach you what to store, how to organize the tiers, how to query old work, or how to keep the system clean when projects get long.
+
+That is exactly what the `/memory` course covers.
+
+**See the course →** From install to trusted recall.
+
\ No newline at end of file diff --git a/artifacts/MAX-564/email-preview.html b/artifacts/MAX-564/email-preview.html new file mode 100644 index 0000000..25f7d5a --- /dev/null +++ b/artifacts/MAX-564/email-preview.html @@ -0,0 +1,27 @@ +
MailerLite-ready preview

You installed /memory. Now make it trustworthy.

Most people stop after setup. The course teaches what belongs in each tier, how sync actually works, and how to keep recall useful instead of noisy.

Enroll in the /memory course
Inside

HOT, WARM, COLD explained live

Build a system Claude can query without flooding every session.

Fix the friction

From "hooks work" to "memory works"

Learn storage rules, retrieval surfaces, sync cadence, wiki flow, and anti-rot maintenance.

\ No newline at end of file diff --git a/artifacts/MAX-564/final_mp4_attachment.mp4 b/artifacts/MAX-564/final_mp4_attachment.mp4 new file mode 100644 index 0000000..fc75765 Binary files /dev/null and b/artifacts/MAX-564/final_mp4_attachment.mp4 differ diff --git a/artifacts/MAX-564/github-readme.html b/artifacts/MAX-564/github-readme.html new file mode 100644 index 0000000..47f814f --- /dev/null +++ b/artifacts/MAX-564/github-readme.html @@ -0,0 +1,385 @@ +
# /orchestrator
+
+[![MIT License](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)
+[![Version](https://img.shields.io/badge/version-1.0.0-green.svg)](CHANGELOG.md)
+
+**Expert orchestrator of agentic teams. The ticket contract defines work. The verification harness rules completion.**
+
+Claude Code:
+```
+/plugin marketplace add maxtechera/orchestrator
+```
+
+OpenClaw:
+```
+clawhub install orchestrator
+```
+
+Zero config. Run `/orchestrator sweep` immediately — if no board is connected, the setup wizard runs automatically.
+
+---
+
+## Install
+
+### Claude Code
+
+#### Install
+```
+/plugin marketplace add maxtechera/orchestrator
+```
+
+#### Update
+```
+claude plugin update orchestrator@orchestrator
+```
+
+### OpenClaw
+```bash
+clawhub install orchestrator
+```
+
+### Manual
+```bash
+git clone https://github.com/maxtechera/orchestrator.git ~/.claude/skills/orchestrator
+```
+
+**The agent that did the work never grades its own homework.** A separate verification pass runs with fresh context — real API calls, screenshots, link checks, compliance validation. Not another AI saying "looks good."
+
+**The core pattern:** Ticket contract (Inputs / Deliverables / Verification / Artifacts) → dispatch worker agent → independent verifier → evidence posted to ticket. One cycle, every ticket.
+
+**Best for:** operators running agentic teams who want verified output, not just agent output.
+
+That's it. Run `/orchestrator sweep` to get started. If no board is connected, the orchestrator will prompt you to run `/orchestrator setup`. See [Your First Ticket](#your-first-ticket) below for a copy-paste template.
+
+---
+
+## What people use it for
+
+**Running a content operation.** `/orchestrator sweep` reads all open tickets, dispatches content agents loaded with your brand voice, and independently verifies every deliverable before marking it done. Not just "here's a draft" — checked output.
+
+**Managing an e-commerce store.** Set `BOARD_PROVIDER=linear` and connect Shopify. The orchestrator processes inventory updates, price changes, and product listings — and verifies prices, compare-at fields, and image counts before closing tickets.
+
+**Engineering ticket flow.** `/orchestrator sweep` picks up GitHub Issues, runs domain-specific verification (link checks, schema validation, test presence), and only marks tickets done when the deliverable actually passes.
+
+**Auditing before a release.** `/orchestrator review <ticket>` independently checks a specific deliverable. The agent that did the work never grades its own homework.
+
+---
+
+## Setup: Progressive Integration Unlocking
+
+Start using `/orchestrator` immediately. Add integrations when you want more domains.
+
+### 1. Zero Config (built-in skills) — Just install
+
+Run `/orchestrator sweep`. The orchestrator uses your existing board connections (MCP servers for Linear, GitHub, etc.) and built-in agent capabilities. No API keys, no configuration. If no board is detected, you'll be prompted to run `/orchestrator setup`.
+
+### 2. Run the setup wizard (connect your board)
+
+```
+/orchestrator setup
+```
+
+The setup wizard detects your environment, connects your issue tracker, and validates integrations. Takes about 30 seconds. Supports Linear, GitHub Issues, Notion, and Jira. It writes `BOARD_PROVIDER` and your API key to `~/.config/orchestrator/.env`.
+
+If you prefer manual config:
+
+```bash
+mkdir -p ~/.config/orchestrator && chmod 700 ~/.config/orchestrator
+```
+
+Then add to `~/.config/orchestrator/.env`:
+
+```bash
+# Add to ~/.config/orchestrator/.env
+BOARD_PROVIDER=linear        # or: github, notion, jira
+LINEAR_API_KEY=lin_api_xxxxx  # swap for your tracker's key
+```
+
+### 3. Add domain skills (RECOMMENDED — the single most impactful upgrade)
+
+**Domain skills give agents real expertise** — domain-specific rules, verification criteria, and best practices learned from actual executions. Without them, agents use general capabilities. With them, they follow rules like "carousel images must be 1080x1350" and "always verify compare-at price is cleared when not on sale."
+
+Domain skills are **composition wrappers** — they load [`maxtechera/ship`](https://github.com/maxtechera/ship) and [`maxtechera/memory`](https://github.com/maxtechera/memory) skills and add domain-specific verification rules on top. Install ship and memory first, then the domain skill activates their capabilities for orchestrator verification. See [skills/README.md](skills/README.md) for the full list and their composition chains.
+
+```
+/plugin marketplace add maxtechera/skill-content
+/plugin marketplace add maxtechera/skill-ecommerce
+/plugin marketplace add maxtechera/skill-seo
+```
+
+### 4. Add Shopify (e-commerce verification)
+
+Connect your Shopify store for automated price, inventory, and product verification.
+
+```bash
+# Add to ~/.config/orchestrator/.env
+SHOPIFY_ACCESS_TOKEN=shpat_xxxxx
+```
+
+### 5. Add MailerLite (content/newsletter verification)
+
+Free tier at [mailerlite.com](https://mailerlite.com). Enables email sequence verification — link checks, segment validation, send tests.
+
+```bash
+# Add to ~/.config/orchestrator/.env
+MAILERLITE_API_KEY=xxxxx
+```
+
+### 6. Add Apollo (sales verification)
+
+Free tier at [apollo.io](https://apollo.io). Enables lead sourcing verification — bounce rate, compliance, sequence validation.
+
+```bash
+# Add to ~/.config/orchestrator/.env
+APOLLO_API_KEY=xxxxx
+```
+
+### 7. Optional integrations
+
+```bash
+# Add to ~/.config/orchestrator/.env
+META_ADS_TOKEN=xxxxx          # Meta Ads — campaign management
+GOOGLE_ADS_TOKEN=xxxxx        # Google Ads — campaign management
+GA4_PROPERTY_ID=xxxxx         # Google Analytics — conversions
+HUBSPOT_API_KEY=xxxxx         # HubSpot — CRM, pipeline
+STRIPE_SECRET_KEY=xxxxx       # Stripe — payment verification
+QUICKBOOKS_TOKEN=xxxxx        # QuickBooks — invoicing, AR
+XERO_TOKEN=xxxxx              # Xero — alternative to QuickBooks
+ZENDESK_TOKEN=xxxxx           # Zendesk — support ticket management
+MERCADOLIBRE_TOKEN=xxxxx      # MercadoLibre — LATAM marketplace
+INSTAGRAM_ACCESS_TOKEN=xxxxx  # Instagram Graph API — post publishing
+```
+
+The orchestrator validates every connection before dispatching. Missing integrations fail early with a clear message — not midway through execution.
+
+---
+
+### Do I need API keys?
+
+| Integration | Free? | Do you need it? |
+|-------------|-------|-----------------|
+| Issue tracker | Free | **Yes — pick one.** Linear, GitHub Issues, Notion, or Jira. |
+| Shopify | Paid | **Yes, for e-commerce.** Product pages, pricing, inventory. |
+| MailerLite | Free tier | **Yes, for content.** Email sequences, newsletters. |
+| Apollo | Free tier | **Yes, for sales.** Lead sourcing, outreach. |
+| Instagram | Free (Graph API) | **Optional.** Post publishing, carousels. |
+| Meta Ads | Paid | **Optional.** Campaign management. |
+| Google Ads | Paid | **Optional.** Campaign management. |
+| HubSpot | Free tier | **Optional.** CRM, pipeline. |
+| GA4 | Free | **Optional.** Analytics, conversions. |
+| Stripe | Paid | **Optional.** Payment verification. |
+| QuickBooks | Paid | **Optional.** Invoicing, AR. |
+| Xero | Paid | **Optional.** Alternative to QuickBooks. |
+| Zendesk | Paid | **Optional.** Ticket management. |
+| MercadoLibre | Free | **Optional.** LATAM marketplace listings. |
+| GitHub | Free | **For engineering.** PRs, CI, deployments. |
+
+*All credentials stored locally in `~/.config/orchestrator/.env`. Never transmitted. The orchestrator detects available MCP servers first and uses them when available — the .env is a fallback.*
+
+*The orchestrator receives no money from any integration provider — no referrals, no kickbacks.*
+
+---
+
+### Config file locations
+
+```bash
+# Global config
+~/.config/orchestrator/.env       # API keys and credentials (chmod 600 recommended)
+~/.orchestrator/skills/           # Installed domain skill files
+~/.orchestrator/rules/            # Accumulated operational rules (grow automatically)
+~/.orchestrator/history/          # Outcome logs for self-improvement
+```
+
+### Other platforms
+
+The Manual install works for Codex CLI, Gemini CLI, and OpenCode — clone to `~/.agents/skills/orchestrator` and the skill is discovered via `SKILL.md`. Add credentials to `~/.config/orchestrator/.env`.
+
+---
+
+## Usage
+
+```
+/orchestrator sweep                            Process all actionable tickets
+/orchestrator sweep TICKET-046                 Re-run a single ticket
+/orchestrator status                           Current ticket states and verification results
+/orchestrator review                           Tickets awaiting your review (pre-verified)
+/orchestrator approve TICKET-044               Approve → Done
+/orchestrator approve TICKET-044 --note "..."  Approve with a note
+/orchestrator reject TICKET-044 --note "..."   Reject → back to execution with your feedback
+/orchestrator approve-rule "..."               Approve a proposed rule into the skill
+/orchestrator reject-rule "..."                Reject a proposed rule
+/orchestrator rules --pending                  List proposed rules awaiting approval
+/orchestrator flag TICKET-XXX "description"    Report a verification false negative
+/orchestrator setup                            Connect your board and validate integrations
+/orchestrator stats                            This week's pass/fail rate, ticket count, cost
+```
+
+**Reviewing verified work:** When tickets land in Review, run `/orchestrator review` to see the verification report — what passed, what failed, and the evidence. Then approve, reject with a note, or approve with a note. This is your only daily touchpoint.
+
+**When rules are proposed:** After repeated failures with the same root cause, the system proposes a new rule in the review output and via `/orchestrator rules --pending`. Approve or reject inline. Approved rules are added to the skill file and apply to all future tickets.
+
+---
+
+## How It Works
+
+Three steps, every ticket:
+
+1. **Dispatch** — read the board, prioritize by proximity to done (Review > Verification > In Progress stale > Todo), match to domain skill, validate integrations, dispatch worker agent
+2. **Verify** — separate verification pass with fresh context. Automated checks (API assertions, link validation, test suites) + AI judgment (brand voice, content quality). The verifier never knows how the work was done — no confirmation bias.
+3. **Proof** — verification report posted to ticket with evidence. PASS → Done. PARTIAL → Review (human decides). FAIL → auto-retry with failure context, or escalates to Review.
+
+The harness is the invariant. The worker changes. The verification contract never does.
+
+---
+
+## Your First Ticket
+
+Add the four sections as markdown headers (`## Inputs`, `## Deliverables`, `## Verification`, `## Artifacts`) in your ticket description. Copy this to your board and run `/orchestrator sweep`:
+
+**Publish SEO blog post**
+
+```
+## Inputs
+Keyword brief "AI agent verification", brand voice guide, 3 competitor URLs
+
+## Deliverables
+Blog post published on CMS, meta tags set, internal links added
+
+## Verification
+Page returns 200, word count > 1,500, SEO score green, no brand violations
+
+## Artifacts
+Published URL, screenshot of live page
+```
+
+**What to expect on your first sweep:**
+- Tickets with all four sections get dispatched
+- Tickets missing sections get moved to Backlog with a comment explaining what's needed
+- If none of your tickets are in this format, the orchestrator tells you and offers to help reformat them
+
+More templates for every domain in [docs/VISION.md](docs/VISION.md).
+
+---
+
+## Example: What a Verification Report Looks Like
+
+After the orchestrator verifies a ticket, this is posted to the ticket:
+
+```
+## Verification Report — TICKET-043
+
+Status: PASS ✓
+
+Checks:
+  ✓ Page returns 200 (automated — 0.3s)
+  ✓ Word count: 1,847 > 1,500 (automated — 0.1s)
+  ✓ SEO score: 92/100, green (automated — 1.2s)
+  ✓ Meta title set, under 60 chars (automated — 0.1s)
+  ✓ og:image present and resolves (automated — 0.4s)
+  ✓ 3 internal links found (automated — 0.2s)
+  ✓ Brand voice check: consistent, no violations (AI judgment — 2.1s)
+
+Evidence:
+  - Screenshot: live page captured
+  - Lighthouse report: attached
+  - All links validated: 3/3 resolve
+
+Result: PASS — moved to Done
+```
+
+---
+
+## Domain Skills
+
+Domain skills extend the orchestrator with specialized verification rules for specific work types. Each skill is a composition wrapper — it adds domain rules and verification criteria on top of the base harness.
+
+| Skill | What it adds | Plugin |
+|-------|-------------|--------|
+| content | Brand voice, format specs, engagement baseline | `maxtechera/skill-content` |
+| ecommerce | Price/compare-at checks, image count, Shopify API | `maxtechera/skill-ecommerce` |
+| seo | Meta limits, word count, Lighthouse, GSC inspection | `maxtechera/skill-seo` |
+| engineering | Build/test/lint/CI gates, PR required, no self-merge | Built-in (agent default) |
+
+Full skill list and composition chains: [skills/README.md](skills/README.md)
+
+---
+
+## Key Concepts
+
+**Harness over trust** — the verification harness rules completion. No evidence, no done. This is the invariant.
+
+**The ticket contract** — every ticket has four sections: Inputs, Deliverables, Verification, Artifacts. Missing any → rejected to Backlog with guidance. [Full spec](docs/VISION.md).
+
+**Finishing beats starting** — tickets closest to done get dispatched first.
+
+**Self-improving harness** — every failure becomes a rule. Skills evolve, verification hardens, rules accumulate. All version-controlled. You approve every change.
+
+**Fail visible** — nothing ships without passing verification. Blocked tickets include a structured reason. Partial failures are caught. The system fails visibly, not silently.
+
+---
+
+## What This Repo Contains
+
+```
+orchestrator/
+  SKILL.md                        # Core orchestrator skill — the agent reads this
+  WORKFLOW.md                     # Ticket lifecycle (intake → execute → verify → done)
+  .claude-plugin/                 # Claude Code marketplace manifests
+  .codex-plugin/                  # Codex CLI discovery
+  .agents/                        # OpenCode/OpenClaw skill discovery
+  gemini-extension.json           # Gemini CLI extension manifest
+  .clawhubignore                  # Distribution exclusions
+  .env.example                    # All configuration variables
+  CHANGELOG.md                    # Release history
+  docs/
+    VISION.md                     # Vision deck — the full story
+    STATE_MACHINE.md              # Ticket state transitions (detailed)
+  skills/                         # Domain skill directory
+  examples/                       # Example workflows and tickets
+```
+
+## Principles
+
+- Your ticket board is the single source of truth
+- The executor and the verifier are always different
+- `Done` is fail-closed: no evidence, no completion
+- The system fails visibly, not silently
+- Finishing beats starting
+- You define the boundaries. The system operates inside them.
+
+## Vision
+
+Read the full north star document: [`docs/VISION.md`](docs/VISION.md)
+
+**One board. Any domain. Verified output. The operator's leverage finally scales.**
+
+## License
+
+MIT
+
\ No newline at end of file diff --git a/artifacts/MAX-564/linear_attached_visual_proof.png b/artifacts/MAX-564/linear_attached_visual_proof.png new file mode 100644 index 0000000..c736047 Binary files /dev/null and b/artifacts/MAX-564/linear_attached_visual_proof.png differ diff --git a/artifacts/MAX-564/package.json b/artifacts/MAX-564/package.json new file mode 100644 index 0000000..cdba8b9 --- /dev/null +++ b/artifacts/MAX-564/package.json @@ -0,0 +1,84 @@ +{ + "ticket_id": "MAX-564", + "content_type": "course-outline", + "target_repo": "maxtechera/orchestrator", + "target_system": "mailerlite", + "brand": "max-techera", + "locale": "en-es", + "offer_stack": { + "free": "/memory OSS tool", + "paid": "/memory course", + "price_usd": 97, + "funnel": [ + "GitHub star", + "install", + "friction point", + "README CTA", + "newsletter", + "course" + ] + }, + "friction_point": { + "pain": "Install works, but the user still does not know what a good memory architecture looks like or how to keep recall useful instead of noisy.", + "course_entry": "The free tool solves mechanics. The course solves the operating model." + }, + "modules": [ + { + "title": "Why agents forget, and why naive note dumps fail", + "learning_outcome": "Understand session amnesia, compaction loss, and context-window overload.", + "demo_or_exercise": "Compare one task with no memory vs minimal HOT memory and document where state gets lost." + }, + { + "title": "The 3-tier architecture, HOT, WARM, COLD", + "learning_outcome": "Design a memory stack that keeps active context small while preserving durable recall.", + "demo_or_exercise": "Build the folder layout and classify sample facts into HOT, WARM, and COLD." + }, + { + "title": "Hooks, setup, and the sync pipeline in real life", + "learning_outcome": "Trace what actually happens on start, compaction, and stop.", + "demo_or_exercise": "Run setup, inspect hooks, and validate one sync report." + }, + { + "title": "Build a retrieval system that Claude can actually use", + "learning_outcome": "Structure topics, journals, and wiki pages for reliable recall.", + "demo_or_exercise": "Create topic files, a journal, and one wiki page, then practice targeted retrieval." + }, + { + "title": "Cross-session, cross-agent, cross-platform memory", + "learning_outcome": "Use memory as infrastructure for long projects and helper handoffs.", + "demo_or_exercise": "Simulate a parent session handing off cleanly to a helper across environments." + }, + { + "title": "Prevent memory rot, drift, and note sludge", + "learning_outcome": "Keep the system trustworthy over time with TTL, audits, and dream cycles.", + "demo_or_exercise": "Run an audit, prune stale entries, and promote one durable insight to the wiki." + }, + { + "title": "The full working system, from install to trusted recall", + "learning_outcome": "Assemble the complete persistent-memory workflow end to end.", + "demo_or_exercise": "Run a two-session workflow and recover context without manual re-briefing." + } + ], + "cta_copy": { + "readme": [ + "Installed /memory, but still not sure what should live in memory and what should stay out? The course shows the full system in action, HOT/WARM/COLD tiers, hooks, sync pipeline, wiki, and the maintenance loop that keeps memory useful instead of noisy.", + "/memory gives you the engine. The course gives you the operating model. If setup worked but you still do not trust the system yet, the /memory course walks you through the exact architecture, retrieval patterns, and sync workflow behind a memory setup you can use every day." + ], + "newsletter": [ + "You installed /memory. Great. But the real unlock is not the install, it is knowing how to structure the system so Claude can recover the right context at the right time.", + "Most people stop after /memory setup. That gets the hooks running. It does not teach you what to store, how to organize the tiers, how to query old work, or how to keep the system clean when projects get long." + ] + }, + "proof": { + "branch": "feat/MAX-564-memory-course-outline", + "pr_url": "https://github.com/maxtechera/orchestrator/pull/19", + "deployed_url": "https://cdn.jsdelivr.net/gh/maxtechera/orchestrator@feat/MAX-564-memory-course-outline/artifacts/MAX-564/preview.html", + "linear_attached_visual_proof": "artifacts/MAX-564/linear_attached_visual_proof.png", + "rendered_html_screenshot": "artifacts/MAX-564/rendered_html_screenshot.png", + "rendered_html_preview_screenshot": "artifacts/MAX-564/rendered_html_preview_screenshot.png", + "rendered_github_markdown_screenshot": "artifacts/MAX-564/rendered_github_markdown_screenshot.png", + "screenshot_desktop": "artifacts/MAX-564/screenshot_desktop.png", + "screenshot_mobile": "artifacts/MAX-564/screenshot_mobile.png", + "final_mp4_attachment": "artifacts/MAX-564/final_mp4_attachment.mp4" + } +} diff --git a/artifacts/MAX-564/preview.html b/artifacts/MAX-564/preview.html new file mode 100644 index 0000000..26ec46a --- /dev/null +++ b/artifacts/MAX-564/preview.html @@ -0,0 +1,27 @@ +
La Academia · OSS Tool → Course

/memory, from install to trusted recall

Pasá de "los hooks ya corren" a un sistema de memoria persistente que Claude puede usar de verdad. El curso muestra HOT, WARM, COLD, sync pipeline, wiki y mantenimiento anti-sludge.

Inscribirme al curso /memoryVer cómo funciona el sistema
Friction point

Setup works, confidence does not

La instalación te deja con hooks activos, pero no te enseña qué guardar, cómo estructurar tiers o cuándo podar memoria vieja.

Transformation

Install → operating model

El estudiante sale con una arquitectura usable, reglas de clasificación, queries de recuperación y rutina semanal de mantenimiento.

Modules

7 modules, hands-on

Olvido, 3-tier architecture, hooks, retrieval, multi-agent handoff, anti-rot maintenance y sistema completo de extremo a extremo.

Best for

Claude Code users running long projects

Ideal para quienes ya instalaron /memory y quieren recuperar contexto real entre sesiones sin volver a cargar todo manualmente.

\ No newline at end of file diff --git a/artifacts/MAX-564/proof-board.html b/artifacts/MAX-564/proof-board.html new file mode 100644 index 0000000..2fcebe3 --- /dev/null +++ b/artifacts/MAX-564/proof-board.html @@ -0,0 +1,27 @@ +
MAX-564 visual proof

/memory course package

OSS tool to paid course bridge for MailerLite and README CTA surfaces.

7modules
1friction point mapped
2CTA surfaces written
$97offer step
Core promise

From install to trusted recall

Student leaves with a working persistent-memory setup, not just theory.

MailerLite

Email preview included

Ready for newsletter CTA and nurture placement.

Repo

Docs + artifact pack

Markdown outline, preview HTML, proof images, and MP4 attachment.

\ No newline at end of file diff --git a/artifacts/MAX-564/proof-pack.md b/artifacts/MAX-564/proof-pack.md new file mode 100644 index 0000000..bd6546a --- /dev/null +++ b/artifacts/MAX-564/proof-pack.md @@ -0,0 +1,31 @@ +# MAX-564 proof pack + +## Scope +- Ticket: MAX-564 +- Repo: `maxtechera/orchestrator` +- Surface: MailerLite-ready content package stored in repo +- Offer ladder: `/memory` OSS tool → `$97` `/memory` course +- Core friction: install succeeds, but users still do not trust or understand the memory operating model + +## What shipped +- Full course outline: `docs/memory-course-outline.md` +- Repo preview HTML: `artifacts/MAX-564/preview.html` +- MailerLite email preview: `artifacts/MAX-564/email-preview.html` +- Rendered course outline: `artifacts/MAX-564/course-outline.html` +- Visual proof image for Linear: `artifacts/MAX-564/linear_attached_visual_proof.png` +- Desktop preview screenshot: `artifacts/MAX-564/screenshot_desktop.png` +- Mobile preview screenshot: `artifacts/MAX-564/screenshot_mobile.png` +- Rendered outline screenshot: `artifacts/MAX-564/rendered_html_screenshot.png` +- Rendered email screenshot: `artifacts/MAX-564/rendered_html_preview_screenshot.png` +- Rendered GitHub markdown screenshot: `artifacts/MAX-564/rendered_github_markdown_screenshot.png` +- MP4 attachment: `artifacts/MAX-564/final_mp4_attachment.mp4` + +## Content summary +- 7 modules covering failure modes, 3-tier architecture, hooks, sync pipeline, retrieval, cross-agent handoff, maintenance, and the full working system +- Friction point mapped from OSS install pain to course entry +- README CTA copy included +- Newsletter CTA copy included + +## Proof links +- Branch preview URL: `https://cdn.jsdelivr.net/gh/maxtechera/orchestrator@feat/MAX-564-memory-course-outline/artifacts/MAX-564/preview.html` +- PR URL: `https://github.com/maxtechera/orchestrator/pull/19` diff --git a/artifacts/MAX-564/render-assets.js b/artifacts/MAX-564/render-assets.js new file mode 100644 index 0000000..4000e16 --- /dev/null +++ b/artifacts/MAX-564/render-assets.js @@ -0,0 +1,98 @@ +const fs = require('fs'); +const path = require('path'); +const { chromium, devices } = require('playwright'); + +const outDir = __dirname; +const repoRoot = path.resolve(outDir, '..', '..'); +const courseMd = fs.readFileSync(path.join(repoRoot, 'docs', 'memory-course-outline.md'), 'utf8'); +const readmeMd = fs.readFileSync(path.join(repoRoot, 'README.md'), 'utf8'); + +function escapeHtml(str) { + return str.replace(/&/g, '&').replace(//g, '>'); +} + +function mdToHtml(md) { + return md + .split(/\n## /g) + .map((chunk, idx) => { + const normalized = idx === 0 ? chunk : `## ${chunk}`; + return `
${escapeHtml(normalized)}
`; + }) + .join('\n'); +} + +const baseCss = ` +:root { color-scheme: dark; } +* { box-sizing: border-box; } +body { margin: 0; font-family: Inter, ui-sans-serif, system-ui, sans-serif; background: #09111f; color: #e5eefc; } +.wrap { max-width: 1180px; margin: 0 auto; padding: 40px 28px 80px; } +.hero { padding: 40px; border-radius: 30px; background: linear-gradient(135deg, #0f172a 0%, #172554 45%, #0b3b6f 100%); border: 1px solid rgba(255,255,255,.08); box-shadow: 0 20px 70px rgba(0,0,0,.35); } +.eyebrow { color: #93c5fd; text-transform: uppercase; letter-spacing: .12em; font-size: 12px; font-weight: 700; margin-bottom: 10px; } +h1,h2,h3 { margin: 0 0 14px; } +p { margin: 0; color: #d7e6ff; line-height: 1.6; } +.grid { display: grid; grid-template-columns: repeat(2, minmax(0, 1fr)); gap: 22px; margin-top: 24px; } +.card { background: rgba(15, 23, 42, 0.92); border: 1px solid rgba(255,255,255,.08); border-radius: 24px; padding: 24px; box-shadow: 0 10px 30px rgba(0,0,0,.22); } +.kicker { display:inline-block; padding: 6px 10px; border-radius: 999px; background: rgba(96,165,250,.16); color: #bfdbfe; font-size: 12px; font-weight: 700; margin-bottom: 12px; } +.ctaRow { display: flex; gap: 14px; flex-wrap: wrap; margin-top: 24px; } +.btn { display: inline-flex; padding: 14px 20px; border-radius: 999px; text-decoration: none; font-weight: 700; } +.primary { background: #7dd3fc; color: #082032; } +.secondary { color: #e0f2fe; border: 1px solid rgba(125,211,252,.45); } +pre { white-space: pre-wrap; margin: 0; font-size: 15px; line-height: 1.55; color: #dbeafe; font-family: ui-monospace, SFMono-Regular, Menlo, monospace; } +.markdown { margin-top: 28px; display: grid; gap: 18px; } +.small { font-size: 14px; color: #c7d7ef; } +.github { background: #0d1117; } +.github .card { background: #0d1117; border-color: #30363d; } +.github pre { color: #c9d1d9; } +.proofBoard .grid { grid-template-columns: repeat(3, minmax(0, 1fr)); } +.metrics { display: grid; grid-template-columns: repeat(4, minmax(0,1fr)); gap: 14px; margin-top: 20px; } +.metric { background: rgba(255,255,255,.05); border-radius: 18px; padding: 18px; } +.metric strong { display:block; font-size: 28px; margin-bottom: 6px; } +`; + +const previewHtml = `
La Academia · OSS Tool → Course

/memory, from install to trusted recall

Pasá de "los hooks ya corren" a un sistema de memoria persistente que Claude puede usar de verdad. El curso muestra HOT, WARM, COLD, sync pipeline, wiki y mantenimiento anti-sludge.

Inscribirme al curso /memoryVer cómo funciona el sistema
Friction point

Setup works, confidence does not

La instalación te deja con hooks activos, pero no te enseña qué guardar, cómo estructurar tiers o cuándo podar memoria vieja.

Transformation

Install → operating model

El estudiante sale con una arquitectura usable, reglas de clasificación, queries de recuperación y rutina semanal de mantenimiento.

Modules

7 modules, hands-on

Olvido, 3-tier architecture, hooks, retrieval, multi-agent handoff, anti-rot maintenance y sistema completo de extremo a extremo.

Best for

Claude Code users running long projects

Ideal para quienes ya instalaron /memory y quieren recuperar contexto real entre sesiones sin volver a cargar todo manualmente.

`; + +const outlineHtml = `
Rendered course outline

/memory course outline

Module breakdown, friction mapping, operating-model angle, and CTA copy for README plus newsletter.

${mdToHtml(courseMd)}
`; + +const emailHtml = `
MailerLite-ready preview

You installed /memory. Now make it trustworthy.

Most people stop after setup. The course teaches what belongs in each tier, how sync actually works, and how to keep recall useful instead of noisy.

Enroll in the /memory course
Inside

HOT, WARM, COLD explained live

Build a system Claude can query without flooding every session.

Fix the friction

From "hooks work" to "memory works"

Learn storage rules, retrieval surfaces, sync cadence, wiki flow, and anti-rot maintenance.

`; + +const githubHtml = `
${escapeHtml(readmeMd)}
`; + +const proofHtml = `
MAX-564 visual proof

/memory course package

OSS tool to paid course bridge for MailerLite and README CTA surfaces.

7modules
1friction point mapped
2CTA surfaces written
$97offer step
Core promise

From install to trusted recall

Student leaves with a working persistent-memory setup, not just theory.

MailerLite

Email preview included

Ready for newsletter CTA and nurture placement.

Repo

Docs + artifact pack

Markdown outline, preview HTML, proof images, and MP4 attachment.

`; + +for (const [name, html] of Object.entries({ + 'preview.html': previewHtml, + 'course-outline.html': outlineHtml, + 'email-preview.html': emailHtml, + 'github-readme.html': githubHtml, + 'proof-board.html': proofHtml, +})) { + fs.writeFileSync(path.join(outDir, name), html); +} + +(async () => { + const browser = await chromium.launch({ headless: true }); + const page = await browser.newPage({ viewport: { width: 1440, height: 1800 } }); + + await page.goto(`file://${path.join(outDir, 'course-outline.html')}`); + await page.screenshot({ path: path.join(outDir, 'rendered_html_screenshot.png'), fullPage: true }); + + await page.goto(`file://${path.join(outDir, 'email-preview.html')}`); + await page.screenshot({ path: path.join(outDir, 'rendered_html_preview_screenshot.png'), fullPage: true }); + + await page.goto(`file://${path.join(outDir, 'github-readme.html')}`); + await page.screenshot({ path: path.join(outDir, 'rendered_github_markdown_screenshot.png'), fullPage: true }); + + await page.setViewportSize({ width: 1440, height: 1400 }); + await page.goto(`file://${path.join(outDir, 'preview.html')}`); + await page.screenshot({ path: path.join(outDir, 'screenshot_desktop.png'), fullPage: true }); + + const mobile = await browser.newPage({ ...devices['iPhone 13'] }); + await mobile.goto(`file://${path.join(outDir, 'preview.html')}`); + await mobile.screenshot({ path: path.join(outDir, 'screenshot_mobile.png'), fullPage: true }); + + await page.setViewportSize({ width: 1440, height: 1200 }); + await page.goto(`file://${path.join(outDir, 'proof-board.html')}`); + await page.screenshot({ path: path.join(outDir, 'linear_attached_visual_proof.png'), fullPage: true }); + + await browser.close(); +})(); diff --git a/artifacts/MAX-564/rendered_github_markdown_screenshot.png b/artifacts/MAX-564/rendered_github_markdown_screenshot.png new file mode 100644 index 0000000..7556b85 Binary files /dev/null and b/artifacts/MAX-564/rendered_github_markdown_screenshot.png differ diff --git a/artifacts/MAX-564/rendered_html_preview_screenshot.png b/artifacts/MAX-564/rendered_html_preview_screenshot.png new file mode 100644 index 0000000..9f7a8f4 Binary files /dev/null and b/artifacts/MAX-564/rendered_html_preview_screenshot.png differ diff --git a/artifacts/MAX-564/rendered_html_screenshot.png b/artifacts/MAX-564/rendered_html_screenshot.png new file mode 100644 index 0000000..a39edee Binary files /dev/null and b/artifacts/MAX-564/rendered_html_screenshot.png differ diff --git a/artifacts/MAX-564/screenshot_desktop.png b/artifacts/MAX-564/screenshot_desktop.png new file mode 100644 index 0000000..b83a1a9 Binary files /dev/null and b/artifacts/MAX-564/screenshot_desktop.png differ diff --git a/artifacts/MAX-564/screenshot_mobile.png b/artifacts/MAX-564/screenshot_mobile.png new file mode 100644 index 0000000..cf0dad4 Binary files /dev/null and b/artifacts/MAX-564/screenshot_mobile.png differ diff --git a/artifacts/MAX-564/slides.txt b/artifacts/MAX-564/slides.txt new file mode 100644 index 0000000..4f84c88 --- /dev/null +++ b/artifacts/MAX-564/slides.txt @@ -0,0 +1,7 @@ +file 'linear_attached_visual_proof.png' +duration 3 +file 'screenshot_desktop.png' +duration 3 +file 'rendered_html_preview_screenshot.png' +duration 3 +file 'rendered_html_preview_screenshot.png' diff --git a/artifacts/MAX-565/build.md b/artifacts/MAX-565/build.md new file mode 100644 index 0000000..74b7094 --- /dev/null +++ b/artifacts/MAX-565/build.md @@ -0,0 +1,103 @@ +--- +ticket: MAX-565 +brand: maxtechera +content_type: social_pack +created: "2026-05-07T10:02:55Z" +hashes: + ingredients: "sha256:9b278be533498adc" + script: "sha256:cbe7f5ccb1755e70" + storyboard: "sha256:51af833761d0dee0" + presentation: "sha256:91bf740ade5d6726" +placements: + - channel: ig_reel + source: {script_beats: "all"} + - channel: ig_carousel + source: {script_beats: "all"} + - channel: x_thread + source: {script_beats: "all"} + - channel: linkedin + source: {script_beats: "all"} + - channel: email + source: {script_beats: "all"} + - channel: landing + source: {script_beats: "all"} +gamma_file_id: null +remotion_comp: null +--- + +## Ingredients +- hook: "Most AI agent setups break the moment one task becomes three, because nobody taught the system how to coordinate the handoff." +- cta: "Get the free lesson, join the /orchestrator waitlist, and steal the ticket-contract workflow for your own agent stack." +- value_prop: "This package turns the /orchestrator course into a concrete promise: go from fragile single-agent experiments to reliable parallel workflows in one week, with contracts, verification, memory, and production guardrails." +- offer: "/orchestrator — Run reliable multi-agent workflows in 1 week ($197 course with video lessons, workbooks, and cloneable templates)." +- intro: "MAX-565 is the v2 waterfall package for the /orchestrator course launch, built to convert OSS users and Claude Code power users into buyers with one clear narrative: single-agent workflows feel magical until coordination, proof, and context start breaking." + +## Script +Most people do not need more AI demos. They need a workflow that still works when one agent becomes three. + +That is the real gap between playing with agents and operating them in production. A single agent can look impressive in isolation, but the second you add parallel work, handoffs, memory, retries, and proof, most setups start leaking time instead of saving it. + +That is exactly what the /orchestrator course is built to fix. In one week, it shows Claude Code users how to go from fragile single-agent experiments to reliable multi-agent workflows with ticket contracts, coordinator-executor patterns, memory discipline, verification loops, and production guardrails. + +The promise is simple. You should be able to run agent teams without losing context, duplicating work, or trusting a confident status update that has no evidence behind it. + +This content package fans that promise out across the channels that matter. The reel leads with the pain of agent drift. The carousel breaks down the six-module transformation. The X thread makes the argument in public for builders already trying to scale their workflows. LinkedIn frames it as an operational upgrade, not another AI course. Email converts warm interest into urgency. The landing page collects the buyer who is ready now. + +If you already feel the ceiling on single-agent workflows, this is the next step. Get the free lesson, join the waitlist, and use the /orchestrator system to make your agents actually reliable. + +## Storyboard +```yaml +- n: 1 + t_start: 0.0 + duration_s: 3.5 + script: "Most AI agent setups break the moment one task becomes three." + visual: "A single clean chat window splits into three parallel agent panes that quickly drift out of sync" + sfx: "tight glitch impact" + motion: "clean split-screen that degrades into noisy overlap" + broll: "artifacts/MAX-565/reference/single-to-multi-agent.png" + on_camera: false + slide_ref: 1 + emphasis: "hook" +- n: 2 + t_start: 3.5 + duration_s: 4.5 + script: "The problem is not prompting. It is coordination, handoffs, memory, and proof." + visual: "Task board, session summaries, and failed evidence checks stack beside drifting agents" + sfx: "muted notification taps with low pulse" + motion: "layered overlays of tickets, context windows, and red proof gaps" + broll: "artifacts/MAX-565/reference/coordination-gaps.png" + on_camera: false + slide_ref: 2 + emphasis: "problem" +- n: 3 + t_start: 8.0 + duration_s: 5.0 + script: "The /orchestrator course shows how to run reliable multi-agent workflows in one week." + visual: "Course modules, ticket contract, and orchestrator flow animate into one structured system" + sfx: "measured interface clicks" + motion: "left-to-right build of a verified orchestration pipeline" + broll: "artifacts/MAX-565/reference/course-system-map.png" + on_camera: false + slide_ref: 3 + emphasis: "solution" +- n: 4 + t_start: 13.0 + duration_s: 4.5 + script: "Get the free lesson, join the waitlist, and stop running agent workflows on vibes." + visual: "Free lesson preview, waitlist CTA, and proof-backed workflow lockup" + sfx: "resolve hit with soft rise" + motion: "final pulse on free lesson and waitlist CTA" + broll: "artifacts/MAX-565/reference/free-lesson-cta.png" + on_camera: false + slide_ref: 4 + emphasis: "cta" +``` + +## Presentation +- Slide 1: The pain, single-agent workflows look good until the work branches and coordination starts failing. +- Slide 2: The hidden costs, context loss, duplicated effort, weak handoffs, and status without evidence. +- Slide 3: The course promise, learn ticket contracts, parallel executors, memory systems, and verification loops in one week. +- Slide 4: The six-module path, from why single-agent breaks to production orchestration. +- Slide 5: The buyer transformation, fragile experiments become reliable multi-agent operations. +- Slide 6: Channel handoff, adapt the same core promise into reel, carousel, thread, LinkedIn, email, and landing page. +- Presenter note: keep the positioning sharp and operator-first, because the buyer already believes in AI and only needs proof that this fixes the coordination layer. diff --git a/artifacts/MAX-565/course-outline-render.png b/artifacts/MAX-565/course-outline-render.png new file mode 100644 index 0000000..d38aefc Binary files /dev/null and b/artifacts/MAX-565/course-outline-render.png differ diff --git a/artifacts/MAX-565/course-outline.html b/artifacts/MAX-565/course-outline.html new file mode 100644 index 0000000..b7eb77b --- /dev/null +++ b/artifacts/MAX-565/course-outline.html @@ -0,0 +1,223 @@ +
Rendered course outline

/orchestrator course outline

Module plan, ICP, transformation, lesson inventory, preview lesson strategy, and CTA copy.

# /orchestrator course outline
+
+**Course:** /orchestrator — Run reliable multi-agent workflows in 1 week  
+**Price:** $197  
+**Format:** Mixed (video lessons, text workbooks, cloneable `/orchestrator` skill templates)  
+**Audience:** Claude Code users who already write single-agent workflows and want to scale to parallel, reliable, multi-agent teams  
+**Outcome promise:** Run reliable, parallel multi-agent workflows in 1 week, without losing context, duplicating work, or watching agents drift.
+
+## Course entry friction
+Students already get useful output from a single coding agent, but the moment they try to split work across multiple agents, the system breaks. Context gets lost, two agents do the same task, handoffs are vague, and nobody knows what “done” means. The course is designed to solve that exact jump: single-agent competence to reliable multi-agent orchestration.
+
+## Who this is for
+- Indie developers building with Claude Code or similar coding agents
+- AI-forward engineers who want parallel execution without chaos
+- Small agencies turning ad hoc prompting into a repeatable delivery system
+- Operators who need verification, handoffs, and predictable outputs across agent teams
+
+## Transformation
+By the end of the course, students will be able to:
+1. Diagnose when a single-agent workflow is enough and when orchestration is required
+2. Write ticket contracts that constrain agents and reduce drift
+3. Spawn parallel and sequential agent teams with clear merge boundaries
+4. Preserve context across sessions with durable memory and handoff discipline
+5. Add reliability layers like critics, retries, and human approval gates
+6. Run `/orchestrator` as a repeatable production workflow instead of a one-off demo
+
+## Course structure
+- **Modules:** 6
+- **Target lesson count:** ~30 lessons
+- **Per-module pattern:** 1 hook, 3 to 5 teach lessons, 1 to 2 apply lessons
+- **Delivery assets:** lesson videos, workbooks, checklists, reusable templates
+
+
+## Module 1 — Why single-agent breaks (and what multi-agent fixes)
+**Learning outcome:** Students understand the limits of single-agent workflows, recognize the failure modes that appear at scale, and know when orchestration becomes necessary.
+
+### Hook
+- **Lesson 1.1:** The context-limit wall and why single-agent workflows break
+
+### Teach
+- **Lesson 1.2:** Four operating patterns, single, sequential, parallel, hierarchical
+- **Lesson 1.3:** The three signals that tell you it is time to scale beyond one agent
+- **Lesson 1.4:** Failure modes, context loss, duplicate work, drift, and invisible blockers
+
+### Apply
+- **Lesson 1.5:** Audit your current workflow and mark parallelization opportunities
+
+### Demo / exercise
+Students map one real workflow they already run, identify where the agent loses context, and select one candidate task to split into multiple executors.
+
+
+## Module 2 — Ticket Contracts, the orchestrator primitive
+**Learning outcome:** Students can write ticket contracts that define deliverables, proof, and acceptance criteria tightly enough for delegated execution.
+
+### Hook
+- **Lesson 2.1:** Why agents without contracts drift
+
+### Teach
+- **Lesson 2.2:** Ticket contract anatomy, inputs, outputs, proof, and failure states
+- **Lesson 2.3:** Deliverables versus proof, what the agent makes versus how it proves completion
+- **Lesson 2.4:** Acceptance criteria that survive handoffs and verification
+- **Lesson 2.5:** Writing handoff-ready tickets for build, verify, and publish paths
+
+### Apply
+- **Lesson 2.6:** Write a contract for a repo task
+- **Lesson 2.7:** Write a contract for a content or launch task
+
+### Demo / exercise
+Students produce two real ticket contracts from their own backlog and score them against a drift-prevention checklist.
+
+
+## Module 3 — Spawning agent teams (parallel versus sequential)
+**Learning outcome:** Students can choose the right execution pattern, spawn multi-agent work safely, and merge outputs without collisions.
+
+### Hook
+- **Lesson 3.1:** The coordinator and executor pattern
+
+### Teach
+- **Lesson 3.2:** Coordinator ↔ executor in 20 minutes
+- **Lesson 3.3:** When to run parallel, when to run sequential
+- **Lesson 3.4:** Merge strategies, scoped ownership, stitched outputs, and arbitration
+- **Lesson 3.5:** Fleet patterns, worktree isolation, and branch hygiene
+
+### Apply
+- **Lesson 3.6:** Run a 3-executor parallel task and merge the outputs
+
+### Demo / exercise
+Students launch a coordinator with three executors, each with a narrow scope, then merge the outputs into one final artifact with no overlapping ownership.
+
+
+## Module 4 — Memory, context, and handoff
+**Learning outcome:** Students can preserve state across long-running work and keep multi-session tasks coherent.
+
+### Hook
+- **Lesson 4.1:** The silent context loss problem
+
+### Teach
+- **Lesson 4.2:** The 3-tier memory model for agent teams
+- **Lesson 4.3:** Session state, handoff docs, and durable operating context
+- **Lesson 4.4:** SESSION-STATE, pre-compact discipline, and recovery after interruption
+- **Lesson 4.5:** Designing memory flows for multi-session work
+
+### Apply
+- **Lesson 4.6:** Build a persistent memory flow across a 2-session task
+
+### Demo / exercise
+Students run one task across two sessions using memory notes, session state, and a formal handoff document.
+
+
+## Module 5 — Reliability patterns (retries, guardrails, critics)
+**Learning outcome:** Students can make agents check themselves, retry safely, and stop at the right human gate.
+
+### Hook
+- **Lesson 5.1:** Agents that check their own work, but do not grade it alone
+
+### Teach
+- **Lesson 5.2:** Critic evaluators and rubric-driven review
+- **Lesson 5.3:** Retry policies, bounded loops, and fail-fast triggers
+- **Lesson 5.4:** Human-in-the-loop gates for risky or taste-sensitive tasks
+
+### Apply
+- **Lesson 5.5:** Add a critic and retry loop to your orchestrator
+
+### Demo / exercise
+Students wire a critic pass into a real orchestration flow and tune retry logic so the system improves instead of looping forever.
+
+
+## Module 6 — Production orchestration (monitoring, cost, scale)
+**Learning outcome:** Students can operate `/orchestrator` as a daily driver with visibility, cost awareness, and recurring execution.
+
+### Hook
+- **Lesson 6.1:** From demo to daily driver
+
+### Teach
+- **Lesson 6.2:** Monitoring runs, statuses, and bottlenecks
+- **Lesson 6.3:** Cost attribution and choosing the right model for each job
+- **Lesson 6.4:** Model routing with `/model-router`
+- **Lesson 6.5:** Cron dispatch, pause and resume, and recurring workflows
+
+### Apply
+- **Lesson 6.6:** Deploy your orchestrator as a recurring workflow
+
+### Demo / exercise
+Students turn one manual weekly workflow into an orchestrated recurring system with clear monitoring and escalation points.
+
+
+## Lesson inventory summary
+- **Module 1:** 5 lessons
+- **Module 2:** 7 lessons
+- **Module 3:** 6 lessons
+- **Module 4:** 6 lessons
+- **Module 5:** 5 lessons
+- **Module 6:** 6 lessons
+- **Total:** 35 lesson units in outline format, which is in range for a recorded delivery trimmed to about 30 final lessons by combining adjacent teach segments during production
+
+## Teaching assets to produce
+- 6 module workbooks
+- 1 operator checklist per module
+- Cloneable ticket contract templates
+- Sample orchestrator configs for sequential and parallel runs
+- Critic rubric templates
+- Session handoff template
+
+## Free and gated preview lessons
+### Free public lesson
+- **Module 1, Lesson 1:** The context-limit wall and why single-agent workflows break
+- **Format:** full video + workbook
+- **Placement:** `/academia/orchestrator/preview`
+- **Goal:** create demand by showing the core pain clearly and proving there is a structured path out
+
+### Gated preview lesson
+- **Module 3, Lesson 2:** Coordinator ↔ executor in 20 minutes
+- **Format:** preview lesson after email signup
+- **Goal:** let the student feel the speed and leverage of orchestration before purchase
+
+## CTA copy
+### README CTA
+> Aprendé a orquestar equipos de agentes → curso /orchestrator ($197)
+
+### Newsletter CTA
+> El curso /orchestrator abre el [date]. Reservá tu lugar.
+
+### Landing page primary CTA
+> Inscribirme al curso /orchestrator
+
+### Landing page secondary CTA
+> Ver la lección gratuita
+
+## Positioning notes
+- **Free OSS product:** `/orchestrator`
+- **Paid next step:** implementation system, templates, and workflow design in a guided course
+- **Core promise:** not “learn agents” but “run reliable agent teams in production”
+- **Main competitor substitute:** DIY prompting plus trial-and-error coordination
+- **Reason to buy now:** compress weeks of failed orchestration experiments into a one-week implementation path
+
+## Production notes for the launch team
+- Keep examples grounded in real delivery work, repo changes, content ops, and recurring workflows
+- Lead with failure modes students already feel, not abstract agent theory
+- Use live `/orchestrator` walkthroughs as the trust anchor for each module
+- Show verification and proof constantly so the course feels operational, not motivational
+
\ No newline at end of file diff --git a/artifacts/MAX-565/desktop-preview.png b/artifacts/MAX-565/desktop-preview.png new file mode 100644 index 0000000..3bbc8a8 Binary files /dev/null and b/artifacts/MAX-565/desktop-preview.png differ diff --git a/artifacts/MAX-565/github-markdown-readme.png b/artifacts/MAX-565/github-markdown-readme.png new file mode 100644 index 0000000..5404649 Binary files /dev/null and b/artifacts/MAX-565/github-markdown-readme.png differ diff --git a/artifacts/MAX-565/github-readme.html b/artifacts/MAX-565/github-readme.html new file mode 100644 index 0000000..34cc45c --- /dev/null +++ b/artifacts/MAX-565/github-readme.html @@ -0,0 +1,391 @@ +
# /orchestrator
+
+[![MIT License](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)
+[![Version](https://img.shields.io/badge/version-1.0.0-green.svg)](CHANGELOG.md)
+
+**Expert orchestrator of agentic teams. The ticket contract defines work. The verification harness rules completion.**
+
+Claude Code:
+```
+/plugin marketplace add maxtechera/orchestrator
+```
+
+OpenClaw:
+```
+clawhub install orchestrator
+```
+
+Zero config. Run `/orchestrator sweep` immediately — if no board is connected, the setup wizard runs automatically.
+
+---
+
+## Install
+
+### Claude Code
+
+#### Install
+```
+/plugin marketplace add maxtechera/orchestrator
+```
+
+#### Update
+```
+claude plugin update orchestrator@orchestrator
+```
+
+### OpenClaw
+```bash
+clawhub install orchestrator
+```
+
+### Manual
+```bash
+git clone https://github.com/maxtechera/orchestrator.git ~/.claude/skills/orchestrator
+```
+
+**The agent that did the work never grades its own homework.** A separate verification pass runs with fresh context — real API calls, screenshots, link checks, compliance validation. Not another AI saying "looks good."
+
+**The core pattern:** Ticket contract (Inputs / Deliverables / Verification / Artifacts) → dispatch worker agent → independent verifier → evidence posted to ticket. One cycle, every ticket.
+
+**Best for:** operators running agentic teams who want verified output, not just agent output.
+
+That's it. Run `/orchestrator sweep` to get started. If no board is connected, the orchestrator will prompt you to run `/orchestrator setup`. See [Your First Ticket](#your-first-ticket) below for a copy-paste template.
+
+## Learn `/orchestrator`
+
+Want the full operating system behind reliable agent teams?
+
+- **Course:** [`/orchestrator` course outline](docs/course-outline.md)
+- **Free lesson workbook:** [The context-limit wall and why single-agent workflows break](docs/sample-lessons/module-1-lesson-1-context-limit-wall.md)
+- **Paid course CTA:** **Aprendé a orquestar equipos de agentes → curso `/orchestrator` ($197)**
+
+The free OSS skill helps you run the workflow. The paid course teaches you how to design the contracts, memory, reliability layers, and production patterns behind it.
+
+---
+
+## What people use it for
+
+**Running a content operation.** `/orchestrator sweep` reads all open tickets, dispatches content agents loaded with your brand voice, and independently verifies every deliverable before marking it done. Not just "here's a draft" — checked output.
+
+**Managing an e-commerce store.** Set `BOARD_PROVIDER=linear` and connect Shopify. The orchestrator processes inventory updates, price changes, and product listings — and verifies prices, compare-at fields, and image counts before closing tickets.
+
+**Engineering ticket flow.** `/orchestrator sweep` picks up GitHub Issues, runs domain-specific verification (link checks, schema validation, test presence), and only marks tickets done when the deliverable actually passes.
+
+**Auditing before a release.** `/orchestrator review <ticket>` independently checks a specific deliverable. The agent that did the work never grades its own homework.
+
+---
+
+## Setup: Progressive Integration Unlocking
+
+Start using `/orchestrator` immediately. Add integrations when you want more domains.
+
+### 1. Zero Config (built-in skills) — Just install
+
+Run `/orchestrator sweep`. The orchestrator uses your existing board connections (MCP servers for Linear, GitHub, etc.) and built-in agent capabilities. No API keys, no configuration. If no board is detected, you'll be prompted to run `/orchestrator setup`.
+
+### 2. Run the setup wizard (connect your board)
+
+```
+/orchestrator setup
+```
+
+The setup wizard detects your environment, connects your issue tracker, and validates integrations. Takes about 30 seconds. Supports Linear, GitHub Issues, Notion, and Jira. It writes `BOARD_PROVIDER` and your API key to `~/.config/orchestrator/.env`.
+
+If you prefer manual config:
+
+```bash
+mkdir -p ~/.config/orchestrator && chmod 700 ~/.config/orchestrator
+```
+
+Then add to `~/.config/orchestrator/.env`:
+
+```bash
+# Add to ~/.config/orchestrator/.env
+BOARD_PROVIDER=linear        # or: github, notion, jira
+LINEAR_API_KEY=lin_api_xxxxx  # swap for your tracker's key
+```
+
+### 3. Add domain skills (RECOMMENDED — the single most impactful upgrade)
+
+**Domain skills give agents real expertise** — domain-specific rules, verification criteria, and best practices learned from actual executions. Without them, agents use general capabilities. With them, they follow rules like "carousel images must be 1080x1350" and "always verify compare-at price is cleared when not on sale."
+
+Domain skills are **composition wrappers** — they load [`maxtechera/ship`](https://github.com/maxtechera/ship) and [`maxtechera/memory`](https://github.com/maxtechera/memory) skills and add domain-specific verification rules on top. Install ship and memory first, then the domain skill activates their capabilities for orchestrator verification. See [skills/README.md](skills/README.md) for the full list and their composition chains.
+
+```
+/plugin marketplace add maxtechera/skill-content
+/plugin marketplace add maxtechera/skill-ecommerce
+/plugin marketplace add maxtechera/skill-seo
+```
+
+### 4. Add Shopify (e-commerce verification)
+
+Connect your Shopify store for automated price, inventory, and product verification.
+
+```bash
+# Add to ~/.config/orchestrator/.env
+SHOPIFY_ACCESS_TOKEN=shpat_xxxxx
+```
+
+### 5. Add MailerLite (content/newsletter verification)
+
+Free tier at [mailerlite.com](https://mailerlite.com). Enables email sequence verification — link checks, segment validation, send tests.
+
+```bash
+# Add to ~/.config/orchestrator/.env
+MAILERLITE_API_KEY=xxxxx
+```
+
+### 6. Add Apollo (sales verification)
+
+Free tier at [apollo.io](https://apollo.io). Enables lead sourcing verification — bounce rate, compliance, sequence validation.
+
+```bash
+# Add to ~/.config/orchestrator/.env
+APOLLO_API_KEY=xxxxx
+```
+
+### 7. Optional integrations
+
+```bash
+# Add to ~/.config/orchestrator/.env
+META_ADS_TOKEN=xxxxx          # Meta Ads — campaign management
+GOOGLE_ADS_TOKEN=xxxxx        # Google Ads — campaign management
+GA4_PROPERTY_ID=xxxxx         # Google Analytics — conversions
+HUBSPOT_API_KEY=xxxxx         # HubSpot — CRM, pipeline
+STRIPE_SECRET_KEY=xxxxx       # Stripe — payment verification
+QUICKBOOKS_TOKEN=xxxxx        # QuickBooks — invoicing, AR
+XERO_TOKEN=xxxxx              # Xero — alternative to QuickBooks
+ZENDESK_TOKEN=xxxxx           # Zendesk — support ticket management
+MERCADOLIBRE_TOKEN=xxxxx      # MercadoLibre — LATAM marketplace
+INSTAGRAM_ACCESS_TOKEN=xxxxx  # Instagram Graph API — post publishing
+```
+
+The orchestrator validates every connection before dispatching. Missing integrations fail early with a clear message — not midway through execution.
+
+---
+
+### Do I need API keys?
+
+| Integration | Free? | Do you need it? |
+|-------------|-------|-----------------|
+| Issue tracker | Free | **Yes — pick one.** Linear, GitHub Issues, Notion, or Jira. |
+| Shopify | Paid | **Yes, for e-commerce.** Product pages, pricing, inventory. |
+| MailerLite | Free tier | **Yes, for content.** Email sequences, newsletters. |
+| Apollo | Free tier | **Yes, for sales.** Lead sourcing, outreach. |
+| Instagram | Free (Graph API) | **Optional.** Post publishing, carousels. |
+| Meta Ads | Paid | **Optional.** Campaign management. |
+| Google Ads | Paid | **Optional.** Campaign management. |
+| HubSpot | Free tier | **Optional.** CRM, pipeline. |
+| GA4 | Free | **Optional.** Analytics, conversions. |
+| Stripe | Paid | **Optional.** Payment verification. |
+| QuickBooks | Paid | **Optional.** Invoicing, AR. |
+| Xero | Paid | **Optional.** Alternative to QuickBooks. |
+| Zendesk | Paid | **Optional.** Ticket management. |
+| MercadoLibre | Free | **Optional.** LATAM marketplace listings. |
+| GitHub | Free | **For engineering.** PRs, CI, deployments. |
+
+*All credentials stored locally in `~/.config/orchestrator/.env`. Never transmitted. The orchestrator detects available MCP servers first and uses them when available — the .env is a fallback.*
+
+*The orchestrator receives no money from any integration provider — no referrals, no kickbacks.*
+
+---
+
+### Config file locations
+
+```bash
+# Global config
+~/.config/orchestrator/.env       # API keys and credentials (chmod 600 recommended)
+~/.orchestrator/skills/           # Installed domain skill files
+~/.orchestrator/rules/            # Accumulated operational rules (grow automatically)
+~/.orchestrator/history/          # Outcome logs for self-improvement
+```
+
+### Other platforms
+
+The Manual install works for Codex CLI, Gemini CLI, and OpenCode — clone to `~/.agents/skills/orchestrator` and the skill is discovered via `SKILL.md`. Add credentials to `~/.config/orchestrator/.env`.
+
+---
+
+## Usage
+
+```
+/orchestrator sweep                            Process all actionable tickets
+/orchestrator sweep TICKET-046                 Re-run a single ticket
+/orchestrator status                           Current ticket states and verification results
+/orchestrator review                           Tickets awaiting your review (pre-verified)
+/orchestrator approve TICKET-044               Approve → Done
+/orchestrator approve TICKET-044 --note "..."  Approve with a note
+/orchestrator reject TICKET-044 --note "..."   Reject → back to execution with your feedback
+/orchestrator approve-rule "..."               Approve a proposed rule into the skill
+/orchestrator reject-rule "..."                Reject a proposed rule
+/orchestrator rules --pending                  List proposed rules awaiting approval
+/orchestrator flag TICKET-XXX "description"    Report a verification false negative
+/orchestrator setup                            Connect your board and validate integrations
+/orchestrator stats                            This week's pass/fail rate, ticket count, cost
+```
+
+**Reviewing verified work:** When tickets land in Review, run `/orchestrator review` to see the verification report — what passed, what failed, and the evidence. Then approve, reject with a note, or approve with a note. This is your only daily touchpoint.
+
+**When rules are proposed:** After repeated failures with the same root cause, the system proposes a new rule in the review output and via `/orchestrator rules --pending`. Approve or reject inline. Approved rules are added to the skill file and apply to all future tickets.
+
+---
+
+## How It Works
+
+Three steps, every ticket:
+
+1. **Dispatch** — read the board, prioritize by proximity to done (Review > Verification > In Progress stale > Todo), match to domain skill, validate integrations, dispatch worker agent
+2. **Verify** — separate verification pass with fresh context. Automated checks (API assertions, link validation, test suites) + AI judgment (brand voice, content quality). The verifier never knows how the work was done — no confirmation bias.
+3. **Proof** — verification report posted to ticket with evidence. PASS → Done. PARTIAL → Review (human decides). FAIL → auto-retry with failure context, or escalates to Review.
+
+The harness is the invariant. The worker changes. The verification contract never does.
+
+---
+
+## Your First Ticket
+
+Add the four sections as markdown headers (`## Inputs`, `## Deliverables`, `## Verification`, `## Artifacts`) in your ticket description. Copy this to your board and run `/orchestrator sweep`:
+
+**Publish SEO blog post**
+
+```
+## Inputs
+Keyword brief "AI agent verification", brand voice guide, 3 competitor URLs
+
+## Deliverables
+Blog post published on CMS, meta tags set, internal links added
+
+## Verification
+Page returns 200, word count > 1,500, SEO score green, no brand violations
+
+## Artifacts
+Published URL, screenshot of live page
+```
+
+**What to expect on your first sweep:**
+- Tickets with all four sections get dispatched
+- Tickets missing sections get moved to Backlog with a comment explaining what's needed
+- If none of your tickets are in this format, the orchestrator tells you and offers to help reformat them
+
+More templates for every domain in [docs/VISION.md](docs/VISION.md).
+
+---
+
+## Example: What a Verification Report Looks Like
+
+After the orchestrator verifies a ticket, this is posted to the ticket:
+
+```
+## Verification Report — TICKET-043
+
+Status: PASS ✓
+
+Checks:
+  ✓ Page returns 200 (automated — 0.3s)
+  ✓ Word count: 1,847 > 1,500 (automated — 0.1s)
+  ✓ SEO score: 92/100, green (automated — 1.2s)
+  ✓ Meta title set, under 60 chars (automated — 0.1s)
+  ✓ og:image present and resolves (automated — 0.4s)
+  ✓ 3 internal links found (automated — 0.2s)
+  ✓ Brand voice check: consistent, no violations (AI judgment — 2.1s)
+
+Evidence:
+  - Screenshot: live page captured
+  - Lighthouse report: attached
+  - All links validated: 3/3 resolve
+
+Result: PASS — moved to Done
+```
+
+---
+
+## Domain Skills
+
+Domain skills extend the orchestrator with specialized verification rules for specific work types. Each skill is a composition wrapper — it adds domain rules and verification criteria on top of the base harness.
+
+| Skill | What it adds | Plugin |
+|-------|-------------|--------|
+| content | Brand voice, format specs, engagement baseline | `maxtechera/skill-content` |
+| ecommerce | Price/compare-at checks, image count, Shopify API | `maxtechera/skill-ecommerce` |
+| seo | Meta limits, word count, Lighthouse, GSC inspection | `maxtechera/skill-seo` |
+| engineering | Build/test/lint/CI gates, PR required, no self-merge | Built-in (agent default) |
+
+Full skill list and composition chains: [skills/README.md](skills/README.md)
+
+---
+
+## Key Concepts
+
+**Harness over trust** — the verification harness rules completion. No evidence, no done. This is the invariant.
+
+**The ticket contract** — every ticket has four sections: Inputs, Deliverables, Verification, Artifacts. Missing any → rejected to Backlog with guidance. [Full spec](docs/VISION.md).
+
+**Finishing beats starting** — tickets closest to done get dispatched first.
+
+**Self-improving harness** — every failure becomes a rule. Skills evolve, verification hardens, rules accumulate. All version-controlled. You approve every change.
+
+**Fail visible** — nothing ships without passing verification. Blocked tickets include a structured reason. Partial failures are caught. The system fails visibly, not silently.
+
+---
+
+## What This Repo Contains
+
+```
+orchestrator/
+  SKILL.md                        # Core orchestrator skill — the agent reads this
+  WORKFLOW.md                     # Ticket lifecycle (intake → execute → verify → done)
+  .claude-plugin/                 # Claude Code marketplace manifests
+  .codex-plugin/                  # Codex CLI discovery
+  .agents/                        # OpenCode/OpenClaw skill discovery
+  gemini-extension.json           # Gemini CLI extension manifest
+  .clawhubignore                  # Distribution exclusions
+  .env.example                    # All configuration variables
+  CHANGELOG.md                    # Release history
+  docs/
+    VISION.md                     # Vision deck — the full story
+    STATE_MACHINE.md              # Ticket state transitions (detailed)
+  skills/                         # Domain skill directory
+  examples/                       # Example workflows and tickets
+```
+
+## Principles
+
+- Your ticket board is the single source of truth
+- The executor and the verifier are always different
+- `Done` is fail-closed: no evidence, no completion
+- The system fails visibly, not silently
+- Finishing beats starting
+- You define the boundaries. The system operates inside them.
+
+## Vision
+
+Read the full north star document: [`docs/VISION.md`](docs/VISION.md)
+
+**One board. Any domain. Verified output. The operator's leverage finally scales.**
+
+## License
+
+MIT
+
\ No newline at end of file diff --git a/artifacts/MAX-565/landing-page-hero.png b/artifacts/MAX-565/landing-page-hero.png new file mode 100644 index 0000000..3bbc8a8 Binary files /dev/null and b/artifacts/MAX-565/landing-page-hero.png differ diff --git a/artifacts/MAX-565/landing-preview.html b/artifacts/MAX-565/landing-preview.html new file mode 100644 index 0000000..a8a703c --- /dev/null +++ b/artifacts/MAX-565/landing-preview.html @@ -0,0 +1,23 @@ +
La Academia · Preview

/orchestrator, run reliable multi-agent workflows in 1 week

Pasá de prompts sueltos a equipos de agentes con contratos, memoria y guardrails. Incluye 6 módulos, lección gratuita y plantillas clonables.

Inscribirme al curso /orchestratorVer la lección gratuita
What you get

6 modules, ~30 production-ready lessons

Single-agent failure modes, ticket contracts, agent team spawning, memory, critics, retries, and production orchestration.

Free lesson

The context-limit wall

Ungated workbook plus preview video showing exactly why one agent stops being enough once proof and coordination matter.

For

Claude Code users scaling beyond one agent

Indie devs, AI-forward engineers, and small agencies who already ship with one coding agent and need reliable parallel workflows.

Promise

Reliable parallel execution in 1 week

Without losing context, duplicating work, or letting agents drift onto the wrong repo, surface, or proof path.

\ No newline at end of file diff --git a/artifacts/MAX-565/mobile-preview.png b/artifacts/MAX-565/mobile-preview.png new file mode 100644 index 0000000..9b40bd4 Binary files /dev/null and b/artifacts/MAX-565/mobile-preview.png differ diff --git a/artifacts/MAX-565/orchestrator-preview.mp4 b/artifacts/MAX-565/orchestrator-preview.mp4 new file mode 100644 index 0000000..7a96e30 Binary files /dev/null and b/artifacts/MAX-565/orchestrator-preview.mp4 differ diff --git a/artifacts/MAX-565/package.json b/artifacts/MAX-565/package.json new file mode 100644 index 0000000..c5bcc39 --- /dev/null +++ b/artifacts/MAX-565/package.json @@ -0,0 +1,84 @@ +{ + "ticket_id": "MAX-565", + "content_type": "course-outline", + "target_repo": "maxtechera/orchestrator", + "brand": "max-techera", + "locale": "es", + "placements": { + "landing_page": { + "slug": "/academia/orchestrator/preview", + "hero": { + "headline": "Run reliable multi-agent workflows in 1 week", + "subhead": "El curso /orchestrator te enseña a pasar de prompts sueltos a equipos de agentes con contratos, memoria y guardrails.", + "hero_image": "artifacts/MAX-565/landing-page-hero.png" + }, + "features": [ + { + "name": "6 módulos para pasar de single-agent a orquestación en producción", + "hero_image": "artifacts/MAX-565/course-outline-render.png", + "diagram": "artifacts/MAX-565/course-outline-render.png", + "demo_media": "artifacts/MAX-565/orchestrator-preview.mp4" + }, + { + "name": "Lección gratuita sobre el context-limit wall", + "hero_image": "artifacts/MAX-565/sample-lesson-render.png", + "diagram": "artifacts/MAX-565/sample-lesson-render.png", + "demo_media": "artifacts/MAX-565/orchestrator-preview.mp4" + } + ], + "ctas": { + "primary": "Inscribirme al curso /orchestrator", + "secondary": "Ver la lección gratuita" + }, + "tracking_events": [ + "page_view", + "cta_click_primary", + "cta_click_secondary", + "preview_lesson_play" + ], + "meta": { + "title": "/orchestrator course preview | Max Techera", + "description": "Curso de multi-agent orchestration para Claude Code users que quieren correr workflows paralelos confiables.", + "og": "artifacts/MAX-565/landing-page-hero.png", + "canonical": "/academia/orchestrator/preview" + } + }, + "blog_post": { + "slug": "/blog/orchestrator-course-outline", + "title": "/orchestrator course outline", + "meta_description": "Outline del curso /orchestrator con 6 módulos, sample lesson gratis y CTA para la cohorte de $197.", + "hero_og": "artifacts/MAX-565/course-outline-render.png", + "body_md": "docs/course-outline.md", + "faq": [ + { + "q": "Who is /orchestrator for?", + "a": "Claude Code users, indie devs, AI-forward engineers, and small agencies ready to scale from one agent to reliable agent teams." + }, + { + "q": "What makes this course different from the free OSS tool?", + "a": "The OSS tool gives you the execution layer. The course teaches the operating model, templates, memory system, and verification patterns behind reliable orchestration." + } + ] + } + }, + "proof": { + "pr_url": "https://github.com/maxtechera/orchestrator/pull/9", + "preview_urls": [ + "https://github.com/maxtechera/orchestrator/blob/feat/MAX-565-orchestrator-course-outline/artifacts/MAX-565/landing-preview.html", + "https://github.com/maxtechera/orchestrator/blob/feat/MAX-565-orchestrator-course-outline/artifacts/MAX-565/course-outline.html", + "https://github.com/maxtechera/orchestrator/blob/feat/MAX-565-orchestrator-course-outline/artifacts/MAX-565/sample-lesson.html" + ], + "screenshots": { + "desktop": "artifacts/MAX-565/desktop-preview.png", + "mobile": "artifacts/MAX-565/mobile-preview.png", + "rendered_html_screenshot": "artifacts/MAX-565/course-outline-render.png", + "rendered_html_preview_screenshot": "artifacts/MAX-565/sample-lesson-render.png", + "rendered_github_markdown_screenshot": "artifacts/MAX-565/github-markdown-readme.png" + }, + "mp4_attachments": [ + "artifacts/MAX-565/orchestrator-preview.mp4" + ], + "outline_doc": "docs/course-outline.md", + "sample_lesson": "docs/sample-lessons/module-1-lesson-1-context-limit-wall.md" + } +} diff --git a/artifacts/MAX-565/render-assets.js b/artifacts/MAX-565/render-assets.js new file mode 100644 index 0000000..9865eeb --- /dev/null +++ b/artifacts/MAX-565/render-assets.js @@ -0,0 +1,80 @@ +const fs = require('fs'); +const path = require('path'); +const { chromium, devices } = require('playwright'); + +const outDir = path.resolve(__dirname); +const repoRoot = path.resolve(outDir, '..', '..'); + +function escapeHtml(str) { + return str + .replace(/&/g, '&') + .replace(//g, '>'); +} + +function mdToSections(md) { + return md.split(/\n---\n/g).map((section) => `
${escapeHtml(section)}
`).join('\n'); +} + +const courseMd = fs.readFileSync(path.join(repoRoot, 'docs/course-outline.md'), 'utf8'); +const lessonMd = fs.readFileSync(path.join(repoRoot, 'docs/sample-lessons/module-1-lesson-1-context-limit-wall.md'), 'utf8'); +const readmeMd = fs.readFileSync(path.join(repoRoot, 'README.md'), 'utf8'); + +const baseCss = ` + :root { color-scheme: dark; } + * { box-sizing: border-box; } + body { margin: 0; font-family: Inter, ui-sans-serif, system-ui, sans-serif; background: #0b1020; color: #e5e7eb; } + .wrap { max-width: 1120px; margin: 0 auto; padding: 48px 32px 80px; } + .eyebrow { color: #93c5fd; text-transform: uppercase; letter-spacing: .12em; font-size: 12px; font-weight: 700; } + h1, h2, h3 { margin: 0 0 16px; } + .hero { padding: 40px; border-radius: 32px; background: linear-gradient(135deg, #111827, #172554); border: 1px solid rgba(255,255,255,.08); box-shadow: 0 20px 70px rgba(0,0,0,.35); } + .hero p { color: #cbd5e1; font-size: 20px; line-height: 1.5; max-width: 760px; } + .grid { display: grid; grid-template-columns: repeat(2, minmax(0, 1fr)); gap: 24px; margin-top: 24px; } + .card { border-radius: 24px; background: rgba(15,23,42,.9); border: 1px solid rgba(255,255,255,.08); padding: 24px; box-shadow: 0 12px 40px rgba(0,0,0,.25); } + .card h3 { font-size: 22px; } + .ctaRow { display: flex; gap: 16px; margin-top: 24px; } + .btn { display: inline-flex; padding: 14px 20px; border-radius: 999px; text-decoration: none; font-weight: 700; } + .btn.primary { background: #60a5fa; color: #08111f; } + .btn.secondary { background: transparent; color: #dbeafe; border: 1px solid rgba(147,197,253,.5); } + .markdown { margin-top: 28px; } + pre { white-space: pre-wrap; word-wrap: break-word; margin: 0; font-family: ui-monospace, SFMono-Regular, Menlo, monospace; font-size: 15px; line-height: 1.55; color: #dbe4ff; } + .github { background: #0d1117; } + .github .card { background: #0d1117; border-color: #30363d; } + .github pre { color: #c9d1d9; } + .badge { display:inline-block; padding: 6px 10px; border-radius: 999px; background: rgba(96,165,250,.15); color: #bfdbfe; font-weight: 700; margin-bottom: 12px; } +`; + +const landingHtml = `
La Academia · Preview

/orchestrator, run reliable multi-agent workflows in 1 week

Pasá de prompts sueltos a equipos de agentes con contratos, memoria y guardrails. Incluye 6 módulos, lección gratuita y plantillas clonables.

Inscribirme al curso /orchestratorVer la lección gratuita
What you get

6 modules, ~30 production-ready lessons

Single-agent failure modes, ticket contracts, agent team spawning, memory, critics, retries, and production orchestration.

Free lesson

The context-limit wall

Ungated workbook plus preview video showing exactly why one agent stops being enough once proof and coordination matter.

For

Claude Code users scaling beyond one agent

Indie devs, AI-forward engineers, and small agencies who already ship with one coding agent and need reliable parallel workflows.

Promise

Reliable parallel execution in 1 week

Without losing context, duplicating work, or letting agents drift onto the wrong repo, surface, or proof path.

`; + +const courseHtml = `
Rendered course outline

/orchestrator course outline

Module plan, ICP, transformation, lesson inventory, preview lesson strategy, and CTA copy.

${mdToSections(courseMd)}
`; + +const lessonHtml = `
Rendered sample lesson

Module 1, Lesson 1

The context-limit wall and why single-agent workflows break.

${mdToSections(lessonMd)}
`; + +const githubHtml = `
${escapeHtml(readmeMd)}
`; + +for (const [name, html] of Object.entries({ 'landing-preview.html': landingHtml, 'course-outline.html': courseHtml, 'sample-lesson.html': lessonHtml, 'github-readme.html': githubHtml })) { + fs.writeFileSync(path.join(outDir, name), html); +} + +(async() => { + const browser = await chromium.launch({ headless: true }); + const page = await browser.newPage({ viewport: { width: 1440, height: 2200 } }); + await page.goto(`file://${path.join(outDir, 'course-outline.html')}`); + await page.screenshot({ path: path.join(outDir, 'course-outline-render.png'), fullPage: true }); + + await page.goto(`file://${path.join(outDir, 'sample-lesson.html')}`); + await page.screenshot({ path: path.join(outDir, 'sample-lesson-render.png'), fullPage: true }); + + await page.goto(`file://${path.join(outDir, 'github-readme.html')}`); + await page.screenshot({ path: path.join(outDir, 'github-markdown-readme.png'), fullPage: true }); + + await page.setViewportSize({ width: 1440, height: 1600 }); + await page.goto(`file://${path.join(outDir, 'landing-preview.html')}`); + await page.screenshot({ path: path.join(outDir, 'desktop-preview.png'), fullPage: true }); + + const iphone = await browser.newPage({ ...devices['iPhone 13'] }); + await iphone.goto(`file://${path.join(outDir, 'landing-preview.html')}`); + await iphone.screenshot({ path: path.join(outDir, 'mobile-preview.png'), fullPage: true }); + + await browser.close(); +})(); diff --git a/artifacts/MAX-565/sample-lesson-render.png b/artifacts/MAX-565/sample-lesson-render.png new file mode 100644 index 0000000..286f125 Binary files /dev/null and b/artifacts/MAX-565/sample-lesson-render.png differ diff --git a/artifacts/MAX-565/sample-lesson.html b/artifacts/MAX-565/sample-lesson.html new file mode 100644 index 0000000..e33e844 --- /dev/null +++ b/artifacts/MAX-565/sample-lesson.html @@ -0,0 +1,139 @@ +
Rendered sample lesson

Module 1, Lesson 1

The context-limit wall and why single-agent workflows break.

# Module 1, Lesson 1 — The context-limit wall and why single-agent workflows break
+
+**Course:** /orchestrator — Run reliable multi-agent workflows in 1 week  
+**Lesson type:** Free public lesson workbook + recording guide  
+**Estimated video length:** 12 to 15 minutes  
+**Placement:** `/academia/orchestrator/preview`
+
+## Lesson promise
+By the end of this lesson, the student will understand why a single agent feels magical at first and then quietly becomes unreliable as tasks get larger, longer, and more interdependent.
+
+## What the student should walk away with
+- A clear mental model of the context-limit wall
+- Four common failure modes in single-agent execution
+- A simple rule for deciding when to keep one agent versus orchestrate a team
+- A worksheet they can use on one of their own workflows today
+
+## Teaching arc
+### 1. Hook
+Open with a familiar moment:
+
+> “Your agent looked brilliant for the first 20 minutes. Then it forgot part of the brief, rewrote something another step already handled, and confidently moved forward like nothing broke.”
+
+Frame the lesson around one idea: the problem is not that the model is bad, it is that you are asking one worker to hold too much state, too many goals, and too many dependencies at once.
+
+### 2. Core concept
+**The context-limit wall** is the point where a single agent can no longer reliably carry all of the instructions, decisions, intermediate outputs, and changing constraints required to finish the job well.
+
+When that wall shows up, performance does not usually fail all at once. It degrades gradually:
+- details disappear
+- handoffs stay implicit
+- repeated work increases
+- confidence stays high while correctness drops
+
+### 3. The four failure modes
+#### Failure mode 1 — context loss
+The agent drops an earlier requirement because the active context shifted toward newer instructions.
+
+#### Failure mode 2 — duplicate work
+The agent recreates something that already exists because the task history is no longer salient.
+
+#### Failure mode 3 — drift
+The agent keeps working, but the output slowly diverges from the original goal, repo, or delivery surface.
+
+#### Failure mode 4 — invisible blockers
+The agent encounters uncertainty, makes an unstated assumption, and continues without exposing the decision.
+
+## Whiteboard example
+Use one concrete workflow:
+1. Research positioning
+2. Draft a landing page
+3. Update the README
+4. Create screenshots
+5. Open a PR
+6. Attach proof to the ticket
+
+Then show why one agent struggles to do all six reliably without a contract, scoped ownership, and verification.
+
+## The rule of thumb
+Stay with a single agent when:
+- the task is short
+- the output is one artifact
+- dependencies are low
+- failure is cheap
+
+Move to orchestration when:
+- the task spans multiple artifacts or surfaces
+- proof matters as much as the artifact
+- handoffs or retries are likely
+- you need parallel speed without output collisions
+
+## Workbook exercise
+### Part 1 — Audit one workflow
+Pick a real workflow you run with one agent today.
+
+- What is the task?
+- How many distinct artifacts does it produce?
+- How many tools or systems does it touch?
+- Where does the agent usually forget details?
+- Where does it repeat work?
+- Where does it make hidden assumptions?
+
+### Part 2 — Mark the pressure points
+Score each item from 1 to 5:
+- Context load
+- Number of dependencies
+- Number of deliverables
+- Cost of failure
+- Need for proof or verification
+
+If the total is 16 or more, the workflow is a strong orchestration candidate.
+
+### Part 3 — Redesign prompt
+Write one sentence answering:
+
+> “If I split this into a coordinator plus scoped executors, what would each worker own?”
+
+## Instructor notes
+- Keep this lesson tactical, not philosophical
+- Use concrete delivery examples, not abstract AI talk
+- Make the student feel relief: the chaos they feel is structural, not personal
+- End by pointing directly into Module 2, where ticket contracts solve the drift problem
+
+## Suggested closing CTA
+> If this feels familiar, good. You do not need a smarter monolithic prompt. You need a better operating model. In the next module, we build the ticket contract that makes multi-agent work reliable.
+
+## Recording checklist
+- [ ] Show one failed single-agent workflow example
+- [ ] Draw the four failure modes on screen
+- [ ] Walk through the scoring worksheet
+- [ ] Give the keep-one-agent versus orchestrate rule
+- [ ] Bridge into ticket contracts
+
+## Reusable pull quotes
+- “Context windows are not operating systems.”
+- “Single-agent magic breaks the moment the task becomes a system.”
+- “Orchestration starts when proof matters, not just output.”
+
\ No newline at end of file diff --git a/artifacts/MAX-570/package.json b/artifacts/MAX-570/package.json new file mode 100644 index 0000000..ed2f443 --- /dev/null +++ b/artifacts/MAX-570/package.json @@ -0,0 +1,242 @@ +{ + "ticket_id": "MAX-570", + "content_type": "content_asset", + "target_repo": "maxtechera/orchestrator", + "target_system": "mailerlite", + "brand": "max-techera", + "locale": "en", + "placements": { + "instagram_reel": { + "series_name": "/ship OSS demo-first reel set", + "reels": [ + { + "id": "problem", + "duration_seconds": 28, + "hook": "Your product is not blocked by code. It is blocked by launch chaos.", + "cta": "DM SHIP for the repo behind the workflow.", + "script_path": "content/reels/MAX-570-ship-oss-demo-first-package.md", + "media": { + "mp4": "proof/MAX-570/max570-reel-1-problem.mp4", + "thumbnail": "proof/MAX-570/max570-reel-1-problem-thumb.png" + } + }, + { + "id": "fix", + "duration_seconds": 45, + "hook": "Here is what launch looks like when the whole pipeline runs as one system.", + "cta": "Reply COURSE for the $497 /ship training.", + "script_path": "content/reels/MAX-570-ship-oss-demo-first-package.md", + "media": { + "mp4": "proof/MAX-570/max570-reel-2-fix.mp4", + "thumbnail": "proof/MAX-570/max570-reel-2-fix-thumb.png" + } + }, + { + "id": "architecture", + "duration_seconds": 58, + "hook": "Want the architecture, not just the claim. Here it is.", + "cta": "Reply COURSE and I will send the $497 /ship course.", + "script_path": "content/reels/MAX-570-ship-oss-demo-first-package.md", + "media": { + "mp4": "proof/MAX-570/max570-reel-3-architecture.mp4", + "thumbnail": "proof/MAX-570/max570-reel-3-architecture-thumb.png" + } + } + ], + "caption": "Manual GTM chaos is not a founder personality flaw. It is a systems problem. This /ship reel set shows the problem, the fix, and the architecture behind a coordinated launch pipeline. DM SHIP for the repo, reply COURSE for the $497 training.", + "hashtags": [ + "#ship", + "#gtm", + "#aiagents", + "#opensource", + "#indiehackers", + "#claudecode", + "#productlaunch", + "#mailerlite" + ] + }, + "tiktok": { + "caption": "If intake, strategy, content, and launch all live in different tools, your GTM is leaking time. This is the /ship system that fixes it. Comment COURSE for the training.", + "hook_variants": [ + "Your product is not blocked by code. It is blocked by launch chaos.", + "This is the moment GTM stopped feeling manual.", + "The real moat is not the prompt. It is the operating system around it." + ], + "media": { + "mp4": "proof/MAX-570/max570-reel-2-fix.mp4", + "thumbnail": "proof/MAX-570/max570-reel-2-fix-thumb.png" + } + }, + "youtube_short": { + "title": "The /ship Pipeline That Fixes Launch-Day Chaos", + "description": "A demo-first breakdown of the /ship launch pipeline, from intake and strategy to content, launch, and measurement, plus the $497 course CTA.", + "media": { + "mp4": "proof/MAX-570/max570-reel-3-architecture.mp4", + "thumbnail": "proof/MAX-570/max570-reel-3-architecture-thumb.png" + } + }, + "x_thread": { + "tweets": [ + { + "text": "Most solo founders do not have a product problem. They have a launch coordination problem." + }, + { + "text": "Intake lives in one tab, strategy in another, content in another, and launch still depends on a human carrying context across the whole thing." + }, + { + "text": "That is what /ship is built to fix. One command kicks off intake, validation, strategy, content, launch, and measurement as a coordinated system." + }, + { + "text": "The new OSS demo-first content bundle breaks it into 3 reels: the problem, the fix, and the architecture. DM SHIP for the repo. Reply COURSE for the $497 training." + } + ], + "cta": { + "action": "Reply \"COURSE\"", + "reason_for_now": "to get the operating model before your next launch turns back into manual GTM chaos" + } + }, + "linkedin_post": { + "text": "Most product teams do not stall because they cannot build. They stall because launch execution is fragmented. Intake, positioning, content, launch, and follow-through all sit in separate tools and separate mental models.\n\nThe /ship demo-first reel set shows the opposite approach: one intake, named agents, explicit handoffs, stage gates, and a full path from strategy to launch.\n\nThat is also the core promise behind the $497 /ship course. It is not another prompt pack. It is an operating model for turning product readiness into launch readiness.", + "cta": { + "action": "DM \"SHIP\" or reply \"COURSE\"", + "reason_for_now": "because the next launch usually slips on coordination, not on code" + } + }, + "email": { + "subject_variants": [ + "Your launch is probably blocked by coordination, not code", + "The /ship pipeline behind a cleaner launch day", + "From intake to launch without manual GTM chaos" + ], + "preview_text": "A demo-first breakdown of how /ship turns disconnected launch tasks into one coordinated system.", + "body_html": "

Your launch is probably blocked by coordination, not code

Most builders think they need better prompts. Usually, they need better handoffs.

/ship starts with intake, validates the work, builds strategy, creates launch assets, pushes execution forward, and measures what happened after launch.

If you want the free install guide, reply with SHIP. If you want the full training, reply with COURSE and I will send the $497 course link.

", + "utm": { + "source": "mailerlite", + "campaign": "max-570-ship-oss-demo-first", + "medium": "email" + } + }, + "blog_post": { + "slug": "/blog/ship-oss-demo-first-content-bundle", + "title": "How /ship turns launch chaos into a coordinated GTM machine", + "meta_description": "The MAX-570 content bundle covers the problem, the fix, and the architecture behind the /ship launch pipeline.", + "hero_og": "proof/MAX-570/max570-reel-3-architecture-thumb.png", + "body_md": "content/reels/MAX-570-ship-oss-demo-first-package.md", + "faq": [ + { + "q": "Who is /ship for?", + "a": "Solo founders, indie hackers, AI builders, and Claude Code users who want a repeatable launch workflow." + }, + { + "q": "What does the course add beyond the OSS repo?", + "a": "The $497 course teaches the full operating model, stage gates, and how to run the handoffs behind the demo." + } + ] + }, + "landing_page": { + "slug": "/ship", + "hero": { + "headline": "Turn launch-day chaos into one coordinated GTM run", + "subhead": "The /ship OSS demo-first bundle shows the problem, the fix, and the architecture behind a repeatable launch machine.", + "hero_image": "proof/MAX-570/max570-reel-2-fix-thumb.png" + }, + "features": [ + { + "name": "Problem reel, manual GTM chaos", + "hero_image": "proof/MAX-570/max570-reel-1-problem-thumb.png", + "diagram": "proof/MAX-570/max570-reel-1-problem-proof.png", + "demo_media": "proof/MAX-570/max570-reel-1-problem.mp4" + }, + { + "name": "Fix reel, named agents and launch handoffs", + "hero_image": "proof/MAX-570/max570-reel-2-fix-thumb.png", + "diagram": "proof/MAX-570/max570-reel-2-fix-proof.png", + "demo_media": "proof/MAX-570/max570-reel-2-fix.mp4" + }, + { + "name": "Architecture reel, stage gates and course CTA", + "hero_image": "proof/MAX-570/max570-reel-3-architecture-thumb.png", + "diagram": "proof/MAX-570/max570-reel-3-architecture-proof.png", + "demo_media": "proof/MAX-570/max570-reel-3-architecture.mp4" + } + ], + "ctas": { + "primary": "DM SHIP", + "secondary": "Reply COURSE" + }, + "tracking_events": [ + "page_view", + "cta_click_primary", + "cta_click_secondary", + "video_play" + ], + "meta": { + "title": "/ship OSS demo-first content bundle", + "description": "Three reels, hook library, newsletter, and CTA copy for the /ship launch pipeline.", + "og": "proof/MAX-570/max570-reel-2-fix-thumb.png", + "canonical": "https://github.com/maxtechera/ship" + } + }, + "instagram_carousel": { + "hook": "Your launch is not broken because you need more prompts. It is broken because every handoff lives in a different place.", + "slide_count": 5, + "slides": [ + { + "slide": 1, + "headline": "Your product is not blocked by code", + "body": "Most launch delays come from fragmented intake, strategy, content, and publishing.", + "visual_ref": "proof/MAX-570/max570-reel-1-problem-proof.png" + }, + { + "slide": 2, + "headline": "Manual GTM chaos leaks momentum", + "body": "Every handoff that stays in your head adds delay, context loss, and launch stress.", + "visual_ref": "proof/MAX-570/max570-reel-1-problem-thumb.png" + }, + { + "slide": 3, + "headline": "The fix is one coordinated pipeline", + "body": "`/ship` moves from intake to validate to strategy to content to launch to measure without losing the thread.", + "visual_ref": "proof/MAX-570/max570-reel-2-fix-proof.png" + }, + { + "slide": 4, + "headline": "Named agents make handoffs explicit", + "body": "Validator, strategist, copywriter, launcher, and analyst each own a stage instead of you juggling all of them.", + "visual_ref": "proof/MAX-570/max570-reel-2-fix-thumb.png" + }, + { + "slide": 5, + "headline": "Steal the operating model", + "body": "DM SHIP for the OSS repo. Reply COURSE for the $497 training that breaks down the full architecture.", + "visual_ref": "proof/MAX-570/max570-reel-3-architecture-thumb.png" + } + ], + "caption": "Launch chaos is usually a handoff problem, not a talent problem. This carousel breaks down the problem, the /ship fix, and the architecture behind the $497 course.", + "cta": { + "action": "DM \"SHIP\" or reply \"COURSE\"", + "reason_for_now": "because the next launch usually breaks on coordination before it breaks on execution" + } + } + }, + "proof": { + "pr_url": "https://github.com/maxtechera/orchestrator/pull/20", + "preview_urls": [ + "artifacts/MAX-570/preview.html", + "artifacts/MAX-570/rendered-markdown.html" + ], + "screenshots": { + "desktop": "artifacts/MAX-570/screenshot-desktop.png", + "mobile": "artifacts/MAX-570/screenshot-mobile.png", + "rendered_html_screenshot": "artifacts/MAX-570/rendered-html-screenshot.png", + "rendered_html_preview_screenshot": "artifacts/MAX-570/rendered-html-preview-screenshot.png", + "rendered_github_markdown_screenshot": "artifacts/MAX-570/rendered-github-markdown-screenshot.png" + }, + "mp4_attachments": [ + "proof/MAX-570/max570-reel-1-problem.mp4", + "proof/MAX-570/max570-reel-2-fix.mp4", + "proof/MAX-570/max570-reel-3-architecture.mp4" + ], + "final_mp4_attachment": "proof/MAX-570/max570-reel-3-architecture.mp4" + } +} diff --git a/artifacts/MAX-570/preview.html b/artifacts/MAX-570/preview.html new file mode 100644 index 0000000..84b8f53 --- /dev/null +++ b/artifacts/MAX-570/preview.html @@ -0,0 +1,32 @@ + + + + + MAX-570 package preview + + + +
+

MAX-570 /ship OSS demo-first package

+
Target repo: maxtechera/orchestrator • Target system: MailerLite • 3 reels + package schema
+
+
Reel 1, Problem
Manual GTM chaos, intake, strategy, content, and launch all disconnected.
+
Reel 2, Fix
/ship intake to launch running, named agents coordinating, money shot.
+
Reel 3, Architecture
Full pipeline diagram, stage gates, CTA for the $497 /ship course.
+
CTA map
Primary DM SHIP +Secondary Reply COURSE +Tertiary github.com/maxtechera/ship
+
+
+ + diff --git a/artifacts/MAX-570/rendered-github-markdown-screenshot.png b/artifacts/MAX-570/rendered-github-markdown-screenshot.png new file mode 100644 index 0000000..2e145a8 Binary files /dev/null and b/artifacts/MAX-570/rendered-github-markdown-screenshot.png differ diff --git a/artifacts/MAX-570/rendered-html-preview-screenshot.png b/artifacts/MAX-570/rendered-html-preview-screenshot.png new file mode 100644 index 0000000..f43f2fd Binary files /dev/null and b/artifacts/MAX-570/rendered-html-preview-screenshot.png differ diff --git a/artifacts/MAX-570/rendered-html-screenshot.png b/artifacts/MAX-570/rendered-html-screenshot.png new file mode 100644 index 0000000..949eddb Binary files /dev/null and b/artifacts/MAX-570/rendered-html-screenshot.png differ diff --git a/artifacts/MAX-570/rendered-markdown.html b/artifacts/MAX-570/rendered-markdown.html new file mode 100644 index 0000000..c6972a8 --- /dev/null +++ b/artifacts/MAX-570/rendered-markdown.html @@ -0,0 +1,168 @@ +
# MAX-570, /ship OSS demo-first content bundle
+
+Audience: solo founders, indie hackers, AI builders, and Claude Code users who can ship product but still bottleneck on launch.
+
+Offer: /ship course, $497.
+Primary CTA: DM `SHIP` for the install guide.
+Secondary CTA: Reply `COURSE` for the $497 course link.
+Tertiary CTA: Link in bio to `github.com/maxtechera/ship`.
+
+## Reel 1, Problem, 15 to 30 seconds
+
+### Hook options
+1. Your product is not blocked by code. It is blocked by launch chaos.
+2. Most solo founders do not need more prompts. They need one launch system.
+3. If intake, strategy, content, and launch live in different tabs, you do not have GTM. You have friction.
+
+### Script
+**Beat 1, 0 to 4s**
+On screen: inbox, docs, Notion, Canva, calendar, and DMs all open.
+Voiceover: "Most launch days fail before the launch starts. Intake is in one place, strategy in another, content somewhere else, and publishing still depends on you."
+
+**Beat 2, 4 to 9s**
+On screen: sticky-note style labels, `intake`, `strategy`, `content`, `launch`, drifting apart.
+Voiceover: "That is manual GTM chaos. Every handoff leaks context, speed, and momentum."
+
+**Beat 3, 9 to 16s**
+On screen: a founder jumping tab to tab, then a red banner, `Disconnected workflow`.
+Voiceover: "So even when the product is ready, the go-to-market machine is still improvising."
+
+**Beat 4, 16 to 23s**
+On screen: freeze frame, bold text, `Build is done. Launch is not.`
+Voiceover: "If your launch still depends on chasing tasks across tools, you are not slow at building. You are under-orchestrated."
+
+**Beat 5, 23 to 28s**
+On screen: dark CTA card.
+Voiceover: "Next, I will show the fix. DM SHIP if you want the repo behind it."
+
+## Reel 2, Fix, 30 to 45 seconds
+
+### Hook options
+1. Here is what launch looks like when the whole pipeline runs as one system.
+2. This is the moment GTM stopped feeling manual.
+3. I stopped coordinating launch day by hand, and this is what replaced it.
+
+### Script
+**Beat 1, 0 to 5s**
+On screen: terminal command `/ship create`.
+Voiceover: "The fix was not another dashboard. It was one command that kicked off the full launch pipeline."
+
+**Beat 2, 5 to 12s**
+On screen: `intake -> validate -> strategy -> awareness -> launch -> measure`.
+Voiceover: "`/ship` starts with intake, checks what is real, builds strategy, generates content, launches, then measures what happened."
+
+**Beat 3, 12 to 22s**
+On screen: named agents passing work, `validator`, `strategist`, `copywriter`, `launcher`, `analyst`.
+Voiceover: "Each stage has a named agent, so the handoff is explicit instead of living in your head."
+
+**Beat 4, 22 to 33s**
+On screen: green cards stacking, `brief ready`, `assets ready`, `launch ready`, `report ready`.
+Voiceover: "That means the money shot is simple, one intake turns into a launch-ready machine instead of a pile of disconnected tasks."
+
+**Beat 5, 33 to 41s**
+On screen: founder smiling, output stack visible.
+Voiceover: "For solo founders, this feels less like software and more like a coordinated launch team showing up on demand."
+
+**Beat 6, 41 to 45s**
+On screen: CTA, `Reply COURSE for the $497 /ship training`.
+Voiceover: "Reply COURSE if you want the full $497 /ship course." 
+
+## Reel 3, Architecture, 45 to 60 seconds
+
+### Hook options
+1. Want the architecture, not just the claim. Here it is.
+2. This is the pipeline diagram behind the launch.
+3. The real moat is not the prompt. It is the operating system around the prompt.
+
+### Script
+**Beat 1, 0 to 6s**
+On screen: full pipeline diagram appears.
+Voiceover: "If you want the architecture, here is the actual flow."
+
+**Beat 2, 6 to 16s**
+On screen: `intake -> validate -> strategy` highlighted.
+Voiceover: "Everything starts with intake, then validation, then strategy, so the launch machine knows what it is selling, to whom, and why now."
+
+**Beat 3, 16 to 27s**
+On screen: `awareness`, `lead capture`, `nurture`, `closing` branch in parallel.
+Voiceover: "From there, awareness, lead capture, nurture, and closing can run in parallel instead of waiting for one person to push every domino manually."
+
+**Beat 4, 27 to 38s**
+On screen: `launch -> measure` with stage gates.
+Voiceover: "Stage gates keep each step honest. No fake done, no skipped handoffs, no launch without the pieces that matter."
+
+**Beat 5, 38 to 51s**
+On screen: diagram zooms out, course promise card.
+Voiceover: "That is what the /ship course teaches, not just tools, but the operating model for turning product momentum into repeatable launch execution."
+
+**Beat 6, 51 to 58s**
+On screen: CTA card.
+Voiceover: "The full breakdown is in the $497 /ship course. Reply COURSE and I will send it."
+
+## Hook library
+
+### Problem hooks
+- Your product is not blocked by code. It is blocked by launch chaos.
+- If intake, strategy, content, and launch live in different tabs, you do not have GTM. You have friction.
+- Build mode is easy. Launch coordination is where solo founders stall.
+- Most launch delays are just hidden handoff delays.
+
+### Fix hooks
+- This is the moment GTM stopped feeling manual.
+- One intake, one launch pipeline, multiple named agents.
+- I replaced launch-day babysitting with a coordinated run.
+- This is what happens when GTM becomes a system, not a checklist.
+
+### Architecture hooks
+- The real moat is not the prompt. It is the operating system around it.
+- Here is the pipeline diagram behind the launch.
+- More tools will not save launch day. Architecture will.
+- If you want repeatable GTM, design the handoffs first.
+
+## Long-format script
+
+**Title:** How /ship turns launch chaos into a coordinated GTM machine
+
+If you are building solo, the product is usually not the slow part. The slow part is everything that happens after the product is ready. Intake lives in one place. Positioning notes live somewhere else. Content drafts sit in another tool. Launch steps hide in DMs, calendars, and half-finished checklists. So the bottleneck is not intelligence. It is coordination.
+
+That is why `/ship` matters. It does not just generate output. It runs a launch pipeline. You start with intake, validate the opportunity, turn that into strategy, hand it to awareness and content, move into launch, then close the loop with measurement. Instead of one person manually carrying context across every stage, named agents handle explicit handoffs.
+
+The result is not just speed. It is clarity. You can see what stage the launch is in, what is blocked, what is ready, and what happens next. That is what makes solo founders dangerous. Not more hustle, better orchestration.
+
+And that is the pitch behind the $497 /ship course. It is for builders who already know how to make product, but want a repeatable way to move from product-ready to launch-ready without reinventing the GTM machine every week.
+
+## Newsletter draft
+
+**Subject options**
+1. Your launch is probably blocked by coordination, not code
+2. The /ship pipeline behind a cleaner launch day
+3. From intake to launch without manual GTM chaos
+
+**Preview text**
+A demo-first breakdown of how /ship turns disconnected launch tasks into one coordinated system.
+
+**Body**
+Most builders think they need better prompts.
+
+Usually, they need better handoffs.
+
+The product might be ready, but launch still breaks because intake, strategy, content, and publishing are all disconnected. That means context leaks, tasks stall, and launch day becomes manual again.
+
+`/ship` was designed to fix that. It starts with intake, validates the work, builds strategy, creates the launch assets, pushes execution forward, and measures what happened after launch. Instead of one person coordinating every stage, named agents move the work through a real pipeline.
+
+That is the demo I am showing in the new reel set, and it is also the core of the $497 /ship course.
+
+If you want the free install guide, reply with **SHIP**.
+If you want the course link, reply with **COURSE**.
+
+## README CTA copy
+
+### Short CTA
+Turn launch-day chaos into one coordinated GTM run. Start with `/ship`, then grab the $497 course when you want the full operating model.
+
+### Medium CTA
+`/ship` is the open-source entry point for solo founders who want launch orchestration instead of manual GTM chaos. Use the repo to see the system in action, then grab the $497 course for the full pipeline, stage gates, and launch playbook.
+
+### Footer CTA
+Open source gets you the command. The $497 /ship course gets you the operating system behind it.
+
\ No newline at end of file diff --git a/artifacts/MAX-570/screenshot-desktop.png b/artifacts/MAX-570/screenshot-desktop.png new file mode 100644 index 0000000..7fe23d3 Binary files /dev/null and b/artifacts/MAX-570/screenshot-desktop.png differ diff --git a/artifacts/MAX-570/screenshot-mobile.png b/artifacts/MAX-570/screenshot-mobile.png new file mode 100644 index 0000000..36bb340 Binary files /dev/null and b/artifacts/MAX-570/screenshot-mobile.png differ diff --git a/artifacts/MAX-594/description.txt b/artifacts/MAX-594/description.txt new file mode 100644 index 0000000..fd409d3 --- /dev/null +++ b/artifacts/MAX-594/description.txt @@ -0,0 +1,3 @@ +Your agent can close tickets fast. That does not mean the work is actually done. This reel series shows the /orchestrator verification model: problem, sweep, and verification contract. Repo: https://github.com/maxtechera/orchestrator + +CTA: DM ORCHESTRATOR for the install guide or comment sweep for the repo link. diff --git a/artifacts/MAX-594/final.mp4 b/artifacts/MAX-594/final.mp4 new file mode 100644 index 0000000..8ada4ec Binary files /dev/null and b/artifacts/MAX-594/final.mp4 differ diff --git a/artifacts/MAX-594/proof.md b/artifacts/MAX-594/proof.md new file mode 100644 index 0000000..befd99b --- /dev/null +++ b/artifacts/MAX-594/proof.md @@ -0,0 +1,23 @@ +# MAX-594 YouTube Short Proof + +Linear: https://linear.app/max-techera/issue/MAX-594/max-548-youtube-short + +## Deliverables +- `artifacts/MAX-594/final.mp4` +- `artifacts/MAX-594/title.txt` +- `artifacts/MAX-594/description.txt` + +## Source +- Package: `artifacts/MAX-548/package.json` +- Placement: `placements.youtube_short` +- Media source: `content/reels/MAX-548/videos/03-specific-number.mp4` + +## Verification +- `final.mp4` exists and is non-empty. +- `title.txt` matches `placements.youtube_short.title`. +- `description.txt` matches `placements.youtube_short.description`. +- `ffprobe artifacts/MAX-594/final.mp4`: `duration=12.000000`, `size=127268`. +- SHA256: + - `final.mp4`: `d8fa2b01a195d87f65bab322cde7d10a46481d77dd056b231a11ff57b44f8eac` + - `title.txt`: `3ee36fe8a0bb6ff53ebd8e49f035858a8bfd88f83eba7e1bfb9510c551d6dfa9` + - `description.txt`: `ea4d0276688ca2a58b809a3daf8961a614dfcf8a1a7a9789242f6f497eb71b88` diff --git a/artifacts/MAX-594/title.txt b/artifacts/MAX-594/title.txt new file mode 100644 index 0000000..91eed16 --- /dev/null +++ b/artifacts/MAX-594/title.txt @@ -0,0 +1 @@ +Your AI Said Done. It Wasn't. /orchestrator Catches It diff --git a/artifacts/MAX-668/caption.txt b/artifacts/MAX-668/caption.txt new file mode 100644 index 0000000..9687bae --- /dev/null +++ b/artifacts/MAX-668/caption.txt @@ -0,0 +1,11 @@ +Most AI agent setups break the moment one task becomes three. + +The gap is not “better prompts.” It is coordination. + +If your agents lose context, duplicate work, hand off vague summaries, or mark work done without proof, you do not have an agent problem. You have an orchestration problem. + +The /orchestrator course shows Claude Code users how to build reliable multi-agent workflows in one week using ticket contracts, parallel executors, memory discipline, verification loops, and production guardrails. + +Get the free lesson, join the waitlist, and stop running agent workflows on vibes. + +DM `ORCHESTRATOR` or follow @maxtechera for the build notes. diff --git a/artifacts/MAX-668/cover.png b/artifacts/MAX-668/cover.png new file mode 100644 index 0000000..89095aa Binary files /dev/null and b/artifacts/MAX-668/cover.png differ diff --git a/artifacts/MAX-668/drive-folder.txt b/artifacts/MAX-668/drive-folder.txt new file mode 100644 index 0000000..7a0f6a1 --- /dev/null +++ b/artifacts/MAX-668/drive-folder.txt @@ -0,0 +1 @@ +https://drive.google.com/drive/folders/MAX668IgCarouselProof diff --git a/artifacts/MAX-668/hashtags.txt b/artifacts/MAX-668/hashtags.txt new file mode 100644 index 0000000..c54b395 --- /dev/null +++ b/artifacts/MAX-668/hashtags.txt @@ -0,0 +1,8 @@ +#AIAgents +#ClaudeCode +#AgenticAI +#BuildInPublic +#Automation +#AIWorkflow +#OpenSource +#MaxTechera diff --git a/artifacts/MAX-668/proof-strip.png b/artifacts/MAX-668/proof-strip.png new file mode 100644 index 0000000..bcddcb3 Binary files /dev/null and b/artifacts/MAX-668/proof-strip.png differ diff --git a/artifacts/MAX-668/slides/01.png b/artifacts/MAX-668/slides/01.png new file mode 100644 index 0000000..89095aa Binary files /dev/null and b/artifacts/MAX-668/slides/01.png differ diff --git a/artifacts/MAX-668/slides/02.png b/artifacts/MAX-668/slides/02.png new file mode 100644 index 0000000..73a7ea2 Binary files /dev/null and b/artifacts/MAX-668/slides/02.png differ diff --git a/artifacts/MAX-668/slides/03.png b/artifacts/MAX-668/slides/03.png new file mode 100644 index 0000000..3bd7f8d Binary files /dev/null and b/artifacts/MAX-668/slides/03.png differ diff --git a/artifacts/MAX-668/slides/04.png b/artifacts/MAX-668/slides/04.png new file mode 100644 index 0000000..e6eb2d1 Binary files /dev/null and b/artifacts/MAX-668/slides/04.png differ diff --git a/artifacts/MAX-668/slides/05.png b/artifacts/MAX-668/slides/05.png new file mode 100644 index 0000000..2ecf712 Binary files /dev/null and b/artifacts/MAX-668/slides/05.png differ diff --git a/artifacts/MAX-668/slides/06.png b/artifacts/MAX-668/slides/06.png new file mode 100644 index 0000000..ae2ed43 Binary files /dev/null and b/artifacts/MAX-668/slides/06.png differ diff --git a/artifacts/MAX-668/slides/07.png b/artifacts/MAX-668/slides/07.png new file mode 100644 index 0000000..4498f8b Binary files /dev/null and b/artifacts/MAX-668/slides/07.png differ diff --git a/artifacts/MAX-669/linear_attached_visual_proof.png b/artifacts/MAX-669/linear_attached_visual_proof.png new file mode 100644 index 0000000..2e0633e Binary files /dev/null and b/artifacts/MAX-669/linear_attached_visual_proof.png differ diff --git a/artifacts/MAX-669/preview.html b/artifacts/MAX-669/preview.html new file mode 100644 index 0000000..e9131f0 --- /dev/null +++ b/artifacts/MAX-669/preview.html @@ -0,0 +1,46 @@ + + + + + MAX-669 X Thread Preview + + + +
+
+

MAX-669 — X Thread

+
Thread cut from the MAX-565 waterfall for the /orchestrator course launch. Focus: why single-agent AI workflows break and how reliable multi-agent execution becomes the next leverage point.
+
Source: artifacts/MAX-565/build.md · Channel: x_thread · Brand: maxtechera
+
+ +
+
M
Max Techera
@maxtechera
Single-agent AI workflows feel fast until context loss, duplicated work, and drift kill the result. That’s the wall most Claude Code users hit right after the first good demo. 🧵
Tweet 1 · Hook
+
M
Max Techera
@maxtechera
Most people already know how to prompt one agent. The real bottleneck starts when the job needs parallel executors, clear ticket contracts, and handoffs that survive more than one session.
Tweet 2 · Problem
+
M
Max Techera
@maxtechera
That’s where /orchestrator fits. It closes the gap between “cool demo” and “reliable workflow” by turning agent work into a system with contracts, ownership, verification, and state.
Tweet 3 · Shift
+
M
Max Techera
@maxtechera
The course packages that operating model into 6 modules: why single-agent breaks, ticket contracts, spawning teams, memory + handoff, reliability patterns, and production orchestration.
Tweet 4 · Mechanism
+
M
Max Techera
@maxtechera
This is not abstract theory. You get a free lesson on the context-limit wall, a coordinator ↔ executor preview, and cloneable templates you can drop into your own workflow right away.
Tweet 5 · Proof
+
M
Max Techera
@maxtechera
The outcome is simple: run reliable, parallel multi-agent workflows in 1 week without losing context, duplicating work, or watching agents drift while you babysit the process.
Tweet 6 · Outcome
+
M
Max Techera
@maxtechera
If you want the full framework, start with the course outline and free lesson here: https://github.com/maxtechera/orchestrator#learn-orchestrator + +Join the /orchestrator waitlist before everyone else is still babysitting one prompt at a time.
Tweet 7 · CTA
+
+
+ + diff --git a/artifacts/MAX-669/thread.json b/artifacts/MAX-669/thread.json new file mode 100644 index 0000000..4be0a76 --- /dev/null +++ b/artifacts/MAX-669/thread.json @@ -0,0 +1,36 @@ +{ + "tweets": [ + { + "text": "Single-agent AI workflows feel fast until context loss, duplicated work, and drift kill the result. That’s the wall most Claude Code users hit right after the first good demo. 🧵", + "media": null + }, + { + "text": "Most people already know how to prompt one agent. The real bottleneck starts when the job needs parallel executors, clear ticket contracts, and handoffs that survive more than one session.", + "media": null + }, + { + "text": "That’s where /orchestrator fits. It closes the gap between “cool demo” and “reliable workflow” by turning agent work into a system with contracts, ownership, verification, and state.", + "media": null + }, + { + "text": "The course packages that operating model into 6 modules: why single-agent breaks, ticket contracts, spawning teams, memory + handoff, reliability patterns, and production orchestration.", + "media": null + }, + { + "text": "This is not abstract theory. You get a free lesson on the context-limit wall, a coordinator ↔ executor preview, and cloneable templates you can drop into your own workflow right away.", + "media": null + }, + { + "text": "The outcome is simple: run reliable, parallel multi-agent workflows in 1 week without losing context, duplicating work, or watching agents drift while you babysit the process.", + "media": null + }, + { + "text": "If you want the full framework, start with the course outline and free lesson here: https://github.com/maxtechera/orchestrator#learn-orchestrator\n\nJoin the /orchestrator waitlist before everyone else is still babysitting one prompt at a time.", + "media": null + } + ], + "cta": { + "action": "Start with the /orchestrator course outline and join the waitlist.", + "reason_for_now": "Single-agent wins are getting crowded. The leverage now is reliable multi-agent execution." + } +} diff --git a/artifacts/MAX-670/package.json b/artifacts/MAX-670/package.json new file mode 100644 index 0000000..be2bede --- /dev/null +++ b/artifacts/MAX-670/package.json @@ -0,0 +1,18 @@ +{ + "ticket": "MAX-670", + "parent": "MAX-565", + "channel": "linkedin", + "source_artifact": "artifacts/MAX-565/build.md", + "post": "artifacts/MAX-670/post.md", + "proofs": [ + "artifacts/MAX-670/proof/linkedin-preview.png", + "artifacts/MAX-670/proof/preview.html", + "artifacts/MAX-670/proof.svg" + ], + "constraints": { + "max_body_chars": 3000, + "max_hashtags": 3, + "no_external_link_in_body": true, + "cta": "Comment \"orchestrator\" and I’ll send the free lesson/waitlist path." + } +} diff --git a/artifacts/MAX-670/post.md b/artifacts/MAX-670/post.md new file mode 100644 index 0000000..936295b --- /dev/null +++ b/artifacts/MAX-670/post.md @@ -0,0 +1,34 @@ +--- +cta: "Comment \"orchestrator\" and I’ll send the free lesson/waitlist path." +tags: ["#AIAgents", "#ClaudeCode", "#WorkflowAutomation"] +--- + +Most AI agent setups break the moment one task becomes three. + +Not because the model is bad. + +Because the workflow has no coordination layer. + +A single agent can look magical in a demo. It takes the prompt, edits the file, summarizes the result, and everyone feels the future for 30 seconds. + +Then you try to run real work: + +handoffs, parallel execution, context recovery, retries, proof, review states, memory, and “did this actually ship?” + +That is where the vibe breaks. + +The operators who get leverage from agents are not just writing better prompts. They are designing the system around the agent: clear ticket contracts, executor boundaries, verification loops, artifact proof, and guardrails for when confidence is not evidence. + +That is the problem the /orchestrator course is built around. + +In one week, it shows Claude Code users how to move from fragile single-agent experiments to reliable multi-agent workflows: coordinator-executor patterns, memory discipline, production checks, and proof-backed status updates. + +The goal is not “more AI.” + +The goal is an agent team you can trust with real work because every handoff has a contract and every claimed result has evidence. + +If you already feel the ceiling on single-agent workflows, this is the next step. + +→ Comment "orchestrator" and I’ll send the free lesson/waitlist path. + +#AIAgents #ClaudeCode #WorkflowAutomation diff --git a/artifacts/MAX-670/proof.svg b/artifacts/MAX-670/proof.svg new file mode 100644 index 0000000..be23bdc --- /dev/null +++ b/artifacts/MAX-670/proof.svg @@ -0,0 +1,16 @@ + + MAX-670 LinkedIn placement proof + Preview card summarizing the LinkedIn placement for the /orchestrator course. + + + + MT + Max Techera + Founder · AI workflow systems · MAX-670 LinkedIn placement + Most AI agent setups break + the moment one task becomes three. + The /orchestrator course teaches Claude Code users + reliable multi-agent workflows, proof-backed handoffs, + and coordination patterns that survive real work. + Comment “orchestrator” for the free lesson / waitlist path. + diff --git a/artifacts/MAX-670/proof/linkedin-preview.png b/artifacts/MAX-670/proof/linkedin-preview.png new file mode 100644 index 0000000..6e8b236 Binary files /dev/null and b/artifacts/MAX-670/proof/linkedin-preview.png differ diff --git a/artifacts/MAX-670/proof/preview.html b/artifacts/MAX-670/proof/preview.html new file mode 100644 index 0000000..52b85d0 --- /dev/null +++ b/artifacts/MAX-670/proof/preview.html @@ -0,0 +1,7 @@ +MAX-670 LinkedIn preview
MT
Max Techera Preview
Founder · AI workflow systems · MAX-670 LinkedIn placement

Most AI agent setups break the moment one task becomes three.

Not because the model is bad.

Because the workflow has no coordination layer.

A single agent can look magical in a demo. It takes the prompt, edits the file, summarizes the result, and everyone feels the future for 30 seconds.

Then you try to run real work:

handoffs, parallel execution, context recovery, retries, proof, review states, memory, and “did this actually ship?”

That is where the vibe breaks.

The operators who get leverage from agents are not just writing better prompts. They are designing the system around the agent: clear ticket contracts, executor boundaries, verification loops, artifact proof, and guardrails for when confidence is not evidence.

That is the problem the /orchestrator course is built around.

In one week, it shows Claude Code users how to move from fragile single-agent experiments to reliable multi-agent workflows: coordinator-executor patterns, memory discipline, production checks, and proof-backed status updates.

The goal is not “more AI.”

The goal is an agent team you can trust with real work because every handoff has a contract and every claimed result has evidence.

If you already feel the ceiling on single-agent workflows, this is the next step.

→ Comment "orchestrator" and I’ll send the free lesson/waitlist path.

#AIAgents #ClaudeCode #WorkflowAutomation

LikeCommentRepostSend
\ No newline at end of file diff --git a/artifacts/MAX-670/validate.py b/artifacts/MAX-670/validate.py new file mode 100755 index 0000000..12cefa4 --- /dev/null +++ b/artifacts/MAX-670/validate.py @@ -0,0 +1,18 @@ +#!/usr/bin/env python3 +from pathlib import Path +import re, sys +post = Path(__file__).with_name('post.md').read_text(encoding='utf-8') +body = post.split('---', 2)[-1].strip() if post.startswith('---') else post.strip() +hashtags = re.findall(r'(? script -> asset -> publish -> follow-up`. +Voiceover: "With ship-engine, the flow is explicit. Brief in, assets out, next step visible." + +**Beat 4, 16 to 24s** +On screen: bold before/after card, `No pipeline = launch friction` and `Pipeline = repeatable shipping`. +Voiceover: "That is the real before and after. Not more AI hype, more throughput with fewer dropped handoffs." + +**Beat 5, 24 to 30s** +On screen: CTA card. +Voiceover: "If you want more proof-first systems like this, subscribe to NODO. Comment SHIP if you want the walkthrough." + +## Caption draft +Before ship-engine, launch content lived across tabs, drafts, and half-finished follow-ups. + +After ship-engine, the workflow became visible: brief, script, asset, publish, follow-up. + +That is the unlock. Not more noise. Better orchestration. + +Subscribe to NODO for more proof-first AI operator systems. +Comment SHIP if you want the repo walkthrough. + +## X thread +1. Before ship-engine, launch content lived in scattered tabs, drafts, and mental overhead. +2. After ship-engine, the flow became visible: brief -> script -> asset -> publish -> follow-up. +3. That shift matters because most teams do not actually have a content problem. They have a handoff problem. +4. When every step depends on memory, DMs, and context switching, shipping slows down even if the ideas are good. +5. A pipeline fixes that. The win is not more output. The win is repeatable throughput. +6. If you want more proof-first AI operator systems, subscribe to NODO. If you want the walkthrough, reply SHIP. + +## Creative notes +- Visual language: dark UI, red chaos state on the left, green pipeline state on the right. +- Subtitle style: high-contrast, proof-first, terse. +- Keep the CTA frame clean enough to use as Linear visual proof. diff --git a/content/reels/MAX-530-launch-content.md b/content/reels/MAX-530-launch-content.md new file mode 100644 index 0000000..5afc2d2 --- /dev/null +++ b/content/reels/MAX-530-launch-content.md @@ -0,0 +1,63 @@ +# MAX-530, incident-led launch content package + +Primary channel: Instagram Reel +Secondary channel: X thread +Primary visual: postmortem-style rule cards after an AI-assisted prod break +Primary CTA: Subscribe to NODO +Secondary CTA: Reply `RULES` if you want the operator checklist + +## Reel concept, The 5 rules we wrote after breaking prod, 30 seconds + +### Hook options +1. We broke prod, then wrote 5 rules for every AI team. +2. The incident was painful. The rules that came out of it are now non-negotiable. +3. If AI is touching prod, you need rules before you need more prompts. + +### Script +**Beat 1, 0 to 4s** +On screen: alert-style title card, `We broke prod. Here are the 5 rules.` +Voiceover: "We broke prod, and that forced us to write five rules every AI team should have before touching live systems." + +**Beat 2, 4 to 10s** +On screen: rule cards 1 and 2, `No direct prod writes` and `Human approval for risky actions`. +Voiceover: "Rule one, no direct prod writes from autonomous flows. Rule two, risky actions need a human approval step." + +**Beat 3, 10 to 17s** +On screen: rule cards 3 and 4, `Proof before status` and `Tight rollback paths`. +Voiceover: "Rule three, proof before status changes. Rule four, every path needs a clean rollback before you call it ready." + +**Beat 4, 17 to 24s** +On screen: rule card 5, `Short feedback loops, not blind autonomy`, plus a compact incident timeline. +Voiceover: "Rule five, optimize for short feedback loops, not blind autonomy. Faster checks beat bigger messes." + +**Beat 5, 24 to 30s** +On screen: CTA card, `Subscribe to NODO` and `Reply RULES for the checklist`. +Voiceover: "If you want more operator systems built from real incidents, subscribe to NODO. Reply RULES if you want the checklist." + +## Caption draft +We broke prod, then turned the postmortem into five operating rules for AI teams. + +1. No direct prod writes from autonomous flows. +2. Human approval for risky actions. +3. Proof before status changes. +4. Rollback paths before confidence. +5. Short feedback loops over blind autonomy. + +Painful lesson, useful system. + +Subscribe to NODO for more proof-first operator workflows. +Reply RULES if you want the checklist. + +## X thread +1. We broke prod, and the useful outcome was not the incident itself. It was the five operating rules we wrote immediately after. +2. Rule 1: no direct prod writes from autonomous flows. If the action is live and reversible costs are high, the system should stop short. +3. Rule 2: risky actions need a human approval step. Not because humans are perfect, but because irreversible mistakes compound fast. +4. Rule 3: proof before status changes. Do not mark work done, reviewed, or shipped until the artifact and the evidence actually exist. +5. Rule 4: every critical path needs a rollback. Confidence is not a rollback plan. +6. Rule 5: optimize for short feedback loops, not blind autonomy. Faster verification beats bigger cleanup. +7. If you are building with AI in live systems, these rules are worth stealing. Subscribe to NODO for more operator workflows built from real incidents. Reply RULES if you want the checklist. + +## Creative notes +- Visual language: dark incident dashboard, electric cyan accents, alert red only on the opening frame. +- Keep each rule as a clean card so screenshots can double as Linear visual proof. +- Tone: calm postmortem, not hype. The credibility comes from the scar tissue. diff --git a/content/reels/MAX-548/README.md b/content/reels/MAX-548/README.md new file mode 100644 index 0000000..f1772ec --- /dev/null +++ b/content/reels/MAX-548/README.md @@ -0,0 +1,26 @@ +# MAX-548, /orchestrator reel variant pack + +This package ships 5 short-form reel variants for `/orchestrator` in the correct repo (`maxtechera/orchestrator`). + +## Deliverables +- 5 scripts, one per required variant angle +- 3 hooks per variant +- 5 rendered 9:16 MP4 proof assets +- 5 thumbnail PNGs +- 1 proof board PNG for Linear attachment +- `artifacts/MAX-548/package.json` for the Content Engine placement cards + +## Variant map +1. Problem agitate solve +2. Contrarian +3. Specific number +4. Insider reveal +5. Testimonial + +## CTA map +- Primary: IG DM keyword `ORCHESTRATOR` for the free install guide +- Secondary: comment `sweep` for the repo link reply +- Tertiary: link in bio → `github.com/maxtechera/orchestrator` + +## Note +The ticket contract names a ManyChat flow id as `TBD_MAX_PROVIDES`. That value was not available in the workspace, so the assets keep the DM keyword and CTA language but do not embed a concrete production flow id. diff --git a/content/reels/MAX-548/make_thumbnails.sh b/content/reels/MAX-548/make_thumbnails.sh new file mode 100755 index 0000000..abc4bab --- /dev/null +++ b/content/reels/MAX-548/make_thumbnails.sh @@ -0,0 +1,26 @@ +#!/usr/bin/env bash +set -euo pipefail +FONT=$(fc-match -f '%{file}\n' 'DejaVu Sans' | head -1) +ROOT=/data/workspace/tmp-MAX-548-orchestrator/content/reels/MAX-548 +OUT="$ROOT/thumbnails" +mkdir -p "$OUT" +make_thumb() { + local slug="$1" + local title="$2" + cat > "$OUT/$slug.html" < +
MAX-548 /orchestrator

${title}

Your AI said done. It wasn't.
github.com/maxtechera/orchestrator
+HTML + wkhtmltoimage --quality 100 --width 1080 --height 1920 "$OUT/$slug.html" "$OUT/$slug.png" >/dev/null 2>&1 +} +make_thumb "01-problem-agitate-solve" "Your AI agent said done. It wasn't." +make_thumb "02-contrarian" "The problem is not the model." +make_thumb "03-specific-number" "Sweep 10 tickets, catch the 3 that lied." +make_thumb "04-insider-reveal" "The real win is the verification contract." +make_thumb "05-testimonial" "This is what stopped the looks-done problem." diff --git a/content/reels/MAX-548/proof/proof-board.html b/content/reels/MAX-548/proof/proof-board.html new file mode 100644 index 0000000..39b6c26 --- /dev/null +++ b/content/reels/MAX-548/proof/proof-board.html @@ -0,0 +1,15 @@ + + +

MAX-548 proof board, /orchestrator reel series

+

Five required variants, rendered as MP4 plus thumbnail proof in the correct repo surface.

+
+
Problem agitate solve
+
Contrarian
+
Specific number
+
Insider reveal
+
Testimonial
+
+ diff --git a/content/reels/MAX-548/render-text/01-problem-agitate-solve-body.txt b/content/reels/MAX-548/render-text/01-problem-agitate-solve-body.txt new file mode 100644 index 0000000..385549e --- /dev/null +++ b/content/reels/MAX-548/render-text/01-problem-agitate-solve-body.txt @@ -0,0 +1,3 @@ +Ticket closed. Broken link still live. Test still red. +Now the cleanup work lands on you. +Run /orchestrator so the sweep checks proof before done is accepted. diff --git a/content/reels/MAX-548/render-text/01-problem-agitate-solve-cta.txt b/content/reels/MAX-548/render-text/01-problem-agitate-solve-cta.txt new file mode 100644 index 0000000..a96dfda --- /dev/null +++ b/content/reels/MAX-548/render-text/01-problem-agitate-solve-cta.txt @@ -0,0 +1 @@ +DM ORCHESTRATOR for the free install guide diff --git a/content/reels/MAX-548/render-text/01-problem-agitate-solve-headline.txt b/content/reels/MAX-548/render-text/01-problem-agitate-solve-headline.txt new file mode 100644 index 0000000..2b57cf2 --- /dev/null +++ b/content/reels/MAX-548/render-text/01-problem-agitate-solve-headline.txt @@ -0,0 +1 @@ +Your AI agent said done. It wasn't. diff --git a/content/reels/MAX-548/render-text/02-contrarian-body.txt b/content/reels/MAX-548/render-text/02-contrarian-body.txt new file mode 100644 index 0000000..3fe282a --- /dev/null +++ b/content/reels/MAX-548/render-text/02-contrarian-body.txt @@ -0,0 +1,3 @@ +Smarter agents still fail when nobody verifies the finish. +/orchestrator keeps the tickets with evidence and flags the fake dones. +More autonomy without verification only creates faster mistakes. diff --git a/content/reels/MAX-548/render-text/02-contrarian-cta.txt b/content/reels/MAX-548/render-text/02-contrarian-cta.txt new file mode 100644 index 0000000..f15a6d1 --- /dev/null +++ b/content/reels/MAX-548/render-text/02-contrarian-cta.txt @@ -0,0 +1 @@ +Comment sweep for the repo link diff --git a/content/reels/MAX-548/render-text/02-contrarian-headline.txt b/content/reels/MAX-548/render-text/02-contrarian-headline.txt new file mode 100644 index 0000000..3a59072 --- /dev/null +++ b/content/reels/MAX-548/render-text/02-contrarian-headline.txt @@ -0,0 +1 @@ +The problem is not the model. diff --git a/content/reels/MAX-548/render-text/03-specific-number-body.txt b/content/reels/MAX-548/render-text/03-specific-number-body.txt new file mode 100644 index 0000000..a562d5c --- /dev/null +++ b/content/reels/MAX-548/render-text/03-specific-number-body.txt @@ -0,0 +1,3 @@ +Close the 7 with proof. Escalate the 3 missing real evidence. +Less trust theater. Less production risk. Faster clean handoffs. +That is what the /orchestrator sweep gives you. diff --git a/content/reels/MAX-548/render-text/03-specific-number-cta.txt b/content/reels/MAX-548/render-text/03-specific-number-cta.txt new file mode 100644 index 0000000..41a5c0f --- /dev/null +++ b/content/reels/MAX-548/render-text/03-specific-number-cta.txt @@ -0,0 +1 @@ +Link in bio for the open-source repo diff --git a/content/reels/MAX-548/render-text/03-specific-number-headline.txt b/content/reels/MAX-548/render-text/03-specific-number-headline.txt new file mode 100644 index 0000000..08d6478 --- /dev/null +++ b/content/reels/MAX-548/render-text/03-specific-number-headline.txt @@ -0,0 +1 @@ +Sweep 10 tickets, catch the 3 that lied. diff --git a/content/reels/MAX-548/render-text/04-insider-reveal-body.txt b/content/reels/MAX-548/render-text/04-insider-reveal-body.txt new file mode 100644 index 0000000..434f81e --- /dev/null +++ b/content/reels/MAX-548/render-text/04-insider-reveal-body.txt @@ -0,0 +1,3 @@ +Artifact delta. Business delta. Surface correctness. +If one is missing, the ticket does not get the victory lap. +That is how /orchestrator catches fake done states. diff --git a/content/reels/MAX-548/render-text/04-insider-reveal-cta.txt b/content/reels/MAX-548/render-text/04-insider-reveal-cta.txt new file mode 100644 index 0000000..f9d423b --- /dev/null +++ b/content/reels/MAX-548/render-text/04-insider-reveal-cta.txt @@ -0,0 +1 @@ +DM ORCHESTRATOR for the install guide diff --git a/content/reels/MAX-548/render-text/04-insider-reveal-headline.txt b/content/reels/MAX-548/render-text/04-insider-reveal-headline.txt new file mode 100644 index 0000000..7637014 --- /dev/null +++ b/content/reels/MAX-548/render-text/04-insider-reveal-headline.txt @@ -0,0 +1 @@ +The real win is the verification contract. diff --git a/content/reels/MAX-548/render-text/05-testimonial-body.txt b/content/reels/MAX-548/render-text/05-testimonial-body.txt new file mode 100644 index 0000000..b04d24a --- /dev/null +++ b/content/reels/MAX-548/render-text/05-testimonial-body.txt @@ -0,0 +1,3 @@ +We had agents closing tickets that still needed human cleanup. +After adding /orchestrator, the bluff tickets showed up fast. +Human review got smaller because the sweep found the real misses. diff --git a/content/reels/MAX-548/render-text/05-testimonial-cta.txt b/content/reels/MAX-548/render-text/05-testimonial-cta.txt new file mode 100644 index 0000000..aa28129 --- /dev/null +++ b/content/reels/MAX-548/render-text/05-testimonial-cta.txt @@ -0,0 +1 @@ +Comment sweep or grab the repo diff --git a/content/reels/MAX-548/render-text/05-testimonial-headline.txt b/content/reels/MAX-548/render-text/05-testimonial-headline.txt new file mode 100644 index 0000000..c96d5cc --- /dev/null +++ b/content/reels/MAX-548/render-text/05-testimonial-headline.txt @@ -0,0 +1 @@ +This is what stopped the looks-done problem. diff --git a/content/reels/MAX-548/render_variants.sh b/content/reels/MAX-548/render_variants.sh new file mode 100755 index 0000000..2f5750b --- /dev/null +++ b/content/reels/MAX-548/render_variants.sh @@ -0,0 +1,30 @@ +#!/usr/bin/env bash +set -euo pipefail +FONT=$(fc-match -f '%{file}\n' 'DejaVu Sans' | head -1) +ROOT=/data/workspace/tmp-MAX-548-orchestrator/content/reels/MAX-548 +OUT="$ROOT/videos" +TXT="$ROOT/render-text" +mkdir -p "$OUT" "$TXT" + +render() { + local slug="$1" + local headline="$2" + local body="$3" + local cta="$4" + printf '%s\n' "$headline" > "$TXT/$slug-headline.txt" + printf '%s\n' "$body" > "$TXT/$slug-body.txt" + printf '%s\n' "$cta" > "$TXT/$slug-cta.txt" + ffmpeg -y -f lavfi -i color=c=0x0a0f1c:s=1080x1920:d=12 \ + -vf "drawtext=fontfile=$FONT:text='MAX-548 /orchestrator':fontcolor=0x93c5fd:fontsize=30:x=80:y=100,\ + drawtext=fontfile=$FONT:textfile=$TXT/$slug-headline.txt:fontcolor=white:fontsize=74:x=80:y=220:line_spacing=12,\ + drawtext=fontfile=$FONT:textfile=$TXT/$slug-body.txt:fontcolor=0xdbe4f0:fontsize=42:x=80:y=650:line_spacing=18,\ + drawtext=fontfile=$FONT:textfile=$TXT/$slug-cta.txt:fontcolor=0x7dd3fc:fontsize=40:x=80:y=1560:line_spacing=16,\ + drawtext=fontfile=$FONT:text='github.com/maxtechera/orchestrator':fontcolor=white:fontsize=32:x=80:y=1760" \ + -c:v libx264 -pix_fmt yuv420p -threads 2 "$OUT/$slug.mp4" +} + +render "01-problem-agitate-solve" "Your AI agent said done. It wasn't." $'Ticket closed. Broken link still live. Test still red.\nNow the cleanup work lands on you.\nRun /orchestrator so the sweep checks proof before done is accepted.' "DM ORCHESTRATOR for the free install guide" +render "02-contrarian" "The problem is not the model." $'Smarter agents still fail when nobody verifies the finish.\n/orchestrator keeps the tickets with evidence and flags the fake dones.\nMore autonomy without verification only creates faster mistakes.' "Comment sweep for the repo link" +render "03-specific-number" "Sweep 10 tickets, catch the 3 that lied." $'Close the 7 with proof. Escalate the 3 missing real evidence.\nLess trust theater. Less production risk. Faster clean handoffs.\nThat is what the /orchestrator sweep gives you.' "Link in bio for the open-source repo" +render "04-insider-reveal" "The real win is the verification contract." $'Artifact delta. Business delta. Surface correctness.\nIf one is missing, the ticket does not get the victory lap.\nThat is how /orchestrator catches fake done states.' "DM ORCHESTRATOR for the install guide" +render "05-testimonial" "This is what stopped the looks-done problem." $'We had agents closing tickets that still needed human cleanup.\nAfter adding /orchestrator, the bluff tickets showed up fast.\nHuman review got smaller because the sweep found the real misses.' "Comment sweep or grab the repo" diff --git a/content/reels/MAX-548/scripts.md b/content/reels/MAX-548/scripts.md new file mode 100644 index 0000000..42b727c --- /dev/null +++ b/content/reels/MAX-548/scripts.md @@ -0,0 +1,82 @@ +# MAX-548 scripts, /orchestrator reel series + +## Shared audience +AI / LLM developers, Claude Code users, and indie hackers running agent teams on real work. + +## Shared message +Your AI agent said done. It wasn't. `/orchestrator` runs a sweep, checks proof, and catches fake completions before they hit production. + +--- + +## Variant 1, Problem agitate solve + +### Hooks +1. Your AI agent said done. It wasn't. +2. The ticket closed, but the bug was still live. +3. Done is not done when the proof fails. + +### Script +Hook: Your AI agent said done. It wasn't. +Agitate: The ticket is closed, the broken link is still there, the test is still red, and now you have cleanup work. +Solve: Run `/orchestrator` so the sweep checks proof before the ticket gets marked complete. +CTA: DM `ORCHESTRATOR` for the free install guide. + +--- + +## Variant 2, Contrarian + +### Hooks +1. The problem is not the model. It's fake done states. +2. Smarter agents still fail if nobody verifies the finish. +3. More autonomy without verification just creates faster mistakes. + +### Script +Hook: People think the answer is a better model. +Contrarian take: The real problem is agents marking work done without proving it. +Proof: `/orchestrator` runs a sweep, keeps the tickets with evidence, and flags the ones that only look complete. +CTA: Comment `sweep` and I'll reply with the repo. + +--- + +## Variant 3, Specific number + +### Hooks +1. Sweep 10 tickets, catch the 3 that lied. +2. One verification sweep can save hours of cleanup. +3. 10 tickets reviewed, 3 fake dones caught, 0 guesswork. + +### Script +Hook: Sweep 10 tickets, catch the 3 that lied. +Proof: `/orchestrator` can review the batch, close the 7 with proof, and escalate the 3 missing real evidence. +Outcome: Less trust theater, less production risk, faster clean handoffs. +CTA: Link in bio for the open-source repo. + +--- + +## Variant 4, Insider reveal + +### Hooks +1. The real win is the verification contract, not the agent demo. +2. The secret is forcing artifact plus business delta plus surface correctness. +3. Most agent demos stop at output. `/orchestrator` checks the finish line. + +### Script +Hook: The real win is the verification contract. +Reveal: `/orchestrator` does not accept a vague done update. It asks for artifact delta, business delta, and surface correctness. +Proof: If one of those is missing, the ticket does not get the victory lap. +CTA: DM `ORCHESTRATOR` if you want the install guide. + +--- + +## Variant 5, Testimonial style + +### Hooks +1. The moment we started sweeping, the fake dones showed up fast. +2. `/orchestrator` made our agent work reviewable instead of hopeful. +3. This is what finally stopped the “looks done” problem. + +### Script +Hook: We had agents closing tickets that still needed human cleanup. +Story: After adding `/orchestrator`, we could see which tickets had proof and which ones were bluffing. +Result: Reviews got faster because we only spent human attention where the sweep found real problems. +CTA: Comment `sweep` or grab the repo from the link in bio. diff --git a/content/reels/MAX-548/thumbnails/01-problem-agitate-solve.html b/content/reels/MAX-548/thumbnails/01-problem-agitate-solve.html new file mode 100644 index 0000000..79ccc4f --- /dev/null +++ b/content/reels/MAX-548/thumbnails/01-problem-agitate-solve.html @@ -0,0 +1,8 @@ + +
MAX-548 /orchestrator

Your AI agent said done. It wasn't.

Your AI said done. It wasn't.
github.com/maxtechera/orchestrator
diff --git a/content/reels/MAX-548/thumbnails/01-problem-agitate-solve.png b/content/reels/MAX-548/thumbnails/01-problem-agitate-solve.png new file mode 100644 index 0000000..353ec33 Binary files /dev/null and b/content/reels/MAX-548/thumbnails/01-problem-agitate-solve.png differ diff --git a/content/reels/MAX-548/thumbnails/02-contrarian.png b/content/reels/MAX-548/thumbnails/02-contrarian.png new file mode 100644 index 0000000..a70f90a Binary files /dev/null and b/content/reels/MAX-548/thumbnails/02-contrarian.png differ diff --git a/content/reels/MAX-548/thumbnails/03-specific-number.png b/content/reels/MAX-548/thumbnails/03-specific-number.png new file mode 100644 index 0000000..db95564 Binary files /dev/null and b/content/reels/MAX-548/thumbnails/03-specific-number.png differ diff --git a/content/reels/MAX-548/thumbnails/04-insider-reveal.png b/content/reels/MAX-548/thumbnails/04-insider-reveal.png new file mode 100644 index 0000000..0446da6 Binary files /dev/null and b/content/reels/MAX-548/thumbnails/04-insider-reveal.png differ diff --git a/content/reels/MAX-548/thumbnails/05-testimonial.png b/content/reels/MAX-548/thumbnails/05-testimonial.png new file mode 100644 index 0000000..e918904 Binary files /dev/null and b/content/reels/MAX-548/thumbnails/05-testimonial.png differ diff --git a/content/reels/MAX-548/videos/01-problem-agitate-solve.mp4 b/content/reels/MAX-548/videos/01-problem-agitate-solve.mp4 new file mode 100644 index 0000000..ea0fff3 Binary files /dev/null and b/content/reels/MAX-548/videos/01-problem-agitate-solve.mp4 differ diff --git a/content/reels/MAX-548/videos/02-contrarian.mp4 b/content/reels/MAX-548/videos/02-contrarian.mp4 new file mode 100644 index 0000000..49b1b08 Binary files /dev/null and b/content/reels/MAX-548/videos/02-contrarian.mp4 differ diff --git a/content/reels/MAX-548/videos/03-specific-number.mp4 b/content/reels/MAX-548/videos/03-specific-number.mp4 new file mode 100644 index 0000000..8ada4ec Binary files /dev/null and b/content/reels/MAX-548/videos/03-specific-number.mp4 differ diff --git a/content/reels/MAX-548/videos/04-insider-reveal.mp4 b/content/reels/MAX-548/videos/04-insider-reveal.mp4 new file mode 100644 index 0000000..e14608e Binary files /dev/null and b/content/reels/MAX-548/videos/04-insider-reveal.mp4 differ diff --git a/content/reels/MAX-548/videos/05-testimonial.mp4 b/content/reels/MAX-548/videos/05-testimonial.mp4 new file mode 100644 index 0000000..294ee0c Binary files /dev/null and b/content/reels/MAX-548/videos/05-testimonial.mp4 differ diff --git a/content/reels/MAX-569-asset-manifest.md b/content/reels/MAX-569-asset-manifest.md new file mode 100644 index 0000000..b858290 --- /dev/null +++ b/content/reels/MAX-569-asset-manifest.md @@ -0,0 +1,22 @@ +# MAX-569 asset manifest + +Generated assets live in `/data/workspace/artifacts/MAX-569/` during execution. + +## Files +- `max569-01-v1-problem-agitate-solve.mp4` +- `max569-02-v2-contrarian.mp4` +- `max569-03-v3-specific-number.mp4` +- `max569-04-v4-insider-reveal.mp4` +- `max569-05-v5-testimonial.mp4` +- matching `*-thumb.png` +- matching `*-proof.png` + +## CTA map +- Primary: DM `ORCHESTRATOR` +- Secondary: comment `sweep` +- Tertiary: link in bio to `github.com/maxtechera/orchestrator` + +## Notes +- Assets were produced for the exact target repo `maxtechera/orchestrator`. +- Visual proof PNGs mirror the rendered thumbnail for Linear attachment. +- Videos are lightweight placeholder renders derived from the approved reel copy so the review packet has actual MP4 exports, not just scripts. diff --git a/content/reels/MAX-569-oss-demo-first-package.md b/content/reels/MAX-569-oss-demo-first-package.md new file mode 100644 index 0000000..bb72eb5 --- /dev/null +++ b/content/reels/MAX-569-oss-demo-first-package.md @@ -0,0 +1,102 @@ +# MAX-569, /orchestrator OSS demo-first reel package + +Angle: "Your AI said done. It wasn't. /orchestrator catches that." + +Audience: AI and LLM developers, Claude Code users, indie hackers shipping agent-driven products. + +Primary CTA: DM `ORCHESTRATOR` for the free install guide. +Secondary CTA: comment `sweep` for the repo link. +Tertiary CTA: link in bio to `github.com/maxtechera/orchestrator`. + +## Variant 1, Problem / Agitate / Solve +Hooks: +1. Your AI said "done". Your repo said otherwise. +2. The scariest agent bug is fake completion. +3. If your agent can't prove it, it didn't ship. + +Script: +- Scene 1: Terminal shows a single agent claiming success after touching the wrong repo. +- Scene 2: On-screen line, "Merged? No. Proof? No. Wrong surface." +- Scene 3: Introduce `/orchestrator` as the sweep that reads the ticket, enforces target repo, and requires proof. +- Scene 4: End card, "DM ORCHESTRATOR for the free install guide." + +## Variant 2, Contrarian +Hooks: +1. More autonomous agents are not the fix. +2. The problem is not intelligence. It's orchestration. +3. Stop adding agents. Add guardrails. + +Script: +- Scene 1: "Everyone wants more agent autonomy." +- Scene 2: "But one fast wrong agent just creates faster wrong work." +- Scene 3: "`/orchestrator` fans work out, checks proof, and keeps the wrong repo from counting as done." +- Scene 4: CTA card. + +## Variant 3, Specific number +Hooks: +1. 3 checks before I trust any agent output. +2. My agents need 3 receipts before I move a ticket. +3. We killed fake done with 3 gates. + +Script: +- Scene 1: Show the three gates, artifact delta, business delta, surface correctness. +- Scene 2: Show a failed run missing one gate. +- Scene 3: Show `/orchestrator` blocking state change. +- Scene 4: CTA card. + +## Variant 4, Insider reveal +Hooks: +1. The trick is not the prompt. +2. Here's the part most agent demos hide. +3. Real agent systems need a skeptical supervisor. + +Script: +- Scene 1: "Clean demo: agent says done." +- Scene 2: "Reality: wrong repo, no attachment, no proof pack." +- Scene 3: "`/orchestrator` keeps a human-reviewable paper trail." +- Scene 4: CTA card. + +## Variant 5, Testimonial style +Hooks: +1. I stopped trusting green checkmarks. +2. This is the workflow that finally made agents usable. +3. My favorite agent feature is saying 'not done yet'. + +Script: +- Scene 1: First-person pain point, "I kept getting polished lies from single agents." +- Scene 2: "Then I forced every run through `/orchestrator`." +- Scene 3: "Now parallel workers only count when repo, proof, and outcome all match." +- Scene 4: CTA card. + +## Hook bank by variant + +### Variant 1 +- Your AI said "done". Your repo said otherwise. +- The scariest agent bug is fake completion. +- If your agent can't prove it, it didn't ship. + +### Variant 2 +- More autonomous agents are not the fix. +- The problem is not intelligence. It's orchestration. +- Stop adding agents. Add guardrails. + +### Variant 3 +- 3 checks before I trust any agent output. +- My agents need 3 receipts before I move a ticket. +- We killed fake done with 3 gates. + +### Variant 4 +- The trick is not the prompt. +- Here's the part most agent demos hide. +- Real agent systems need a skeptical supervisor. + +### Variant 5 +- I stopped trusting green checkmarks. +- This is the workflow that finally made agents usable. +- My favorite agent feature is saying "not done yet". + +## Production notes +- Format: 1080x1920 vertical. +- Tone: proof-first, terse, demo-led. +- Visual language: dark terminal, red failure card, green proof card, clean CTA end frame. +- Subtitle style: bold white with high-contrast shadow. diff --git a/content/reels/MAX-570-ship-oss-demo-first-package.md b/content/reels/MAX-570-ship-oss-demo-first-package.md new file mode 100644 index 0000000..3cbcf11 --- /dev/null +++ b/content/reels/MAX-570-ship-oss-demo-first-package.md @@ -0,0 +1,167 @@ +# MAX-570, /ship OSS demo-first content bundle + +Audience: solo founders, indie hackers, AI builders, and Claude Code users who can ship product but still bottleneck on launch. + +Offer: /ship course, $497. +Primary CTA: DM `SHIP` for the install guide. +Secondary CTA: Reply `COURSE` for the $497 course link. +Tertiary CTA: Link in bio to `github.com/maxtechera/ship`. + +## Reel 1, Problem, 15 to 30 seconds + +### Hook options +1. Your product is not blocked by code. It is blocked by launch chaos. +2. Most solo founders do not need more prompts. They need one launch system. +3. If intake, strategy, content, and launch live in different tabs, you do not have GTM. You have friction. + +### Script +**Beat 1, 0 to 4s** +On screen: inbox, docs, Notion, Canva, calendar, and DMs all open. +Voiceover: "Most launch days fail before the launch starts. Intake is in one place, strategy in another, content somewhere else, and publishing still depends on you." + +**Beat 2, 4 to 9s** +On screen: sticky-note style labels, `intake`, `strategy`, `content`, `launch`, drifting apart. +Voiceover: "That is manual GTM chaos. Every handoff leaks context, speed, and momentum." + +**Beat 3, 9 to 16s** +On screen: a founder jumping tab to tab, then a red banner, `Disconnected workflow`. +Voiceover: "So even when the product is ready, the go-to-market machine is still improvising." + +**Beat 4, 16 to 23s** +On screen: freeze frame, bold text, `Build is done. Launch is not.` +Voiceover: "If your launch still depends on chasing tasks across tools, you are not slow at building. You are under-orchestrated." + +**Beat 5, 23 to 28s** +On screen: dark CTA card. +Voiceover: "Next, I will show the fix. DM SHIP if you want the repo behind it." + +## Reel 2, Fix, 30 to 45 seconds + +### Hook options +1. Here is what launch looks like when the whole pipeline runs as one system. +2. This is the moment GTM stopped feeling manual. +3. I stopped coordinating launch day by hand, and this is what replaced it. + +### Script +**Beat 1, 0 to 5s** +On screen: terminal command `/ship create`. +Voiceover: "The fix was not another dashboard. It was one command that kicked off the full launch pipeline." + +**Beat 2, 5 to 12s** +On screen: `intake -> validate -> strategy -> awareness -> launch -> measure`. +Voiceover: "`/ship` starts with intake, checks what is real, builds strategy, generates content, launches, then measures what happened." + +**Beat 3, 12 to 22s** +On screen: named agents passing work, `validator`, `strategist`, `copywriter`, `launcher`, `analyst`. +Voiceover: "Each stage has a named agent, so the handoff is explicit instead of living in your head." + +**Beat 4, 22 to 33s** +On screen: green cards stacking, `brief ready`, `assets ready`, `launch ready`, `report ready`. +Voiceover: "That means the money shot is simple, one intake turns into a launch-ready machine instead of a pile of disconnected tasks." + +**Beat 5, 33 to 41s** +On screen: founder smiling, output stack visible. +Voiceover: "For solo founders, this feels less like software and more like a coordinated launch team showing up on demand." + +**Beat 6, 41 to 45s** +On screen: CTA, `Reply COURSE for the $497 /ship training`. +Voiceover: "Reply COURSE if you want the full $497 /ship course." + +## Reel 3, Architecture, 45 to 60 seconds + +### Hook options +1. Want the architecture, not just the claim. Here it is. +2. This is the pipeline diagram behind the launch. +3. The real moat is not the prompt. It is the operating system around the prompt. + +### Script +**Beat 1, 0 to 6s** +On screen: full pipeline diagram appears. +Voiceover: "If you want the architecture, here is the actual flow." + +**Beat 2, 6 to 16s** +On screen: `intake -> validate -> strategy` highlighted. +Voiceover: "Everything starts with intake, then validation, then strategy, so the launch machine knows what it is selling, to whom, and why now." + +**Beat 3, 16 to 27s** +On screen: `awareness`, `lead capture`, `nurture`, `closing` branch in parallel. +Voiceover: "From there, awareness, lead capture, nurture, and closing can run in parallel instead of waiting for one person to push every domino manually." + +**Beat 4, 27 to 38s** +On screen: `launch -> measure` with stage gates. +Voiceover: "Stage gates keep each step honest. No fake done, no skipped handoffs, no launch without the pieces that matter." + +**Beat 5, 38 to 51s** +On screen: diagram zooms out, course promise card. +Voiceover: "That is what the /ship course teaches, not just tools, but the operating model for turning product momentum into repeatable launch execution." + +**Beat 6, 51 to 58s** +On screen: CTA card. +Voiceover: "The full breakdown is in the $497 /ship course. Reply COURSE and I will send it." + +## Hook library + +### Problem hooks +- Your product is not blocked by code. It is blocked by launch chaos. +- If intake, strategy, content, and launch live in different tabs, you do not have GTM. You have friction. +- Build mode is easy. Launch coordination is where solo founders stall. +- Most launch delays are just hidden handoff delays. + +### Fix hooks +- This is the moment GTM stopped feeling manual. +- One intake, one launch pipeline, multiple named agents. +- I replaced launch-day babysitting with a coordinated run. +- This is what happens when GTM becomes a system, not a checklist. + +### Architecture hooks +- The real moat is not the prompt. It is the operating system around it. +- Here is the pipeline diagram behind the launch. +- More tools will not save launch day. Architecture will. +- If you want repeatable GTM, design the handoffs first. + +## Long-format script + +**Title:** How /ship turns launch chaos into a coordinated GTM machine + +If you are building solo, the product is usually not the slow part. The slow part is everything that happens after the product is ready. Intake lives in one place. Positioning notes live somewhere else. Content drafts sit in another tool. Launch steps hide in DMs, calendars, and half-finished checklists. So the bottleneck is not intelligence. It is coordination. + +That is why `/ship` matters. It does not just generate output. It runs a launch pipeline. You start with intake, validate the opportunity, turn that into strategy, hand it to awareness and content, move into launch, then close the loop with measurement. Instead of one person manually carrying context across every stage, named agents handle explicit handoffs. + +The result is not just speed. It is clarity. You can see what stage the launch is in, what is blocked, what is ready, and what happens next. That is what makes solo founders dangerous. Not more hustle, better orchestration. + +And that is the pitch behind the $497 /ship course. It is for builders who already know how to make product, but want a repeatable way to move from product-ready to launch-ready without reinventing the GTM machine every week. + +## Newsletter draft + +**Subject options** +1. Your launch is probably blocked by coordination, not code +2. The /ship pipeline behind a cleaner launch day +3. From intake to launch without manual GTM chaos + +**Preview text** +A demo-first breakdown of how /ship turns disconnected launch tasks into one coordinated system. + +**Body** +Most builders think they need better prompts. + +Usually, they need better handoffs. + +The product might be ready, but launch still breaks because intake, strategy, content, and publishing are all disconnected. That means context leaks, tasks stall, and launch day becomes manual again. + +`/ship` was designed to fix that. It starts with intake, validates the work, builds strategy, creates the launch assets, pushes execution forward, and measures what happened after launch. Instead of one person coordinating every stage, named agents move the work through a real pipeline. + +That is the demo I am showing in the new reel set, and it is also the core of the $497 /ship course. + +If you want the free install guide, reply with **SHIP**. +If you want the course link, reply with **COURSE**. + +## README CTA copy + +### Short CTA +Turn launch-day chaos into one coordinated GTM run. Start with `/ship`, then grab the $497 course when you want the full operating model. + +### Medium CTA +`/ship` is the open-source entry point for solo founders who want launch orchestration instead of manual GTM chaos. Use the repo to see the system in action, then grab the $497 course for the full pipeline, stage gates, and launch playbook. + +### Footer CTA +Open source gets you the command. The $497 /ship course gets you the operating system behind it. diff --git a/docs/course-outline.md b/docs/course-outline.md new file mode 100644 index 0000000..0999b0f --- /dev/null +++ b/docs/course-outline.md @@ -0,0 +1,207 @@ +# /orchestrator course outline + +**Course:** /orchestrator — Run reliable multi-agent workflows in 1 week +**Price:** $197 +**Format:** Mixed (video lessons, text workbooks, cloneable `/orchestrator` skill templates) +**Audience:** Claude Code users who already write single-agent workflows and want to scale to parallel, reliable, multi-agent teams +**Outcome promise:** Run reliable, parallel multi-agent workflows in 1 week, without losing context, duplicating work, or watching agents drift. + +## Course entry friction +Students already get useful output from a single coding agent, but the moment they try to split work across multiple agents, the system breaks. Context gets lost, two agents do the same task, handoffs are vague, and nobody knows what “done” means. The course is designed to solve that exact jump: single-agent competence to reliable multi-agent orchestration. + +## Who this is for +- Indie developers building with Claude Code or similar coding agents +- AI-forward engineers who want parallel execution without chaos +- Small agencies turning ad hoc prompting into a repeatable delivery system +- Operators who need verification, handoffs, and predictable outputs across agent teams + +## Transformation +By the end of the course, students will be able to: +1. Diagnose when a single-agent workflow is enough and when orchestration is required +2. Write ticket contracts that constrain agents and reduce drift +3. Spawn parallel and sequential agent teams with clear merge boundaries +4. Preserve context across sessions with durable memory and handoff discipline +5. Add reliability layers like critics, retries, and human approval gates +6. Run `/orchestrator` as a repeatable production workflow instead of a one-off demo + +## Course structure +- **Modules:** 6 +- **Target lesson count:** ~30 lessons +- **Per-module pattern:** 1 hook, 3 to 5 teach lessons, 1 to 2 apply lessons +- **Delivery assets:** lesson videos, workbooks, checklists, reusable templates + +--- + +## Module 1 — Why single-agent breaks (and what multi-agent fixes) +**Learning outcome:** Students understand the limits of single-agent workflows, recognize the failure modes that appear at scale, and know when orchestration becomes necessary. + +### Hook +- **Lesson 1.1:** The context-limit wall and why single-agent workflows break + +### Teach +- **Lesson 1.2:** Four operating patterns, single, sequential, parallel, hierarchical +- **Lesson 1.3:** The three signals that tell you it is time to scale beyond one agent +- **Lesson 1.4:** Failure modes, context loss, duplicate work, drift, and invisible blockers + +### Apply +- **Lesson 1.5:** Audit your current workflow and mark parallelization opportunities + +### Demo / exercise +Students map one real workflow they already run, identify where the agent loses context, and select one candidate task to split into multiple executors. + +--- + +## Module 2 — Ticket Contracts, the orchestrator primitive +**Learning outcome:** Students can write ticket contracts that define deliverables, proof, and acceptance criteria tightly enough for delegated execution. + +### Hook +- **Lesson 2.1:** Why agents without contracts drift + +### Teach +- **Lesson 2.2:** Ticket contract anatomy, inputs, outputs, proof, and failure states +- **Lesson 2.3:** Deliverables versus proof, what the agent makes versus how it proves completion +- **Lesson 2.4:** Acceptance criteria that survive handoffs and verification +- **Lesson 2.5:** Writing handoff-ready tickets for build, verify, and publish paths + +### Apply +- **Lesson 2.6:** Write a contract for a repo task +- **Lesson 2.7:** Write a contract for a content or launch task + +### Demo / exercise +Students produce two real ticket contracts from their own backlog and score them against a drift-prevention checklist. + +--- + +## Module 3 — Spawning agent teams (parallel versus sequential) +**Learning outcome:** Students can choose the right execution pattern, spawn multi-agent work safely, and merge outputs without collisions. + +### Hook +- **Lesson 3.1:** The coordinator and executor pattern + +### Teach +- **Lesson 3.2:** Coordinator ↔ executor in 20 minutes +- **Lesson 3.3:** When to run parallel, when to run sequential +- **Lesson 3.4:** Merge strategies, scoped ownership, stitched outputs, and arbitration +- **Lesson 3.5:** Fleet patterns, worktree isolation, and branch hygiene + +### Apply +- **Lesson 3.6:** Run a 3-executor parallel task and merge the outputs + +### Demo / exercise +Students launch a coordinator with three executors, each with a narrow scope, then merge the outputs into one final artifact with no overlapping ownership. + +--- + +## Module 4 — Memory, context, and handoff +**Learning outcome:** Students can preserve state across long-running work and keep multi-session tasks coherent. + +### Hook +- **Lesson 4.1:** The silent context loss problem + +### Teach +- **Lesson 4.2:** The 3-tier memory model for agent teams +- **Lesson 4.3:** Session state, handoff docs, and durable operating context +- **Lesson 4.4:** SESSION-STATE, pre-compact discipline, and recovery after interruption +- **Lesson 4.5:** Designing memory flows for multi-session work + +### Apply +- **Lesson 4.6:** Build a persistent memory flow across a 2-session task + +### Demo / exercise +Students run one task across two sessions using memory notes, session state, and a formal handoff document. + +--- + +## Module 5 — Reliability patterns (retries, guardrails, critics) +**Learning outcome:** Students can make agents check themselves, retry safely, and stop at the right human gate. + +### Hook +- **Lesson 5.1:** Agents that check their own work, but do not grade it alone + +### Teach +- **Lesson 5.2:** Critic evaluators and rubric-driven review +- **Lesson 5.3:** Retry policies, bounded loops, and fail-fast triggers +- **Lesson 5.4:** Human-in-the-loop gates for risky or taste-sensitive tasks + +### Apply +- **Lesson 5.5:** Add a critic and retry loop to your orchestrator + +### Demo / exercise +Students wire a critic pass into a real orchestration flow and tune retry logic so the system improves instead of looping forever. + +--- + +## Module 6 — Production orchestration (monitoring, cost, scale) +**Learning outcome:** Students can operate `/orchestrator` as a daily driver with visibility, cost awareness, and recurring execution. + +### Hook +- **Lesson 6.1:** From demo to daily driver + +### Teach +- **Lesson 6.2:** Monitoring runs, statuses, and bottlenecks +- **Lesson 6.3:** Cost attribution and choosing the right model for each job +- **Lesson 6.4:** Model routing with `/model-router` +- **Lesson 6.5:** Cron dispatch, pause and resume, and recurring workflows + +### Apply +- **Lesson 6.6:** Deploy your orchestrator as a recurring workflow + +### Demo / exercise +Students turn one manual weekly workflow into an orchestrated recurring system with clear monitoring and escalation points. + +--- + +## Lesson inventory summary +- **Module 1:** 5 lessons +- **Module 2:** 7 lessons +- **Module 3:** 6 lessons +- **Module 4:** 6 lessons +- **Module 5:** 5 lessons +- **Module 6:** 6 lessons +- **Total:** 35 lesson units in outline format, which is in range for a recorded delivery trimmed to about 30 final lessons by combining adjacent teach segments during production + +## Teaching assets to produce +- 6 module workbooks +- 1 operator checklist per module +- Cloneable ticket contract templates +- Sample orchestrator configs for sequential and parallel runs +- Critic rubric templates +- Session handoff template + +## Free and gated preview lessons +### Free public lesson +- **Module 1, Lesson 1:** The context-limit wall and why single-agent workflows break +- **Format:** full video + workbook +- **Placement:** `/academia/orchestrator/preview` +- **Goal:** create demand by showing the core pain clearly and proving there is a structured path out + +### Gated preview lesson +- **Module 3, Lesson 2:** Coordinator ↔ executor in 20 minutes +- **Format:** preview lesson after email signup +- **Goal:** let the student feel the speed and leverage of orchestration before purchase + +## CTA copy +### README CTA +> Aprendé a orquestar equipos de agentes → curso /orchestrator ($197) + +### Newsletter CTA +> El curso /orchestrator abre el [date]. Reservá tu lugar. + +### Landing page primary CTA +> Inscribirme al curso /orchestrator + +### Landing page secondary CTA +> Ver la lección gratuita + +## Positioning notes +- **Free OSS product:** `/orchestrator` +- **Paid next step:** implementation system, templates, and workflow design in a guided course +- **Core promise:** not “learn agents” but “run reliable agent teams in production” +- **Main competitor substitute:** DIY prompting plus trial-and-error coordination +- **Reason to buy now:** compress weeks of failed orchestration experiments into a one-week implementation path + +## Production notes for the launch team +- Keep examples grounded in real delivery work, repo changes, content ops, and recurring workflows +- Lead with failure modes students already feel, not abstract agent theory +- Use live `/orchestrator` walkthroughs as the trust anchor for each module +- Show verification and proof constantly so the course feels operational, not motivational diff --git a/docs/memory-course-outline.md b/docs/memory-course-outline.md new file mode 100644 index 0000000..c9bb4a2 --- /dev/null +++ b/docs/memory-course-outline.md @@ -0,0 +1,128 @@ +# /memory course outline, OSS tool course + +## Course position in the ladder +- **Free offer:** `/memory` OSS tool +- **Paid offer:** `/memory course` at **$97** +- **Funnel:** GitHub star → install → friction point → README CTA → newsletter → course +- **Audience:** Claude Code users who installed `/memory`, can run setup, but still do not trust their memory system enough to rely on it in real work. + +## The friction point this course solves +The install gets the hooks running, but the user still hits the same anxiety loop: + +> "I installed it, the hooks fire, but I do not actually know what a *good* persistent-memory system looks like, what to save, how to structure the vault, when to sync, or how to keep it from turning into note sludge." + +That is the course entry. The free tool solves **mechanics**. The course solves **operating model**. + +### Install pain → paid transformation map +| Install friction after the OSS tool | What the course teaches instead | +|---|---| +| Hooks run, but the user cannot tell if memory quality is good or noisy | A practical rubric for what belongs in HOT, WARM, and COLD | +| User has an Obsidian vault, but no structure for durable recall | A repeatable 3-tier architecture with folder boundaries and sync rules | +| Sessions save data, but retrieval still feels random | Query patterns, wiki usage, and topic-file design for reliable recall | +| The user fears memory bloat and stale notes | TTL, dream cycle, pruning, and contradiction cleanup | +| The user can sync one session, but not a team or long-running project | A complete cross-session and cross-agent memory workflow | + +## Course promise +Build a persistent-memory system for Claude Code that survives session boundaries, compaction, subagents, and long projects, without drowning in stale notes or giant context dumps. + +## Core transformation +By the end of the course, the student goes from: +- "I installed `/memory`, but I am not sure what it is really doing" +- to +- "I have a working memory architecture, I know what each tier stores, I know when to sync, and I can recover project context across sessions on demand." + +## Module breakdown + +### Module 1. Why agents forget, and why naive note dumps fail +**Learning outcome:** Understand the real failure modes behind session amnesia, compaction loss, and context-window overload. + +**Demo / exercise:** +- Run the same Claude Code task twice, once with no memory system and once with a minimal HOT layer. +- Identify where state gets lost: decisions, preferences, current task, and project boundaries. +- Write a simple "before memory / after memory" diagnostic for one real workflow. + +### Module 2. The 3-tier architecture, HOT, WARM, COLD +**Learning outcome:** Design a memory stack where active context stays tiny, topic knowledge loads on demand, and permanent knowledge stays searchable instead of bloating every session. + +**Demo / exercise:** +- Build a full `/memory` folder layout from scratch. +- Configure `MEMORY.md`, `SESSION-STATE.md`, `memory/topics/*.md`, and daily journals. +- Classify 20 sample facts into HOT, WARM, or COLD and explain why. + +### Module 3. Hooks, setup, and the sync pipeline in real life +**Learning outcome:** Move beyond "the hooks fired" into a reliable sync loop that survives start, stop, compaction, and multi-session work. + +**Demo / exercise:** +- Run `/memory setup`, inspect installed hooks, and trace what happens on session start, compaction, and session stop. +- Map the full detect → classify → write flow using one real project. +- Validate one sync report and fix one intentional misconfiguration. + +### Module 4. Build a retrieval system that Claude can actually use +**Learning outcome:** Structure topics, journals, and wiki pages so future sessions can pull the *right* memory instead of dumping everything back into context. + +**Demo / exercise:** +- Create three topic files, one daily journal, and one wiki page from a week of work. +- Practice queries for recent decisions, durable preferences, and project-specific rules. +- Refactor a noisy topic file into a usable retrieval surface. + +### Module 5. Cross-session, cross-agent, cross-platform memory +**Learning outcome:** Use `/memory` as infrastructure for longer runs, helpers, and platform switching, not just a personal note bucket. + +**Demo / exercise:** +- Simulate a parent session that spawns a helper and hand off enough state for clean continuation. +- Pass work from Claude Code to OpenClaw or another environment while preserving continuity. +- Build a memory checklist for one multi-day project. + +### Module 6. Prevent memory rot, drift, and note sludge +**Learning outcome:** Keep the system trustworthy over time with TTL, audits, dream cycles, and contradiction cleanup. + +**Demo / exercise:** +- Run a memory audit on a deliberately messy example. +- Expire stale topic entries, merge duplicates, and promote one durable insight into the wiki. +- Create a weekly maintenance cadence using `/memory dream` and `/memory audit`. + +### Module 7. The full working system, from install to trusted recall +**Learning outcome:** Assemble the entire system into a repeatable setup the student can use daily for coding, research, and long-lived projects. + +**Demo / exercise:** +- Set up a greenfield project with `/memory`. +- Run a two-session workflow separated by compaction or restart. +- Recover context cleanly in the second session without re-briefing Claude manually. + +## Suggested delivery shape +- **Format:** 6 to 7 modules, short hands-on lessons +- **Teaching style:** show the memory system live, not as theory +- **Assets:** diagrams for tier boundaries, hook lifecycle, sync pipeline, and wiki flow +- **Outcome:** student leaves with a working persistent-memory setup, not just conceptual understanding + +## README CTA copy +### Option A +Installed `/memory`, but still not sure what should live in memory and what should stay out? + +The course shows the full system in action, HOT/WARM/COLD tiers, hooks, sync pipeline, wiki, and the maintenance loop that keeps memory useful instead of noisy. + +**Join the `/memory` course →** Learn the operating model behind persistent Claude Code memory. + +### Option B +`/memory` gives you the engine. The course gives you the operating model. + +If setup worked but you still do not trust the system yet, the `/memory` course walks you through the exact architecture, retrieval patterns, and sync workflow behind a memory setup you can use every day. + +**Get the course →** Build a persistent-memory system that actually survives real work. + +## Newsletter CTA copy +### Option A +You installed `/memory`. Great. But the real unlock is not the install, it is knowing how to structure the system so Claude can recover the *right* context at the right time. + +In the new `/memory` course, I break down the full setup, hooks, 3-tier architecture, sync pipeline, wiki flow, and the maintenance loop that keeps memory from turning into note sludge. + +**Enroll here →** Build your persistent-memory system for Claude Code. + +### Option B +Most people stop after `/memory setup`. + +That gets the hooks running. It does **not** teach you what to store, how to organize the tiers, how to query old work, or how to keep the system clean when projects get long. + +That is exactly what the `/memory` course covers. + +**See the course →** From install to trusted recall. diff --git a/docs/memory-marketplace-package.md b/docs/memory-marketplace-package.md new file mode 100644 index 0000000..0ff4409 --- /dev/null +++ b/docs/memory-marketplace-package.md @@ -0,0 +1,79 @@ +# Memory marketplace optimization package + +This doc packages the final repo-optimization assets for the `maxtechera/memory` Claude Code marketplace submission. + +## GitHub repo description + +**Final description, 81 chars** + +`Durable memory for AI agents with Obsidian sync, session hooks, and recall flows.` + +## GitHub topics + +Use these six topics in this exact order: + +1. `memory` +2. `ai-agents` +3. `claude-code` +4. `obsidian` +5. `session-hooks` +6. `knowledge-management` + +## Social preview card + +Use: `artifacts/MAX-534/social-preview-card.png` + +Card angle: show the free `/memory` install as the entry point, then position Obsidian sync and durable recall as the upgrade path that makes the repo marketplace-ready. + +## Claude marketplace manifest verification + +Manifest checked against the current Claude plugin format on 2026-04-19 by fetching the live `maxtechera/memory` repo manifests: + +- Plugin slug: `memory` +- Category: `productivity` +- Source path: `./` +- Homepage/repository: `https://github.com/maxtechera/memory` +- Install verb: `/plugin marketplace add maxtechera/memory` + +Before submit, verify these files in the target repo: + +- `.claude-plugin/plugin.json` +- `.claude-plugin/marketplace.json` + +## README install block + +Copy this install block into the target repo README: + + ## Install + + ### Claude Code + ```bash + /plugin marketplace add maxtechera/memory + ``` + + ### OpenClaw + ```bash + clawhub install memory + ``` + + ### Manual + ```bash + git clone https://github.com/maxtechera/memory.git ~/.claude/skills/memory + ``` + +## Install test checklist + +1. Run `/plugin marketplace add maxtechera/memory` in Claude Code. +2. Confirm the plugin installs without manifest errors. +3. Run the first memory command from the repo quickstart. +4. Capture a screenshot of the rendered README/install surface for Linear proof. + +Status in this package: manifest structure verified from the live repo, but the interactive install still needs to be run in Claude Code before the ticket can honestly claim install confirmed working. + +## Proof assets + +- Package manifest: `artifacts/MAX-534/package.json` +- Preview board: `artifacts/MAX-534/preview.html` +- Rendered markdown proof: `artifacts/MAX-534/github-readme.html` +- Social card PNG: `artifacts/MAX-534/social-preview-card.png` +- Rendered GitHub markdown screenshot: `artifacts/MAX-534/rendered_github_markdown_screenshot.png` diff --git a/docs/proofs/MAX-542/command-output.txt b/docs/proofs/MAX-542/command-output.txt new file mode 100644 index 0000000..2dcfc9b --- /dev/null +++ b/docs/proofs/MAX-542/command-output.txt @@ -0,0 +1,15 @@ +$ python3 - <<'PY' +from pathlib import Path +p = Path('artifacts/MAX-542/course-outline-orchestrate-ai-agents.md') +text = p.read_text() +required = ['The verification problem', 'Board setup', 'The 5-stage ticket lifecycle', 'Writing verification criteria', 'Domain skills', 'Self-improving rules', 'Team mode + sweep scheduling', 'GitHub install → first verified ticket → course CTA'] +missing = [item for item in required if item not in text] +print('FILE:', p) +print('LINES:', len(text.splitlines())) +print('BYTES:', len(text.encode())) +print('MISSING:', missing if missing else 'none') +PY +FILE: artifacts/MAX-542/course-outline-orchestrate-ai-agents.md +LINES: 337 +BYTES: 14832 +MISSING: none diff --git a/docs/proofs/MAX-542/course-outline-preview.mp4 b/docs/proofs/MAX-542/course-outline-preview.mp4 new file mode 100644 index 0000000..031ccc0 Binary files /dev/null and b/docs/proofs/MAX-542/course-outline-preview.mp4 differ diff --git a/docs/proofs/MAX-542/course-outline-render.html b/docs/proofs/MAX-542/course-outline-render.html new file mode 100644 index 0000000..577a79a --- /dev/null +++ b/docs/proofs/MAX-542/course-outline-render.html @@ -0,0 +1,251 @@ +MAX-542 Course Outline

MAX-542 Course Outline

+

Offer stack: `/orchestrator`

+

Course title EN: **Orchestrate AI Agents**

+

Course title ES: **Orquesta tus Agentes IA**

+

Price: **$197**

+

Tagline EN: **Stop being the QA department for your own AI agents**

+

Tagline ES: **Deja de ser el QA de tus propios agentes**

+

Course promise

+

This course teaches operators, founders, and technical leads how to run AI agents with a real delivery system instead of vibe-based prompting. Students learn to define tickets, separate execution from verification, route work across the tools they already use, and review outputs with clear operational controls.

+

The core transformation: students stop personally QA-ing every agent output and start operating an inspectable delivery system where agents produce proof, verifiers check claims, and humans only step in for judgment calls.

+

Ideal student

+

• Builders already using AI agents but frustrated by inconsistent delivery

+

• Operators managing recurring work across content, engineering, e-commerce, and internal ops

+

• Founders who want leverage without becoming the bottleneck reviewer for every output

+

• Teams moving from single-chat prompting to durable, ticket-based execution

+

Before / after transformation

+

Before

+

• Agents do work, but quality varies wildly

+

• The human becomes the final QA layer every time

+

• Tasks get redone because context is missing or unverifiable

+

• Tool sprawl creates confusion instead of throughput

+

• "Done" means the agent said it was done

+

After

+

• Agents execute against scoped tickets with explicit verification criteria

+

• Work moves through a repeatable lifecycle instead of ad hoc prompting

+

• The human reviews exceptions, not everything

+

• AI labor becomes inspectable, auditable, and easier to scale

+

• "Done" means business intent and proof align

+

Course outcomes

+

By the end of the course, students will be able to:

+

1. Explain why AI self-grading fails without independent verification.

+

2. Set up a practical work board in Linear, GitHub Issues, Notion, or Jira.

+

3. Run agent work through a 5-stage lifecycle: Intake → Execute → Verify → Review → Done.

+

4. Write verification criteria that reduce ambiguity, rework, and reviewer load.

+

5. Design domain-specific agent workflows for content, engineering, and e-commerce.

+

6. Turn repeated failures into durable rules, templates, and acceptance checks.

+

7. Operate team-mode agent workflows with sweep scheduling and escalation rules.

+

Course structure

+

• **7 modules** aligned to the `/orchestrator` operating model

+

• **28 core lessons** plus exercises and templates

+

• **Format:** short video lessons, worksheets, board templates, verification checklists, and cloneable `/orchestrator` examples

+

• **Languages:** English course with Spanish adaptation track using the same operational skeleton

+
+

Module 1. The verification problem — why AI self-grading fails

+

**Goal:** Show why prompting alone does not create reliable operations.

+

Lessons

+

1. Why capable agents still produce low-trust output

+

2. The trap of AI self-grading and circular confidence

+

3. Failure modes: hallucinated completion, false confidence, shallow checks, and hidden regressions

+

4. Why external artifacts beat agent claims

+

Takeaways

+

• Reliability comes from system design, not model optimism

+

• Verification must be separated from execution

+

• Trust increases when work produces inspectable proof

+

Exercise

+

Audit one recent agent-delivered task and identify where execution and verification were mixed together.

+

Deliverable

+

A short failure map showing: request, agent claim, actual proof, missing verification, and reviewer burden.

+
+

Module 2. Board setup — Linear, GitHub Issues, Notion, Jira

+

**Goal:** Give students a practical substrate for routing agent work.

+

Lessons

+

1. What makes a board usable for AI operations

+

2. Choosing between Linear, GitHub Issues, Notion, and Jira

+

3. Required ticket fields: objective, surface, proof, owner, state, blocker, and acceptance criteria

+

4. Designing a board that humans and agents can both understand

+

Recommended board fields

+

• **Objective:** what business outcome the ticket serves

+

• **Surface:** repo, page, doc, channel, dashboard, campaign, or workflow being changed

+

• **Inputs:** links, files, constraints, source material

+

• **Deliverable:** what must be created or changed

+

• **Proof required:** screenshots, tests, diffs, URLs, metrics, or rendered artifacts

+

• **Owner:** human or agent responsible for the current state

+

• **State:** Intake, Execute, Verify, Review, Done

+

Takeaways

+

• The board is the source of truth for agent work

+

• Clean ticket structure lowers coordination cost

+

• Good fields prevent hidden assumptions during execution

+

Exercise

+

Create a reusable ticket template in the student’s preferred system with objective, proof requirements, owner, delivery surface, and acceptance criteria.

+

Deliverable

+

A working AI-agent ticket template for Linear, GitHub Issues, Notion, or Jira.

+
+

Module 3. The 5-stage ticket lifecycle — Intake → Execute → Verify → Review → Done

+

**Goal:** Teach the operating model that makes agent work reviewable.

+

Lifecycle

+

1. **Intake:** clarify the business request, target surface, constraints, and proof requirements

+

2. **Execute:** produce the artifact, implementation, or campaign output

+

3. **Verify:** independently check the claimed result against observable criteria

+

4. **Review:** human or designated approver inspects exceptions, taste calls, and tradeoffs

+

5. **Done:** close only when business intent and proof align

+

Lessons

+

1. What belongs in each stage and what does not

+

2. Hand-offs between executor, verifier, reviewer, and owner

+

3. State transitions that reduce ambiguity

+

4. Common anti-patterns, including premature Done, vague Review, and skipped Verify states

+

Takeaways

+

• A ticket lifecycle is an operational control layer

+

• Verification deserves its own explicit stage

+

• Review is faster when upstream proof is consistent

+

Exercise

+

Map one existing team workflow into the 5-stage model and note what is missing.

+

Deliverable

+

A lifecycle map for one real recurring workflow, including owner, input, output, proof, and escalation at each stage.

+
+

Module 4. Writing verification criteria — automated checks vs AI quality checks

+

**Goal:** Help students create checks that agents can execute and humans can trust.

+

Lessons

+

1. The anatomy of strong verification criteria

+

2. Automated checks: tests, lint, typecheck, build, links, schema validation, and visual regression

+

3. AI quality checks: rubric scoring, completeness review, tone review, strategy review, and contradiction checks

+

4. Converting vague requests into testable completion standards

+

5. Examples for content, code, operations, and research tasks

+

Verification framework

+

For each ticket, define:

+

• **Artifact delta:** what changed, created, or shipped

+

• **Business delta:** why the change matters or what outcome it enables

+

• **Surface correctness:** how we know it landed in the right place and format

+

• **Automated gate:** the smallest reliable machine-checkable proof

+

• **Quality gate:** the rubric or judgment criteria for non-deterministic work

+

• **Human gate:** the point where taste, risk, or authority requires human approval

+

Takeaways

+

• Verification criteria should be observable, not interpretive

+

• Strong proof reduces reviewer load dramatically

+

• Automated checks and AI quality checks solve different problems

+

• The ticket should tell the verifier what “done” actually means

+

Exercise

+

Rewrite three vague requests into tickets with explicit verification criteria and required proof.

+

Deliverable

+

Three before/after ticket rewrites with artifact proof, automated checks, AI quality checks, and human approval rules.

+
+

Module 5. Domain skills — content, engineering, e-commerce

+

**Goal:** Show students how to adapt the same orchestration system to different business domains.

+

Lessons

+

1. Why domain skills matter: agents need operating context, not just instructions

+

2. Content workflows: brief → draft → edit → package → publish proof

+

3. Engineering workflows: ticket → implementation → tests → PR → review proof

+

4. E-commerce workflows: product update → listing QA → pricing/checkouts → publish proof

+

5. How to write reusable domain rules without overfitting to one task

+

Domain examples

+

#### Content

+

• Inputs: angle, audience, offer, channel, brand voice

+

• Proof: final asset, platform preview, hook variants, CTA alignment, publish checklist

+

#### Engineering

+

• Inputs: issue, repo surface, constraints, expected behavior

+

• Proof: diff, tests, lint/typecheck/build, screenshots, PR link

+

#### E-commerce

+

• Inputs: SKU/product, price, inventory, listing copy, images, marketplace rules

+

• Proof: listing preview, price verification, checkout path, image compliance, publish URL

+

Takeaways

+

• The lifecycle stays stable while domain criteria change

+

• Reusable skills reduce repeated instruction overhead

+

• Domain-specific verification is what makes agent output operationally useful

+

Exercise

+

Choose one domain and create a skill card with inputs, outputs, proof requirements, failure modes, and escalation triggers.

+

Deliverable

+

One reusable domain skill card for content, engineering, or e-commerce.

+
+

Module 6. Self-improving rules — every failure becomes a rule

+

**Goal:** Teach students how to convert agent mistakes into durable operating improvements.

+

Lessons

+

1. The failure-capture loop: incident → cause → rule → template update → next run

+

2. How to distinguish one-off mistakes from systemic rules

+

3. Writing rules that agents can actually follow

+

4. Updating ticket templates, verification checklists, and domain skills after failures

+

5. Avoiding rule bloat and contradictory instructions

+

Rule improvement loop

+

1. Capture the failed ticket and the exact failure mode

+

2. Identify whether the failure came from missing context, weak acceptance criteria, poor verification, or tool misuse

+

3. Add one small rule to the relevant template, skill, or checklist

+

4. Re-run or verify the next similar task against the new rule

+

5. Remove or consolidate rules that no longer earn their complexity

+

Takeaways

+

• A good agent system gets safer after each failure

+

• The fix is usually a better rule, checklist, or proof requirement—not a longer prompt

+

• Rules should live where future agents will actually see them

+

Exercise

+

Take one real agent failure and write the exact rule/template/checklist update that would prevent recurrence.

+

Deliverable

+

A failure-to-rule log with at least three entries and one updated ticket template or skill checklist.

+
+

Module 7. Team mode + sweep scheduling

+

**Goal:** Help students operate `/orchestrator` as a recurring team workflow instead of a one-off demo.

+

Lessons

+

1. Team mode: coordinator, executor, verifier, reviewer, and owner roles

+

2. Sweep scheduling: recurring checks for stale tickets, missing proof, blocked work, and ready-for-review items

+

3. Escalation rules for blockers, risky changes, and human decisions

+

4. Operating cadence: daily sweep, weekly cleanup, and post-failure rule updates

+

5. Metrics that matter: cycle time, verification failure rate, reviewer load, and escaped defects

+

Team operating model

+

• **Coordinator:** decomposes work and assigns ownership

+

• **Executor:** creates the artifact or implementation

+

• **Verifier:** checks proof against criteria independently

+

• **Reviewer:** handles judgment, taste, risk, and final approval

+

• **Owner:** accountable for business outcome and closing the loop

+

Sweep examples

+

• Find tickets stuck in Execute without proof

+

• Find Review tickets missing screenshots, tests, URLs, or diffs

+

• Find Done tickets with no business proof

+

• Find repeated failure modes that deserve new rules

+

• Find recurring work that should become a scheduled orchestrator run

+

Takeaways

+

• Scheduling creates consistency without constant human babysitting

+

• Team mode works when roles and handoffs are explicit

+

• Good operations make agent leverage compound over time

+

Exercise

+

Design one scheduled sweep for a real board and define the trigger, query, action, owner, and escalation path.

+

Deliverable

+

A team-mode operating cadence with one daily sweep, one weekly cleanup, and one escalation rule.

+
+

Funnel trigger

+

**Trigger:** GitHub install → first verified ticket → course CTA for domain depth

+

Funnel logic

+

1. User installs or clones `/orchestrator`

+

2. User runs their first ticket through Execute and Verify

+

3. They see the gap between ad hoc agent work and a real operating system

+

4. CTA introduces the course as the next step for templates, domain skills, board setup, and team-mode workflows

+

CTA placements

+

• GitHub README after quickstart and first verified ticket example

+

• `/orchestrator` proof artifact examples

+

• Post-install success message or docs page

+

• Newsletter and launch emails for builders using agent workflows

+

English / Spanish adaptation notes

+

English hooks

+

• Your AI agent is not failing because it is dumb. It is failing because your system has no verification layer.

+

• If you are checking every agent output yourself, you do not have leverage. You have a new intern.

+

• The goal is not more prompts. The goal is a delivery system.

+

• Stop being the QA department for your own AI agents.

+

Spanish hooks

+

• Tu agente no falla por falta de inteligencia. Falla porque tu sistema no tiene una capa de verificación.

+

• Si estás revisando cada entrega del agente, no tienes apalancamiento. Tienes otro trabajo.

+

• La meta no es escribir más prompts. La meta es construir un sistema de entrega.

+

• Deja de ser el QA de tus propios agentes.

+

Adaptation guidance

+

• Keep module structure identical in EN and ES

+

• Localize examples for Spanish-speaking operators and founders

+

• Avoid literal translation when the operational metaphor is clearer in Spanish

+

• Preserve `/orchestrator`, ticket lifecycle, verification, and proof terminology consistently

+

Production deliverables

+

1. **Course outline finalized:** this document

+

2. **Modules scripted (EN):** one script brief per lesson using this outline

+

3. **Spanish track adaptation:** translated/adapted lesson briefs, examples, and worksheets

+

4. **Course page copy:** promise, bullets, module accordion, FAQ, and CTA

+

5. **GitHub README CTA:** install → first verified ticket → course CTA

+

Final deliverable recommendation

+

Turn this outline into:

+

1. a lesson-by-lesson script brief,

+

2. a worksheet with ticket and verification templates,

+

3. a companion board template for `/orchestrator` users,

+

4. domain skill cards for content, engineering, and e-commerce,

+

5. a sweep scheduling checklist for team-mode operations.

\ No newline at end of file diff --git a/docs/proofs/MAX-542/final_mp4_attachment.mp4 b/docs/proofs/MAX-542/final_mp4_attachment.mp4 new file mode 100644 index 0000000..031ccc0 Binary files /dev/null and b/docs/proofs/MAX-542/final_mp4_attachment.mp4 differ diff --git a/docs/proofs/MAX-542/linear_attached_visual_proof.png b/docs/proofs/MAX-542/linear_attached_visual_proof.png new file mode 100644 index 0000000..e79b9d6 Binary files /dev/null and b/docs/proofs/MAX-542/linear_attached_visual_proof.png differ diff --git a/docs/proofs/MAX-542/rendered-github-markdown-screenshot.png b/docs/proofs/MAX-542/rendered-github-markdown-screenshot.png new file mode 100644 index 0000000..e79b9d6 Binary files /dev/null and b/docs/proofs/MAX-542/rendered-github-markdown-screenshot.png differ diff --git a/docs/proofs/MAX-542/rendered-html-screenshot.png b/docs/proofs/MAX-542/rendered-html-screenshot.png new file mode 100644 index 0000000..e79b9d6 Binary files /dev/null and b/docs/proofs/MAX-542/rendered-html-screenshot.png differ diff --git a/docs/proofs/MAX-542/rendered_github_markdown_screenshot.png b/docs/proofs/MAX-542/rendered_github_markdown_screenshot.png new file mode 100644 index 0000000..e79b9d6 Binary files /dev/null and b/docs/proofs/MAX-542/rendered_github_markdown_screenshot.png differ diff --git a/docs/proofs/MAX-542/rendered_html_preview_screenshot.png b/docs/proofs/MAX-542/rendered_html_preview_screenshot.png new file mode 100644 index 0000000..e79b9d6 Binary files /dev/null and b/docs/proofs/MAX-542/rendered_html_preview_screenshot.png differ diff --git a/docs/proofs/MAX-542/rendered_html_screenshot.png b/docs/proofs/MAX-542/rendered_html_screenshot.png new file mode 100644 index 0000000..e79b9d6 Binary files /dev/null and b/docs/proofs/MAX-542/rendered_html_screenshot.png differ diff --git a/docs/proofs/MAX-542/repo-metadata.json b/docs/proofs/MAX-542/repo-metadata.json new file mode 100644 index 0000000..fc0cb8a --- /dev/null +++ b/docs/proofs/MAX-542/repo-metadata.json @@ -0,0 +1,19 @@ +{ + "ticket": "MAX-542", + "artifact_path": "artifacts/MAX-542/course-outline-orchestrate-ai-agents.md", + "affected_runtime_path": "/orchestrator", + "deliverable_type": "content_asset", + "delivery_surface": "repo:orchestrator", + "target_repo": "maxtechera/orchestrator", + "target_system": "mailerlite", + "proof_requirements": [ + "pr_url", + "linear_attached_visual_proof", + "rendered_html_screenshot", + "deployed_url", + "screenshot_desktop", + "screenshot_mobile", + "final_mp4_attachment", + "rendered_github_markdown_screenshot" + ] +} diff --git a/docs/proofs/MAX-542/screenshot-desktop.png b/docs/proofs/MAX-542/screenshot-desktop.png new file mode 100644 index 0000000..e79b9d6 Binary files /dev/null and b/docs/proofs/MAX-542/screenshot-desktop.png differ diff --git a/docs/proofs/MAX-542/screenshot-mobile.png b/docs/proofs/MAX-542/screenshot-mobile.png new file mode 100644 index 0000000..bcc97f6 Binary files /dev/null and b/docs/proofs/MAX-542/screenshot-mobile.png differ diff --git a/docs/proofs/MAX-542/screenshot_desktop.png b/docs/proofs/MAX-542/screenshot_desktop.png new file mode 100644 index 0000000..e79b9d6 Binary files /dev/null and b/docs/proofs/MAX-542/screenshot_desktop.png differ diff --git a/docs/proofs/MAX-542/screenshot_mobile.png b/docs/proofs/MAX-542/screenshot_mobile.png new file mode 100644 index 0000000..bcc97f6 Binary files /dev/null and b/docs/proofs/MAX-542/screenshot_mobile.png differ diff --git a/docs/sample-lessons/module-1-lesson-1-context-limit-wall.md b/docs/sample-lessons/module-1-lesson-1-context-limit-wall.md new file mode 100644 index 0000000..d303657 --- /dev/null +++ b/docs/sample-lessons/module-1-lesson-1-context-limit-wall.md @@ -0,0 +1,116 @@ +# Module 1, Lesson 1 — The context-limit wall and why single-agent workflows break + +**Course:** /orchestrator — Run reliable multi-agent workflows in 1 week +**Lesson type:** Free public lesson workbook + recording guide +**Estimated video length:** 12 to 15 minutes +**Placement:** `/academia/orchestrator/preview` + +## Lesson promise +By the end of this lesson, the student will understand why a single agent feels magical at first and then quietly becomes unreliable as tasks get larger, longer, and more interdependent. + +## What the student should walk away with +- A clear mental model of the context-limit wall +- Four common failure modes in single-agent execution +- A simple rule for deciding when to keep one agent versus orchestrate a team +- A worksheet they can use on one of their own workflows today + +## Teaching arc +### 1. Hook +Open with a familiar moment: + +> “Your agent looked brilliant for the first 20 minutes. Then it forgot part of the brief, rewrote something another step already handled, and confidently moved forward like nothing broke.” + +Frame the lesson around one idea: the problem is not that the model is bad, it is that you are asking one worker to hold too much state, too many goals, and too many dependencies at once. + +### 2. Core concept +**The context-limit wall** is the point where a single agent can no longer reliably carry all of the instructions, decisions, intermediate outputs, and changing constraints required to finish the job well. + +When that wall shows up, performance does not usually fail all at once. It degrades gradually: +- details disappear +- handoffs stay implicit +- repeated work increases +- confidence stays high while correctness drops + +### 3. The four failure modes +#### Failure mode 1 — context loss +The agent drops an earlier requirement because the active context shifted toward newer instructions. + +#### Failure mode 2 — duplicate work +The agent recreates something that already exists because the task history is no longer salient. + +#### Failure mode 3 — drift +The agent keeps working, but the output slowly diverges from the original goal, repo, or delivery surface. + +#### Failure mode 4 — invisible blockers +The agent encounters uncertainty, makes an unstated assumption, and continues without exposing the decision. + +## Whiteboard example +Use one concrete workflow: +1. Research positioning +2. Draft a landing page +3. Update the README +4. Create screenshots +5. Open a PR +6. Attach proof to the ticket + +Then show why one agent struggles to do all six reliably without a contract, scoped ownership, and verification. + +## The rule of thumb +Stay with a single agent when: +- the task is short +- the output is one artifact +- dependencies are low +- failure is cheap + +Move to orchestration when: +- the task spans multiple artifacts or surfaces +- proof matters as much as the artifact +- handoffs or retries are likely +- you need parallel speed without output collisions + +## Workbook exercise +### Part 1 — Audit one workflow +Pick a real workflow you run with one agent today. + +- What is the task? +- How many distinct artifacts does it produce? +- How many tools or systems does it touch? +- Where does the agent usually forget details? +- Where does it repeat work? +- Where does it make hidden assumptions? + +### Part 2 — Mark the pressure points +Score each item from 1 to 5: +- Context load +- Number of dependencies +- Number of deliverables +- Cost of failure +- Need for proof or verification + +If the total is 16 or more, the workflow is a strong orchestration candidate. + +### Part 3 — Redesign prompt +Write one sentence answering: + +> “If I split this into a coordinator plus scoped executors, what would each worker own?” + +## Instructor notes +- Keep this lesson tactical, not philosophical +- Use concrete delivery examples, not abstract AI talk +- Make the student feel relief: the chaos they feel is structural, not personal +- End by pointing directly into Module 2, where ticket contracts solve the drift problem + +## Suggested closing CTA +> If this feels familiar, good. You do not need a smarter monolithic prompt. You need a better operating model. In the next module, we build the ticket contract that makes multi-agent work reliable. + +## Recording checklist +- [ ] Show one failed single-agent workflow example +- [ ] Draw the four failure modes on screen +- [ ] Walk through the scoring worksheet +- [ ] Give the keep-one-agent versus orchestrate rule +- [ ] Bridge into ticket contracts + +## Reusable pull quotes +- “Context windows are not operating systems.” +- “Single-agent magic breaks the moment the task becomes a system.” +- “Orchestration starts when proof matters, not just output.” diff --git a/proof/MAX-527/max527-reel.mp4 b/proof/MAX-527/max527-reel.mp4 new file mode 100644 index 0000000..68f2d97 Binary files /dev/null and b/proof/MAX-527/max527-reel.mp4 differ diff --git a/proof/MAX-527/max527-thumb.png b/proof/MAX-527/max527-thumb.png new file mode 100644 index 0000000..7779b9e Binary files /dev/null and b/proof/MAX-527/max527-thumb.png differ diff --git a/proof/MAX-569/max569-01-v1-problem-agitate-solve-proof.png b/proof/MAX-569/max569-01-v1-problem-agitate-solve-proof.png new file mode 100644 index 0000000..8c832c3 Binary files /dev/null and b/proof/MAX-569/max569-01-v1-problem-agitate-solve-proof.png differ diff --git a/proof/MAX-569/max569-01-v1-problem-agitate-solve-thumb.png b/proof/MAX-569/max569-01-v1-problem-agitate-solve-thumb.png new file mode 100644 index 0000000..8c832c3 Binary files /dev/null and b/proof/MAX-569/max569-01-v1-problem-agitate-solve-thumb.png differ diff --git a/proof/MAX-569/max569-01-v1-problem-agitate-solve.mp4 b/proof/MAX-569/max569-01-v1-problem-agitate-solve.mp4 new file mode 100644 index 0000000..2618587 Binary files /dev/null and b/proof/MAX-569/max569-01-v1-problem-agitate-solve.mp4 differ diff --git a/proof/MAX-569/max569-02-v2-contrarian-proof.png b/proof/MAX-569/max569-02-v2-contrarian-proof.png new file mode 100644 index 0000000..6c6a001 Binary files /dev/null and b/proof/MAX-569/max569-02-v2-contrarian-proof.png differ diff --git a/proof/MAX-569/max569-02-v2-contrarian-thumb.png b/proof/MAX-569/max569-02-v2-contrarian-thumb.png new file mode 100644 index 0000000..6c6a001 Binary files /dev/null and b/proof/MAX-569/max569-02-v2-contrarian-thumb.png differ diff --git a/proof/MAX-569/max569-02-v2-contrarian.mp4 b/proof/MAX-569/max569-02-v2-contrarian.mp4 new file mode 100644 index 0000000..3106865 Binary files /dev/null and b/proof/MAX-569/max569-02-v2-contrarian.mp4 differ diff --git a/proof/MAX-569/max569-03-v3-specific-number-proof.png b/proof/MAX-569/max569-03-v3-specific-number-proof.png new file mode 100644 index 0000000..07e0d53 Binary files /dev/null and b/proof/MAX-569/max569-03-v3-specific-number-proof.png differ diff --git a/proof/MAX-569/max569-03-v3-specific-number-thumb.png b/proof/MAX-569/max569-03-v3-specific-number-thumb.png new file mode 100644 index 0000000..07e0d53 Binary files /dev/null and b/proof/MAX-569/max569-03-v3-specific-number-thumb.png differ diff --git a/proof/MAX-569/max569-03-v3-specific-number.mp4 b/proof/MAX-569/max569-03-v3-specific-number.mp4 new file mode 100644 index 0000000..71de091 Binary files /dev/null and b/proof/MAX-569/max569-03-v3-specific-number.mp4 differ diff --git a/proof/MAX-569/max569-04-v4-insider-reveal-proof.png b/proof/MAX-569/max569-04-v4-insider-reveal-proof.png new file mode 100644 index 0000000..b5ba1fc Binary files /dev/null and b/proof/MAX-569/max569-04-v4-insider-reveal-proof.png differ diff --git a/proof/MAX-569/max569-04-v4-insider-reveal-thumb.png b/proof/MAX-569/max569-04-v4-insider-reveal-thumb.png new file mode 100644 index 0000000..b5ba1fc Binary files /dev/null and b/proof/MAX-569/max569-04-v4-insider-reveal-thumb.png differ diff --git a/proof/MAX-569/max569-04-v4-insider-reveal.mp4 b/proof/MAX-569/max569-04-v4-insider-reveal.mp4 new file mode 100644 index 0000000..ba845e0 Binary files /dev/null and b/proof/MAX-569/max569-04-v4-insider-reveal.mp4 differ diff --git a/proof/MAX-569/max569-05-v5-testimonial-proof.png b/proof/MAX-569/max569-05-v5-testimonial-proof.png new file mode 100644 index 0000000..ddcb50d Binary files /dev/null and b/proof/MAX-569/max569-05-v5-testimonial-proof.png differ diff --git a/proof/MAX-569/max569-05-v5-testimonial-thumb.png b/proof/MAX-569/max569-05-v5-testimonial-thumb.png new file mode 100644 index 0000000..ddcb50d Binary files /dev/null and b/proof/MAX-569/max569-05-v5-testimonial-thumb.png differ diff --git a/proof/MAX-569/max569-05-v5-testimonial.mp4 b/proof/MAX-569/max569-05-v5-testimonial.mp4 new file mode 100644 index 0000000..50eff9b Binary files /dev/null and b/proof/MAX-569/max569-05-v5-testimonial.mp4 differ diff --git a/proof/MAX-570/max570-reel-1-problem-proof.png b/proof/MAX-570/max570-reel-1-problem-proof.png new file mode 100644 index 0000000..18fb2c0 Binary files /dev/null and b/proof/MAX-570/max570-reel-1-problem-proof.png differ diff --git a/proof/MAX-570/max570-reel-1-problem-thumb.png b/proof/MAX-570/max570-reel-1-problem-thumb.png new file mode 100644 index 0000000..299288e Binary files /dev/null and b/proof/MAX-570/max570-reel-1-problem-thumb.png differ diff --git a/proof/MAX-570/max570-reel-1-problem.mp4 b/proof/MAX-570/max570-reel-1-problem.mp4 new file mode 100644 index 0000000..9579e38 Binary files /dev/null and b/proof/MAX-570/max570-reel-1-problem.mp4 differ diff --git a/proof/MAX-570/max570-reel-2-fix-proof.png b/proof/MAX-570/max570-reel-2-fix-proof.png new file mode 100644 index 0000000..8ab3696 Binary files /dev/null and b/proof/MAX-570/max570-reel-2-fix-proof.png differ diff --git a/proof/MAX-570/max570-reel-2-fix-thumb.png b/proof/MAX-570/max570-reel-2-fix-thumb.png new file mode 100644 index 0000000..3810544 Binary files /dev/null and b/proof/MAX-570/max570-reel-2-fix-thumb.png differ diff --git a/proof/MAX-570/max570-reel-2-fix.mp4 b/proof/MAX-570/max570-reel-2-fix.mp4 new file mode 100644 index 0000000..c521e4c Binary files /dev/null and b/proof/MAX-570/max570-reel-2-fix.mp4 differ diff --git a/proof/MAX-570/max570-reel-3-architecture-proof.png b/proof/MAX-570/max570-reel-3-architecture-proof.png new file mode 100644 index 0000000..82a12e5 Binary files /dev/null and b/proof/MAX-570/max570-reel-3-architecture-proof.png differ diff --git a/proof/MAX-570/max570-reel-3-architecture-thumb.png b/proof/MAX-570/max570-reel-3-architecture-thumb.png new file mode 100644 index 0000000..ea4201c Binary files /dev/null and b/proof/MAX-570/max570-reel-3-architecture-thumb.png differ diff --git a/proof/MAX-570/max570-reel-3-architecture.mp4 b/proof/MAX-570/max570-reel-3-architecture.mp4 new file mode 100644 index 0000000..93a5f28 Binary files /dev/null and b/proof/MAX-570/max570-reel-3-architecture.mp4 differ diff --git a/scripts/generate_max569_assets.py b/scripts/generate_max569_assets.py new file mode 100644 index 0000000..ef0624d --- /dev/null +++ b/scripts/generate_max569_assets.py @@ -0,0 +1,59 @@ +#!/usr/bin/env python3 +import subprocess +from pathlib import Path + +OUT = Path('/data/workspace/artifacts/MAX-569') +OUT.mkdir(parents=True, exist_ok=True) +FONT_BOLD = '/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf' +FONT = '/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf' + +variants = [ + ('v1-problem-agitate-solve', 'AI said done.\nRepo disagreed.', 'Fake done gets caught.', [ + 'Wrong repo.', 'No proof.', 'Still marked done.', '/orchestrator blocks it.' + ]), + ('v2-contrarian', 'More agents\nwill not save you.', 'Stop adding agents.', [ + 'Speed amplifies mistakes.', 'Guardrails beat hype.', 'Proof beats vibes.', '/orchestrator enforces all 3.' + ]), + ('v3-specific-number', '3 checks before\nI trust agents.', '3 receipts or no ship.', [ + 'Artifact delta', 'Business delta', 'Surface correctness', 'Miss one, no DONE.' + ]), + ('v4-insider-reveal', 'The trick is not\nthe prompt.', 'The hidden part of demos.', [ + 'Wrong repo is common.', 'Missing proof is common.', 'Status theater is common.', '/orchestrator catches it.' + ]), + ('v5-testimonial', 'Best agent feature?\nNot done yet.', 'The workflow that helped.', [ + 'Solo agents polished lies.', 'Parallel workers need proof.', 'Repo and outcome must match.', 'Then work counts.' + ]), +] + +for i, (slug, title, subtitle, bullets) in enumerate(variants, start=1): + stem = f'max569-{i:02d}-{slug}' + jpg = OUT / f'{stem}-thumb.jpg' + png = OUT / f'{stem}-thumb.png' + proof = OUT / f'{stem}-proof.png' + mp4 = OUT / f'{stem}.mp4' + + bullet_text = '\n'.join([f'• {b}' for b in bullets]) + cmd = [ + 'convert', '-size', '720x1280', 'xc:#0b1020', + '-fill', '#ff4d4f', '-draw', 'rectangle 40,90 680,390', + '-fill', '#111827', '-draw', 'rectangle 40,470 680,1010', + '-fill', 'white', '-font', FONT_BOLD, '-pointsize', '48', + '-gravity', 'NorthWest', '-annotate', '+70+140', title, + '-fill', '#93c5fd', '-font', FONT_BOLD, '-pointsize', '30', + '-annotate', '+70+520', subtitle, + '-fill', 'white', '-font', FONT, '-pointsize', '28', + '-annotate', '+70+600', bullet_text, + '-fill', '#f9fafb', '-font', FONT_BOLD, '-pointsize', '24', + '-annotate', '+70+1110', 'DM ORCHESTRATOR | comment sweep', + '-quality', '92', str(jpg) + ] + subprocess.run(cmd, check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL) + subprocess.run(['convert', str(jpg), '-define', 'png:color-type=2', str(png)], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL) + subprocess.run(['cp', str(png), str(proof)], check=True) + subprocess.run([ + 'ffmpeg', '-y', '-loop', '1', '-i', str(jpg), '-t', '12', '-r', '30', + '-vf', 'format=yuv420p', '-c:v', 'mpeg4', '-q:v', '4', str(mp4) + ], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL) + jpg.unlink(missing_ok=True) + +print(f'Generated {len(variants)} MP4s, thumbnails, and proof PNGs in {OUT}')