A while back a customer asked me, half-joking, whether Arkweaver could just write its own "what we shipped" post. We put it off because the honest version of that feature is hard: you can't fake customer quotes for work no customer asked for. This week we shipped the honest version, plus a handful of things that make setup a lot less of a chore.
TL;DR
Arkweaver now generates a weekly release note from your merged GitHub pull requests, matching shipped work back to the customers who asked for it. Deliverables can publish straight to Notion, with new pages only and nothing overwritten. A single "Apply Default Launch Workflows" button sets up minor, major, and flagship launches sized by how many customers actually asked for a feature. Automation rules now run on live demand counts instead of dollar-value ranges nobody configured. Onboarding is faster, and a batch of rendering and permissions fixes make deliverables and shared templates behave the way you'd expect.
How does Arkweaver turn shipped work into release notes?
Connect a read-only GitHub integration and every Monday Arkweaver reads the trailing week of merged pull requests, then hands you one release note to review, send, and publish.
The part I care about is how it sorts the work. It splits merges into two piles. The first is work customers actually asked for, matched against features Arkweaver already knows about from your calls. Those get marked Built, which fires the same status automation you already use and drafts the newsletter and website write-ups from the prompts that ship with the product. The second pile is everything nobody asked for, so infra, polish, unrequested changes. Those have no customer evidence behind them, so they use a different set of prompts that know that and leave the customer-voice sections out rather than inventing a quote.
A couple of deliberate limits, because I think they matter more than the feature itself. GitHub only sets a feature's status when you don't have an issue tracker connected. If you've wired up Jira or Linear, that's a deliberate statement of what shipped, and GitHub stays the fallback. And a merge never creates a feature. We looked at treating GitHub as an issue-tracker provider, which would have mapped every merge onto a feature 1:1, and you'd have ended up with thirty junk rows a week. No thanks.
You review the whole thing from an approvals panel at the top of Activity. Nothing goes out until you say so.
How do I publish deliverables to Notion?
There's a new Storage integration category, and Notion is the first destination in it. Connect it with OAuth, and any deliverable your rules already create gets written to the Notion page or database you picked, with a link back to the Arkweaver feature, problem, or product line it came from.
The rule I'd flag: publishing only ever creates new pages. Nothing already in your workspace is updated, archived, or deleted. Regenerate a deliverable and you get a new dated page next to the old one, not an overwrite. That's not a promise in the docs, it's enforced in the code — the Notion client has no update, archive, or delete method, and a test fails CI if anyone ever adds one. I'd rather you trust the integration than have to audit it.
This is for teams who already live in Notion and don't want product context stranded inside Arkweaver.
What do the new launch workflow defaults do?
One button, "Apply Default Launch Workflows," fills in your whole automation setup from a single definition, so you're not hand-filling four cards and guessing which deliverables belong where.
It sets up three sizes of launch, sized by how many customers asked for a feature:
- Minor runs on every feature: user stories at Planned, a one-pager at In Progress. Two deliverables.
- Major kicks in when several customers asked. It adds a PRD, audience definition, positioning and messaging, a GTM brief, a sales battlecard, a training outline, a LinkedIn post, and a newsletter write-up. Ten total.
- Flagship is for the features the most customers asked for. It adds customer research, a blog post, and a feature website write-up. All thirteen.
The thresholds aren't hardcoded. They're read from your own demand distribution when you apply, so "Major" means the same relative thing whether you have forty customers or four thousand. Honestly this is the setup I wish we'd shipped first, because most groups either never configured automations or set them once and couldn't tell later what they'd chosen.
Why did we switch automation rules to demand counts?
A feature's interested-customer count is now a rule scope, sitting alongside Linear labels in Automations, and it drives the entire feature lifecycle rather than only the Built status.
Bands stack, so a feature at 12 customers picks up both the 5+ and the 10+ template sets. We retired the old dollar-value range rules at the same time, because they only ever worked on Built status and nobody had actually configured them. Label and demand scopes also got their own status-email copy, and status emails are now edited as plain text instead of raw HTML, which is one less way to make a mess.
What changed in onboarding?
There's a new conversational onboarding wizard at /onboarding/start, rolling out behind a flag for now. The existing step wizard is still the default and hasn't changed.
The goal was less friction to the same payoff, not a chat gimmick. Connecting your calls already starts analysis with a 90-day backfill, so the engineering question now runs over a live progress line instead of after a dead "here are some facts while you wait" screen. Deliverables and automation come pre-selected with the consequence spelled out and one confirm, rather than as open questions. Six screens became four. The payoff itself, real customer names and a verbatim quote matched against a shipped feature, is untouched, and onboarding still finishes at that payoff so nobody gets stranded at the end.
Smaller fixes worth knowing about
A few things that were quietly annoying:
- The Close the Loop page used to hide the entire feature stream if you hadn't shipped in the last seven days. One staging group had 8 features in progress and 15 customers requesting them and still saw a blank page. The stream and queued-emails panel now render whenever there's something to show.
- Generated deliverables were rendering as one run-on block with no space between paragraphs. Fixed the CSS and tightened the prompt's markdown rules so labelled sections like "Proof Point:" sit on their own lines.
- Owners and admins can now edit and delete the 13 seeded default templates, which were previously locked because they're owned by a system user. Templates you haven't shared with your group stay private to you.
- The MCP setup page got a cleanup: Claude Code is now the first supported client with a claude mcp add command, Codex and Cursor snippets are labelled with real file paths, and the starter prompts are pre-filled with your most-requested feature names so they run as written.
FAQ
Does Arkweaver need write access to my GitHub repo?
No. The GitHub release notes integration is read-only. It reads the trailing week's merged pull requests to build the release note and never writes to your repository.
Will publishing to Notion overwrite my existing pages?
No. Notion publishing only ever creates new pages. Regenerating a deliverable produces a new dated page next to the previous one, and nothing in your workspace is updated, archived, or deleted.
How are major and flagship launches decided?
By how many customers asked for the feature, read from your own demand distribution at the moment you apply the workflows. The thresholds aren't fixed numbers, so the launch tiers scale with the size of your customer base.
Is the new conversational onboarding wizard live for everyone?
Not yet. It's behind a flag, and the existing step wizard remains the default until a group is switched over. No existing onboarding behavior changes until then.
What happened to the dollar-value automation rules?
We retired them. They only worked on the Built status and almost nobody had configured them. Demand-based scopes replace them and drive the full feature lifecycle instead.