Last week we asked Claude a deceptively simple question: "We've shipped four minor versions. What workflow have we actually been running?"
It wasn't a prompt hunt. It wasn't a template exercise. The question was about extraction — looking at v1.0 through v1.4.0, every PR, every release note, every issue triage — and pulling out the shape of how we actually work.
The answer came back in seven phases:
Build → Ship → Plan → Execute → Release → Document → Market
Each phase was tied to something specific that had happened in the repo. Not an aspiration. Not a framework someone invented at a conference. A structure that was already running, just never named.
Extraction, not invention
Most "AI-designed workflow" pieces you read are about the AI generating something from a blank page. That's the wrong direction.
What Claude did here was the opposite. It read:
- The commit graph (where does branching actually happen?)
- The release notes (what made it into a tagged version vs. what got held back?)
- Issue comments (how do we triage? who decides scope?)
- The CLI extraction diff from v1.2 (why did we carve that piece out?)
Then it handed back the pattern that was already load-bearing. "You've been doing Plan-Execute-Release as a tight loop after every CLI change. You document at release time. You market at minor versions, not patches." That's not insight Claude invented — it's insight Claude surfaced.
The difference matters. The workflow is trustworthy because it's descriptive, not prescriptive. When a new engineer joins, we don't hand them a nice diagram that won't survive contact with reality. We hand them the pattern the team is already running, named.
The artifact
From that single conversation to a reusable repo:
→ github.com/cc4-marketing/cc4-opensource
It's small on purpose. Seven README sections, one per phase. Each section has a real example from our history — "here's what Execute looked like on the DMG packaging branch," "here's what Release looked like when we bumped the appcast." No theory. Just the shape of what we shipped, cleaned up enough to be handed off.
What made the Document phase usable
Here's the part I want to be honest about. The seven-phase shape came from Claude. But one phase in particular — Document — got its teeth from somewhere else: the Compound Engineering work at Every.to .
Their /ce:compound convention is the idea that you don't document what you built. You document why a non-obvious problem was solved the way it was. The workflow's title, the WIP limit, the rollback recipe — those are the ten-line docs. But the why — "we tried X and it deadlocked under load, so we switched to Y" — that's what makes a workflow survive staff turnover.
We cribbed that discipline directly. Every phase in the cc4-opensource README has a WHY section tucked into it. Removing it made the readme 40% shorter. Keeping it made the workflow something a third engineer could actually pick up without a handoff meeting.
It's a quiet contribution. Compound engineering doesn't announce itself in a commit message. It shows up in the sixth month, when someone grep's the docs for "why did we pick this path" and finds a real answer.
Why marketing teams should care
Three patterns we're taking into every team's onboarding now:
1. Ask AI to describe, not invent. If you have three months of work, don't start a new workflow doc from scratch. Dump the artifacts — commits, release notes, meeting transcripts, Slack threads — and ask: what pattern keeps appearing? The answer is usually sitting in the work already, just unnamed.
2. Write the why, not just the what. Every phase in our workflow doc has a "Why this decision" paragraph. That's the Every discipline. It's the difference between documentation that rots in six months and documentation that compounds in value.
3. One artifact, two audiences. The cc4-opensource README serves as both an engineering handbook and a marketing story. Engineers read phase 3 and learn how we plan. Marketers read the same phase and see the structure behind our launches. Same words, different readers. That's leverage.
The question worth keeping
Before starting any new process doc, whether it's for content production, a launch sequence, or a release train, ask AI one question first:
"Based on what we've already done, what patterns keep appearing? And how do we formalize them?"
The answer is usually closer than a blank page. And better, because it's already been stress-tested by reality.
Alice Marketer is an AI Marketing Strategist at CC4.Marketing. She ships workflow tooling you can actually use.