Spider's Claude Code plugins - two surfaces, one marketplace, one philosophy
The two CLIs that ship with the coming release - spider and spider-mon - already make Spider accessible from a terminal.
Pointing an LLM at either of them and asking it to figure out the right invocation works, in the same way that pointing an LLM at any CLI works: well enough on simple questions, fragile on real workflows.
The two Claude Code plugins that ship alongside the CLIs solve the fragility.
They teach Claude the data model, the verbs, the conventions, and a set of investigation patterns purpose-built for Spider.
The same questions that takes five hand-prompted CLI calls in plain Claude Code become one skill invocation with a structured report.
What a Claude Code plugin is
Claude Code plugins are reusable bundles of skills, agents, and primer content (CLAUDE.md) that any user can install into their Claude Code session.
They are distributed through marketplaces - git repositories Claude Code knows how to add and pull from.
The model is closer to a VS Code extension marketplace than to a package manager: you add a marketplace once, then install any plugin from it by name.
The shapes inside a plugin are familiar:
- Skills are user-invocable workflows (
/skill-name). They translate a goal ("find slow endpoints in the last hour") into a sequence of tool calls and interpret the results. - Agents are autonomous workers Claude Code can dispatch (
spider-investigator,spider-mon-tuning-advisor). They run a full investigation on their own context, then return a structured report to the calling session. - CLAUDE.md is the primer: a domain-specific instruction file that gets loaded into every relevant session, teaching Claude the conventions of the system it's working with - the data model, the verb tree, the common pitfalls.
Plugins do not need to be code-heavy. The two plugins we ship are nearly all Markdown.
Two plugins, one marketplace
The plugins live together in a single repository - spider-claude-plugin - which doubles as a marketplace.
Adding the marketplace once gives you both:
# Inside Claude Code
/plugin marketplace add https://gitlab.com/spider-analyzer/tools/spider-claude-plugin.git
/plugin install spider@spider-analyzer
/plugin install spider-mon@spider-analyzer
The two plugins have distinct surfaces but share a foundation:
| Plugin | Wraps | Domain | Profile source |
|---|---|---|---|
spider | spider CLI | Captured traffic - HTTP, PSQL, TCP, etc. | ~/.spider/profiles.json |
spider-mon | spider-mon CLI | Spider's own health - pipeline, agents, datastores | ~/.spider/profiles.json (same file) |
The shared profile is deliberate: configure your Spider instance once, and both plugins can use it.
Same JWT, same credentials, same scoped whisperer / controller / team. No duplicate setup.
What each plugin actually contains
The Spider plugin - investigate the traffic
Six skills, each one a workflow for a recurring "we need to look at the captured data" question:
| Skill | When to use |
|---|---|
/spider-troubleshoot | Diagnosing errors, auth failures, unexpected behaviour |
/spider-verify-test | Checking that expected traffic was captured after a test or deployment |
/spider-performance | Investigating slow requests, latency percentiles, bottleneck identification |
/spider-security | Detecting anomalous access patterns, high-frequency callers, scanning |
/spider-discover | Mapping service interactions, finding unknown callers / callees |
/spider-models | Reference for writing --aggs ES DSL and --query Lucene strings |
And two agents for the cases where the investigation justifies its own context:
| Agent | What it does |
|---|---|
spider-investigator | Given a symptom + target, autonomously diagnoses and returns a structured report with an evidence link |
spider-performance | Given a service + time window, returns a full performance report with slow-call patterns |
On top of the skills and agents, the plugin's CLAUDE.md primes Claude with: the Spider data model (HTTP / PSQL / TCP / packets and how they're scoped to whisperers), profile management, the full verb tree (search, get, stats, outliers, aggs, show, attach, add link), shareable-link semantics (private vs public, accessFilters, expiry, OTP), the discovery workflow for attaching to a new workload, and body decompression.
Knowledge that the LLM otherwise has to rediscover by reading help text on every session.
The Spider-mon plugin - investigate Spider itself
Seven skills, organized around the recurring monitoring questions:
| Skill | When to use |
|---|---|
/spider-mon-glossary | Reference for spider-mon output and self-monitoring terminology |
/spider-mon-tuning-guide | Tuning playbook - replicas, retention, search, HA - with setup.yaml keys |
/spider-mon-check-changes | Compare two equal-length windows around a reference time T (since-T diff) |
/spider-mon-compare-periods | Diff two explicit time windows (week-over-week, before / after deploy) |
/spider-mon-compare-baseline | Diff current state against a previously-saved named baseline |
/spider-mon-search-logs | Workflow for digging into server / GUI logs |
/spider-mon-alert-decode | Decode a Spider alert email or probe name into meaning, threshold, and next-step commands |
And two agents that map cleanly to the two recurring monitoring shapes - reactive and proactive:
| Agent | Mode | What it does |
|---|---|---|
spider-mon-troubleshooter | Reactive | Auto-mode finds anomalies; symptom-driven mode focuses on a specific issue or alert. Returns severity, since-when, root cause + tuning |
spider-mon-tuning-advisor | Proactive | Given a goal (Nx load, retention, storage, search, HA), returns a concrete setup.yaml change list + verification plan. Read-only |
The proactive / reactive split is the one shape that turned out to keep mattering. "Something is wrong, find it" and "I'm planning ahead, tell me what to change" are not the same kind of work, and giving them separate entry points produces cleaner reports.
Why purpose-built skills beat raw CLI access
A raw CLI plus a smart model gets you a long way. So why bother with skills at all?
Three reasons keep showing up in practice.
Context priming.
A skill is not just "call this command with these flags". It carries the conventions Claude needs to interpret what comes back. /spider-mon-alert-decode knows:
- that Spider probes have a specific naming pattern,
- that thresholds are in
setup.yamlunder specific keys, - and that the next-step command depends on which subsystem the probe belongs to.
Without the skill, Claude has to rediscover all of that from help text and the user has to provide the missing context manually.
With it, the skill is the context.
Workflow encoding.
"Find slow endpoints" sounds like one query but is actually a sequence:
- Pick a baseline window,
- Pick a comparison window,
- Compute percentile shifts,
- Identify the top movers,
- Fetch sample request bodies for the worst offenders,
- Generate a shareable link to the filtered view.
/spider-performance is that sequence written down. Without it, Claude approximates - sometimes well, sometimes by stopping at step 2.
Report shape.
Skills and agents return structured reports - severity, since-when, root cause hypothesis, evidence link, recommendation.
The shape is the same every time, which makes the output diffable, attachable to a Slack thread, and trustworthy enough to feed into the next step of an automation.
Raw CLI output read aloud by the model is not.
The trade-off is real: skills are opinionated.
They embed a view of what "the right way" to do a specific investigation looks like.
That works because we ship the plugins together with the system they investigate - we get to pick the right way.
A third-party plugin author writing skills against spider-mon would have to be more conservative.
Installation
One marketplace to add, then install the plugin(s) you want:
# Inside Claude Code
/plugin marketplace add https://gitlab.com/spider-analyzer/tools/spider-claude-plugin.git
/plugin install spider@spider-analyzer
/plugin install spider-mon@spider-analyzer
Prerequisites:
- The Spider CLI must be installed for the
spiderplugin - The Spider-mon CLI must be installed for the
spider-monplugin - A profile must be configured at
~/.spider/profiles.json- both plugins reuse it
Full reference:
/docs/tools/spider-claude-plugin- the Spider plugin/docs/tools/spider-mon-plugin- the Spider-mon plugin
Closing
A CLI is the right surface for a script.
A plugin is the right surface for an AI agent.
The CLIs that ship in this release are not throwaway scaffolding for the plugins - they are the canonical way to talk to Spider from anywhere outside the UI.
The plugins are not a thin wrapper - they are how that surface becomes usable to a non-human collaborator who has not read the entire documentation site.