We only use cookies to enhance your experience. No cross-site tracking, no ads. Read our Cookie Policy.
Point your agent to your PM's feature demo video, and it writes the help center article, screenshots included.
Demo the feature the way you would explain it to a customer.
Give it the supercut link, feed it your style guide, and say where the article should live.
Intro, numbered steps, and a screenshot chosen for each one.
Record the feature demo video once and let your agent write the help center article. It reads the transcript and picks the frame that matters at each step, so the article arrives with the screenshots already in it.
Connected to your agent.
Connected to your agent.
Claude, Cursor, or similar.
Whoever knows the feature opens Supercut and demos it. That is usually the product manager, but the education team can record it just as well. It does not matter who owns it, as long as the supercut demo is shared with the team. You can blur anything sensitive, so real customer data is not revealed. If you are recording, make sure you cover:
The feature in one sentence, before any clicking.
The path through the product to get there.
What to click, in order, and what changes each time.
How the customer knows it worked.
Limits, the permissions needed, and the mistakes people make.
Give the supercut link to your agent, feed it your style guide, and prompt it to write a help center article in Intercom. It will pull everything it needs from the recording: the transcript and a frame from each step. Ask it to create a draft rather than publish. Agents are good at writing content, but it always needs a human review.
Your agent turns the demo into a draft article in Intercom, ready to be reviewed and published. It writes the intro and the numbered steps, picks a frame for each one, and keeps your product's own names for things. Anything you blurred in the recording stays blurred in the frames, so privacy and confidentiality are handled.
One recording, two formats. Publish the article and embed the supercut demo inside it. They can read the article, watch the demo, or ask the recording questions.
Record the demo, then paste this to your agent. Swap [SUPERCUT LINK] for your recording and [YOUR STYLE GUIDE] for your style guide skill or documentation.
Here is a supercut of a feature demo video: [SUPERCUT LINK]
Read it and write a help center article as a draft in Intercom.
Follow this style guide: [YOUR STYLE GUIDE]
1. Fetch the transcript for that recording.
2. Break the demo into numbered steps, in the order I did them. One step per action, not one step per sentence.
3. For each step, pull a frame from the second where I am doing that action. Use the transcript timestamps to pick the moment.
4. Write the article with these sections:
- Title: what the customer is trying to do, in their words rather than ours
- What this does: one or two lines, before any steps
- Numbered steps: what to click, and what changes each time
- What you should see: how the customer knows it worked
- If it does not work: limits, permissions, and the mistakes I flagged
Rules:
- Create it as a draft. Do not publish it.
- Match the voice and formatting in the style guide.
- Use the product's real names for screens, buttons and settings. Do not rename them.
- The frames are stills, not video. Do not describe animation or hover states unless I said them out loud.
- Write for a customer, not for the team. No internal shorthand and no jargon I did not use.
- If I did not explain something, leave it out rather than guessing.
- Keep it to what I actually demoed. Do not add features I did not show.
- When you are done, list the steps you wrote and anything I should re-record.The agent can only write what you demoed. Cover the elements above while you record and the article fills itself in.
Most product teams demo new features internally. Then the education or support team watches the recording and writes the article by hand. That handoff already works, it just costs someone an afternoon. This recipe keeps the handoff and drops the afternoon. The recording isn't the article, it's the source.
This is one of several things your agent can do across the two tools.
Record the bug happening. Your agent gets the transcript and frames, and the Linear ticket writes itself.
Explain how it should work, once. Your agent writes the stories your developers need to build it.
Record yourself doing the work once. Your agent picks it up and writes the documentation directly in your database.
Record your update. Your agent posts the summary, the action items, and links to the moments that matter.