SpecterOps Skills is a security plugin marketplace with three different installers

Three installers, and only one carries plugin behaviour

The same repository installs three different ways, and the differences matter more than the commands suggest. The full path is a plugin marketplace. In Codex you add the marketplace, either from a local checkout path or from the hosted repository, then open Codex and install from the plugins view. In Claude Code the plugin lives under plugins/<name>/ and you add the marketplace with the slash command, then install a single plugin by name, where specterops-skills is the marketplace name:

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

The third path is npx skills, and it is explicitly the reduced one. It installs skill instructions only, and the documentation is clear that it does not install full plugin behaviour such as MCP configuration, Claude commands, hooks or agent definitions. You can list what is available with --list, target a single skill with --skill, and pass --agent claude-code --agent codex to register the same skill with both clients.

The repository stopped shipping MCP installers

One line in the documentation is the most consequential change in the project: this repository no longer ships MCP runner or first-run installer scripts. The responsibility moved to you. Codex supports MCP servers through declarative mcp_servers configuration, so the workflow is to install or clone each external MCP server yourself and then point Codex at it with command, args and optional env values in either the user-level ~/.codex/config.toml or a project-level .codex/config.toml. Three servers are named as worked examples, a BloodHound server, a Ghostwriter server, and Binary Ninja MCP, the last configured with whatever command or endpoint your own installation documents. Two operational details are easy to skip and expensive to miss: Codex has to be restarted after the configuration changes, and you should confirm the tools appear under the slash mcp command before you rely on any MCP-assisted skill.

Manifests live in two places, one per client

The repository carries parallel metadata because the two clients do not agree on a format. Every plugin includes a Codex manifest at .codex-plugin/plugin.json inside the plugin, and a Claude Code manifest at .claude-plugin/plugin.json, with the plugin itself under plugins/<name>/. A .claude-plugin directory also exists at the repository root, which is what makes the marketplace addable as a hosted repository rather than only as a local path. Both clients accept either form of source. Locally you point the marketplace command at your own checkout path, and remotely you name the repository, which is how a fork or an internal mirror would be consumed. The install step then differs by client rather than by source: Claude Code names one plugin at a time against the marketplace namespace, while Codex opens a plugins view and installs from there. Skills installed through npx bypass both manifests, since no plugin metadata is involved at all.

Two catalogue entries are placeholders and one column stops early

The plugin table at the bottom of the README is generated, and the file says so in a comment: the block begins with an instruction to run just generate-catalog, so the list is a build artefact rather than something maintained by hand. It carries four columns, plugin, Codex, Claude Code and MCP, and the support pattern is uneven in a way worth reading before you plan around it. Two entries are marked Planned in the Codex column, one for Active Directory Certificate Services assessment and one for Microsoft SQL Server reconnaissance, and both descriptions say plainly that they are planned and that no capability is currently packaged. The Claude Code column is Yes for the earlier entries and then drops to a dash for the tradecraft and infrastructure rows, including the Windows, macOS and Linux tradecraft plugins and the Cobalt Strike entry. Roughly seventeen of the visible entries support both clients, and the rest are Codex-only.

Three plugins need MCP servers you wire yourself

The MCP column is almost entirely dashes, which means those plugins are instruction-only and carry no server dependency. Three entries are marked Manual instead, and each one names a specific external server. The BloodHound plugin covers BloodHound, AzureHound and the GitHound, JamfHound and OktaHound family of OpenGraph attack-path queries, references a SCIM bridge, and describes optional BloodHound MCP packaging. The report-drafting plugin covers findings, report drafting, Ghostwriter MCP and operation logs, which is why the Ghostwriter server configuration appears in the Codex examples. The reverse-engineering plugin covers reverse engineering workflows and MCP-assisted binary analysis for Binary Ninja, Ghidra and related tooling, which is why the Binary Ninja example appears. In other words, the plugins with real tool integration are the ones that also require you to install, configure and credential a server before the skill can do anything.

Much of the catalogue is offensive tooling, so authorisation is the first question

Read the catalogue as a security practitioner's toolbox rather than a developer toolkit, because that is what it is. The defensive and productivity side covers development scaffolding, repository hygiene, code review, web application QA, source-backed research, finding and report drafting, report timeline consolidation, evidence packaging, and Codex activity reporting. The offensive side covers reconnaissance and OSINT, application and code security assessment, Configuration Manager reconnaissance, command-and-control extension development including Beacon Object Files, the Mythic framework and Cobalt Strike, reusable Electron payload packaging with persistence and discovery, infrastructure operations across SSH, tunnels and firewalls, social engineering research and phishing pretext development, and execution and persistence tradecraft for Windows, macOS and Linux. Two entries in that list are explicitly placeholders. Nothing in the README states an authorisation policy, so scoping and permission remain your responsibility before any of it runs.

Maintenance runs through eight imported justfiles

The repository keeps its own tooling in the open, which is a good sign for a catalogue other people depend on. A justfile sits at the root and does almost nothing itself: it sets the shell to bash with errexit, nounset and pipefail, defines a default recipe that prints the available commands, and then imports eight files from a maintenance directory, covering core recipes, go review, activity reports, BloodHound tasks, the catalogue generator, hygiene, portability and CI. That structure is why the plugin table can be regenerated rather than hand-edited, and why the catalogue carries a generated marker. The tree also holds an agents directory, a skills directory, a .agents directory, a .devcontainer directory, a root .claude-plugin directory and a contributing guide that covers the development environment, validation commands, plugin metadata scaffolding and pull request expectations. Licensing is Apache-2.0, the last commit was 23 September 2026, and there are no published releases to pin against.

Editorial conclusion

Use this marketplace if you run Codex or Claude Code for security work and want a vetted starting point instead of writing your own agent definitions, and read the authorisation boundary first, because a large part of the catalogue is offensive tooling spanning command-and-control development, payload packaging and phishing pretext research. Three things to check before you install. Pick the path that matches what you want: npx skills gives you instructions only, without MCP configuration, commands, hooks or agent definitions. The three plugins marked Manual in the MCP column need servers you configure yourself. And two plugins, for ADCS and for SQL Server, are placeholders with no capability packaged yet.

Frequently asked questions

Official sources

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