Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add yogasw/wick --skill wick-plugin-servicegit clone --depth 1 https://github.com/yogasw/wickWrote 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/yogasw/wick/wick-plugin-service)<a href="https://agentmods.dev/skills/yogasw/wick/wick-plugin-service"><img src="https://agentmods.dev/badge/skills/yogasw/wick/wick-plugin-service/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/yogasw/wick/wick-plugin-service"><img src="https://agentmods.dev/badge/skills/yogasw/wick/wick-plugin-service.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00199 | $0.04822 |
| Opus 5.5 | $0.00080 | $0.01929 |
| Sonnet 5.5 | $0.00040 | $0.00964 |
| Haiku 4.5 | $0.00020 | $0.00482 |
Grade A, and why
wick-plugin-service 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 yesterday.
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 — 317 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Service plugins — always-on at /x/{key}/*
Scope: the service plugin contract and the host that runs it. Picking a kind, templates and
wick plugin buildare in wick-plugin-authoring; installing, sources, signing and troubleshooting installs are in wick-plugins. Docs:docs/plugins/authoring-service.mdanddocs/plugins/service-a2a.md.
Mental model
A service plugin is a plain http.Handler in its own process. wick:
- starts it at boot (and after a reload) and keeps it running — a crash is
restarted with backoff (
internal/services/plugin/supervisor.go); with auto-off it may sleep while idle and wake on the next request; - reverse-proxies
/x/{key}/*to it over a unix socket, deciding auth per route from the manifest (host.goServeHTTP); - pushes its config over the gRPC control service (
Configure) after every spawn and on every save; - optionally drives it as a Team remote agent (
remote_source).
It reuses the tool-plugin machinery (HTTP on $WICK_PLUGIN_SOCKET + the Tool
control service Schema/Configure/Health); it differs in lifecycle (never
idle-killed) and mount point.
| Tool plugin | Service plugin | |
|---|---|---|
| SDK | pkg/plugin/toolplugin + pkg/tool |
pkg/service |
| Mounted at | /tools/{key} (wick layout, login) |
/x/{key}/*, no wick layout |
| Auth | wick login + tool access; WebhookGroup public |
per route: public / token / wick-session |
| Lifetime | spawned on first request, idle-killed | always on, supervised |
| Router | tool.Router / tool.Ctx |
stdlib *http.ServeMux (Go 1.22 patterns) |
Pick a service when something outside wick must reach the code at any time (A2A agent, webhook relay, bot bridge) or when it keeps in-memory state between requests. A page for signed-in users → tool. Something the LLM calls → connector.
Files
| Path | What |
|---|---|
pkg/service/service.go |
Module, Meta, Route, Env, RemoteSource, Describer, BaseURL, auth consts |
pkg/service/serve.go |
ServeService, Manifest, Handler, remote RPC mount, --dump-manifest |
pkg/service/a2aservice/ |
Mount(mux, Card, Reply) — A2A agent card + JSON-RPC on top of a reply func |
pkg/plugin/service.go |
wire types: ServiceModule, ServiceRoute, Auth*, CapRemoteSource, RemotePath*, RemoteTurn/Event/SendResult, EnvPluginToken, EnvBaseURL, MatchRoute |
plugins/service/_template/ |
starter (main.go, service.go, VERSION, README.md) |
plugins/service/example_a2a_repeater/ |
full example: A2A + RemoteSource, with tests |
internal/services/plugin/host.go |
load, /x/ proxy, auth, header injection |
internal/services/plugin/supervisor.go |
process lifecycle, backoff, ring log |
internal/services/plugin/config.go |
config store (owner service_plugin:<key>), SetConfig |
internal/services/plugin/tokens.go |
access tokens (persisted, hashed) + callback tokens (memory) |
internal/services/plugin/callback.go |
/x/-/api/... callback API, HandleCallback, CallerFrom |
internal/services/plugin/admin.go |
/manager/api/service-plugins admin API, RemoteSources |
internal/services/plugin/plugintest/ |
builds + runs the real repeater under a Host |
internal/agents/remote/pluginremote/ |
Team remote agent adapter over /_wick/remote/* |
internal/tools/agents/api_team_plugin_remote.go |
/tools/agents/api/team/plugin-sources, /tools/agents/api/team/plugin-remote |
fe/manager/src/lib/components/services/ServiceDetail.svelte |
admin page |
internal/pkg/api/server.go (search servicePlugins) |
wiring |
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.
- yesterday First seen · 317 lines · 199 tokens per session scan A 4cbea1d9a185
wick-plugin-service is a skill published in the GitHub repository yogasw/wick (5 stars, last pushed yesterday), licensed MIT. It adds 199 tokens to every session and 4,822 once invoked, about $0.0008 per session on Opus 5.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-10-06.
Other skills, from other repositories
event-driven-architecture
Kafka, RabbitMQ, SQS/SNS, event sourcing, CQRS, saga patterns, dead letter queues, and idempotency. Use when designing asynchronous systems, implementing message-driven workflows, or building event streaming pipelines.
edge-computing
Edge computing with Cloudflare Workers, Deno Deploy, Bun, Vercel Edge Functions, AWS Lambda@Edge, and edge databases (Turso, D1, DynamoDB Global Tables). Use when building low-latency edge applications, edge-side rendering, or globally distributed compute.
hono-ops
Hono on Cloudflare Workers - composition, middleware, typed bindings, validation, RPC, streaming, testing. Use for: hono, hono middleware, app.route, hono rpc, c.env bindings, onError, zValidator, vitest-pool-workers, spa fallback worker.
edge-computing
Cloudflare Workers, Deno Deploy, Vercel Edge Functions, edge patterns (geo-routing, caching). Use when implementing edge compute, CDN logic, or global low-latency APIs.
api-gateway
API Gateway patterns (Kong, Traefik, AWS API Gateway) — rate limiting, auth, routing, versioning. Use when implementing API gateway, reverse proxy, or API management.
terraform-infrastructure
Structures, writes, and reviews Terraform infrastructure code. Covers module layout, remote state, workspace strategy, variable and secrets handling, CI plan/apply pipeline, naming conventions, and multi-region deployment patterns (provider aliases, per-region state, failover strategies), while delegating shared risk…