/** * Capability authoring tools (spec §3), refactored to a single risk-gated path. * * ProposePlugin author a NEW plugin from any capability mix — skills, * commands, subagents, hooks, MCP servers. The risk gate is * *computed from content*, not pre-declared by tool choice: * passive content (skills, commands, read-only subagents) is * authored autonomously; executable content (hooks, MCP servers, * mutating/high-privilege subagents) auto-triggers a "show the * code + tool grant → human confirms → activate" gate in the * same call. A mixed plugin (skill + hook) is authored in one * call, and a hook can never be mis-routed through a "passive" * tool because the gate keys off what the draft contains. * UpdatePlugin merge inline-authored capabilities into an EXISTING local * plugin. Nothing is fetched from a remote, so the supply-chain * "benign v1 → hostile v2" risk that keeps a marketplace * UpdatePlugin out of the model's hands does not apply here; * executable additions still pass through the same confirm gate. * * Both author into `.agents/plugins//` in the requested vendor layouts * (Claude Code + GitHub Copilot by default) via the format registry, so results * are proper, publishable plugins that round-trip through parsePluginDir. * * Privilege-amplification guardrail: an authored subagent may never carry a * plugin-system (capability-acquisition) tool in its allowlist — enforced in * both tools — so a low-trust authored agent cannot bootstrap privilege. */ import { type ToolDefinition } from "../extensions/types.js"; export declare function createProposePluginToolDefinition(): ToolDefinition; export declare function createUpdatePluginToolDefinition(): ToolDefinition; export declare function createRemovePluginCapabilityToolDefinition(): ToolDefinition; /** All three authoring tool definitions, for registration on the top-level agent. */ export declare function createProposePluginToolDefinitions(): ToolDefinition[]; //# sourceMappingURL=propose-plugin.d.ts.map