# Case Executor

> Execute OpenCase test cases (agent manual testing): fetch the execution prompt with run, operate the application under test for real with browser/computer-use tools, judge pass/fail against Expected line by line, and record a dated, attributed execution record; when the failure is a product bug, draft an issue with gh. Also used for drift-hunting on scripted cases. Use when the user asks to "exec…

- **Type:** Skill
- **Install:** `agentstack add skill-realmorrisliu-opencase-case-executor`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [realmorrisliu](https://agentstack.voostack.com/s/realmorrisliu)
- **Installs:** 0
- **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [realmorrisliu](https://github.com/realmorrisliu)
- **Source:** https://github.com/realmorrisliu/opencase/tree/main/skills/case-executor

## Install

```sh
agentstack add skill-realmorrisliu-opencase-case-executor
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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](https://github.com/realmorrisliu)
- **Source:** [realmorrisliu/opencase](https://github.com/realmorrisliu/opencase)
- **License:** MIT

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-realmorrisliu-opencase-case-executor
- Seller: https://agentstack.voostack.com/s/realmorrisliu
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.