بنقرة واحدة
testing-joyride
// Test Joyride features in the examples workspace. Covers output terminal verification, who-tracking, REPL log queries, and evaluation result validation. Use when: testing Joyride features.
// Test Joyride features in the examples workspace. Covers output terminal verification, who-tracking, REPL log queries, and evaluation result validation. Use when: testing Joyride features.
Joyride core — REPL evaluation, async patterns, VS Code API access, Flares, JS interop, and available libraries. Use when: working with Joyride evaluation, writing ClojureScript in any Joyride context, creating Flares/WebViews, exploring VS Code APIs via the REPL, or using joyride_evaluate_code / joyride_request_human_input tools.
Joyride User scope scripting — scripts and source files in ~/.config/joyride/. Covers user activation scripts, global keyboard shortcuts, disposable management, and npm dependencies. Use when: creating or editing User scripts/source files, setting up user_activate.cljs, or configuring global keybindings.
Joyride Workspace scope scripting — scripts and source files in <workspace>/.joyride/. Covers workspace activation, project-specific automation, workspace vs user scope precedence, and team sharing. Use when: creating or editing Workspace scripts/source files, setting up workspace_activate.cljs, or building project-specific automation.
One-time migration: modernize a Joyride project's copilot-instructions.md to use bundled skills instead of duplicated API docs or fetch URLs. Use when: the instructions file tells you to check for migration, or the user asks about updating their Joyride AI context.
Joyride extension internals — subsystem contracts, state architecture, activation sequences, and namespace reference. Use when: modifying core extension code, debugging state issues, working with app-db or SCI context, understanding activation or script execution flow, investigating nREPL or when-context behavior, or working with the output or disposable system.
| name | testing-joyride |
| description | Test Joyride features in the examples workspace. Covers output terminal verification, who-tracking, REPL log queries, and evaluation result validation. Use when: testing Joyride features. |
Structured testing patterns for verifying Joyride features in the examples workspace. This skill is a living document — test areas are added as features are developed and verified.
who slugsEach test area uses a dedicated who slug. When querying the REPL log, filter by the slug you used — entries from other slugs (other agents, the human ui, previous test runs) will not appear in filtered results. This is by design, but means a query for the wrong slug returns nothing even when entries exist.
The joyride_evaluate_code tool returns result, stdout, stderr directly. But the REPL Output Log (clojure_repl_output_log) is the authoritative record of what happened — it captures categorized entries (evaluatedCode, evaluationResults, evaluationOutput, evaluationErrorOutput) with who attribution and timestamps. Always cross-check against the log when verifying features.
awaitResult deliberatelyawaitResult: true for expressions where you need the unwrapped resultawaitResult: false for expressions that throw or produce side effects you want to observe without hangingVerifies that evaluations appear in the Joyride Output terminal with correct who badges, and that the REPL log captures all output categories with consistent attribution.
who slugevaluatedCode and evaluationResults entries exist with correct who, ns, and repl-session-key: "joyride"(do (println "test-stdout") 42) with awaitResult: truestdout field in tool response contains "test-stdout\n"evaluationOutput entry with the stdout text and correct whoawaitResult: false:
(do
(println "stdout-line")
(binding [*print-fn* *print-err-fn*]
(println "stderr-line"))
(throw (ex-info "thrown-error" {:test true})))
stdout: "stdout-line\n" and stderr: "stderr-line\n"evaluationOutput (stdout), evaluationErrorOutput (stderr), evaluationErrorOutput (thrown error), all with same whootherWhosSinceLast: ["B"]otherWhosSinceLast (no intervening evaluator)otherWhosSinceLast: ["ui"]Use a single dedicated slug for an expression that produces stdout, stderr, and a thrown error simultaneously. Query the log and confirm every entry carries the same who value. This catches attribution bugs where output streams lose their evaluator identity.
All tests above should also pass when Calva is not connected to the REPL. The Joyride REPL and Backseat Driver log operate independently of Calva's nREPL connection.