Landing Proof Shots Maintainer

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:

1. capture mode: seed the org and take the screenshots for the user
2. 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