landing-proof-shots-maintainer
starsforks
How to install landing-proof-shots-maintainer?
undertone0809/rudder/landing-proof-shots-maintainer
$npx -y skills add Undertone0809/rudder --skill landing-proof-shots-maintainerUse 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.
SKILL.md
| 1 | # Landing Proof Shots Maintainer |
| 2 | |
| 3 | Use this skill to maintain a reliable, presentation-ready workflow for Rudder |
| 4 | landing-page and demo screenshots. |
| 5 | |
| 6 | This skill supports two operating modes and should surface both up front unless |
| 7 | the user already chose one: |
| 8 | |
| 9 | 1. capture mode: seed the org and take the screenshots for the user |
| 10 | 2. seed-only mode: seed the org and hand the environment back so the user can |
| 11 | take screenshots themselves |
| 12 | |
| 13 | Important: |
| 14 | |
| 15 | - both modes must use the landing-quality mock dataset maintained by |
| 16 | `mock-data-maintainer` |
| 17 | - seed-only mode is not a lighter fallback dataset |
| 18 | - do not substitute a small import, a partial org copy, or a simplified sample |
| 19 | when the user asked for the landing-shot dataset |
| 20 | |
| 21 | ## Use This Skill For |
| 22 | |
| 23 | - landing page screenshot generation |
| 24 | - demo-deck product stills |
| 25 | - seeding a realistic Rudder org for self-serve screenshots |
| 26 | - requests like: |
| 27 | - "mock some real-looking org data and screenshot it" |
| 28 | - "give me demo data and I'll screenshot it myself" |
| 29 | - "don't give me browser screenshots" |
| 30 | - "each major feature should have a screenshot" |
| 31 | - "include chat creating an issue" |
| 32 | - "show issues across multiple projects" |
| 33 | |
| 34 | ## Do Not Use This Skill For |
| 35 | |
| 36 | - ad hoc debugging screenshots where realism does not matter |
| 37 | - generic desktop screenshots outside Rudder |
| 38 | - narrow cropped captures of a single widget when the user asked for a page |
| 39 | - cases where the user only wants a one-off current state and no seeded data |
| 40 | |
| 41 | ## Core Outcome |
| 42 | |
| 43 | Produce one of these clean outcomes: |
| 44 | |
| 45 | - a full screenshot set the user can present directly |
| 46 | - a seeded dev/demo org with clear routes so the user can take those shots |
| 47 | |
| 48 | The underlying demo data should be the same in both modes and should come from |
| 49 | `mock-data-maintainer`: |
| 50 | |
| 51 | - same realistic projects, issues, agents, approvals, chat, costs, and org data |
| 52 | - same screenshot-worthy density and statefulness |
| 53 | - same readiness for major feature surfaces |
| 54 | |
| 55 | In both cases the baseline quality bar is: |
| 56 | |
| 57 | - no browser chrome |
| 58 | - no desktop wallpaper or OS overlays |
| 59 | - no stale or broken pages |
| 60 | - no obviously fake empty-state data |
| 61 | - full-page whole-app screenshots, not clipped subsections |
| 62 | |
| 63 | ## Default Placement |
| 64 | |
| 65 | Primary outputs usually go under: |
| 66 | |
| 67 | - `/tmp/rudder-landing-proof-shots/shots` |
| 68 | - `/tmp/rudder-landing-proof-shots/manifest.json` |
| 69 | |
| 70 | ## Required First Decision |
| 71 | |
| 72 | At the start, choose one mode: |
| 73 | |
| 74 | ### Mode A: Capture For The User |
| 75 | |
| 76 | Use when the user wants a finished screenshot bundle. |
| 77 | |
| 78 | Deliver: |
| 79 | |
| 80 | - seeded org |
| 81 | - screenshot files |
| 82 | - manifest |
| 83 | - final file list |
| 84 | |
| 85 | ### Mode B: Seed For User Self-Capture |
| 86 | |
| 87 | Use when the user wants you to prepare data but prefers to drive the capture. |
| 88 | |
| 89 | Deliver: |
| 90 | |
| 91 | - seeded org name and id |
| 92 | - base URL |
| 93 | - the exact routes worth opening |
| 94 | - any credentials or runtime notes required locally |
| 95 | |
| 96 | Do not keep capturing after switching into seed-only mode unless the user asks. |
| 97 | Do keep the seeded data at the same quality bar as capture mode. |
| 98 | |
| 99 | ## Default Workflow |
| 100 | |
| 101 | ### 1. Define The Surface List |
| 102 | |
| 103 | Map the request into a concrete screenshot set. |
| 104 | |
| 105 | Common default set: |
| 106 | |
| 107 | - dashboard |
| 108 | - chat proposal review |
| 109 | - chat created-issue state |
| 110 | - issue list |
| 111 | - issues across multiple projects |
| 112 | - approval review |
| 113 | - heartbeats |
| 114 | - costs |
| 115 | - org structure |
| 116 | |
| 117 | If the user asks for heavier issue coverage, seed more projects and cross-project |
| 118 | issue density before capture. |
| 119 | |
| 120 | ### 2. Seed An Isolated Demo Org |
| 121 | |
| 122 | Prefer the repository's existing mock-data seed/capture script: |
| 123 | |
| 124 | ```bash |
| 125 | LANDING_SHOTS_SKIP_CAPTURE=1 LANDING_SHOTS_HOLD_OPEN=1 \ |
| 126 | node cli/node_modules/tsx/dist/cli.mjs \ |
| 127 | .agents/skills/maintainer/mock-data-maintainer/scripts/capture-landing-proof-shots.ts |
| 128 | ``` |
| 129 | |
| 130 | Why: |
| 131 | |
| 132 | - it creates an isolated Rudder instance for landing shots |
| 133 | - it seeds realistic projects, agents, issues, approvals, chat, costs, and org data |
| 134 | - it avoids polluting the developer's normal local environment |
| 135 | |
| 136 | The legacy `scripts/capture-landing-proof-shots.ts` path is kept as a wrapper |
| 137 | for compatibility, but the dataset and implementation live under |
| 138 | `mock-data-maintainer`. |
| 139 | |
| 140 | If the user chose seed-only mode, this same seeded dataset is still the target. |
| 141 | Only the capture responsibility changes. |
| 142 | |
| 143 | Record: |
| 144 | |
| 145 | - `baseUrl` |
| 146 | - seeded org id and issue prefix |
| 147 | - chat id |
| 148 | - approval id |
| 149 | - output directory |
| 150 | |
| 151 | ### 3. Verify The Environment Before Capture |
| 152 | |
| 153 | Do not touch capture until the instance is confirmed alive. |
| 154 | |
| 155 | Check: |
| 156 | |
| 157 | ```bash |
| 158 | curl http://127.0.0.1:3101/api/health |
| 159 | curl -I http://127.0.0.1:3101/RUD/dashboard |
| 160 | ``` |
| 161 | |
| 162 | Rules: |
| 163 | |
| 164 | - if health fails, restore the seeded instance first |
| 165 | - do not keep debugging screenshots against a dead port |
| 166 | - prefer `127.0.0.1` when `localhost` behaves inconsistently in browser tooling |
| 167 | |
| 168 | ### 4. Capture The Entire App Page |
| 169 | |
| 170 | This is the most important constraint |
People who liked this also viewed
6 picksType
- paperclip-create-agentCreate new agents in Paperclip with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt/config, and submit a hSkillsJul 2026
- subagent-driven-developmentUse when executing implementation plans with independent tasks in the current sessionSkillsJul 2026
- dispatching-parallel-agentsUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependenciesSkillsJul 2026
- browser-act-skill-forgeForges reusable Skill packages (SKILL.md + scripts) from website exploration via browser-act — no re-exploration later. Use when: user wants a reusable Skill for any website, needs to understand a sitSkillsJul 2026
- wizardGenerate an interactive bash wizard that walks a human through a manual procedure — third-party setup, a one-off migration, an A→B state transition — opening URLs, capturing values, confirming each stSkillsJul 2026
- wonda-cliUsing the Wonda CLI to generate images, videos, music, and audio from the terminal — plus LinkedIn, Reddit, and X/Twitter research and automationSkillsJul 2026
