Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
/plugin marketplace add melodic-software/claude-code-pluginsnpx agentmods add plugins/melodic-software/claude-code-plugins/autonomygit clone --depth 1 https://github.com/melodic-software/claude-code-pluginsGrade A, and why
autonomy scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.
{
"$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
"name": "autonomy",
"version": "0.22.18",
"description": "Governed autonomous agent operation: role-topology, binding-seam, wiring-vs-advisor, telemetry, return-accounting, trigger-dispatch, per-work-class guardrail-matrix, standing-routine-catalog, and design-only runner-charter contracts for climbing the AI-adoption ladder, plus a guided-setup skill that discovers an adopting org's state, writes its schema-versioned binding, wires standards-pinned OTLP emission with a zero-cost file-artifact default, wires human-attested return capture at the task boundary, wires signal adapters with one governed dispatch entrypoint, binds the five-class guardrail matrix to an org's isolation substrates with an in-boundary live-validation probe before recording each fail-closed binding, and stands up standing-routine-catalog classes as scheduled temporal signal adapters behind the one governed queue with free scheduling defaults wired as reviewable changes and each routine's work-class mapping homed on the security surface.",
"author": {
"name": "Melodic Software",
"email": "[email protected]"
},
"license": "MIT",
"keywords": [
"adoption",
"autonomy",
"binding",
"governance",
"guided-setup",
"otlp",
"return-accounting",
"routines",
"runner",
"telemetry",
"topology"
],
"userConfig": {
"lane_stop_gate_enabled": {
"type": "boolean",
"title": "lane-stop gate",
"description": "Opt an autonomous lane into the deterministic Stop-hook completion gate. Default OFF \u2014 a Stop-blocking hook must never engage for an interactive session. Honored from user or managed settings only (the gate reads those files itself); per-session lanes are armed by the claude-ops lane launcher instead. The env mirror is never authority (#1784).",
"default": false
},
"lane_stop_gate_sentinel": {
"type": "string",
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 81 lines scan A afe6a66eb23b
autonomy is a plugin published in the GitHub repository melodic-software/claude-code-plugins (12 stars, last pushed yesterday), licensed MIT. Its token cost is not measured: this kind of file is read by the harness, not the model. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other plugins, from other repositories
community-claude-plugins
Plugin marketplace listing 1 plugin: example-deployment.
adversarial-testing
Adversarial test generation that finds real bugs by inverting the reward structure.
collaborative-planning
Collaborative planning commands with iterative requirements gathering. Ensures thorough understanding before implementation through structured Q&A sessions.
local-llm
Manage local Ollama LLM models for development and testing.
norvig-patterns
54 elegant coding patterns derived from Peter Norvig's pytudes. Guides Claude to write cleaner, more Pythonic code using proven patterns for algorithms, data structures, testing, and code structure.
collaborative-spec-builder
Collaborative specification building with iterative Q&A before implementation.