The Problem
A cross-functional project had stalled. The web team needed final copy for a set of competitor comparison pages before design could move forward, and the content structure had open questions eating up bandwidth. I’d committed to delivering at least one page by end of day. By the end of the evening we’d shipped seven — and Claude had turned the workflow into a reusable skill, so I’d never have to run it by hand again.The Approach
Each comparison page needs the same things: verified competitor pricing, an accurate feature matrix, proof points from real sales deals, and copy that sounds like the brand without sacrificing SEO. I had internal competitive battlecards with field intel — deal sizes, customer quotes, objection patterns. My job was to point Claude at that institutional knowledge and decide what “good” looked like; its job was to combine it with fresh external research and produce something a web team could build from. Claude designed a four-phase pipeline: research (read the battlecard, pull the current live page from the CMS API, run fresh web research for pricing and features), draft (write a 12-section outline from a proven template), publish (push to the team’s Notion workspace, update the internal battlecard, update the sales team’s reference cards, create tracking tickets), and notify (draft a Slack post for the sales channel). The architectural call it made — the one that mattered — was what runs in parallel versus sequentially. Research and drafting fan out: background agents per competitor, simultaneously. But publishing to external systems (Notion, Linear, Slack) needs credentials those background agents don’t inherit, so that stayed sequential in the main session.What Happened
The first page took the longest — Claude drafted it the slow way, one pass, before the pipeline existed. The research it ran caught a pricing error that had been live on our own site for months: the competitor’s pricing was flat-rate, not per-user as we’d been stating. That’s exactly why fresh verification matters — a prospect who knows the competitor’s real pricing would dismiss the whole page. The second page went faster because Claude applied the lessons from the first: read the battlecard deeply before external research (its first pass had skipped seven named sales wins that made far stronger proof points than generic claims), apply the brand voice from the start instead of retrofitting it, and use the product’s branded feature name when comparing recording capabilities. By the third, the pattern was stable enough to parallelize. Five research agents ran at once, then five drafting agents, each reading the first two pages as references. They produced complete outlines with the right structure and voice. The system-dependent work — publishing, ticket creation, battlecard updates — ran in the main thread, where the credentials live. One surprise the research surfaced: three of our live comparison pages had copy-paste contamination from a different competitor’s template — FAQ answers naming the wrong company. The kind of thing that quietly erodes trust with any informed visitor, and it only showed up because Claude was systematically pulling and auditing every page from the CMS. The brand-voice calibration was its own problem. Our voice says “lead with the human, not the feature.” SEO says “lead with the answer.” They only actually collide in one place: the opening sentence of each content card, where the hero needs to be answer-first for AI-search extraction. Feature tables are structural — voice doesn’t apply. Differentiator cards and FAQ answers have room for warmth without hurting extractability. We landed around 55-60% voice adherence — enough to feel like us, not so much that it reads like a brand page instead of an evaluation resource.What I Learned
The biggest insight was that the research loop should be bidirectional. Fresh competitor research doesn’t just feed the comparison page — it feeds back into the internal battlecard and the sales team’s reference cards. When the research found a competitor had shipped five features our battlecard didn’t mention, that correction needed to propagate everywhere, not just to the website. Having Claude codify the workflow into a reusable skill means that bidirectional refresh now happens by default next time, instead of something I have to remember to ask for.Drafted by my Claude from our working session. I approved it before it went up.