MockServer is a testing server and proxy that imitates APIs, records and changes network traffic, and deliberately introduces failures. It is for developers testing applications against unavailable dependencies, debugging requests, and checking how systems handle degraded services across several network protocols. The catalogue add-ons help operate, configure, and test MockServer.
Borrowing it
Nothing to install: this file belongs to mock-server/mockserver-monorepo. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/mock-server/mockserver-monorepo/master/.opencode/skills/review-spec/SKILL.mdgit clone --depth 1 https://github.com/mock-server/mockserver-monorepoWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/mock-server/mockserver-monorepo/review-spec)<a href="https://agentmods.dev/skills/mock-server/mockserver-monorepo/review-spec"><img src="https://agentmods.dev/badge/skills/mock-server/mockserver-monorepo/review-spec/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/mock-server/mockserver-monorepo/review-spec"><img src="https://agentmods.dev/badge/skills/mock-server/mockserver-monorepo/review-spec.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00051 | $0.01646 |
| Opus 5 | $0.00026 | $0.00823 |
| Sonnet 5 | $0.00010 | $0.00329 |
| Haiku 4.5 | $0.00005 | $0.00165 |
Grade A, and why
review-spec scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 198 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Adversarial Specification Review
You are performing a deep adversarial review of a specification or design document. Your job is to find defects, not to reassure the author. The spec is wrong until proven right.
Step 1: Load the Review Constitution
Read .opencode/rules/review-constitution.md in full. This is the 8-lens
framework you MUST apply. Do not skip any lens.
Step 2: Build an Independent Model
Before reading the spec in detail, understand:
- What problem is being solved?
- Who are the actors (users, systems, components)?
- What are the boundaries of the change?
- What existing behaviour might be affected?
Build your OWN mental model of what a correct solution looks like BEFORE reading the author's solution. This prevents anchoring bias.
Step 3: Read the Spec
Read the full specification. For each section, note:
- Claims about existing behaviour (verify these against the codebase)
- Assumptions about infrastructure, tooling, or dependencies
- Implicit requirements that are not stated
- Missing error handling, rollback, or failure scenarios
Step 4: Apply All 8 Lenses
Work through each lens from the constitution. For each lens:
- List the principles that are applicable to this spec
- Evaluate the spec against each applicable principle
- Record any violations as findings using the constitution's finding format
- If a lens is not applicable, state why
Lens Priority for Spec Reviews
Ambiguity (Lens 1) — highest priority for specs:
- Undefined domain terms (AMB-01)
- Vague requirements without RFC 2119 language (AMB-02)
- Missing numeric bounds and units (AMB-03)
- Incomplete conditional logic (AMB-04)
- Unspecified error message content (AMB-05)
- Control plane vs data plane distinction (AMB-08)
Incompleteness (Lens 2):
- Missing failure mode scenarios for external dependencies (INC-01)
- Missing validation rules for user inputs (INC-02)
- Incomplete state machine transitions (INC-03)
- Missing data lifecycle (create/read/update/delete/archive) (INC-04)
- Unspecified concurrency model (INC-05)
- Missing timeout values (INC-07)
- Missing pagination for list operations (INC-08)
- Missing consumer docs update (INC-11)
- Missing file inventory completeness check (INC-12)
- Missing Netty ByteBuf lifecycle specification (INC-13)
- Missing ring buffer sizing analysis (INC-14)
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 198 lines · 51 tokens per session scan A 459e44ad3a15
review-spec is a skill published in the GitHub repository mock-server/mockserver-monorepo (4,967 stars, last pushed today), licensed Apache-2.0. It adds 51 tokens to every session and 1,646 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
maintainer
This document encodes the project context, recurring patterns, and conventions needed to ship code, triage issues, and respond to users effectively. It is the entry point to the broader knowledge base in references/.
plano-agent-skills
Best practices for building agents and agentic applications with Plano, including configuration, routing, orchestration, guardrails, observability, and deployment.
plano-cli-operations
Apply Plano CLI best practices. Use for startup troubleshooting, cliagent workflows, and template-based project bootstrapping.
plano-config-fundamentals
Validate and fix Plano config fundamentals. Use for config versioning, listener types, provider registration, secrets handling, and startup validation failures.
plano-deployment-security
Apply Plano deployment and production security practices. Use for Docker networking, state storage choices, readiness checks, and environment-based secret handling.
plano-observability-debugging
Improve Plano tracing and debugging workflows. Use for sampling strategy, span attributes, and trace query-based root-cause analysis.