/configure

name: configure
description: Use after `/plugin install sponsio-claude-code` to wire the runtime end-to-end. The plugin install only registers hooks + skills; the contract library and per-environment overrides are configured here. Bootstraps the per-plugin contract library tree at ~/.sponsio/plugins/, installs bundled starter libraries for popular MCP servers (github, filesystem, playwright), generates fresh starter libraries for plugins / MCP servers that don't ship one (via `sponsio plugin scan`), tunes the shipped rules to the user's actual environment (workspace path, expected call volume, dev/CI/prod profile), and verifies with a smoke test. Use when the user says any of "configure sponsio-claude-code", "set up sponsio-claude-code", "first-time setup of sponsio", "wire up sponsio in this Claude Code session", "add Sponsio guardrails for my MCP tools", "tune the plugin for my environment", "the plugin is too strict / too loose", "calibrate sponsio rules", "scan this plugin", "generate sponsio rules for X", "create a contract library for my plugin", "I just installed Y plugin / MCP server, what should sponsio block", or asks how to make sponsio-claude-code actually block things.

sponsio-claude-code — configure the host shield

You are walking the user through configuring the **sponsio-claude-code** plugin so it actually wraps tool calls in this Claude Code session. Without these steps, the plugin loads but every per-plugin library is empty and every tool call passes through unguarded.

The flow has two halves: **setup** (steps 1–2, 4–6) covers the common case where the user runs popular MCP servers we ship starters for; **scan** (step 3) covers plugins / MCP servers without a bundled starter and lives inline because most sessions touch both halves.

Prerequisites (check silently first)

Run:

sponsio --version

• Not found → tell the user to install: `pip install sponsio` (or

`pip install -e ".[all]"` from a local clone). Stop here until they confirm.

• Present → continue.

If the user owns the agent code and wants to wire Sponsio into their own framework integration (LangGraph, OpenAI Agents, Claude Agent SDK, …) **instead of** running it as a Claude Code host plugin, delegate to the `sponsio` skill (`sponsio onboard .`). This skill is only for the host-plugin case where the user is gating tool calls inside their Claude Code session.

Routing rules from a policy document

Sponsio has two layers, and rules must land in the right YAML or they do nothing. When the user hands you a policy document / instruction file / "list of things the agent must not do" and asks you to encode it, classify **each rule** before writing anywhere.

| Signal | → Layer 1 (this skill — write to `~/.sponsio/plugins/<id>/sponsio.yaml`) | → Layer 2 (delegate to `sponsio` skill — writes `<project>/sponsio.yaml`) | |---|---|---| | Tool names mentioned | `Bash`, `Edit`, `Write`, `Read`, `mcp__*` | tool names from the user's project's tool inventory | | Path form | absolute or `~/...` paths outside the user's project | paths relative to the project (`src/...`) | | Subject of the rule | "Cursor must not…", "Claude Code must not…" | "the loan agent must…", "the chatbot should…" | | Domain language | shell, git, file system, MCP server primitives | AML, KYC, refund, PII, approval, faithfulness, hallucination | | `./sponsio.yaml` exists in cwd | weaker signal — Layer 2 is in play, but rule may still be Layer 1 | stronger signal — most rules belong here |

Process: 1. For each rule, score by the signals above. 2. Route unambiguously-Layer-1 rules to this skill's flow (write under `~/.sponsio/plugins/<id>/sponsio.yaml`). 3. For Layer-2 rules, **stop writing here** and tell the user "rules X, Y look like rules for the agent you're building, not the IDE agent — switching to the `sponsio` skill (`sponsio onboard`) for those". Do not silently dump them into a host-plugin YAML. 4. For genuinely ambiguous rules ("PII must not leak"), ask the user which layer they mean before writing.

The default failure mode is over-writing to Layer 1 because that's this skill's home turf. Cross-layer leakage is a worse user error than the extra clarification round.

Step 1 — bootstrap the library root

Run:

sponsio plugin init

This creates `~/.sponsio/plugins/_host/sponsio.yaml` (covers Claude Code's first-party tools — Bash, Edit, Write, …) and runs a built-in allow + block smoke test. Show the user the output verbatim; if the smoke test fails, **stop** and surface the error — the install is broken and we shouldn't pretend otherwise.

If the file already exists (the user re-ran setup), the command prints `…already exists. Re-run with --force to overwrite.` That's informational, not an error.

Step 2 — enumerate the user's MCP servers

You need to know which MCP servers / plugins the user actually has installed before deciding which libraries to ship. Run `claude mcp list`, or have the user open `~/.claude/settings.json` and read `mcpServers`. Don't guess. If the user doesn't know, that's the answer — they have none beyond the built-ins, and you can skip straight to step 4.

For each registered server, decide which branch of step 3 applies:

sponsio plugin install --list
#   _host (auto-installed by `plugin init`)
#   filesystem
#   github
#   playwright

• **Bundled** (`github`, `filesystem`, `playwright`) → step 3a.
• **Not bundled** (anything else) → step 3b.

A single session often hits both branches.

Step 3a — bundled MCP servers (use `sponsio plugin install`)

Show the user what each bundled starter covers so they can pick:

• `_host` — already installed by step 1.
• `github` — github-mcp-server. Hard-deny on `delete_repository`,

blocks deletes of `main` / `master` / production branches, blocks writes to `.env`, `.github/workflows/*.yml`, `CODEOWNERS`. Caps issue / PR / merge rates.

• `filesystem` — @modelcontextprotocol/server-filesystem. Blocks