Caution
This is all experimental! Use at your own peril. Don't use any of it outside of a lab environment and definitely not on a production network.
Most of these are deliberate constraints to force efficiency and avoid the common tendency of just throwing more resources at it to make it go faster.
-
Bottom-up approach: Instead if working from the top down and trying to direct AI what to do and bake in conventional investigative strategies, the goal here is to build it's skills from the bottom up and then see what it does. Defining atomic skills may lead to self-assembly of novel investigative techniques and strategies. Maybe it will work, maybe it won't - my bet is on the AI.
-
Prefer simple Typescript for tools, plugins and skills augmentation. No Python and no Bash scripts, dammit! Ideally the skills' actions should amount to trivial scripts or preferably 1-liners. This is not meant to become a repository full of complex scripting logic. AI has given Python a last gasp of breath in it's dying days but it still needs to die.
-
Avoid nonsense prompting like "You are a top-notch genius-level forensics expert...". Well obviously it is and I have yet to see evidence of these kind of word games actually improving it's reasoning abilities. At best it will affect it's writing tone. It's basically "pigeon superstition" so let's avoid it. In any case, I don't expect future LLMs to need prompt-engineering tricks. In general, keep prompting minimalist, neutral and direct.
-
Model-agnostic: While frontier models will certainly do more novel things and operate faster, the goal is that these skills should work with the dumbest models. The skills should not make any assumptions about the model's capabilities or level of intelligence. That's also why this project uses OpenCode. Ultimately we want the models to make simple boiled-down decisions and make good decisions, and for that you don't really need the latest greatest models.
-
Minimize data movement: Avoid copying data out of Velociraptor's datastore unless it's really necessary. It can be tempting to just hauls the data out and analyze it in Elasticsearch or some other external system rather than figuring out how to do the same analysis in-situ. Velociraptor natively provides most of the analysis / data processing capabilities that typical tasks will need. LLMs provide direction/decision-making (i.e. the control plane), and even though they are constantly getting better at handling larger datasets, the data will tend to match that growth rate or maybe even outpace it. Processing data with an LLM is also way less efficient that dedicated data processing tools and much more costly.
-
Skill feedback: Agents should implement "Karpathy Loop" refinement of skills.
OpenCode skills are highly compatible with OpenAI's skills specification. Both platforms are built around the emerging, open-source Agent Skills standard (agentskills.io). Because this standard relies on portable, lightweight Markdown structures rather than vendor-locked architecture, a skill written for one platform generally translates smoothly to the other with only minor adjustments.
Both OpenAI's coding agent (Codex CLI) and OpenCode process skills by reading structured folders that contain a central markdown file.
-
File Format: Both expect a
SKILL.mdfile wrapped in YAML frontmatter followed by system-style Markdown instructions. -
Discovery Protocol: Both tools read the frontmatter metadata (
nameanddescription) to register the skill. The LLM agent only "loads" the full Markdown instructions when a task explicitly triggers that description. -
Shared Storage Paths: OpenCode natively sweeps across directory structures to pick up skills from multiple formats. It will actively look into
.agents/skills/(the directory format utilized by OpenAI and other generic agents) and read them without issues. -
Instructions: The raw instructions (
## What I do,## When to use me) are 100% cross-compatible. -
Tool Bindings: If a skill references specific tool calls or execution hooks unique to Claude Code or OpenAI, OpenCode will simply ignore the unrecognized fields gracefully and rely strictly on the Markdown guidelines.
A common standard used across community repositories allows you to
explicitly state cross-compatibility within the frontmatter using the
compatibility or compatible-with field:
---
name: git-release
description: Create consistent releases and changelogs.
compatibility: opencode
---You may be able to use some skills at this stage but this is early days. Check back later for updates!