| name | landing-proof-shots-maintainer |
| description | Use when maintaining Rudder landing-page/demo screenshot workflows: seeding screenshot-ready demo orgs, capturing polished full-page app screenshots, producing screenshot manifests, or handing a seeded environment to the user for self-capture. |
Landing Proof Shots Maintainer
Use this skill to maintain a reliable, presentation-ready workflow for Rudder
landing-page and demo screenshots.
This skill supports two operating modes and should surface both up front unless
the user already chose one:
- capture mode: seed the org and take the screenshots for the user
- seed-only mode: seed the org and hand the environment back so the user can
take screenshots themselves
Important:
- both modes must use the landing-quality mock dataset maintained by
mock-data-maintainer
- seed-only mode is not a lighter fallback dataset
- do not substitute a small import, a partial org copy, or a simplified sample
when the user asked for the landing-shot dataset
Use This Skill For
- landing page screenshot generation
- demo-deck product stills
- seeding a realistic Rudder org for self-serve screenshots
- requests like:
- "mock some real-looking org data and screenshot it"
- "give me demo data and I'll screenshot it myself"
- "don't give me browser screenshots"
- "each major feature should have a screenshot"
- "include chat creating an issue"
- "show issues across multiple projects"
Do Not Use This Skill For
- ad hoc debugging screenshots where realism does not matter
- generic desktop screenshots outside Rudder
- narrow cropped captures of a single widget when the user asked for a page
- cases where the user only wants a one-off current state and no seeded data
Core Outcome
Produce one of these clean outcomes:
- a full screenshot set the user can present directly
- a seeded dev/demo org with clear routes so the user can take those shots
The underlying demo data should be the same in both modes and should come from
mock-data-maintainer:
- same realistic projects, issues, agents, approvals, chat, costs, and org data
- same screenshot-worthy density and statefulness
- same readiness for major feature surfaces
In both cases the baseline quality bar is:
- no browser chrome
- no desktop wallpaper or OS overlays
- no stale or broken pages
- no obviously fake empty-state data
- full-page whole-app screenshots, not clipped subsections
Default Placement
Primary outputs usually go under:
/tmp/rudder-landing-proof-shots/shots/tmp/rudder-landing-proof-shots/manifest.json
Required First Decision
At the start, choose one mode:
Mode A: Capture For The User
Use when the user wants a finished screenshot bundle.
Deliver:
- seeded org
- screenshot files
- manifest
- final file list
Mode B: Seed For User Self-Capture
Use when the user wants you to prepare data but prefers to drive the capture.
Deliver:
- seeded org name and id
- base URL
- the exact routes worth opening
- any credentials or runtime notes required locally
Do not keep capturing after switching into seed-only mode unless the user asks.
Do keep the seeded data at the same quality bar as capture mode.
Default Workflow
1. Define The Surface List
Map the request into a concrete screenshot set.
Common default set:
- dashboard
- chat proposal review
- chat created-issue state
- issue list
- issues across multiple projects
- approval review
- heartbeats
- costs
- org structure
If the user asks for heavier issue coverage, seed more projects and cross-project
issue density before capture.
2. Seed An Isolated Demo Org
Prefer the repository's existing mock-data seed/capture script:
LANDING_SHOTS_SKIP_CAPTURE=1 LANDING_SHOTS_HOLD_OPEN=1 \
node cli/node_modules/tsx/dist/cli.mjs \
.agents/skills/maintainer/mock-data-maintainer/scripts/capture-landing-proof-shots.ts
Why:
- it creates an isolated Rudder instance for landing shots
- it seeds realistic projects, agents, issues, approvals, chat, costs, and org data
- it avoids polluting the developer's normal local environment
The legacy scripts/capture-landing-proof-shots.ts path is kept as a wrapper
for compatibility, but the dataset and implementation live under
mock-data-maintainer.
If the user chose seed-only mode, this same seeded dataset is still the target.
Only the capture responsibility changes.
Record:
baseUrl- seeded org id and issue prefix
- chat id
- approval id
- output directory
3. Verify The Environment Before Capture
Do not touch capture until the instance is confirmed alive.
Check:
curl http://127.0.0.1:3101/api/health
curl -I http://127.0.0.1:3101/RUD/dashboard
Rules:
- if health fails, restore the seeded instance first
- do not keep debugging screenshots against a dead port
- prefer
127.0.0.1 when localhost behaves inconsistently in browser tooling
4. Capture The Entire App Page
This is the most important constraint.
When capturing screenshots:
- capture the whole Rudder page for that route
- include the full app shell for the state being presented
- avoid cropped component-only images
- avoid locator clips unless the user explicitly asked for a detail shot
What the user should see in the final PNG:
- the complete page surface
- correct layout, hierarchy, and surrounding context
- no browser tabs, URL bar, or other browser chrome
Wrong:
- only the chat panel
- only the issues table
- only a modal body
- a desktop region screenshot of a browser window
Right:
- the entire page route rendered as a clean app screenshot
5. Prefer App-Style Capture, Not Browser-Window Photos
Default capture path:
- Playwright
- system Chrome executable when needed
- page-level screenshot flow that preserves the whole app page
Avoid by default:
- manual desktop screen capture
- browser-window photos with URL bar or tabs
- monitor-region crops
6. Manufacture Stateful Screens Intentionally
Some screenshots require interaction first.
For chat issue creation:
- open the seeded chat
- submit the user request that should create an issue proposal
- wait for the proposal review block
- capture the full chat page in proposal state
- approve it
- wait for the "Created issue ..." state
- capture the full chat page again in created-issue state
For issue coverage:
- seed multiple projects when requested
- create enough issues that the page looks like a working org
- make sure the issue list visibly spans multiple projects when that is part of the ask
- capture the full issues page, not just the table region
7. Generate A Manifest
After capture, write a manifest so the bundle is inspectable and reusable.
Expected fields:
- generation timestamp
- base URL used
- screenshot filenames
- the mode used:
capture or seed-only
- short notes about the environment or method
8. Hand Off Clearly
For capture mode, return:
- the screenshot directory
- the final file list
- the manifest path
For seed-only mode, return:
- org name and id
- base URL
- the routes the user should open
- any caveat that materially affects local capture
Do not hand back a downgraded org here. The user should be able to capture the
same surfaces they would have received in capture mode.
Judgment Rules
Must Stay True
- screenshots must be presentation-ready
- data should look like a plausible operating organization
- screenshots must cover the user-requested major product surfaces
- chat and issue screenshots must show meaningful state, not empty shells
- issue-heavy pages should visibly span multiple projects when requested
- full-page whole-app capture beats clipped partial capture by default
What To Avoid
- continuing after the demo server has died
- using browser chrome screenshots when the user asked for app-style shots
- mistaking browser-launch problems for Rudder page failures
- clipping down to one component when the user asked for a page
- mixing unrelated personal browser state into the demo capture workflow
- treating seed-only mode as permission to use smaller or different data than the
landing-shot mock org
Troubleshooting
Health Checks Fail
- restart the isolated landing-shot seed instance
- do not debug capture before the app is reachable again
Browser Opens But Shows The Wrong Thing
- do not assume a new browser window was created successfully
- verify the actual page URL and route state before capture
- prefer direct Playwright navigation inside the capture flow
Capture Looks Like A Browser Screenshot
If the image includes:
- browser tabs
- the URL bar
- browser toolbars
- desktop wallpaper
- window thumbnails
- cropped-only content with missing page context
then the method is wrong for the task.
Switch back to clean whole-page app capture.
Bundled Playwright Browser Fails To Launch
- use system Chrome with
executablePath
- keep the same page-level capture flow
Output Expectations
Successful capture mode should leave:
- a full screenshot set in
/tmp/rudder-landing-proof-shots/shots
- a
manifest.json
- app-style PNGs ready for direct use in marketing or product presentation
Successful seed-only mode should leave:
- a live seeded Rudder org
- clear routes for self-serve capture
- enough realistic data that the user does not need more prep work first
Non-Goals
This skill is not responsible for:
- redesigning the UI before capture
- editing the landing page itself
- writing copy that explains the screenshots
Those can follow after the screenshot or seeding workflow if the user asks.
