Demystifying Agent Tradecraft: Introducing SpecterOps Skills

A public repository for turning practitioner knowledge into reusable, reviewable workflows for AI-assisted security work.

SpecterOps Skills is our public repository of reusable skills, plugins, and agent definitions for AI-assisted workflows. It is designed to capture how practitioners approach real work: what to inspect first, which references matter, what requires approval, and how to verify the result.

The repository provides models with structured, task-specific context with the specific goal of keeping practitioners responsible for the decisions that matter. Our goal is to help security professionals use these tools more consistently and effectively without separating the workflow from the expertise required to evaluate its output.

What is in the repository?

As of August 2026, the repository contains 26 plugin families, 79 skills, and 22 reusable agent definitions. Twenty-three plugins are active, while three are incubating until they contain a usable, reviewed capability. This lifecycle distinction helps us separate available workflows from areas that are still being developed.

The collection spans software development, code review, security research, reconnaissance, application security, infrastructure operations, reporting, reverse engineering, adversary simulation, BloodHound analysis and development, C2 extension development, and platform-specific tradecraft across Windows and macOS. Some capabilities support broad engineering workflows. Others are intentionally narrow because deep technical work often benefits from focused, carefully selected context.

The repository uses three related building blocks:

• Skills provide focused instructions, references, scripts, and examples for a bounded task.
• Plugins package related skills and supporting material for a particular workflow or practice area.
• Agent definitions describe reusable roles—such as a researcher, code reviewer, report writer, or BloodHound analyst—that can be composed with those capabilities.

The same material can be used through Codex and Claude Code plugins, and individual skills can be installed through the npx skills ecosystem when the full plugin is unnecessary. Integrations such as BloodHound, Ghostwriter, Binary Ninja, and Ghidra remain explicit dependencies. When a workflow requires an external system, users should be able to see that requirement, configure it deliberately, and understand what data crosses the boundary.

Why SpecterOps is doing this

SpecterOps exists to demystify adversary tradecraft. We have historically pursued that mission through open-source tools, technical research, training, and practitioner-led services. Skills offer another way to share that knowledge: breaking complex work into understandable components and making it more accessible to defenders and operators.

This effort also reflects a lesson our team has been documenting in recent research: context design is interface design.

When Matthew Nickerson revisited BloodHound MCP after a year of real-world use, he found that exposing more tools did not automatically produce a more capable analyst. The improved design used a smaller tool catalog, recoverable errors, domain-specific references, and prompts that guided the workflow without trying to teach the entire domain at once. As he summarized it, “MCP design is context design.”

Kaleb Pomeroy reached a complementary conclusion while designing an MCP interface for BloodHound: tools for agents should be shaped around user intent rather than simply mirror backend API endpoints. The important question is not only what an agent can call, but what it should do next.

The skills repository applies those ideas beyond a single product. A well-designed skill provides the context needed for a specific task, directs the model to deeper material when necessary, and defines what successful completion looks like. This makes the interaction more useful to practitioners and the resulting workflow easier to inspect and improve.

From prompts to maintained workflows

Publishing a skill is only the beginning. The long-term value of the repository depends on maintaining confidence in the material it contains.

SpecterOps intends to curate this repository as a maintained software project. Every active plugin must contain a usable capability. Ownership records identify status and scope. Generated catalogs keep supported installation surfaces synchronized. A pinned Python, uv, and just toolchain gives contributors and CI the same validation interface. Pull requests are checked for metadata consistency, broken internal references, portability problems, secret exposure, unsafe repository structure, stale generated files, and provenance for packaged executable artifacts.

These controls give contributors a consistent way to develop and validate changes, while helping users understand what is supported and how each capability is maintained.

Our maintenance model going forward is based on six principles:

1. Practitioner-led contributions. Skills should be grounded in demonstrated knowledge, useful source material, or a repeatable workflow. Model-assisted drafting can help, but the resulting material must be reviewed and owned by someone who understands the domain.
2. Explicit lifecycle and ownership. New ideas may incubate in public, but they become installable capabilities only after they contain substantive material and have an accountable maintainer.
3. Review for both utility and risk. Offensive-security content needs enough fidelity to be useful, together with clear prerequisites, operational constraints, and validation steps. Responsible publication should help practitioners understand both the capability and its appropriate use.
4. Portable, multi-client design where practical. We will support the agent ecosystems practitioners use while minimizing unnecessary dependence on the behavior of any single model.
5. Reproducible maintenance. Local checks and CI should agree. Routine validation should be deterministic, offline, read-only, and safe in a dirty worktree. Networked maintenance, such as checking external links or upstream drift, belongs in a separate and bounded process.
6. Transparent limitations. A skill should state when it needs credentials, external tooling, a specific operating system, human approval, or additional context. Clearly documenting an open question is preferable to presenting an unsupported answer as settled.

We expect the collection to evolve. Skills will be corrected, divided, combined, promoted, and occasionally retired as the underlying tools and tradecraft change. Sustainable maintenance means preserving a trustworthy path from a user’s intent to a reviewable outcome, even as the specific contents of the repository develop over time.

Kyle Avery’s contributions: the value of domain expertise

The repository already benefits from experts outside SpecterOps who have chosen to contribute their knowledge. Kyle Avery, principal security researcher at Fortra’s Outflank and an offensive R&D practitioner with Outflank, has provided many strong examples of the collaboration we hope to encourage.

What comes next

We want SpecterOps Skills to become a durable public resource for agent-assisted security work: useful to our own practitioners, useful to the wider community, and open to contributions from people with expertise across the field.

Curation will remain an important part of that work. New plugins, public interfaces, publication surfaces, and licensing decisions should begin with an issue. Changes should explain their user-visible impact and include the validation performed. When sensitive vulnerability details require coordination, we will use private disclosure paths rather than a public issue.

The larger goal is to make practitioner knowledge easier to apply while preserving the role of practitioner judgment.

AI-assisted security work is moving quickly. By building clearer interfaces, curating useful context, testing workflows, and sharing what we learn, we can help these tools support more consistent and reviewable security outcomes.