How launches work

A launch in Buron is the loop that turns a code change into marketing assets. You ship a feature. An agent captures the context. Buron's curator clusters related changes into launches. Content agents generate the assets. No briefing meeting, no handoff doc, no two-week delay.

The problem launches solve

Marketing handoff is broken at every company under 50 people. An engineer ships a feature, writes a two-line commit message, merges the PR, and moves on. A week later someone asks "what did we ship?" and the answer requires archaeology: pull requests, Slack messages, pinging the engineer who's already deep in the next thing.

The result is predictable. Changelogs are incomplete. Blog posts are delayed by weeks. Social posts are vague because the person writing them didn't build the feature. Half of what ships never gets announced at all.

The problem isn't that teams lack marketing tools. It's the gap between the moment code ships and the moment marketing has enough context to act.

The loop

A launch has four stages:

1. Capture. The developer runs /launch in their editor (or it runs automatically in CI). The agent reads the diff, the PR thread, commit messages, code comments, test descriptions, everything the developer would otherwise have to explain in a meeting, and writes a structured source file.

2. Push. The source file is pushed to your team's knowledge layer in Buron. The developer's code never leaves their machine: only the markdown source reaches Buron.

3. Curate. Buron's curator agent clusters related sources into launches. Three PRs that shipped a new onboarding flow become one launch, not three. The curator assesses the launch tier (patch, minor, or major) based on what changed.

4. Generate. Content agents pick up the launch and produce assets from a constrained playbook: changelog entry for any launch, blog post for minor and above, social posts for major. Each agent reads your team's accumulated context: brand voice, prior launches, product docs. Quality compounds as the agents learn from corrections.

What makes it work

Capture at the source. Context is richest at the moment of shipping. Every hour of delay between merge and handoff degrades the quality of downstream content. /launch runs where the code lives, when the code ships.

Raw material, not finished copy. The source file is a dense dump: verbatim PR threads, commit messages, code comments, test descriptions. It doesn't write marketing copy. The content agents downstream synthesize the source into assets. Keeping the capture step raw means nothing is lost to premature compression.

Convention over configuration. The source file follows a rigid structure so every downstream agent can parse it reliably. Frontmatter carries the repo, branch, PR URL, and commit range. Body sections cover what shipped, the PR thread, code context, documentation references, edge cases, and assets.

What a source file looks like

The /launch skill writes a markdown file with typed frontmatter:

---
title: Add two-factor authentication
type: source
source_kind: changes
env: claude-code
repo: acme/webapp
branch: feat/2fa
pr_url: https://github.com/acme/webapp/pull/42
commit_range: abc1234..def5678
created: 2026-05-11
---

The body contains raw context: what shipped, the PR thread (verbatim), code comments, test names, screenshots, and open questions. Everything the content agents need to write accurate assets without talking to the developer.

CI automation

For teams that want every PR to file a source automatically, buron setup-ci generates a GitHub Actions workflow. The workflow runs on pull request events, installs the CLI, and invokes /launch through the team's chosen agent. Sources accumulate passively. The team ships PRs as normal, and marketing assets appear in the dashboard without anyone running a manual command.

Related docs

• File your first launch: run /launch on a real PR
• Automate launch filing: set up CI so every PR files a source
• Run Buron from CI: the underlying CI setup