AI-Powered Documentation for Product Releases
I designed and built an AI workflow that turns product releases into help articles. A Claude Code skill, connected to the company’s product-tracking and brand systems, drafts updated Intercom articles in English and Portuguese whenever work is marked complete, ready for a person to review and publish.
Senior Product Designer
2026
Challenge
A compliance issue and a client escalation meant renaming Audit Logs to Activities across Pipefy. Every help article that used the term had to change too.
I rewrote the first article by hand: every mention, step, table and screenshot, then all of it again in Portuguese. With around 300 articles and squads shipping every week, manual updates couldn’t keep up.
Process
Pipefy already had two internal skills I could build on. Product-OS, created by a PM, is where squads log initiatives as backlog, doing or complete. Design-OS, created by the design principal, holds the brand guidelines, tone of voice and copy rules. The question became: what if “complete” could trigger the docs update?
I built a Claude Code skill that connects both to Intercom through its MCP. When a deliverable is marked complete, the skill finds the affected articles, or decides a new one is needed. It drafts the update in English and Portuguese, follows the Design-OS copy rules, and saves it as a draft. It never publishes: a person always reviews first. I worked with the PM behind Product-OS and got my Merge Requests approved through GitHub.
I tested with dry runs before touching Intercom’s UI, then piloted the skill with a group of colleagues. Setup was the main friction, so I walked testers through it and wrote setup documentation.
Results
In its first dry run, the skill flagged the AI Agent Logs article as out of step with the product. The article said only Pipe Admins could see logs, when any member with read access can, and it left out newly shipped tracing features. I shared the findings with the Agents squad, and the skill drafted the corrected article that’s now live.
I presented the skill to the 100+ person product team. Afterwards, colleagues kept messaging me, eager to test it, a clear sign of how much the team needed it. What took me two hours by hand became a draft in minutes, plus a review.
What I'd carry forward
First, the best automation hangs off a signal people already produce. Squads were already marking work complete in Product-OS, so nobody had to change how they worked for the docs to stay current.
Second, keeping a person in the loop was a design decision, not a limitation. Saving drafts only, never publishing, is what made colleagues trust the skill enough to use it.
Third, adoption is part of the product, and the work isn’t finished. Most of my time with testers went into setup, not output, so next time I’d design onboarding from day one. The next features would be a notification telling the approver a draft is waiting, and a companion skill that automatically takes screenshots of the interface to go with each article. Replacing outdated screenshots was half of the manual work that started this project, so automating it would close the loop.