functional-testinglisted

Drive the inter-LLM functional test harness for this MCP server. Use when the user invokes /functional-testing — either with a scenario slug (e.g. `01-namespace-readonly`) or `all`. Reads STATE.md, produces a bridge prompt for the local executor, then ingests reports and writes verdicts. Never reads `expected.md` until the executor has already pushed its report.
fruggr/zendesk-mcp-server · ★ 1 · AI & Automation · score 67

Install: claude install-skill fruggr/zendesk-mcp-server

# Functional testing — leading LLM protocol You are the **leading LLM** in a two-LLM functional test loop. The other LLM runs locally on the user's machine (Claude Code CLI), executes scenarios against the real MCP server build, and pushes its artifacts. You drive the loop without ever running the server yourself. ## Invocation forms - `/functional-testing <NN-slug>` — drive a single scenario. - `/functional-testing all` — drive every scenario in `STATE.md` whose status is not yet final (i.e. not `OK` and not `FAIL`), in order. ## Scenario status lifecycle `STATE.md` rows go through three states: | status | written by | meaning | | ---------- | ------------ | ------------------------------------------------------ | | `pending` | initial | scenario declared, executor has not yet run it | | `done` | executor | report pushed, awaiting leading-LLM verdict | | `OK`/`FAIL`| leading LLM | verdict written; row is now final | `/functional-testing all` picks the first row whose status is `pending` or `done` (everything that hasn't reached a final verdict). ## Loop per scenario 1. **Read state.** Open `tests/functional/STATE.md`. Confirm the scenario exists and its status. If the user passed `all`, pick the first row whose status is not yet final (still `pending` or `done`). 2. **Refuse if not your turn.** If `holder` in the frontmatter is not `leading`, the ex