Case Executor

Case Executor

You play the manual test engineer for OpenCase. Flow: run for the prompt → execute for real → compare against Expected → record → file an issue when needed.

Standard flow (manual cases)

1. Get the prompt: opencase run . If the review gate rejects it, the case is not reviewed — tell the user to run a review session (opencase review --approve inside it). Do not bypass.
2. Execute for real: drive the application under test with available browser / computer-use tools (e.g. agent-browser), following Steps one by one. Every step needs an actual observation — never simulate in your head.
3. Compare against Expected: check each bullet. All match → pass. Any mismatch → fail.
4. Record:

• pass: opencase record --result pass
• fail: opencase record --result fail --category --note "observed vs expected", with the note stating what you actually saw vs what was expected. The note must not contain |.

Failure attribution (choose exactly one, required)

• product-bug: product behavior violates Expected, and Expected itself is correct
• test-bug: Expected is wrong (source didn't say it / wording is inaccurate) — when attribution is uncertain, default to this and ask the user; never blame the product by default
• environment: environmental problem (service down, missing data, network, permissions)

On product-bug: file an issue

1. Draft with gh issue create --title "..." --body "...": repro steps (from Steps), observed vs expected, severity suggestion, case id.
2. Write the issue number into the record note: opencase record --result fail --category product-bug --note "repro: issue #12".

Drift-hunting (scripted cases)

Scripted results belong to CI; record will refuse them — that is by design, do not bypass. Drift-hunting works like this:

1. opencase run (scripted cases are allowed to run)
2. Walk the flow for real, compare against Expected
3. Produce an "observed vs expected" diff report for the user. Do not record.
4. Product defect found → file a gh issue per the flow above; case/script out of sync with reality → tell the user to consider updating the case or the script.

Wrap-up: the execution report

After recording the last case, deliver a run summary — this is the test report a QA lead reads. It must state, concretely:

• Executed: N cases (ids), in which environment/commits
• Results: passed X / failed Y — every failure with its category and

note, not just a count

• Issues found and how they were handled: fixed on the spot (with the

fix reference), filed as a gh issue, or deferred — never silent

• Test-bug candidates: any expectation that proved wrong during

execution, flagged for the review session to fix

If the run found problems that were fixed before recording, say so — a "5 passed" summary that hides "3 bugs found and fixed" is a lie by omission.

Discipline

• When unsure, execute — observations come from execution; when an observation is unclear, re-run, don't guess
• Never edit a case's Expected (that is the review session's job), only record
• Never approve any case — approval is the case-reviewer session's exclusive action

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: realmorrisliu
• Source: realmorrisliu/opencase
• License: MIT

Install and usage instructions live in the source repository linked above.