القائمة
Run a Selenium test in visible (non-headless) mode with slowdown so the user can watch it. Use when user wants to demo or visually watch a Selenium test or mentions /demo command.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | demo |
| description | Run a Selenium test in visible (non-headless) mode with slowdown so the user can watch it. Use when user wants to demo or visually watch a Selenium test or mentions /demo command. |
/demo should_display_board_with_columns
/demo CreateTaskPageTest.should_display_create_task_form
/demo CreateTaskPageTest # Run all tests in class
/demo # Run all frontend Selenium tests
Temporarily modifies Selenium configuration to run browser tests visibly with delays, so the user can watch the test execute in real time. All changes are reverted after the test completes (even on failure).
Read ProductSpecification/technology.md for:
tech-profile block → resolve backend concern to .claude/tech/{backend}/templates/acceptance/ for file paths and language conventionsRead .claude/tech/{backend}/templates/acceptance/ to find the UI test base class and Browser statements class paths and conventions.
Read ports from infrastructure/.env:
source infrastructure/.env
Locate the UI test base class and Browser statements class using tech profile template conventions.
UI test base class:
--window-size argument so the visible window fits the host display. The headless default (e.g. 1920,1080) often equals the full screen resolution; in non-headless mode the compositor cannot place a full-screen-sized window with decorations and Chrome dies on connect (session deleted ... not connected to DevTools / NoSuchSessionException at the first interaction). Use a size comfortably smaller than the screen (e.g. 1280,800). Revert this with the other demo changes.Browser statements class:
infrastructure/scripts/stop-backend.shinfrastructure/scripts/run-backend.sh (background)/run-frontend if not)Resolve the argument to a test filter using the acceptance test command pattern from Conventions table.
| Argument | Filter |
|---|---|
should_method_name | Filter to *.ClassName.should_method_name (search test files to resolve class) |
ClassName.should_method_name | Filter to *.ClassName.should_method_name |
ClassName | Filter to *.ClassName |
| (none) | Run all frontend acceptance tests |
Use a generous timeout (180s) since delays add up.
After the test finishes (pass or fail), revert both files to their original state — undo all changes from step 2.
Report whether the test passed or failed. If it failed, include the error output.
/demo completesReview the latest work unit with fresh, unnarrowed eyes and surface any problem it contains as follow-ups. Use after a work-unit commit, or when the user runs /agent-review.
Continue working on a story or task by reading progress.md, executing the next work unit, and updating progress. Use when user wants to resume story/task work or mentions /continue command.
Preview the planned design for a scenario before writing tests. Shows domain model changes, usecase patterns, and key design choices. Use before red-usecase to get user approval on the implementation approach. If the user rejects the design, offers to discuss inline or escalate to /architecture for a full ADR.
Write a journey summary capturing noteworthy moments (predictions, decisions, surprises, mistakes, quirks). Runs automatically the moment the agent observes something worth noting during work, and manually before /clear or /compact as a final sweep. Idempotent — skips entries already recorded. Use when the agent observes a noteworthy moment, before clearing context, or when the user mentions /handoff.
Re-explain the last thing in plain words. Use ONLY when the user explicitly types /plain or asks to "explain that simply / in plain words / like I'm not an expert". Never invoke on your own initiative — this is a manual button the user presses when something was hard to follow.
Imagine the incident a just-shipped work unit would cause and surface unguarded gaps as follow-ups. Use after a work-unit commit, or when the user runs /premortem.