CONTENT CREATION

Flag Stale Doc Screenshots on Every UI Pull Request

When a PR changes front-end UI files, this workflow cross-references which docs screenshots depend on those components and posts a checklist comment listing the images…

CategoryContent Creation
Enginesim
Difficultyintermediate
Triggerevent
Steps5
Setup~15 min

How it runs

The automated pipeline, trigger to output.

  • TriggerPR opened or updatedGitHubGitHub
  • LogicFilter to UI component file changes
  • ActionLoad component-to-screenshot mapNotionNotion
  • LogicResolve affected screenshots; exit if none
  • OutputPost screenshot checklist as PR commentGitHubGitHub

What it does

Every time a pull request touches UI code, this workflow figures out which documentation screenshots are now at risk of being out of date and posts a review comment naming each one, so reviewers never merge a UI change that silently breaks the docs.

When to use it

Use it when your docs live alongside code and screenshots tend to rot after redesigns. Ideal for teams who want screenshot freshness enforced as part of code review instead of discovered by an angry customer weeks later.

How it works

  1. 1A GitHub pull request event fires when files change.
  2. 2The workflow inspects the changed file paths and keeps only the ones under your UI component directories.
  3. 3It loads a mapping (kept in a Notion database) of components to the doc screenshots that show them.
  4. 4A logic step resolves the changed components to the set of affected screenshot files.
  5. 5If the set is empty it exits quietly; otherwise it posts a GitHub PR comment with a checkbox list of every screenshot to re-capture and the page each appears on.

Set it up

What you configure once, before turning it on.

  1. 1
    Connect GitHubRepos, issues, pull requests, actions.
  2. 2
    Connect NotionPages, databases, comments.
  3. 3
    Set each agent's modelWe leave models unset so you pick the tier — fast + cheap, or top-quality.
  4. 4
    Tune it to your dataEdit the prompts, filters, and field mappings so it matches how your team works.
  5. 5
    Test, then turn it onRun once against a sample, confirm the output, then enable the trigger.

Run this workflow in your colony.

14-day trial. No DevOps. No Sales call. Provisioned in under a minute.