zendesk-mcp-server: Skill for Claude Code

Functional validation plan — author protocol

A code change is not "done" when the unit tests pass. Someone who did not write the code must be able to exercise the feature end-to-end and confirm it behaves as claimed. This skill produces the brief that lets them do that.

When to apply

• Whenever you produce an implementation plan that changes MCP-runtime- observable behaviour: the plan must include a functional validation plan as a first-class section, not an afterthought.
• Whenever you land a feature or bugfix whose behaviour is observable at MCP-server runtime (auth flows, transports, tool surface, resources, prompts, persistence, timing).

Skip for changes with no MCP-runtime-observable behaviour: pure docs, comments, formatting, and pure tooling / dev-tooling (build scripts, the typecheck/lint/format setup, dev-only scripts, CI, release automation) — those are covered by the standard gates (pnpm typecheck / pnpm check / pnpm test

• CI), not a third-party functional pass. Say so explicitly rather than silently omitting the plan.

Hard rules

• Independent validator. Write the plan FOR someone other than the implementer — another agent (e.g. the local executor) or a human. Don't assume it shares your conversation context: spell out the state to manipulate and how to observe results. Independence is about context, not identity: every agent here posts under the same human's GitHub account, so a report is not the author's just because it carries the author's login. Judge it on its evidence, and leave the "does this count" call to the repository owner — stating the role behind a run once is enough.
• Assume a fully ready environment — don't make the validator build it. The validator's session is already on the PR branch, in a live checkout, with the MCP server running and authenticated and its tools loaded as mcp__<server>__* (--mode all). So the plan must NOT ask the validator to:
  • check out / fetch / clone / pull the branch (it's already on it — at most, capture git rev-parse HEAD to name the SHA);
  • build, install, or start the server (pnpm …, transport choices, pnpm mcp:live, other scripts/);
  • locate or configure credentials, tokens, or the base URL (a valid token is already wired into the running server and reused by any sanctioned script).