Anthropic's Claude Agent Skills give developers a clean primitive for packaging a set of tools, instructions, and context that Claude can reliably use. You write a skill, the model reads the skill's guidance when relevant, and the skill's tools become available for the model to call. It's a good abstraction, and it's changed how custom agents get built.
Because Griffin uses the same Claude models that run Agent Skills, the interesting comparison is: "build my security workflow as a set of Agent Skills on top of raw Claude" versus "use Griffin, which is essentially a set of pre-built security skills with extra scaffolding." Both paths end up with Claude doing the reasoning. The difference is how much of the wiring you own.
What Agent Skills Actually Give You
Agent Skills are a structured way to extend Claude with domain-specific capabilities. A skill packages three things: a description of what the skill is for, a set of instructions the model reads when the skill is invoked, and a set of tools the model can call while using the skill.
For security, you might build skills like "dependency risk analyzer" with a tool that queries your SBOM registry, "triage finding" with tools that read from your findings database and write to your ticketing system, and "remediation drafter" with tools that interact with your repo and resolver. Each skill gets its own context and its own set of side effects.
The value of skills is that they make Claude's behavior predictable and inspectable. Instead of a sprawling system prompt, you have modular, versionable capabilities with well-defined inputs and outputs. When Claude invokes a skill, you can see which tools it called, what they returned, and how the reasoning unfolded.
The Build Path With Agent Skills
Building a security workflow on top of Agent Skills is entirely viable, and it's the right answer for some teams. Here's what the build looks like.
First, you define the tool surface. You need functions that pull findings, look up CVEs, query your SBOM, check package versions, open tickets, post to Slack, and so on. Each tool needs a clear schema, proper authentication, and reasonable error handling. That's dozens of tools, each with its own integration story.
Second, you write the skills. For each security workflow — triage, remediation, policy evaluation, compliance reporting — you package the relevant instructions and tools into a skill. The instructions are where you encode your domain knowledge: what makes a finding actually risky, how your team prefers remediations, what "done" looks like for each workflow.
Third, you build the evaluation layer. Skills give you tool calls and reasoning traces, but they don't grade the output. If you want to catch hallucinated CVEs, broken package coordinates, or policy-violating remediations, you have to build graders yourself.
Fourth, you build the orchestration. Real security workflows span multiple skills — a triage decision might flow into a remediation, which flows into a PR, which flows into verification. Skills don't orchestrate themselves; you need a workflow layer that decides which skill to invoke when and how to handle failures.
Teams that take this path end up with something genuinely custom, which is the whole point. They control the domain model, the policies, the escalation rules. They also end up with a meaningful ongoing maintenance burden, which is the other whole point.
What Griffin Packages
Griffin is, in effect, a fully-built security skill library with the orchestration and evaluation layer on top. The tools Griffin uses to query findings, look up CVEs, resolve packages, scan manifests, and open tickets are the same kinds of tools you'd write yourself if you built this on Agent Skills. Griffin happens to already have them.
The skills — the instructions that guide Claude's behavior for each workflow — are tuned against a corpus of real security work. Griffin has seen a lot of SBOMs, a lot of findings, a lot of remediation outcomes. The prompts and policies baked into Griffin's skills encode those lessons in a way that would take a security team months to replicate.
The evaluation layer is the part most teams underestimate. Griffin's graders check every Claude-generated output for hallucinations, format violations, policy conflicts, and tool misuse. Building that kind of grading harness from scratch is weeks of work per workflow, and keeping it current as Claude's capabilities shift is ongoing.
The orchestration is also pre-built. Griffin knows how to run a scan, cascade into triage, route remediations, open tickets, and notify integrations. You can watch a workflow run end-to-end in the UI, inspect the tool calls, and replay any step. Getting that level of observability on top of Agent Skills requires a real investment in logging, tracing, and replay infrastructure.
When Agent Skills Are The Right Choice
There are three cases where building on Agent Skills beats using Griffin.
The first is when your security model is genuinely non-standard. If you're a security product company building your own agent, or an enterprise with a security posture that doesn't fit any industry template, Griffin's opinions will fight you. Agent Skills give you a clean slate. You encode your own definition of "risky," your own workflow stages, your own integrations.
The second is when the scope is small. If you have a single, well-defined security workflow that covers ninety percent of your needs — say, "triage dependency findings and open Jira tickets" — you can build that as one or two Agent Skills in a week. Adopting Griffin for that small a scope is overkill.
The third is when you want full code ownership. Some teams have strong preferences about not depending on external platforms for their security tooling. Agent Skills let you keep the whole stack in your repo, running against your own Claude API key, with no vendor in the path.
When Griffin Is The Right Choice
Griffin is the better path when the scope is broad — multiple workflows, multiple integrations, multiple kinds of findings — and the team building it doesn't want that to be a full-time engineering project. Griffin is also the better path when you want the evaluation harness and observability to come out of the box, because those layers are where home-built Agent Skills implementations most often fall short.
And Griffin is the better path when you want the workflow templates themselves — the opinions baked into the skills — to come from a team that has spent years looking at security data. That's not a knock on building your own. It's just acknowledging that Griffin's prompts and policies have a lot of tacit knowledge in them, and replicating that knowledge in your own skills takes time.
The Honest Middle Path
A lot of teams end up doing both. They use Griffin for the broad, standard security workflows where Griffin's opinions match their needs. They build custom Agent Skills for the specific, weird, company-specific workflows Griffin doesn't cover — a proprietary risk scoring model, a custom integration with an internal tool, a bespoke compliance check.
That split works well because Agent Skills and Griffin both run on the same Claude models. You're not choosing between two intelligences. You're choosing where to spend engineering effort and where to take someone else's opinion. For the workflows where the opinion matches your needs, Griffin saves you months. For the workflows where it doesn't, Agent Skills give you the control to build exactly what you need.