+/ship OSS demo-first content bundle
+Prepared for MAX-570.
+Positioning spine
+
+- Category: OSS demo-first GTM execution system
+- Core pain: founders are stitching intake, strategy, content, launch, and follow-up across disconnected tools and disconnected people
+- Core promise: run
/ship once and the GTM workstream starts moving as one coordinated system
+- Primary CTA: install
/ship, then join the $497 course waitlist for the deeper playbook
+- Secondary CTA: reply
SHIP or click through to see the full demo/course page
+
+
+Hook library
+Problem-led hooks
+
+- Your GTM is not broken because you lack ideas. It is broken because intake, strategy, content, and launch live in four different systems.
+- Most founders do not need more AI tools. They need one pipeline that actually moves from brief to launch.
+- If your launch still depends on copy-pasting between docs, chats, boards, and email, you do not have a system. You have GTM debt.
+- Manual GTM chaos looks productive right until launch week turns into missed handoffs.
+- The real bottleneck is not content creation. It is coordination.
+
+Demo-led hooks
+
+- Run
/ship once, and the whole GTM pipeline lights up.
+- This is what demo-first marketing looks like when named agents coordinate the whole launch.
+- Instead of prompting one tool at a time, we let the pipeline run from intake to launch.
+- The money shot is not one AI agent writing copy. It is the handoff graph actually moving.
+- This is the first demo I have seen where the GTM team behaves like a system, not a bag of prompts.
+
+Architecture-led hooks
+
+- Behind every clean launch is a messy pipeline, unless you design the stage gates up front.
+- The unlock is not another dashboard. It is a pipeline with gate owners, proof, and next actions.
+- We mapped the full GTM flow because most launches die in the handoffs nobody owns.
+- If you cannot point to intake, validate, strategy, awareness, lead capture, nurture, closing, launch, and measure, you are improvising.
+- This is the architecture behind turning open source attention into course revenue.
+
+CTA variants
+
+- Cold: Watch the
/ship demo, then steal the workflow.
+- Warm: Install
/ship and see how the pipeline feels in your own stack.
+- Hot: Join the $497 course waitlist if you want the full operating system, templates, and launch playbook.
+
+
+Reel 1, Problem, 15 to 30 seconds
+Working title
+Manual GTM chaos is killing your launches
+Hook
+Your GTM is not slow because your team is lazy. It is slow because intake, strategy, content, and launch are all disconnected.
+Script
+Hook, 0:00 to 0:03
On-screen: Your GTM is four broken handoffs pretending to be a strategy.
Voiceover: Your GTM is not one system. It is four broken handoffs pretending to be a strategy.
+Problem, 0:03 to 0:12
On-screen sequence: form -> doc -> chat -> board -> launch
Voiceover: A lead comes in here. Strategy lives somewhere else. Content is buried in chats. Launch happens in another tool. Nobody sees the whole pipeline.
+Escalation, 0:12 to 0:20
On-screen: missed handoffs, stale docs, calendar slips
Voiceover: So every launch becomes manual follow-up, copy-paste ops, and last-minute chaos.
+Bridge, 0:20 to 0:25
On-screen: The bottleneck is coordination.
Voiceover: The bottleneck is not ideas. It is coordination.
+CTA, 0:25 to 0:30
On-screen: Next reel: the fix
Voiceover: In the next reel, I will show you the fix, a demo-first pipeline that actually moves.
+Shotlist
+
+- Cursor jumping between intake form, document, Slack or chat, task board, calendar.
+- Tight crop on duplicate notes and stale status markers.
+- Timeline or board slipping past a deadline.
+- Hard cut to bold text,
The bottleneck is coordination.
+
+Caption
+Most GTM teams do not have a content problem. They have a handoff problem.
+Intake lives in one place. Strategy in another. Content in another. Launch in another.
+That works right until you need speed.
+Follow for reel 2, I will show the system that turns that chaos into one moving pipeline.
+
+Reel 2, Fix, 30 to 45 seconds
+Working title
+Run /ship once and the launch starts moving
+Hook
+Run /ship once, and the GTM pipeline starts moving from intake to launch.
+Script
+Hook, 0:00 to 0:03
On-screen: Run /ship once.
Voiceover: Run /ship once, and the pipeline starts moving.
+Demo start, 0:03 to 0:12
On-screen: dashboard boot, active run created, coordinator view
Voiceover: The coordinator reads the ticket, routes the work by stage, and keeps the whole run moving instead of waiting on one person to manually push it forward.
+Named agents, 0:12 to 0:24
On-screen: strategist, content, growth, nurture, closer, launcher, analyst, critic
Voiceover: Strategy handles positioning. Content builds the assets. Growth wires capture. Nurture handles MailerLite. Launch checks credentials. Critic and analyst gate quality before anything ships.
+Money shot, 0:24 to 0:36
On-screen: stage map lighting up, cards moving left to right, approvals landing
Voiceover: The money shot is this, not one isolated prompt, but the whole chain, intake to launch, with named agents coordinating the handoffs.
+Offer bridge, 0:36 to 0:42
On-screen: Open source install -> newsletter -> course
Voiceover: For open source, the path is simple, install the tool, join the newsletter, then convert into the course.
+CTA, 0:42 to 0:45
On-screen: Watch the full demo
Voiceover: If you want the full walkthrough, watch the demo and grab the course waitlist.
+Shotlist
+
+- Terminal or command palette running
/ship.
+- Dashboard render with active stages.
+- Quick flashes of each named agent role.
+- Pipeline graph or kanban flow moving in sequence.
+- Final CTA card with course price anchor.
+
+Caption
+This is the part most AI demos miss.
+The win is not one agent writing one asset.
+The win is intake, strategy, content, capture, nurture, closing, and launch moving as one system.
+That is what /ship is built to do.
+
+Reel 3, Architecture, 45 to 60 seconds
+Working title
+The architecture behind /ship
+Hook
+If you want repeatable launches, you need stage gates, owners, and one visible pipeline.
+Script
+Hook, 0:00 to 0:04
On-screen: full pipeline diagram
Voiceover: If you want repeatable launches, you need stage gates, owners, and one visible pipeline.
+Map the stages, 0:04 to 0:20
On-screen: idea -> validate -> strategy -> awareness -> lead capture -> nurture -> closing -> launch -> measure
Voiceover: /ship maps the whole GTM path, from idea and validation, into strategy, awareness, lead capture, nurture, closing, launch, and measure.
+Explain why it matters, 0:20 to 0:34
On-screen: blockers and approvals appearing at each gate
Voiceover: Every stage has a job, an owner, and a gate. That means fewer hidden blockers, less duplicated work, and a launch process you can actually inspect.
+OSS conversion model, 0:34 to 0:48
On-screen: GitH
+
+
+
diff --git a/artifacts/MAX-570/MAX-570-oss-demo-first-teaser.mp4 b/artifacts/MAX-570/MAX-570-oss-demo-first-teaser.mp4
new file mode 100644
index 0000000..c365105
Binary files /dev/null and b/artifacts/MAX-570/MAX-570-oss-demo-first-teaser.mp4 differ
diff --git a/artifacts/MAX-570/proof-pack.md b/artifacts/MAX-570/proof-pack.md
new file mode 100644
index 0000000..5d52fff
--- /dev/null
+++ b/artifacts/MAX-570/proof-pack.md
@@ -0,0 +1,19 @@
+# MAX-570 proof pack
+
+## Delivered artifacts
+- Content bundle: `docs/marketing/MAX-570-oss-demo-first-content-bundle.md`
+- README CTA update: `README.md`
+- Rendered markdown HTML: `artifacts/MAX-570/MAX-570-oss-demo-first-content-bundle.rendered.html`
+- Rendered markdown screenshot: `artifacts/MAX-570/rendered-github-markdown-screenshot.png`
+- Final MP4 teaser: `artifacts/MAX-570/MAX-570-oss-demo-first-teaser.mp4`
+
+## Requested items covered
+- 3-reel script set: included
+- Hook library: included
+- Long-format script: included
+- Newsletter draft: included
+- README CTA copy: included in bundle and applied to `README.md`
+
+## Proof notes
+- `rendered-github-markdown-screenshot.png` is a rendered screenshot of the markdown bundle using GitHub Markdown CSS.
+- `MAX-570-oss-demo-first-teaser.mp4` is a lightweight vertical proof video built from the reel narrative spine for attachment/evidence use.
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..6700d03
Binary files /dev/null and b/artifacts/MAX-570/rendered-github-markdown-screenshot.png differ
diff --git a/artifacts/MAX-570/video/slide1.png b/artifacts/MAX-570/video/slide1.png
new file mode 100644
index 0000000..d170eaf
Binary files /dev/null and b/artifacts/MAX-570/video/slide1.png differ
diff --git a/artifacts/MAX-570/video/slide2.png b/artifacts/MAX-570/video/slide2.png
new file mode 100644
index 0000000..aeb401d
Binary files /dev/null and b/artifacts/MAX-570/video/slide2.png differ
diff --git a/artifacts/MAX-570/video/slide3.png b/artifacts/MAX-570/video/slide3.png
new file mode 100644
index 0000000..c54c545
Binary files /dev/null and b/artifacts/MAX-570/video/slide3.png differ
diff --git a/artifacts/MAX-570/video/slide4.png b/artifacts/MAX-570/video/slide4.png
new file mode 100644
index 0000000..2d1fd57
Binary files /dev/null and b/artifacts/MAX-570/video/slide4.png differ
diff --git a/artifacts/MAX-570/video/slides.txt b/artifacts/MAX-570/video/slides.txt
new file mode 100644
index 0000000..3a1851b
--- /dev/null
+++ b/artifacts/MAX-570/video/slides.txt
@@ -0,0 +1,9 @@
+file 'slide1.png'
+duration 4
+file 'slide2.png'
+duration 5
+file 'slide3.png'
+duration 5
+file 'slide4.png'
+duration 4
+file 'slide4.png'
diff --git a/docs/marketing/MAX-570-oss-demo-first-content-bundle.md b/docs/marketing/MAX-570-oss-demo-first-content-bundle.md
new file mode 100644
index 0000000..dd59080
--- /dev/null
+++ b/docs/marketing/MAX-570-oss-demo-first-content-bundle.md
@@ -0,0 +1,274 @@
+# /ship OSS demo-first content bundle
+
+Prepared for MAX-570.
+
+## Positioning spine
+
+- Category: OSS demo-first GTM execution system
+- Core pain: founders are stitching intake, strategy, content, launch, and follow-up across disconnected tools and disconnected people
+- Core promise: run `/ship` once and the GTM workstream starts moving as one coordinated system
+- Primary CTA: install `/ship`, then join the $497 course waitlist for the deeper playbook
+- Secondary CTA: reply `SHIP` or click through to see the full demo/course page
+
+---
+
+## Hook library
+
+### Problem-led hooks
+1. Your GTM is not broken because you lack ideas. It is broken because intake, strategy, content, and launch live in four different systems.
+2. Most founders do not need more AI tools. They need one pipeline that actually moves from brief to launch.
+3. If your launch still depends on copy-pasting between docs, chats, boards, and email, you do not have a system. You have GTM debt.
+4. Manual GTM chaos looks productive right until launch week turns into missed handoffs.
+5. The real bottleneck is not content creation. It is coordination.
+
+### Demo-led hooks
+6. Run `/ship` once, and the whole GTM pipeline lights up.
+7. This is what demo-first marketing looks like when named agents coordinate the whole launch.
+8. Instead of prompting one tool at a time, we let the pipeline run from intake to launch.
+9. The money shot is not one AI agent writing copy. It is the handoff graph actually moving.
+10. This is the first demo I have seen where the GTM team behaves like a system, not a bag of prompts.
+
+### Architecture-led hooks
+11. Behind every clean launch is a messy pipeline, unless you design the stage gates up front.
+12. The unlock is not another dashboard. It is a pipeline with gate owners, proof, and next actions.
+13. We mapped the full GTM flow because most launches die in the handoffs nobody owns.
+14. If you cannot point to intake, validate, strategy, awareness, lead capture, nurture, closing, launch, and measure, you are improvising.
+15. This is the architecture behind turning open source attention into course revenue.
+
+### CTA variants
+- Cold: Watch the `/ship` demo, then steal the workflow.
+- Warm: Install `/ship` and see how the pipeline feels in your own stack.
+- Hot: Join the $497 course waitlist if you want the full operating system, templates, and launch playbook.
+
+---
+
+## Reel 1, Problem, 15 to 30 seconds
+
+### Working title
+Manual GTM chaos is killing your launches
+
+### Hook
+Your GTM is not slow because your team is lazy. It is slow because intake, strategy, content, and launch are all disconnected.
+
+### Script
+**Hook, 0:00 to 0:03**
+On-screen: `Your GTM is four broken handoffs pretending to be a strategy.`
+Voiceover: Your GTM is not one system. It is four broken handoffs pretending to be a strategy.
+
+**Problem, 0:03 to 0:12**
+On-screen sequence: `form -> doc -> chat -> board -> launch`
+Voiceover: A lead comes in here. Strategy lives somewhere else. Content is buried in chats. Launch happens in another tool. Nobody sees the whole pipeline.
+
+**Escalation, 0:12 to 0:20**
+On-screen: missed handoffs, stale docs, calendar slips
+Voiceover: So every launch becomes manual follow-up, copy-paste ops, and last-minute chaos.
+
+**Bridge, 0:20 to 0:25**
+On-screen: `The bottleneck is coordination.`
+Voiceover: The bottleneck is not ideas. It is coordination.
+
+**CTA, 0:25 to 0:30**
+On-screen: `Next reel: the fix`
+Voiceover: In the next reel, I will show you the fix, a demo-first pipeline that actually moves.
+
+### Shotlist
+1. Cursor jumping between intake form, document, Slack or chat, task board, calendar.
+2. Tight crop on duplicate notes and stale status markers.
+3. Timeline or board slipping past a deadline.
+4. Hard cut to bold text, `The bottleneck is coordination.`
+
+### Caption
+Most GTM teams do not have a content problem. They have a handoff problem.
+
+Intake lives in one place. Strategy in another. Content in another. Launch in another.
+
+That works right until you need speed.
+
+Follow for reel 2, I will show the system that turns that chaos into one moving pipeline.
+
+---
+
+## Reel 2, Fix, 30 to 45 seconds
+
+### Working title
+Run `/ship` once and the launch starts moving
+
+### Hook
+Run `/ship` once, and the GTM pipeline starts moving from intake to launch.
+
+### Script
+**Hook, 0:00 to 0:03**
+On-screen: `Run /ship once.`
+Voiceover: Run `/ship` once, and the pipeline starts moving.
+
+**Demo start, 0:03 to 0:12**
+On-screen: dashboard boot, active run created, coordinator view
+Voiceover: The coordinator reads the ticket, routes the work by stage, and keeps the whole run moving instead of waiting on one person to manually push it forward.
+
+**Named agents, 0:12 to 0:24**
+On-screen: strategist, content, growth, nurture, closer, launcher, analyst, critic
+Voiceover: Strategy handles positioning. Content builds the assets. Growth wires capture. Nurture handles MailerLite. Launch checks credentials. Critic and analyst gate quality before anything ships.
+
+**Money shot, 0:24 to 0:36**
+On-screen: stage map lighting up, cards moving left to right, approvals landing
+Voiceover: The money shot is this, not one isolated prompt, but the whole chain, intake to launch, with named agents coordinating the handoffs.
+
+**Offer bridge, 0:36 to 0:42**
+On-screen: `Open source install -> newsletter -> course`
+Voiceover: For open source, the path is simple, install the tool, join the newsletter, then convert into the course.
+
+**CTA, 0:42 to 0:45**
+On-screen: `Watch the full demo`
+Voiceover: If you want the full walkthrough, watch the demo and grab the course waitlist.
+
+### Shotlist
+1. Terminal or command palette running `/ship`.
+2. Dashboard render with active stages.
+3. Quick flashes of each named agent role.
+4. Pipeline graph or kanban flow moving in sequence.
+5. Final CTA card with course price anchor.
+
+### Caption
+This is the part most AI demos miss.
+
+The win is not one agent writing one asset.
+
+The win is intake, strategy, content, capture, nurture, closing, and launch moving as one system.
+
+That is what `/ship` is built to do.
+
+---
+
+## Reel 3, Architecture, 45 to 60 seconds
+
+### Working title
+The architecture behind `/ship`
+
+### Hook
+If you want repeatable launches, you need stage gates, owners, and one visible pipeline.
+
+### Script
+**Hook, 0:00 to 0:04**
+On-screen: full pipeline diagram
+Voiceover: If you want repeatable launches, you need stage gates, owners, and one visible pipeline.
+
+**Map the stages, 0:04 to 0:20**
+On-screen: `idea -> validate -> strategy -> awareness -> lead capture -> nurture -> closing -> launch -> measure`
+Voiceover: `/ship` maps the whole GTM path, from idea and validation, into strategy, awareness, lead capture, nurture, closing, launch, and measure.
+
+**Explain why it matters, 0:20 to 0:34**
+On-screen: blockers and approvals appearing at each gate
+Voiceover: Every stage has a job, an owner, and a gate. That means fewer hidden blockers, less duplicated work, and a launch process you can actually inspect.
+
+**OSS conversion model, 0:34 to 0:48**
+On-screen: `GitHub install -> newsletter -> $497 course`
+Voiceover: For open source, the funnel is built in. The repo earns attention, the newsletter builds trust, and the $497 course monetizes the system behind the demo.
+
+**Close, 0:48 to 0:57**
+On-screen: repo, newsletter, course page visual stack
+Voiceover: So the architecture is not just operational. It is commercial. It turns demo attention into a repeatable offer path.
+
+**CTA, 0:57 to 1:00**
+On-screen: `Install /ship. Join the course waitlist.`
+Voiceover: Install `/ship`, then join the waitlist if you want the full operating system.
+
+### Shotlist
+1. Full-screen architecture diagram.
+2. Step-by-step stage highlight animation.
+3. Gate overlays for critic, analyst, and credential checks.
+4. Repo star or install moment, then newsletter, then course card.
+
+### Caption
+A lot of people ask what sits behind `/ship`.
+
+It is not one prompt.
+It is not one dashboard.
+It is a staged GTM operating system with visible owners and visible gates.
+
+That is how you turn open source attention into something that actually sells.
+
+---
+
+## Long-format script, 3 to 5 minutes
+
+### Title
+The demo-first GTM system behind `/ship`
+
+If your GTM still feels chaotic, it is probably not because your team lacks effort. It is because your work is fragmented.
+
+A lead enters through one form. Positioning lives in a document. Content gets drafted in chat. Launch happens in a board. Follow-up gets patched into email later. Every part exists, but the handoffs are invisible, so the system feels busy while the launch stays slow.
+
+That is the problem `/ship` is designed to fix.
+
+The core idea is simple. Instead of treating GTM like a pile of isolated tasks, treat it like a pipeline with stages, owners, and gates.
+
+So when you run `/ship`, the coordinator reads the ticket and starts routing the work. Strategy gets the positioning right. Content creates the awareness assets. Growth wires lead capture. Nurture handles the MailerLite sequence. Closer shapes the sales angle. Launcher checks credential health before anything goes live. Critic and analyst stop low-quality work from shipping.
+
+That is the demo-first part. You can see the pipeline move. You can see where the work sits. You can see who owns the next decision.
+
+And this matters because most AI demos are still too narrow. They show one agent doing one clever thing. That is interesting, but it is not enough to run a launch. Real launches break in the handoffs.
+
+What we want is a system where intake, strategy, awareness, lead capture, nurture, closing, launch, and measurement all connect. That is the difference between a cool tool and an operating system.
+
+For `/ship`, the commercial path is built around open source. The repo is the top of funnel. The demo proves the workflow. The newsletter deepens trust and keeps the conversation alive. Then the $497 course sells the implementation layer, the playbooks, templates, and operating model behind the visible demo.
+
+So the open source project is not separate from the business model. It is the front door.
+
+That is why the architecture matters. If the pipeline is visible, reliable, and demoable, it does more than make execution cleaner. It makes the product easier to understand, easier to share, and easier to buy.
+
+If you want to see it in action, install `/ship`. If you want the full system, join the waitlist for the $497 course.
+
+---
+
+## Newsletter draft
+
+### Subject line options
+1. The GTM handoff problem
+2. Run `/ship` once
+3. Demo-first GTM, finally
+
+### Preview text
+The problem is not more tools. It is disconnected handoffs.
+
+### Body
+Most GTM teams do not fail because they lack ideas.
+
+They fail because intake, strategy, content, launch, and follow-up all live in different places.
+
+That creates a fake sense of progress. Everyone is working, but the pipeline is fragmented, so launches move slower than they should.
+
+That is the problem behind `/ship`.
+
+The project is built around a simple idea, run the GTM system as a visible pipeline instead of a pile of disconnected tasks.
+
+When the pipeline is clear, you can actually see what is blocked, what is next, and what is ready to ship.
+
+That is also why we are leaning demo-first.
+
+The open source repo shows the workflow.
+The newsletter goes deeper on how it works.
+The $497 course will package the implementation system for teams who want the whole playbook.
+
+If you want to see the operating model, start with the repo.
+If you want the deeper rollout when it drops, join the waitlist.
+
+CTA: Install `/ship` and join the course waitlist.
+
+---
+
+## README CTA copy
+
+### Hero-support option
+Run `/ship` once and watch the GTM pipeline move from intake to launch.
+
+### Mid-page CTA option
+Open source first. Demo first. Install `/ship`, see the workflow, then join the course waitlist if you want the full operating system.
+
+### Bottom CTA option
+If the demo clicks for you, the next step is simple: install `/ship`, join the newsletter, and grab the $497 course when it opens.
+
+### Short button copy options
+- Install `/ship`
+- Watch the demo
+- Join the waitlist
+- Get the course