SpecterOps/skills: a plugin marketplace for offensive security agent workflows

The problem: security tradecraft scattered across prompts and chat history

Offensive security work generates a lot of procedural knowledge that does not belong in a codebase. Reconnaissance checklists, ADCS escalation paths, Beacon Object File build steps, report timelines. Teams that use LLM agents for this work tend to keep it in personal prompt files or pasted notes, which means the workflow dies when the operator changes project or machine. SpecterOps/skills addresses that by turning the procedures into versioned plugins with manifests that Codex and Claude Code can install by name. The catalog lists 21 plugins spanning development scaffolding, code review, source-backed research, reconnaissance, application security assessment, SCCM takeover validation, BloodHound attack-path queries, Electron payload packaging, C2 extension development, report drafting, reverse engineering, timeline consolidation, infrastructure operations, social engineering, Ludus range configuration and Mythic C2 development. The target user is a security engineer or operator already running an agent CLI, not someone looking for a general-purpose toolkit. Nothing in the material suggests these skills work outside Codex and Claude Code; the npx path installs instructions only.

Repository layout and the two-manifest mechanism

Each plugin sits under plugins/<name>/ and carries two manifests: .codex-plugin/plugin.json for Codex and .claude-plugin/plugin.json for Claude Code. That duplication is the core design decision. Rather than maintaining one vendor-neutral format and translating at install time, the repository keeps per-host manifests so each agent gets its native metadata. The plugin catalog in the README is generated, marked by an HTML comment that instructs contributors to run `just generate-catalog`, which implies a Justfile drives catalog generation and that the table is not meant to be edited by hand. The catalog also carries three columns beyond the description: whether Codex is supported, whether Claude Code is supported, and whether MCP is involved. Most plugins show Yes/Yes with no MCP. Three plugins, bloodhound, report-drafting and reverse-engineering, are marked Manual for MCP, which reads as a signal that those workflows expect you to wire up an external server yourself. The two tradecraft plugins for Windows and macOS are Codex-only, and the two Planned entries have no Claude Code column filled at all.

Installing from the marketplace in Codex and Claude Code

The README gives two paths per host, one for a local checkout and one for the hosted repository. For Codex the command is `codex plugin marketplace add /Users/<user>/Projects/skills` or `codex plugin marketplace add SpecterOps/skills`, after which you install from the `/plugins` interface inside Codex. For Claude Code the sequence is `/plugin marketplace add SpecterOps/skills` followed by `/plugin install <plugin-name>@specterops-skills`; the local variant substitutes a filesystem path for the repository slug. The marketplace identifier `specterops-skills` is what the install command resolves against, so a plugin name alone will not work. There is a third path, `npx skills add SpecterOps/skills --list` to enumerate and `npx skills add SpecterOps/skills --skill <skill-name> --agent claude-code --agent codex --global` to install. The README is explicit about the trade-off here: the npx route installs skill instructions only and does not install full plugin behavior such as MCP config, Claude commands, hooks, or agent definitions. If a workflow depends on a hook or a slash command, npx will silently give you less than the plugin marketplace would.

MCP is now your problem, not the repository's

This is the part that changed. The README states plainly that the repository no longer ships MCP runner or first-run installer scripts, and that you must install or clone each external MCP server yourself before pointing Codex at it. Configuration goes into `~/.codex/config.toml` or a project-level `.codex/config.toml` under an `mcp_servers` table. The README supplies two worked examples. BloodHound MCP runs through uv with `command = "uv"` and `args = ["--directory", "/path/to/bloodhound-mcp", "run", "main.py"]`, plus an env block carrying BLOODHOUND_DOMAIN, BLOODHOUND_TOKEN_ID, BLOODHOUND_TOKEN_KEY, BLOODHOUND_SCHEME and BLOODHOUND_PORT. Ghostwriter uses `uv --directory /path/to/GhostWriterMCP run python -m ghostwritermcp.server` with GHOSTWRITER_URL, GHOSTWRITER_API_KEY, GHOSTWRITER_CA_BUNDLE, GHOSTWRITER_OPLOG_ID, GHOSTWRITER_OPERATOR and GHOSTWRITER_SOURCE_IP. Binary Ninja MCP is shown in stdio shape as `npx -y binary-ninja-mcp --host localhost --port 9009`, with the README deferring to whatever your BinjaMCP installation documents. After editing the config you restart Codex and check `/mcp` before trusting any MCP-assisted skill. That verification step is not optional padding; a misconfigured server produces an agent that appears to have tools and does not.

Where the distribution model gets in the way

The split between plugin installation and MCP setup is the main friction. A plugin like bloodhound is marked Manual for MCP in the catalog, so installing the plugin gives you the query workflows but not the server that answers them. You supply credentials, a directory path and a running process before the skill does anything useful. The second limitation is coverage asymmetry. tradecraft-windows and tradecraft-mac list Codex as Yes and Claude Code as blank, so Claude Code users cannot install those workflows through the documented path. Third, ops-adcs and ops-mssql are marked Planned with the catalog text stating no capability is currently packaged. A marketplace listing is not an implementation. Fourth, the repository has no retrieved releases, so there is no versioned artifact to pin against; you are tracking the default branch or a commit. Finally, this is offensive security tooling distributed as agent instructions. The Apache-2.0 licence covers the repository contents, but it says nothing about the external tools the plugins drive, and nothing about whether your engagement scope permits running them. That is a question for your own authorization process, not for the licence file.

How this differs from shipping your own MCP servers

The obvious alternative is to skip the marketplace and write your own MCP servers plus prompt files. That approach gives you full control over the transport, the tool schemas and the credential handling, and it avoids depending on two vendor manifest formats. The difference in mechanism is where the reusable work sits. With hand-rolled servers, the reusable asset is the server code, and the procedure lives in whatever prompt you paste. With SpecterOps/skills, the reusable asset is the procedure itself, packaged as a plugin with a manifest, and the server is deliberately left outside the repository. That inversion is why the README dropped the MCP runner scripts: the maintainers are treating MCP servers as external dependencies with their own release cycles rather than vendoring them. A second alternative, for teams that only want the instructions, is the npx skills path, which installs skill text without plugin behavior. That is a genuinely different artifact, not a lighter version of the same one, and the README says so.

Maintenance, contribution and licence boundaries

The README points contributors at CONTRIBUTING.md, which it says covers the supported development environment, setup and validation commands, plugin metadata scaffolding, pull request expectations and where to ask for help. None of those details are reproduced in the README, so anyone planning to add a plugin should read that file before scaffolding manifests. The generated catalog means adding a plugin is not finished until the catalog is regenerated with `just generate-catalog`; a hand-edited table will be overwritten. The Apache-2.0 licence is permissive and includes a patent grant, which matters if you intend to fork the plugin definitions into an internal marketplace. It does not grant rights to the third-party tools the plugins reference, and it does not transfer any authorization to use offensive techniques. Upgrade cost is low in the sense that there is nothing to build, but the absence of releases means you cannot pin a version string; you either track main or vendor a commit into your own fork.

Editorial conclusion

Adopt this if you already work inside Codex or Claude Code and want SpecterOps' offensive security workflows (reconnaissance, ADCS, BloodHound, C2 extensions) delivered as installable plugins rather than copy-pasted prompts. Do not adopt it if you need a self-contained MCP runtime: the README states the repository no longer ships MCP runner or first-run installer scripts, so every external MCP server has to be installed and configured by hand. Verify first that the plugins you intend to use are actually packaged, because ops-adcs and ops-mssql are marked Planned in the catalog with no capability currently packaged.

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. SpecterOps/skills on GitHub