Menu
Upload a screenshot file and get back a shareable CloudFront URL
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | screenshots |
| description | Upload a screenshot file and get back a shareable CloudFront URL |
| disable-model-invocation | true |
| argument-hint | <file-path> [file-path...] |
Upload a local PNG (or JPG/WEBP/GIF) to the sandbox-screenshots service and surface the returned CloudFront URL back to the user. This is the canonical procedure any agent should follow whenever it needs to share an image — issue comments, design audits, QA reports, ad-hoc replies.
Screenshot capture (Playwright, viewport handling, dev server bootstrap) is unchanged and still lives in scripts/capture_screenshots.py. This skill picks up after the PNG exists on disk.
upload-screenshot must be reachableBefore uploading, confirm the CLI is reachable:
command -v upload-screenshot
If it resolves, use the bare command in the Upload section below.
$PATHinstall.sh adds the venv to $PATH via ~/.bashrc, but non-interactive agent subshells do not source ~/.bashrc. If command -v upload-screenshot returns nothing, check whether the binary exists at the venv path:
ls ~/git/sandbox-screenshots/.venv/bin/upload-screenshot
If that file exists, the install ran — the subshell just cannot see the updated $PATH. Use the absolute path for every upload-screenshot invocation in this skill (and substitute it everywhere this skill writes upload-screenshot):
~/git/sandbox-screenshots/.venv/bin/upload-screenshot /path/to/screenshot.png
If ~/git/sandbox-screenshots/.venv/bin/upload-screenshot does not exist, do NOT auto-install. Stop and fail loudly with a one-line instruction for the operator:
upload-screenshot is not installed. Run ~/git/sandbox-screenshots/install.sh, then re-run this step.
Installation is a one-time human action. Agents must never write to the operator's shell config or run the install script on their behalf.
upload-screenshot /path/to/screenshot.png
The CLI prints JSON on stdout:
{"url":"https://d31nukezbn4e3o.cloudfront.net/YYYY/MM/DD/object.png","key":"YYYY/MM/DD/object.png"}
Return the url value to the user. If uploading multiple files, run the CLI once per file and collect each url.
For a URL-only output (no JSON wrapper), use:
upload-screenshot --url-only /path/to/screenshot.png
Supported content types: image/png, image/jpeg, image/webp, image/gif. The CLI infers the content type from the file extension. Uploaded objects are deleted automatically by an S3 lifecycle rule after 60 days, so these URLs are suitable for throw-away sharing only.
The CLI loads SCREENSHOT_UPLOAD_TOKEN from ~/git/sandbox-screenshots/.env. That file is the only place the token should ever exist on disk.
Never paste the literal SCREENSHOT_UPLOAD_TOKEN value into:
You may reference the variable name SCREENSHOT_UPLOAD_TOKEN in prose when explaining this rule. You may never reproduce its value.
Capture a page, upload the resulting PNG, return the URL:
uv run python scripts/capture_screenshots.py --urls / --output .tmp/screenshots
upload-screenshot .tmp/screenshots/home.png
Then surface the printed url back to the user.
The tester agent captures a batch of pages, uploads each PNG, and posts a single ## Screenshots comment to the issue. See .claude/agents/tester.md Step 7 for the exact comment format.
The designer agent embeds CloudFront URLs (returned by upload-screenshot) in the "Screenshots" sub-section of the audit report. See .claude/agents/designer.md for the report template.
Screenshots used to be pushed to an internal hosting path and shared via long internal URLs. That mechanism is retired. The sandbox-screenshots service is the only supported upload path going forward. Agents that share an image any other way will produce broken links.
Foundational entrypoint for the AI Shipping Labs PRODUCTION HTTP API. Use to learn how to authenticate, where the token/config lives, how to discover the full endpoint surface via the OpenAPI spec, the safe-write protocol, and the cross-cutting surfaces — integration settings / env config, content sync, and background-task observability. For user/CRM endpoints use `ai-shipping-labs-users`; for events and workshops use `ai-shipping-labs-events`.
Run the full development loop - pick issues, implement, QA, PM review, commit, push, repeat. Works for both new features (open issues) and Playwright test implementation (needs-testing issues).
Update a member's own AI Shipping Labs sprint plan through the member Plans API. Use when a member wants to list plans, fetch one plan, download Markdown, sync a Markdown plan back to the platform, toggle progress, or edit weeks, checkpoints, deliverables, next steps, resources, and week notes through /member-api/v1 using a member-owned API key.
Use when asked to update AI Shipping Labs sprint plans from Zoom, Slack, onboarding, questionnaire, or meeting notes; add or import missing sprint plans; clean plan task formatting; or fetch/check people registered for a production event.
Use when asked to create or update an AI Shipping Labs sprint plan from a member's submitted onboarding answers, CRM/user context, or member profile; includes fetching production onboarding data, drafting a markdown plan, importing it through the production plans API, and attaching internal context to the member profile/CRM.
Create and manage AI Shipping Labs events and workshops in production. Use when asked to "create an event", "schedule a workshop", "set up an event series", "add a Zoom event", "make a recurring event", "publish a workshop", cancel/reschedule an occurrence, or bulk-create Zoom meetings for a series. Events are created via the production API; workshops are git content synced from the workshops-content repo.