Use this skill to execute supplied CLI test cases without changing their commands, inputs, ordering, or assertions. It guides preparation, exercise, and validation case by case, then classifies results as passed, failed, blocked, or observed based on actual evidence.
Internal exact-case flow for cli-exercise. Preserves supplied commands, inputs, ordering, assertions, and output constraints.
Run score Not tested
See how to installThis skill provides a procedure for running supplied CLI tests while preserving the requester’s commands, inputs, order, case IDs, and expected conditions. Each case covers one behavior and proceeds through preparation, exercise, and validation before the next begins. Multiple commands may support preparation or validation, but if the case structure must change, the agent asks before splitting, reordering, or adding steps. It observes the actual screen before acting and does not reinterpret a test when an unexpected prompt appears. Results are judged against the specified expectations and actual observed state or output. Contradicted expectations are marked failed; cases that cannot be run or verified are blocked. Runs without correctness conditions are recorded as observations.
Use it to reproduce established CLI test cases faithfully and retain evidence for the results. It is useful when input values or order matter, when an error is the expected result, or when a case includes a write. This helps keep the supplied conditions distinct from what actually happened.
The entry skill must provide the preserved request, validated contract, preflight record, and approved effect scope. If these are missing, the agent returns to the entry procedure instead of filling gaps with assumptions. Authorized writes in a case must be performed as specified or reported as blocked. This skill uses a shared execution module and related skills for evidence and cleanup.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).
Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 26, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
Require the entry skill's preserved request, validated contracts, ready preflight receipt, and approved effect scope. If any is missing, return to the entry skill instead of filling gaps with assumptions.
Keep the caller's original case text. Turn supplied commands and interactions into the canonical actions in the contract. Keep test ordering and case IDs stable.
Each recording case covers one behavior, with at most one exercise invocation. Give it a very short behavior/outcome title, not an inventory of commands or flags. A supplied case may include multiple preparation or validation commands. If its exact steps conflict with this structure, ask before splitting, reordering, omitting, or adding anything. Explicit narrower coverage takes precedence over the default preparation/exercise/validation coverage.
If the caller specifies literal keys, preserve those keys. If they specify an option by name, a mechanical selector can locate it. Ask before inventing values or steps that materially affect the case. Do not add negative tests, extra metadata, new retries, or exploratory branches just because they seem useful.
Keep before/after conditions controlled: equivalent initial state, commands, geometry, data, and timing, with separately identified executables.
Use the shared run module. The exact-action gate must remain active for both live AI actions and generated controllers.
Execute each case's preparation, exercise, and validation in that order before starting the next case; approved cleanup can follow its validation. Do not batch phases across cases or later rearrange captured runs to suggest a different execution order. Preserve and clarify conflicting caller-supplied ordering.
Observe the real screen before actions. Condition-based waits can synchronize unspecified timing, but cannot replace or defeat a stated timing requirement. Never match an expected output merely because it appears in the typed command.
An unexpected prompt is not permission to reinterpret the test. Use only mechanical actions consistent with the supplied case. Otherwise pause, preserve evidence, and report what needs clarification.
If an authorized write is part of the case, execute it as specified or report blocked. Do not replace it with Cancel and claim that the case passed. Follow all applicable environment/tool policies.
Check every expectation against actual observations, with references to the appropriate state, output, file, or approved external readback. Do not rewrite the expectation to match the observed result.
Use failed for contradicted expectations and blocked for requirements that
could not be exercised or verified. An execution with no correctness assertion
is observed, not passed. A nonzero exit can pass an expected-error case;
exit zero cannot excuse a contradicted assertion.
Finish with evidence and cleanup.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
This dispatcher helps with GitHub Agentic Workflows by identifying whether a request is about design, creation, configuration, updates, debugging, or upgrades. It selects the matching workflow prompt or skill file so the agent can follow task-specific guidance.
Exercise a real command-line program with specified cases or a stated goal, then capture and verify the observed behavior. It produces local media evidence such as a session video, helping reviewers see what the command did without treating the recording as proof of general correctness.
Verify CLI exercise expectations against recorded evidence, render requested media, inspect the results, and return local artifacts with case outcomes. The workflow keeps failures visible and does not publish evidence by default.
Use this skill to explore a CLI goal by choosing observable checks within an approved scope. It guides the agent through preparation, one exercise, and immediate validation for each case, then helps report what the evidence established and what remained unreachable.
This internal module checks whether cli-exercise can use its required build, terminal, and media tools. When a dependency is missing, it identifies a suitable setup path and requires approval before installation, then rechecks readiness. It does not authorize recordings or other actions.
Run and record CLI exercise cases through a shared Go runtime and Tuistory adapter. The skill follows approved setup, exercise, validation, and cleanup phases, captures observed terminal behavior, and preserves execution evidence and chronology.