discourse-screenshots
- Repo stars 47,169
- Author updated Live
- Author repo discourse
- Domain
- Design
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @discourse · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Env read
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: discourse-screenshots
description: Capture screenshots of the local Discourse site across the two core themes (Foundation, Horizon)…
category: design
runtime: no special runtime
---
# discourse-screenshots output preview
## PART A: Task fit
- Use case: Capture screenshots of the local Discourse site across the two core themes (Foundation, Horizon) and color modes (light, dark). Use when the user asks for "screenshots of themes", "light/dark mode shots", or similar..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “How it works / Matrix (default) / How to run” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Capture screenshots of the local Discourse site across the two core themes (Foundation, Horizon) and color modes (light, dark). Use when the user asks for "screenshots of themes", "light/dark mode shots", or similar.”.
- **02** When the source has headings, the agent prioritizes “How it works / Matrix (default) / How to run” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, read environment variables; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, read environment variables; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/tmp`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, read environment variables.
Start with a small task and check whether the result follows “How it works / Matrix (default) / How to run”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: discourse-screenshots
description: Capture screenshots of the local Discourse site across the two core themes (Foundation, Horizon)…
category: design
source: discourse/discourse
---
# discourse-screenshots
## When to use
- Capture screenshots of the local Discourse site across the two core themes (Foundation, Horizon) and color modes (ligh…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “How it works / Matrix (default) / How to run” and keep inference separate from source facts.
- read files, write/modify files, read environment variables; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "discourse-screenshots" {
input -> user goal + target files + boundaries + acceptance criteria
context -> How it works / Matrix (default) / How to run
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files, read environment variables | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Discourse screenshots
Drives a system spec (spec/system/theme_screenshots_spec.rb) that discovers all system specs containing screenshot_marker marker calls, runs them under each combination of theme × device × color mode, and outputs PNGs plus a single compare.html viewer.
How it works
Spec authors place screenshot_marker(label: "my-label") at the moment they want to capture. The orchestrator auto-discovers those specs and runs only the it blocks that contain a marker, skipping everything else. The only: kwarg restricts a capture to one device leg:
screenshot_marker(label: "search-menu", only: :desktop)
Output files: tmp/theme-screenshots/raw/{device}-{theme}-{mode}-{label}.png
Comparison viewer: tmp/theme-screenshots/compare.html (tabs for device and color mode)
Matrix (default)
| Theme | Modes | Devices |
|---|---|---|
| Foundation | light, dark | desktop, mobile |
| Horizon | light, dark | desktop, mobile |
How to run
TAKE_SCREENSHOTS=1 LOAD_PLUGINS=1 bin/rspec spec/system/theme_screenshots_spec.rb
LOAD_PLUGINS=1 is always included so chat routes work.
Arguments (env vars)
| Var | Default | Purpose |
|---|---|---|
TAKE_SCREENSHOTS |
(required) | Must be 1 for the spec to run. |
LOAD_PLUGINS |
1 |
Always set so chat and plugin routes work. |
SCREENSHOTS_DIR |
tmp/theme-screenshots |
Where PNGs and the HTML viewer are written. |
SCREENSHOTS_MODES |
light,dark |
Comma-separated color modes. |
SCREENSHOTS_DEVICES |
desktop,mobile |
Comma-separated devices. Mobile uses Playwright WebKit. |
SCREENSHOTS_THEMES |
foundation,horizon |
Comma-separated built-in theme names to include. |
SCREENSHOTS_THEME_URL |
(unset) | Git URL of a remote theme to install and add to the matrix. |
SCREENSHOTS_THEME_NAME |
repo name | Filename label for the remote/extra theme. |
SCREENSHOTS_SUBSET |
(unset) | Substring filter on marker labels — only captures markers whose label contains this string. |
Examples
# Default — all themes × light/dark × desktop/mobile
TAKE_SCREENSHOTS=1 LOAD_PLUGINS=1 bin/rspec spec/system/theme_screenshots_spec.rb
# Desktop, light mode only
TAKE_SCREENSHOTS=1 LOAD_PLUGINS=1 SCREENSHOTS_DEVICES=desktop SCREENSHOTS_MODES=light \
bin/rspec spec/system/theme_screenshots_spec.rb
# Foundation only, dark only
TAKE_SCREENSHOTS=1 LOAD_PLUGINS=1 SCREENSHOTS_THEMES=foundation SCREENSHOTS_MODES=dark \
bin/rspec spec/system/theme_screenshots_spec.rb
# Add a remote theme alongside the built-ins
TAKE_SCREENSHOTS=1 LOAD_PLUGINS=1 \
SCREENSHOTS_THEME_URL=https://github.com/org/my-theme \
SCREENSHOTS_THEME_NAME=my-theme \
bin/rspec spec/system/theme_screenshots_spec.rb
# Only capture markers whose label contains "topic"
TAKE_SCREENSHOTS=1 LOAD_PLUGINS=1 SCREENSHOTS_SUBSET=topic \
bin/rspec spec/system/theme_screenshots_spec.rb
Invocation instructions
When this skill is invoked:
- Build the command from
$ARGUMENTS. If no arguments are given, use the default matrix. - Parse free-form args into env vars (composable — handle multiple at once):
- "dark only" / "light only" →
SCREENSHOTS_MODES=… - "desktop only" / "mobile only" →
SCREENSHOTS_DEVICES=… - "foundation only" / "just horizon" →
SCREENSHOTS_THEMES=… - A git URL for a theme →
SCREENSHOTS_THEME_URL=…; also setSCREENSHOTS_THEME_NAME=<label>if the user provides a name - A label substring (e.g. "only topic markers", "just signup") →
SCREENSHOTS_SUBSET=… - A directory path (e.g. "save to /tmp/foo") →
SCREENSHOTS_DIR=…
- "dark only" / "light only" →
- Always include
LOAD_PLUGINS=1. - Always prefix with
TAKE_SCREENSHOTS=1. - If the user requests an unknown built-in theme name, tell them only
foundationandhorizonare supported — for any other theme useSCREENSHOTS_THEME_URL. - Run via
bin/rspec spec/system/theme_screenshots_spec.rbfrom the repo root. - After the run, list the files saved (
lson the raw dir) and surface thecompare.htmlpath to the user. Show failures ifbin/rspecexits non-zero.
Adding markers to a spec
In any system spec, include ThemeScreenshotMarker and call screenshot_marker at the point you want to capture:
describe "Search" do
include ThemeScreenshotMarker
it "shows search results" do
visit "/search"
search_page.type_in_search("test")
search_page.click_search_button
screenshot_marker(label: "search-results") # captured on all devices
screenshot_marker(label: "search-menu", only: :desktop) # desktop only
end
end
The include ThemeScreenshotMarker line is required — without it, screenshot_marker is undefined when the spec is run directly. The orchestrator also auto-includes it as a safety net, but relying on that alone will break direct spec runs.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review