You read the architecture, now what
You cloned the repo. You ran the tests. You followed one detector from the kernel hook all the way to the dashboard. You are looking at the issues list and nothing is jumping out as "this is the one I should pick first." That is the normal state for a first-time contributor on any project of this size.
Here are three tracks that are deliberately small, well isolated, and actually useful. Pick the one that matches the part of the system you find most interesting.
Track 1: add a detector or a Sigma rule
The detector path lives at crates/sensor/src/detectors/. There is a separate post that walks through writing one from scratch. Look at the existing files for tone; most are under 100 lines, with a unit test block at the bottom and a short README in the same directory.
The Sigma path is even lower-friction. We support a subset of Sigma rules natively over eBPF process and network telemetry. Drop a YAML file under rules/sigma/, add a small smoke test under qa/replay/sigma/, and ship. No Rust required for the rule itself.
Issues to look for on the tracker: anything tagged detector or sigma. There is usually a backlog of "we noticed this technique in the wild, want to write a rule" tickets that have been waiting for someone to pick them up.
Track 2: add a notification sink
The agent emits incidents into a sink fan-out. Existing sinks include syslog, JSONL on disk, and a webhook poster. Adding Discord, PagerDuty, Slack, Mattermost, or whatever you already use is a contained job: implement one trait, wire it into the sink registry, write a unit test that asserts on the request body, and add a config block to the sample config.
Files to read first: crates/agent/src/sinks/mod.rs for the trait, crates/agent/src/sinks/webhook.rs for the closest precedent, and examples/innerwarden.toml for where your config block goes.
The one rule that matters: a sink failing must not take down the agent. Errors get a warn! with structured fields and the sink retries on the next fan-out. Do not propagate with ?.
Track 3: add an integration recipe
Recipes are markdown files under the wiki repo that show how to bolt Inner Warden into something an operator already has. Wazuh, OSSEC, Splunk, Loki, Vector, a specific cloud provider's log pipeline. These are not glamorous changes but they are the ones that move the needle on adoption.
The format is short and concrete. A paragraph on what you are connecting. A config block. A verification step. A troubleshooting list of two or three things that go wrong. Existing recipes under Integration-Recipes.md are the right reference.
No Rust skills needed. If you have run Inner Warden next to one of these tools and got it working, the writeup alone is a useful contribution.
How to find a real issue
On the tracker, the labels worth filtering by are good first issue, help wanted, and detector. If something is tagged spec, check the linked spec doc under .specify/features/ before you start. Spec work has scope you cannot guess from the issue alone.
When in doubt, comment on the issue and ask. We would rather answer the question than have you spend a weekend on a path we have already turned away from.
What NOT to start with
The three areas that look approachable and absolutely are not, until you have warmed up:
The eBPF program loading internals. Aya, BTF, ringbuf, verifier failures. Worth understanding eventually, painful as a first PR. There is a separate post on the lessons we learned the hard way; read that before opening a PR against crates/sensor-ebpf/.
The AI router. The triage layer fans incidents across a local classifier, an autoencoder, and an optional remote LLM. The contract is subtle, the failure modes are interesting, and one wrong threshold tank quality across the whole system. Pick this up after you have shipped something smaller.
The autoencoder lifecycle. Training schedule, feature extraction, model rotation, drift detection. There is a spec, the spec is dense, and the gym repo is its own world. Worth it eventually, not as the first PR.
Read more: Contributing your first PR · Your first detector in 50 lines