Explanation

Extend Slopcamera

Workflows, declarative graphs, the SDK, MCP, and separately installed native engines.

Slopcamera has no plugin API and no open operation-registration hook. Extending what an agent can do goes through a small set of bounded surfaces, each with a fixed contract and a stated trust level: teach the agent through the installed skill and workspace configuration, compose existing operations through the SDK and workflows, expose the fixed toolset through MCP, or add a separately installed native engine under explicit trust.

Teach the agent the contract

The Agent Skill is the lightest surface. slopcamera skill install --target agents (or slopcamera skill install --target claude for Claude Code) installs version-matched guidance that routes an agent to the task reference for each kind of job. It comes from the same release or checkout as the CLI, so the documented grammar matches the installed one. Installing the skill does not install the CLI or native engines; inside a repository, --scope project keeps the install project-local.

For diagrams, a slopcamera.config.* file beside the source extends what the renderer can draw: a configured font with local files, named icon bodies given as sanitized SVG geometry, and light and dark theme overrides. The values are parsed into a typed DiagramConfig. A TypeScript or JavaScript config is imported as trusted workspace code; a JSON config is inert data.

Pick an SDK boundary

Imports select their capability boundary, and each entrypoint is a fixed contract.

The portable projection contains four operations: diagram check, diagram render, image generate, and image vectorize. The complete host adds analysis, edits, gateway, iteration, studio, scene, spatialProject, media, project, render, and recording operations. A graph that names an unsupported operation fails at compilation, before executor or resource admission. An operation input is typed data, never a caller-selected executable, shell command, dynamic loader, or registration hook. The SDK reference records each entrypoint's scope and execution effects.

Author a workflow

Workflows package the same fixed operations so they can be planned, reviewed, and resumed together.

• Built-in recipes are reviewed graph definitions listed by slopcamera workflows list: talking-head cleanup, polished screen demos, chaptered compositions, social variants, creative iteration and selection, and prepared directed-scene delivery. Each takes a typed JSON input against its own schema.
• Custom declarative graphs are authored through @hraness/slopcamera/local/code and driven by slopcamera code init, code check, code plan, and code run. Binding a returned plan digest makes a changed source, input, registry, or runtime reject.
• Imperative modules use @hraness/slopcamera/workflow to compose the same operations with explicit step keys and a parsed input contract.

The trust model is explicit. A custom workflow module is an explicitly imported trusted Bun module: loading it evaluates top-level module code, including during code check and code plan, and it runs as the current user without an operating-system sandbox. The graph it builds is declarative data, and constructing a graph must not execute the operations it names. Runs are durable: slopcamera runs show inspects a run, runs approve records an exact plan digest for a paused node, and runs resume reuses retained outcomes whose identities still match. Run or recover a workflow covers the commands.

Expose a fixed toolset through MCP

slopcamera mcp --root /absolute/workspace serves four tools to MCP clients: the check_diagram and render_diagram compatibility tools, plus search_slopcamera and execute_slopcamera over the bounded portable registry. Paths are root-relative to the selected root, a checked diagram admits at most 64 shapes and 128 edges with at most 40 reported findings, and execute_slopcamera accepts only the four registered operation codes and never evaluates source code. The diagram tools do not load workspace configuration. MCP stays a deliberate subset: a client that needs project editing, scenes, or native jobs uses the CLI or SDK. The MCP tutorial covers client setup.

Add a native engine separately

Blender, CadQuery, and Manim are installed separately, and the operator selects the exact executable or Python environment per invocation; Slopcamera does not silently install or upgrade native tools. slopcamera.studio.run is the single operation allowed to execute authored code. It runs a previously retained, hash-bound bundle through the closed host adapter, and only inside an invocation-scoped trusted-current-user envelope: --allow-trusted-code plus an explicit runtime path on code run, workflows run, or runs resume. A stored write approval cannot grant it, and a missing envelope pauses the node before dispatch. Runtime paths and argv remain host-owned, and the profile declares no OS sandbox or hermetic dependency closure.

The external vgpu example follows the same pattern through a separately provisioned Node/Dawn runtime. It is an example environment, not a registered studio engine. Author a native film describes the retained-source job lifecycle.

Where extension stops

Extending Slopcamera means composing fixed operations, declaring new source, or adding a separately qualified engine. There is no runtime hook that registers operations, no workflow step that loads a caller-selected source path, and no document-level switch that widens a profile. New behavior enters through a reviewed change to the registries in source; build Slopcamera from source is the starting point for carrying a modified contract.