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

What SpecterOps/skills actually distributes

The repository is a marketplace, not a library you import. Each plugin lives under plugins/<name>/ and ships two manifests: a Codex manifest at .codex-plugin/plugin.json and a Claude Code manifest at .claude-plugin/plugin.json. That dual-manifest layout is the central design decision. A plugin is a directory of instructions, agent definitions and optional MCP wiring that both hosts can read, rather than a Python package with an entry point.

The catalog in the README lists twenty plugins. They are grouped by intent: development scaffolding (workflows-development), review (code-review-and-qa), research (workflows-research), offensive operations (ops-reconnaissance, ops-appsec, ops-sccm, ops-adcs, ops-mssql, ops-infrastructure), tradecraft (tradecraft-windows, tradecraft-mac, payloads, c2-extensions, c2-mythic, social-engineering), and reporting (report-drafting, report-timeline). Two entries, ops-adcs and ops-mssql, are marked Planned with the note that no capability is currently packaged. That distinction matters: the catalog is generated, so a Planned row is a promise, not an artifact.

The audience is narrow on purpose. This is for security practitioners who already use an agent host and want the agent to follow a repeatable procedure for reconnaissance, BloodHound querying, Binary Ninja analysis or report drafting. If you are looking for general coding assistance, the plugin set is mostly irrelevant to you.

Two manifests, one plugin directory, and where MCP fits

The mechanism is manifest-driven discovery. Codex reads .codex-plugin/plugin.json, Claude Code reads .claude-plugin/plugin.json, and both resolve to the same plugin directory. The README does not document how the two manifests differ in schema, so treat them as parallel artifacts that must be kept in sync by hand or by the repository's own tooling.

MCP is deliberately not bundled. The README states that the repository no longer ships MCP runner or first-run installer scripts. Instead, you install or clone each external MCP server yourself and point Codex at it through declarative mcp_servers configuration in ~/.codex/config.toml or a project-level .codex/config.toml. The catalog marks three plugins with MCP: Manual, meaning BloodHound, report drafting and reverse engineering expect you to bring the server.

That is a real architectural choice with a cost. It removes the repository's responsibility for running third-party servers, which is defensible for a security vendor shipping offensive tooling. It also means the marketplace install and the MCP install are separate operations with separate failure modes. A plugin can install cleanly and still be useless because the server it references is not running. The README's own verification step reflects this: after changing MCP configuration, restart Codex and confirm the tools appear under /mcp before relying on MCP-assisted skills.

Installing the marketplace in Codex and Claude Code

Codex takes a marketplace path or a GitHub shorthand. Both forms appear in the README.

codex plugin marketplace add /Users/<user>/Projects/skills
# or
codex plugin marketplace add SpecterOps/skills

After the add command succeeds, open Codex and install the plugins you want from the /plugins interface. There is no separate install command in the Codex flow; selection happens in the UI.

Claude Code uses slash commands instead. The hosted form is:

/plugin marketplace add SpecterOps/skills
/plugin install <plugin-name>@specterops-skills

For local development the README swaps the repository reference for an absolute path, keeping the same @specterops-skills suffix on install. Note the suffix: the marketplace name is specterops-skills, and the install line will not resolve without it.

If you only want the instruction files and not the surrounding plugin behavior, the README offers a third path through npx skills. This is the narrowest option and the README is explicit about what it omits: MCP config, Claude commands, hooks and agent definitions are not installed.

npx skills add SpecterOps/skills --list
npx skills add SpecterOps/skills --skill <skill-name> --agent claude-code --agent codex --global

The --list flag enumerates available skills before you commit to one, and --global places the result outside a single project. Expect the list output to be the only confirmation that a skill name exists; the README does not describe a dry-run or validation flag for the add command itself.

Configuring MCP servers by hand, with the two README examples

For the three plugins whose MCP column reads Manual, the configuration is yours to write. The README gives two stdio examples. BloodHound uses uv with a directory argument pointing at a local checkout:

[mcp_servers.bloodhound_mcp]
command = "uv"
args = ["--directory", "/path/to/bloodhound-mcp", "run", "main.py"]

[mcp_servers.bloodhound_mcp.env]
BLOODHOUND_DOMAIN = "YOUR_DOMAIN"
BLOODHOUND_TOKEN_ID = "YOUR_TOKEN_ID"
BLOODHOUND_TOKEN_KEY = "YOUR_TOKEN_KEY"
BLOODHOUND_SCHEME = "https"
BLOODHOUND_PORT = "443"

Ghostwriter follows the same shape but runs a module rather than a script, and carries more environment variables, including a CA bundle path and an operation log ID:

[mcp_servers.ghostwriter]
command = "uv"
args = ["--directory", "/path/to/GhostWriterMCP", "run", "python", "-m", "ghostwritermcp.server"]

[mcp_servers.ghostwriter.env]
GHOSTWRITER_URL = "https://ghostwriter.example.com/"
GHOSTWRITER_API_KEY = "YOUR_API_KEY"

The third example, Binary Ninja, is a stdio server launched through npx with a host and port, and the README tells you to use the command or endpoint documented by your own BinjaMCP installation rather than treating the snippet as canonical. That caveat is worth taking literally: the README is showing the Codex configuration shape, not certifying a specific server build.

What the marketplace does not solve

The largest limitation is that plugin availability is uneven across hosts. The catalog's Codex and Claude Code columns are not identical. tradecraft-windows and tradecraft-mac are marked Yes for Codex and blank for Claude Code. ops-adcs and ops-mssql are marked Planned for Codex and blank everywhere else, with the explicit note that no capability is currently packaged. If your team standardizes on Claude Code, a meaningful slice of the catalog is simply not available to you, and the README does not say when or whether that will change.

The second limitation is the MCP boundary already described. A plugin that needs a server will not work until you have cloned and run that server, and the repository has removed the scripts that used to do it for you. Anyone expecting a one-command setup for the BloodHound, Ghostwriter or Binary Ninja workflows will be disappointed.

The third is scope. This is offensive security tooling from a single vendor. The workflows assume a professional assessment context: operation logs, finding drafts, attack-path queries, implant development. Dropped into a general software team's agent host, most of the catalog is dead weight, and the plugins that do apply (code review, development scaffolding) are the least distinctive part of the set.

How it differs from installing skills one at a time

The obvious alternative is the npx skills path the README itself documents. The difference is not cosmetic. Running npx skills add with --skill and --agent installs instruction files into an agent's skill directory and stops there. The marketplace route installs a plugin, which is the unit that carries MCP configuration, Claude commands, hooks and agent definitions.

So the choice is between portability and completeness. A single skill installed through npx skills travels easily between agents, since you can pass --agent claude-code and --agent codex in the same command, but it arrives stripped of everything that makes a plugin more than a prompt. A plugin installed through the Codex or Claude Code marketplace carries the full behavior but is bound to that host's plugin system and, for three plugins, to an MCP server you maintain separately.

A second alternative is writing the skills yourself. The repository is Apache-2.0 and the plugin layout is plain directories with JSON manifests, so nothing prevents you from copying a plugin directory and editing it. What you would be copying is the workflow content, which is the part that took the vendor effort. The manifests are the easy part.

Licence, maintenance and the cost of keeping up

The repository is licensed Apache-2.0, which permits commercial use, modification and redistribution provided you preserve the licence and notices, and it includes a patent grant. That is a permissive licence, and it is the same licence you would need to check against if you vendor a plugin directory into your own internal marketplace. This is not legal advice; the LICENSE file at the repository root is the authoritative text.

Maintenance signals are mixed in a specific way. The last push to the default branch was on 2026-09-03, and the repository is not archived, so the codebase is being touched. There are no retrieved releases, which means versioning happens through the main branch rather than tagged artifacts. If you need pinned versions to reproduce a workflow months later, the repository does not show a release mechanism to pin against.

The upgrade cost is concentrated in three places. Plugin manifests must stay valid for both Codex and Claude Code, so a host-side schema change can break a plugin without any change in this repository. MCP configuration lives in your ~/.codex/config.toml or project .codex/config.toml, outside the repository, so it will not be updated when you refresh the marketplace. And the catalog is generated through a justfile recipe, just generate-catalog, which means the plugin table is meant to be regenerated rather than hand-edited; if you fork the repository, that recipe is your responsibility.

Editorial conclusion

Adopt SpecterOps/skills if your team already runs Codex or Claude Code and works in security assessment, red teaming or reverse engineering, because the plugins encode workflows you would otherwise write yourself. Do not adopt it if you need a single skill file for a general-purpose assistant: the npx skills path installs instructions only and drops MCP configuration, Claude commands, hooks and agent definitions. Before committing, verify the plugin you intend to use is marked Yes in both Codex and Claude Code columns of the catalog, and check whether its MCP column says Manual, since those plugins expect you to install and point at an external server yourself.

Frequently asked questions

Official sources

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