Shire Developer Documentation

Shire exposes a public Plugin API 1.0 so external developers can add features without receiving, reading or linking the private Core.

The short version:

• Plugins are separate processes, never native DLLs loaded into Shire.
• The Host inside Shire talks to plugins over a local named pipe using newline-delimited JSON-RPC 2.0.
• SDKs exist for Python, TypeScript/Node, C++, Rust and C#. Any language that can write JSON lines to a pipe can implement the protocol.
• Every plugin declares permissions in manifest.json; the user approves them in the Plugin Manager and the Host checks them on every call.
• Plugins describe UI components; Shire renders them with ImGui. Plugins never receive the ImGui context or native handles.

Start here

1. Getting Started — first plugin in under five minutes.
2. Architecture — Core / Host / SDK boundaries.
3. Protocol — the language-independent wire contract.
4. Manifest and Packaging.
5. API Reference — generated from sdk/contract/api.json.
6. UI, Events, Game functions, Permissions and Security.
7. SDK guides: Python, TypeScript, C++, Rust, C#.
8. Developer Tools, Examples, Migration, Troubleshooting, Distribution.

What is implemented in 1.0

• Named-pipe Host with JSON-RPC framing, handshake, per-call permissions, rate limits, input validation and process isolation.
• Public operations: player position/scene, entity list, marker catalogue, teleport, declarative UI, notifications, storage, event subscriptions and logging.
• Plugin Manager window (F9 or Config → Plugins → Open Plugin Manager), install/remove/enable/disable/reload, permission approval, logs and dynamic plugin UI.
• .shiremod packages (stored ZIP), manifest validation, SHA-256 package hash, safe extraction, registry and plugin storage.
• Python, TypeScript/Node, C++, Rust and C# SDKs and working examples.
• Standalone mock Host and contract test suite.

What is intentionally not in 1.0

These are roadmap items, not hidden promises:

• Quests, inventory, map drawing and arbitrary game internals are not exposed. A new native adapter must be added to the Host before those become public.
• Network access is not sandboxed by the permission system. Plugins are normal OS processes; a plugin can open its own sockets. The Host controls what it exposes, not what the OS allows a process to do.
• Plugin catalogue, URL install, automatic updates, reputation and revocation are designed for but not implemented.
• Digital signatures authenticate origin in a future release; they do not replace isolation or permissions.
• Event filters/priorities and a per-plugin CPU watchdog beyond the job object and process-exit detection are not implemented yet.

The private Core is not part of any SDK. Do not reverse engineer offsets from the payload and call them from a plugin; those addresses are build-specific and break on the next patch. Use the Host.