Refresh Help Center screenshots and screencasts after UI changes

A GitHub pull request merges flow can start a repository-targeted agent after a PR is merged into main. The agent can inspect the PR diff, decide whether customer-facing UI changed, locate the relevant Help Center sections, update the draft text, and capture replacement screenshots or screencasts from a supplied dev or staging app. The flow itself filters by repository and base branch; the agent makes the UI relevance decision. Captures require the changed UI to be deployed to a reachable environment and a usable test login. Public publication remains a separate review step.

Before you start

• Locate the merged PR or relevant commit range, the Help Center article IDs and the old screenshots or videos. Confirm the changed UI is deployed to a capture-safe dev, staging or production environment. Code alone cannot verify the rendered interface.

• Provide the full environment URL, expected route and UI state, plus a dedicated test account. Supply credentials privately or through a secret prompt when requested, not in article text, a public URL or source control. The browser must be permitted to reach that host. If SSO, MFA or a network restriction prevents login, arrange a human-assisted sign-in or a permitted test environment.

• Use predictable sample data and remove or mask customer names, email addresses, tokens and notifications. Confirm the agent has repository, Docs, browser_open, browser_snapshot, browser_act, browser_screenshot, browser_record and insert_document_artifact access as needed. Browser tools may not be available in every edition.

Set up the post-merge flow

1. Connect GitHub and make the repository available to the workspace. In Automation → Agents, create a custom agent that can target a repository. Give it get_pull_request_diff, focused repository read tools, Docs search and read tools, and, if you want it to edit drafts, Docs edit tools. Give it browser open, snapshot, act, screenshot and recording tools, plus insert_document_artifact if it should embed captures. Configure an approval policy that fits your publishing process.

2. In Automation → Flows → New flow → Build a custom flow, name the flow, for example Refresh Help Center UI after merge. Under When, choose GitHub pull request merges. Set repository is to the connected owner/repo and base branch is to main.

3. Under then, choose Start an agent run and select that agent. Under on, select a specific repository and choose the same repository. GitHub PR triggers require an explicit target. Review the summary and create the flow.

4. Open the flow's Recent runs or Automation → Activity after a test merge. Confirm the run received the repository, PR number, base branch and head branch, then that it retrieved the actual PR diff. Do not infer the merged change from an arbitrary checkout of main.

Do not put “UI files changed” in a semantic condition and assume it will inspect the diff. A semantic condition evaluates event details; the agent must read the changed files to decide whether UI, labels, routes or workflows changed. If nothing relevant changed, it should stop with a no-update report. A merge event also does not prove that staging already runs the merged commit. If deployment lags, have the run pause or report the needed environment instead of recapturing old UI.

Agent instructions to adapt

For the triggering merged GitHub PR, verify the repository, PR number and base branch, then read the PR diff. Identify customer-visible UI changes and the affected screens, routes, labels, roles and interactions. If there is no relevant UI change, report no Help Center update needed. Search the Help Center space for existing articles, read the precise sections and media blocks, and compare their claims with the diff and deployed UI. If relevant coverage exists, regenerate only the affected section or blocks, preserving unaffected text and links. If coverage is absent, create a draft in the appropriate Help Center collection if authorized, or report the proposed article and outline. For each article, record its document ID, changed claim or visual, and evidence. If the intended staging URL or safe test login is missing, request it privately and pause capture. Never record credentials. Verify the environment contains the merged UI before editing. Capture screenshots or short recordings with sample data and embed approved artifacts by their returned artifact_id. If editing or embedding is unavailable, return precise proposed changes and artifacts for a document-targeted or human follow-up. Do not remove old media until the new block renders. Do not publish. Report changed documents, captures, skipped pages and unresolved differences.

For unattended execution, the URL, reachable environment, safe test login, browser host permission and agent tools must already be available through an approved mechanism. Do not assume Helpin stores reusable browser credentials or that a sign-in persists between runs. Never store a password in the flow name, instructions, repository or public Docs. A secret prompt or interactive login pauses the run for a person. If the merged UI is not yet deployed to the supplied URL, report that fact and rerun after deployment rather than capturing the old interface.

Identify affected pages

1. Identify the PR or commit range and inspect its diff. List changed screens, routes, labels, dialogs and multi-step interactions. If the code changed but the deployed environment has not, wait for deployment rather than capturing the old UI.

2. Search the Help Center space for the feature name and both old and new UI labels. Open candidate articles and note the exact step, image or video block that is stale. Inspect the public snapshot too, because a draft may differ from what readers see.

3. Make a capture checklist with the article ID, route, test account role, sample state, viewport, expected action sequence and desired output. Capture only visuals that actually need replacement.

Capture replacement media

1. Give the agent the staging URL and capture checklist. It calls browser_open, inspects the page snapshot, signs in with the test account using browser_act, navigates to the requested route and refreshes the snapshot after navigation. If authentication or the UI state fails, it should stop and report that instead of fabricating media.

2. Verify the new label, release version, user role, sample data and viewport against the article. For a screenshot, call browser_screenshot with a relevant element selector or viewport. A selected element is preferable to a pixel-imprecise AI redraw when exact UI text matters.

3. For a screencast, call browser_record with start, perform the documented actions with browser_act, then call browser_record with stop. The stopped recording is a private MP4 artifact. Review the captured sequence for idle gaps, pop-ups, unexpected account data and a clear start and end state.

4. Show the captures in the run chat for review. Obtain a fresh capture if the deployed version, steps or sample data are wrong. Do not assume the browser session or login will persist into a later run.

Replace media in Docs

After writing or editing the article text, use insert_document_artifact with the target document_id, the exact artifact_id returned by browser_screenshot or the stopped browser_record, an accessible description, and optionally a caption and after_block_id to place it beside the relevant step. Verify that the tool succeeded and the image or video block renders. A chat artifact is not automatically embedded. Pasting a filename, artifact_ref, URL or Markdown link into the document only creates text. If insertion is unavailable, report that the document is text-only and hand off the artifact for a manual editor workflow. Remove the old media only after the replacement has been reviewed.

For a manual screenshot, insert an Image block, upload or paste the image and set a caption. For a hosted screencast, use the Video block with a supported provider URL, such as Loom, Vimeo, YouTube or Wistia. A hosted video's playback and privacy settings must permit public viewing. See Images and file attachments and Video and rich embeds.

Review and release

1. Have a product reviewer compare the updated instructions and captures with the deployed UI. Check labels, click order, role-specific states, descriptions, captions, public media permissions, links and mobile layout.

2. If the release is not customer-visible, keep the updated document as a draft or proposal. A merged commit is not proof that the Help Center should describe the new UI yet.

3. Once the UI is live for the intended audience, publish or republish the article. Docs edits do not change the public snapshot. Open the public URL in a signed-out browser and play the video or inspect the screenshot. Check other affected articles for old visuals.

Example assignment: Compare merged PR 123 in owner/repo with our published Help Center guide to inviting teammates. The new UI is deployed at the staging URL I provide. Ask privately for the test account, sign in, record only the invite interaction, and capture the final confirmation. Return both artifacts in chat for review; then update the named article's text and insert approved artifacts using their IDs. Do not publish. Report any difference between source, staging and the published page. Replace these placeholders with your own PR, repository, URL and article.

What the flow automates: merged-PR detection, diff inspection, relevance triage, matching articles, authorized draft edits and capture attempts on a verified environment. It does not guarantee a matching article exists, that a merge is deployed, that login can be automated, or that the media is fit for publication. Review the draft and artifacts, then republish when the UI is customer-visible. See Review Help Center docs for every new PR to main for the pre-merge variant.