Ship a toolset-authoring skill with the package

Raised from developmentseed/mcp-toolsets#30, which came out of the repo review in developmentseed/mcp-toolsets#29. An agent asked to port an existing codebase into toolsets currently has to work out which slice of ~2900 lines applies: this repo's README and `docs/CONSUMING.md`, `docs/SESSION-STATE.md`, and the consuming repo's `CLAUDE.md`. Most of it is deployment material a porting agent should never read.

The facts are written down. What is missing is an ordered procedure and a router.

## Where it lives

Here, not in the consuming repo. Authoring is a runtime concern: the plugin contract, typed returns, the async rule, session state, credential headers, views. That surface changes on every release. 0.9.0 is the example, where `inspect_state` became a coroutine. A skill describing it from a consuming repo goes stale silently on every bump.

A consuming repo keeps a thin skill for what only it knows: the scaffold command, the layout, the deploy scoping rules, the target markers. Its section on writing tools is a pointer here.

## How a consumer gets it

Ship it inside the wheel. The package already carries non-Python assets, so the file arrives at exactly the pinned version, with no network fetch and nothing to drift. A CLI subcommand installs it into `.claude/skills/`.

## What it should not do

Restate `CONSUMING.md`. Every fact duplicated is a fact that drifts, and a stale skill is worse than a stale reference because an agent trusts it more. It names the task shapes, gives the steps in order, and points at the section that answers each one.

## Known gaps it should cover

Found by reading both repos:

- **data keys are public names** — captured as `//` and read by the agent's model when it chooses which stored value to pass into a later call, which may land in a different toolset. Naming happens in the first ten minutes of a port and is expensive to undo. Currently at line 711 of a 1159-line document
- **`ToolError` is absent from `CONSUMING.md`** — it is documented in the `tool_result` module docstring and nowhere a consumer reads, so three error idioms are visible in the example toolsets with no stated rule for choosing
- **the plugin contract example names `my_toolset/tools/__init__.py`** — the scaffold writes `src//tools.py`
- **pytest asyncio mode is `auto`** in this repo and in mcp-toolsets, so an async test needs no decorator

## Already done

- developmentseed/mcp-toolsets-runtime#135, released in 0.9.1: the scaffold generates `async def` tools, so a ported tool starts in the right shape
- developmentseed/mcp-toolsets#40: a contract gate refusing blocking I/O in a sync tool, which is the mistake a port actually makes

## Open question

A Claude Code skill is markdown with frontmatter, so any agent pointed at the path can read it. The auto-discovery does not carry: Cursor reads `.cursor/rules` and Codex reads `AGENTS.md`, and neither looks under `.claude/`. A pointer line in `AGENTS.md` is the cheap bridge, but it is a second place to keep current.

Start with the README, docs/CONSUMING.md, docs/SESSION-STATE.md, and the consuming repo’s CLAUDE.md, then inspect the existing non-Python asset packaging and CLI subcommand entry point. Use the tool_result module docstring and the listed scaffold example to identify the skill’s references. Done means the ordered skill ships at the pinned package version, the CLI installs it into .claude/skills/, and it covers the stated gaps without duplicating CONSUMING.md.

Written by the indexing model from the issue text.