Cultivate Method had one tool. As of today it has two.
Bushel is the launch-artefact generator. It reads a validated Winnow recommendation and produces the nine audience-specific copy artefacts a release needs: a blog announcement, a customer email, a website brief, a support agent FAQ, a sales one-pager, a sales deck, an internal Slack post, an internal email, and an internal FAQ. One bundle per launch. Every line carrying its provenance.
Why a second tool
Winnow stops at the recommendation. That's the right place to stop — the synthesis discipline that runs through the methodology (foundations as constraints; opportunities before recommendations; baselines change only when reality changes) doesn't extend into copywriting. Writing a blog post and writing a support FAQ are different jobs. The team's voice, the audience's vocabulary, the channel's constraints all matter in ways the recommendation layer doesn't try to reason about.
So Bushel sits downstream of Winnow's recommend step. The recommendation is the
seed; Bushel takes that seed plus the user stories that supported its delivery,
plus four Bushel-specific foundations (brand voice, audience personas, channel
inventory, a launch playbook), and produces the bundle.
Three audiences, nine artefacts
The catalogue is fixed at nine for v1 — not a pick-and-choose menu. The discipline is the constraint:
- For the customer: a blog announcement, a customer email (variant pair of the blog), and a website brief — a brief for the team to apply to product / pricing pages, not replacement copy.
- For support and sales: an internal agent-facing FAQ, an in-deal sales one-pager, and a five-to-eight-slide markdown deck.
- For the internal team: a cross-team Slack post, a cross-team email (variant pair of the Slack), and a cross-team FAQ.
Every launch produces the same nine cuts. A team that ships four launches a quarter generates thirty-six artefacts; the consistency comes from running the same playbook nine times, not from anyone trying to remember what the blog said while writing the support FAQ.
Provenance, twice
This is the part we cared about most.
The on-disk artefact carries machine-readable YAML frontmatter at the top: the recommendation id, the user stories included, the foundations that framed the voice, the playbook, the model, the run id, the timestamp. The pipeline reads this; lint reads this; audit reads this. It's the same provenance discipline Winnow runs at the recommendation layer, carried through to the launch layer.
The body of the artefact carries a human-readable footer rendering the same fields as plain markdown. When the copy gets pasted into Notion, Slack, or a Google Doc and the frontmatter gets stripped, the footer survives. The trail back to the recommendation and the foundations goes with the copy wherever it lands.
This matters in practice. Six months after a launch, someone asks why the sales one-pager said what it said. With provenance baked into both places, the answer is a one-line trail: this recommendation, these stories, that brand voice file at that commit. No archaeology.
Replace, don't edit
Bushel never edits an artefact incrementally. Every regenerate is a complete bundle.
If the brand voice file changes, you re-run generation. If a user story gets revised,
you re-run generation. If you don't like the blog post draft, you tweak the playbook
and re-run generation. The prior versions move to .history/<run_id>/ automatically
with a manifest mapping each archived artefact to the run that produced it.
The discipline matches Winnow's: humans don't edit the LLM-maintained outputs by hand because hand-edits drift from the inputs. The inputs are where the work happens — the foundations, the playbook, the launch notes. The outputs are regenerated.
Two surfaces
The CLI is the canonical surface for scripted and batch flows:
bushel init
bushel launch create <rec-path>
bushel launch select <slug>
bushel generate <slug>
bushel export <slug>
bushel launch ship <slug>
The Web UI handles the eyeball-and-distribute steps: per-artefact previews, Copy + Download buttons that surface body-only markdown (frontmatter stripped, provenance footer kept), and a launch-level Download all (zip). Either surface talks to the same workspace. The CLI is the canonical path; the Web UI is the comfortable sidekick.
Both share bushel lint: a static health check that flags foundation stubs still
carrying TODO scaffolds, malformed launch frontmatter, orphan recommendations,
selected-but-missing user stories, and provenance mismatches. No LLM cost; safe to
run from CI or a pre-commit hook.
What this completes
Bushel closes the methodology cycle. Winnow ingests raw evidence and synthesises
it into validated recommendations. Bushel takes those recommendations and ships
them. The delivery outcomes — what landed, what didn't, what customers actually
said in response — flow back into Winnow's raw evidence stream, and the cycle
closes through Winnow's reconcile pipeline.
Nothing about Bushel changes how Winnow runs. They share three things — the
foundations directory, the cultivate_shared library, and the Cultivate
methodology — and otherwise sit as independent tools. Either tool installs
standalone; running both is a deliberate cycle-closing choice, not a coupling.
Where to start
The Bushel reference docs are public:
- The Bushel README is the full reference for every command and route.
- The CLI user guide is a plain-English terminal walkthrough.
- The Web UI user guide is the browser walkthrough.
- The tools/bushel page on this site is the shorter "what is this" view.
The next milestone is the public Bushel repository — the mechanical split from the
Cultivate Method Toolset monorepo into a standalone bushel GitHub repo, with PyPI
publishing under pip install bushel. The code is v1 today; the split is the
plumbing.
The pattern's been quiet for a year while we built. With Bushel online, the cycle is complete, and the rest is using it.