{"owner":"aquasecurity","repo":"tracee","hasSkills":true,"totalSkillsCount":12,"totalTokensCount":5373,"categories":["cursor-rule","anthropic-skill","copilot-instructions","command-prompt"],"hasMcp":false,"mcpConfig":null,"found":[".cursor/rules/commit-pr-conventions.mdc",".cursor/skills/tracee-testing-guide/unit-test-checklist.md",".cursor/skills/tracee-testing-guide/SKILL.md",".cursor/skills/shell-style-guide/SKILL.md",".cursor/rules/markdown-docs-style.mdc",".cursor/rules/text-ascii-safety.mdc",".github/copilot-instructions.md","docs/traceectl/commands/metrics.md",".cursor/skills/shell-style-guide/reference.md","docs/traceectl/commands/stream.md","docs/traceectl/commands/event.md","docs/traceectl/commands/version.md"],"skills":{".cursor/rules/commit-pr-conventions.mdc":"---\ndescription: Commit and pull request conventions for Tracee contributors\nalwaysApply: false\n---\n\n# Commit and PR Conventions\n\nWhen preparing commits or PR text in this repository, follow these rules from `docs/contributing/overview.md`:\n\n- Use Conventional Commits: `type(optional scope): description`.\n- Allowed types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`.\n- Write subject in imperative mood and keep it at 50 chars max.\n- Optional body explains **why**, not **how**; wrap at 72 chars.\n- Breaking changes must use `!` in subject and include a `BREAKING CHANGE:` footer.\n- Keep code details in commit message; keep review/process details in PR description.\n- For cross-area work, suggest splitting into self-contained commits when possible.\n- Remind contributors that commits must be signed (GPG/SSH/S/MIME).\n\n## Jira Ticket References\n\nWhen a commit resolves or is tracked by a Jira ticket, place the ticket ID in\nbrackets immediately after `type(scope): `, before the description:\n\n```\ntype(optional scope): [JIRA-XXX] description\n```\n\n- Brackets are required: `[ENF-123]` not `ENF-123`.\n- Place it in the subject only, never in the body or footer.\n- Omit entirely when no Jira ticket applies.\n",".cursor/skills/tracee-testing-guide/unit-test-checklist.md":"# Unit Test Checklist\n\nUse this checklist when creating or revising unit tests in Tracee.\n\n## Design\n\n- test behavior contracts, not implementation internals\n- include at least one failure-path assertion for new logic\n- cover boundary values and empty-input scenarios\n\n## Structure\n\n- keep tests close to source in `*_test.go`\n- prefer table-driven tests for repeated input/output patterns\n- keep test setup minimal and explicit\n\n## Assertions\n\n- use `require` for prerequisites and `assert` for follow-up checks\n- make assertion messages explain the expected behavior\n- avoid brittle assertions based on unrelated formatting or ordering\n\n## Reliability\n\n- clean up resources with `defer`\n- avoid shared mutable state across test cases\n- remove sleeps when deterministic synchronization is possible\n\n## Execution\n\n- iterate quickly:\n  - `make test-unit PKG=<pkg> TEST=<TestName>`\n- verify package:\n  - `make test-unit PKG=<pkg>`\n- verify full suite before finalizing:\n  - `make test-unit`\n\n## Optional Coverage Review\n\n- generate coverage summary:\n  - `make coverage`\n- generate coverage html report:\n  - `make coverage-html`\n",".cursor/skills/tracee-testing-guide/SKILL.md":"---\nname: tracee-testing-guide\ndescription: Run Tracee tests correctly, especially BPF unit tests via make targets. Use when writing tests, debugging test failures, or validating changes before commit.\n---\n\n# Tracee Testing Guide\n\n## Critical Rule\n\nFor BPF-related unit tests, do not run `go test` directly.\nUse `make test-unit` so the required BPF environment is configured.\n\n## When To Use This Skill\n\nUse this skill when:\n- creating new unit tests for changed behavior\n- revising existing `*_test.go` files after refactors\n- fixing flaky tests or false assumptions in assertions\n- tightening coverage for bug fixes\n\n## Fast Development Commands\n\n- All unit tests: `make test-unit`\n- Package-only: `make test-unit PKG=pkg/detectors`\n- Function-only: `make test-unit TEST=TestKernelVersionRequirement_Basic`\n- Function in package: `make test-unit PKG=pkg/ebpf/probes TEST=TestProbeCompatibility_Basic`\n\n## Other Test Suites\n\n- Integration tests: `make test-integration` (root required)\n- E2E tests: `make test-e2e`, `make test-e2e-net`, `make test-e2e-kernel` (root required)\n- Coverage: `make coverage`, `make coverage-html`\n\n## Troubleshooting\n\n- `fatal error: bpf/bpf.h: No such file or directory`\n  - Use `make test-unit` instead of direct `go test`.\n- Slow runs\n  - Use `PKG=` and `TEST=` during iteration.\n- Integration or E2E failures\n  - Verify root privileges and kernel eBPF support.\n\n## Test Authoring Notes\n\n- Use `testify/assert` and `testify/require`.\n- Keep test files near source (`*_test.go`).\n- Prefer explicit cleanup with `defer`.\n- Maintain or improve coverage for changed code.\n\n## Unit Test Creation Workflow\n\n1. Identify the behavior contract and edge cases from changed code.\n2. Add focused test cases first for success path, then error path.\n3. Use table-driven tests when only inputs/expected outputs vary.\n4. Keep each test name descriptive and behavior-based.\n5. Run targeted command first:\n   - `make test-unit PKG=<pkg> TEST=<TestName>`\n6. Run package-wide tests:\n   - `make test-unit PKG=<pkg>`\n7. Before finishing, run broader validation:\n   - `make test-unit`\n\n## Unit Test Revision Workflow\n\nWhen updating existing tests:\n- prefer fixing test intent instead of copying implementation details\n- remove stale assertions tied to old behavior\n- keep failure messages explicit so regressions are easy to diagnose\n- check cleanup paths and goroutine/resource lifecycle assumptions\n\n## Flaky Test Triage Checklist\n\n- verify timing assumptions (timeouts, retries, async ordering)\n- avoid shared mutable global state across tests\n- isolate test inputs from environment-dependent behavior\n- run the test repeatedly with:\n  - `make test-unit PKG=<pkg> TEST=<TestName>`\n\n## Additional Reference\n\nFor a concise checklist to apply during unit test creation and review, see\n[unit-test-checklist.md](unit-test-checklist.md).\n",".cursor/skills/shell-style-guide/SKILL.md":"---\nname: shell-style-guide\ndescription: Enforce Tracee shell standards with shellcheck and shfmt. Use when editing shell scripts, YAML run blocks, or shell code blocks in markdown.\n---\n\n# Shell Style Guide\n\n## Quick Start\n\nApply these requirements for any shell work:\n\n1. ShellCheck must pass with zero errors.\n2. Format with shfmt based on shell type.\n3. Use braces for variable expansion (`${var}`).\n4. Keep `scripts/lib*.sh` POSIX sh compatible.\n\n## Commands\n\n- Bash file:\n  - `shfmt -i 4 -ci -bn -sr -w <file>`\n  - `shellcheck -s bash <file>`\n- POSIX sh file:\n  - `shfmt -p -i 4 -ci -bn -sr -w <file>`\n  - `shellcheck -s sh <file>`\n- Library file:\n  - `shfmt -p -i 4 -ci -bn -sr -w scripts/lib_example.sh`\n  - `shellcheck -s sh -x scripts/lib_example.sh`\n\n## Core Rules\n\n- Use `#!/bin/bash` for executables unless strict POSIX compatibility is required.\n- Use `#!/bin/sh` for `scripts/lib*.sh`.\n- Do not use Bash-only features in POSIX sh (`local`, arrays, `[[ ]]`, process substitution).\n- Quote expansions and use explicit error handling (`set -euo pipefail` for Bash, `set -eu` for POSIX).\n- For POSIX sh helper variables in non-library scripts, use single underscore namespacing.\n\n## Detailed Reference\n\nFor the complete Tracee shell style details, see [reference.md](reference.md).\n",".cursor/rules/markdown-docs-style.mdc":"---\ndescription: Markdown docs style and policy alignment\nglobs:\n  - \"**/*.md\"\nalwaysApply: false\n---\n\n# Markdown Docs Rule\n\nWhen editing markdown docs:\n\n- Keep policy text aligned with canonical project sources.\n- Use normative language consistently (`must`, `should`, `may`).\n- Keep guidance actionable and concise.\n- Avoid duplicating nearby docs; prefer links to canonical references.\n- If policy changes (not only wording), update all affected docs in the same PR.\n- Apply the same standards to man-page markdown sources under `docs/docs/**/man/*.md` and `docs/docs/flags/*.md`.\n",".cursor/rules/text-ascii-safety.mdc":"---\ndescription: Forbid AI typography Unicode and hidden characters in all content\nalwaysApply: false\n---\n\n# Text ASCII Safety\n\nAll new or modified content must be plain ASCII in the allowed ranges:\n`\\x09`, `\\x0A`, and `\\x20-\\x7E`.\n\n- Typographic Unicode and hidden/control characters are forbidden.\n- Run checks only on changed files (staged or diff range), not full-repo scans.\n\n## Changed Files Check\n\n```bash\n.cursor/hooks/ascii-check-changed.sh staged\n```\n",".github/copilot-instructions.md":"# Copilot Instructions for Tracee\n\n## Repository Overview\n\nTracee is a runtime security and observability tool that uses eBPF technology to tap into system activity and expose events ranging from factual system information to sophisticated security detections. It's a large, mature codebase (~500K+ lines) written primarily in Go and C (eBPF), targeting Linux systems with kernel 4.18+.\n\n### Key Technologies\n- **Languages**: Go (1.24+), C (eBPF), Shell scripts\n- **Build Tools**: Make, Clang 12+, Go toolchain\n- **Frameworks**: eBPF/libbpf, gRPC, Kubernetes operators\n- **Target Platforms**: Linux x86_64, aarch64\n\n## Build Instructions & Environment Setup\n\n### Essential Prerequisites\nAlways ensure these requirements before building:\n- **Go 1.24+** (specifically required - earlier versions will fail)\n- **Clang 12+** (minimum version enforced by Makefile)\n- **pkg-config, build-essential, libelf-dev, libzstd-dev** (system packages)\n\n### Core Build Commands\n\n```bash\n# ALWAYS start with environment check\nmake env                    # Shows all environment variables and tool versions\n\n# Basic building (takes 1-2 minutes)\nmake clean                  # Clean all build artifacts first\nmake all                    # Builds tracee, signatures, evt, traceectl\n\n# Individual components\nmake bpf                    # eBPF object only\nmake tracee                 # Main unified binary\nmake signatures             # Go plugin signatures\nmake tracee-bench           # Benchmarking tool\n```\n\n### Testing Commands\n\n```bash\n# Unit tests (takes ~6-8 seconds)\nmake test-unit              # Fast, comprehensive unit tests\n\n# Integration tests (requires root privileges)\nsudo make test-integration  # Some tests skip without root\n\n# Types module testing\nmake test-types             # Separate Go module testing\n\n# Common module testing\nmake test-common            # Common module testing\n```\n\n### Validation & Linting\n\n**IMPORTANT**: Some validation commands require additional tools not installed by default:\n\n```bash\n# Code formatting (NEEDS goimports-reviser, clang-format-19)\nmake check-fmt              # Will fail without proper tools\nmake fix-fmt                # Auto-fix formatting issues\n\n# Other validation\nmake check-vet              # Go vet checks\nmake check-staticcheck      # Static analysis (needs staticcheck tool)\nmake check-err              # Error checking (needs errcheck tool)\nmake check-vulncheck        # Vulnerability checking (needs govulncheck tool)\nmake check-pr               # Full PR validation suite\n```\n\n**Tool Installation**: If you get \"missing required tool\" errors, install via:\n- `goimports-reviser` (v3.12.6): `go install github.com/incu6us/goimports-reviser/v3@fa5587e51ba33c58734984cb41370a5b2582d5b7`\n- `staticcheck` (2025.1): `go install honnef.co/go/tools/cmd/staticcheck@5af2e5fc3b08ba46027eb48ebddeba34dc0bd02c`\n- `errcheck` (v1.9.0): `go install github.com/kisielk/errcheck@11c27a7ce69d583465d80d808817d22d6653ee34`\n- `govulncheck` (v1.1.4): `go install golang.org/x/vuln/cmd/govulncheck@d1f380186385b4f64e00313f31743df8e4b89a77`\n- `clang-format-19`: Use system package manager or download binary\n\n### Build Flags & Options\n\n```bash\nSTATIC=1 make tracee        # Static binary linking\nDEBUG=1 make tracee         # Debug symbols included\nMETRICS=1 make tracee       # Enable BPF metrics\nBTFHUB=1 STATIC=1 make      # Embed BTF for kernel compatibility\n```\n\n### Common Build Issues & Solutions\n\n1. **\"missing required tool\"**: Install the specific tool mentioned in error\n2. **Go version errors**: Must use Go 1.24+, earlier versions fail validation\n3. **Clang version errors**: Must use Clang 12+, checked by Makefile\n4. **Integration test failures**: Many tests require root privileges\n5. **libbpf build failures**: Check system has libelf-dev and build tools\n6. **Permission errors in tests**: Integration tests need `sudo` for eBPF operations\n\n## Project Architecture & Structure\n\n### Core Directories\n\n- **`cmd/`** - Command-line binaries\n  - `tracee/` - Main unified Tracee binary\n  - `evt/` - Event generation and testing tool\n  - `traceectl/` - Control plane client tool (separate Go module)\n\n- **`pkg/`** - Main Go packages and libraries\n  - `ebpf/` - eBPF program management, event processing\n  - `events/` - Event definitions, parsing, filtering\n  - `signatures/` - Signature engine and framework\n  - `policy/` - Policy management and enforcement\n  - `containers/` - Container runtime integration\n  - `proctree/` - Process tree tracking\n  - `filters/` - Event filtering logic\n\n- **`pkg/ebpf/c/`** - eBPF C source code\n  - `tracee.bpf.c` - Main eBPF program\n  - `common/` - Shared headers and utilities\n  - `maps.h`, `types.h` - eBPF data structures\n\n- **`signatures/golang/`** - Detection signatures (Go plugins)\n  - Individual `.go` files implementing specific threat detections\n  - `export.go` - Signature plugin exports\n\n### Build Artifacts\n\nAll build outputs go to `./dist/` directory:\n- `tracee` - Main unified binary\n- `tracee.bpf.o` - Compiled eBPF object\n- `signatures/builtin.so` - Go plugin signatures\n- `libbpf/` - Static libbpf build\n\n### Configuration Files\n\n- **`.revive.toml`** - Go linting configuration (comprehensive rules)\n- **`staticcheck.conf`** - Static analysis configuration\n- **`go.mod`** - Go dependencies (main module)\n- **`types/go.mod`** - Separate types module\n- **`Makefile`** - Primary build configuration (1100+ lines)\n- **`builder/Makefile.checkers`** - Code quality validation\n\n## Continuous Integration & Validation\n\n### PR Workflow (`.github/workflows/pr.yaml`)\nThe PR workflow runs these checks:\n1. **Documentation verification** - Man page sync validation\n2. **Code verification** - Formatting, linting, vet, staticcheck, errcheck, govulncheck\n3. **Build verification** - Multiple tools and components\n4. **Testing** - Unit tests, integration tests, performance tests\n5. **Multi-kernel testing** - Matrix of kernel versions and architectures\n\n### Key Validation Steps\n- **Formatting**: gofmt, clang-format-19, goimports-reviser\n- **Linting**: revive with comprehensive rules\n- **Static Analysis**: staticcheck with custom configuration\n- **Error Checking**: errcheck for unchecked errors\n- **Vulnerability Checking**: govulncheck for known Go vulnerabilities\n- **Architecture Testing**: x86_64 and aarch64 builds\n- **Kernel Compatibility**: Testing across kernel versions 4.18-6.12\n\n### Test Requirements\n- **Unit tests**: Run in any environment, ~6-8 seconds\n- **Integration tests**: Require root privileges for eBPF operations\n- **E2E tests**: Run in CI with specific kernel versions and privileges\n\n## Development Guidelines\n\n### Making Changes\n1. **Always run formatting first**: `make fix-fmt` before commits\n2. **Validate locally**: Use `make check-pr` to run full validation suite\n3. **Test comprehensively**: Run both unit and integration tests when possible\n4. **Check dependencies**: Use `make env` to verify tool versions\n\n### Common Development Patterns\n- **eBPF changes**: Modify files in `pkg/ebpf/c/`, rebuild with `make bpf`\n- **Signature development**: Add new detection rules in `signatures/golang/`\n- **Event processing**: Core logic typically in `pkg/ebpf/` and `pkg/events/`\n- **Testing**: Unit tests alongside source files, E2E tests in `tests/`\n\n### File Locations for Common Tasks\n- **Add new event type**: `pkg/events/core.go`, `pkg/events/definition.go`\n- **Modify eBPF program**: `pkg/ebpf/c/tracee.bpf.c`\n- **Add signature**: New file in `signatures/golang/`\n- **Container integration**: `pkg/containers/`\n- **Policy management**: `pkg/policy/`\n\n## Additional Notes\n\n- **Git submodules**: Repository uses libbpf as submodule (`3rdparty/libbpf/`)\n- **Multi-module**: Main module + separate `types/` module with own `go.mod`\n- **Plugin architecture**: Signatures built as Go plugins loaded at runtime\n- **Cross-compilation**: Supports x86_64 and aarch64 architectures\n- **BTF support**: Can embed BTF for kernel compatibility via BTFHUB=1\n\nTrust these instructions and refer to `make help` for quick command reference. When in doubt about environment setup, always run `make env` first to check tool versions and paths.\n","docs/traceectl/commands/metrics.md":"# Metrics Command Usage\n\nThe `metrics` command in **traceectl** provides information about Tracee's performance and resource usage metrics. This command is helpful for monitoring how Tracee is functioning in real-time.\n\n## Usage\n\nThe `metrics` command is structured as follows:\n\n```sh\ntraceectl metrics \n```\n\n- **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n\n## Examples\n\n- **Display Metrics in Table Format**\n  \n  ```sh\n  traceectl metrics \n  ```\n\n## Summary\n\nThe `metrics` command displays tracee's performance and resource usage metrics. Use this command to monitor Tracee's operational status.\n",".cursor/skills/shell-style-guide/reference.md":"# Tracee Shell Reference\n\nThis reference captures the detailed shell constraints used by Tracee.\nUse it when the task needs exact style behavior beyond the quick checklist.\n\n## Required Tooling\n\n- ShellCheck: zero errors required.\n- shfmt with project flags:\n  - Bash: `shfmt -i 4 -ci -bn -sr -w <file>`\n  - POSIX sh: `shfmt -p -i 4 -ci -bn -sr -w <file>`\n\n## Script Types\n\n- Executables default to Bash (`#!/bin/bash`).\n- Library files `scripts/lib*.sh` must remain POSIX sh (`#!/bin/sh`).\n- Embedded shell blocks in YAML and markdown must be linted/formatted by actual shell mode.\n\n## POSIX Compatibility Notes\n\nIn POSIX sh:\n- Do not use `local`.\n- Do not use arrays.\n- Do not use `[[ ]]`; use `[ ]`.\n- Use `=` for string equality in `[ ]`.\n- Avoid Bash string replacement, regex matching, and process substitution.\n\n## Variable and Naming Rules\n\n- Use `${var}` expansion style.\n- Quote variable expansions by default.\n- In library internals (`scripts/lib*.sh`), reserve `__` namespace for helpers and status variables.\n- In non-library POSIX scripts, use `_function_name_var` style for internal helper variables.\n\n## Validation Workflow\n\nBefore commit:\n1. Format changed shell files with shfmt.\n2. Run ShellCheck in correct mode.\n3. If libraries changed, run `./scripts/lib_test.sh`.\n\n## References\n\n- [Google Shell Style Guide](https://google.github.io/styleguide/shellguide.html)\n- [ShellCheck](https://www.shellcheck.net/)\n- [shfmt](https://github.com/mvdan/sh)\n","docs/traceectl/commands/stream.md":"# Stream Command Usage\n\nThe `stream` command in **traceectl** allows users to stream events directly from Tracee in real time. This command provides flexible output formats for better integration and readability.\n\n## Usage\n\nThe `stream` command is structured as follows:\n\n```sh\ntraceectl stream [flags] [policies]...\n```\n\n- **`[policies]`**: List of policies to stream (default is all policies)\n- **`--format`**: Specifies the format (default is `table`).\n- **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n- **`--output`**: Specifies the output (default is `stdout`)\n\n## Examples\n\n- **Stream Events in JSON Format with a specified policies and a different unix socket**\n  \n  ```sh\n  traceectl stream --format json --server /tmp/tracee.sock policy1 policy2\n  ```\n\n- **Stream Events to file**\n  \n  ```sh\n  traceectl stream --output /path/to/file \n  ```\n\n- **Stream Events in JSON Format**\n  \n  ```sh\n  traceectl stream --format json\n  ```\n\n- **Stream Events in Table Format**\n  \n  ```sh\n  traceectl stream --format table\n  ```\n\n## Summary\n\nThe `stream` command provides a real-time feed of Tracee events, allowing you to monitor system activity as it happens.\n","docs/traceectl/commands/event.md":"# Event Command Usage\n\nThe `event` command in **traceectl** is used for managing events within Tracee. It allows you to list, describe, enable, and disable various event types that Tracee can capture. Below is the usage guide for the `event` command and its subcommands.\n\n## Usage\n\nThe `event` command is structured as follows:\n\n```sh\ntraceectl event [subcommand] [flags]\n```\n\n## Subcommands\n\n- **describe**: Retrieves detailed information about a specific **event** or **all the events**, including its fields, types, and other metadata.\n  \n  ```sh\n  traceectl event describe EVENT\n  ```\n\n  - **`EVENT`**: The name of the event to describe (default is all events).\n  - **`--format`**: Specifies the format (default is `table`).\n  - **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n  - **`--output`**: Specifies the output (default is `stdout`)\n\n- **enable**: Enables capturing of a specific event type in Tracee.\n  \n  ```sh\n  traceectl event enable <event_name>\n  ```\n\n  - **`EVENT`**: The name of the event to enable.\n  - **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n  - **`--output`**: Specifies the output (default is `stdout`)\n\n- **disable**: Disables capturing of a specific event type in Tracee.\n  \n  ```sh\n  traceectl event disable <event_name>\n  ```\n\n  - **`EVENT`**: The name of the event to disable.\n  - **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n  - **`--output`**: Specifies the output (default is `stdout`)\n\n## Examples\n\n- **List All Events in JSON Format**\n  \n  ```sh\n  traceectl event describe --format json\n  ```\n\n- **Describe an Event**\n  \n  ```sh\n  traceectl event describe execve\n  ```\n\n- **Enable an Event**\n  \n  ```sh\n  traceectl event enable execve\n  ```\n\n- **Disable an Event**\n  \n  ```sh\n  traceectl event disable execve\n  ```\n\n## Summary\n\nThe `event` command in traceectl is a powerful tool for managing Tracee's event capabilities. Use the, `describe`, `enable`, and `disable` subcommands to gain detailed insight and control over the events Tracee monitors.\n","docs/traceectl/commands/version.md":"# Version Command\n\nThe `version` command in **traceectl** provides detailed information about the current version of the tool. This includes the version number, build date, and other relevant metadata.\n\n## Usage\n\nTo display the version information, use the following command:\n\n``` bash\ntraceectl version\n```\n\n- **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n\nThis command will output details such as:\n\n- **Version Number**: The current version of traceectl.\n- **Commit Hash**: The Git commit hash associated with the current build (if applicable).\n\n### Example Output\n\n``` bash\nv0.22.0\n```\n\n### Summary\n\n- **`traceectl version`**: Displays detailed version information.\n\nUse this command to verify your version or to gather information for troubleshooting purposes.\n"},"files":{".cursor/rules/commit-pr-conventions.mdc":"---\ndescription: Commit and pull request conventions for Tracee contributors\nalwaysApply: false\n---\n\n# Commit and PR Conventions\n\nWhen preparing commits or PR text in this repository, follow these rules from `docs/contributing/overview.md`:\n\n- Use Conventional Commits: `type(optional scope): description`.\n- Allowed types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`.\n- Write subject in imperative mood and keep it at 50 chars max.\n- Optional body explains **why**, not **how**; wrap at 72 chars.\n- Breaking changes must use `!` in subject and include a `BREAKING CHANGE:` footer.\n- Keep code details in commit message; keep review/process details in PR description.\n- For cross-area work, suggest splitting into self-contained commits when possible.\n- Remind contributors that commits must be signed (GPG/SSH/S/MIME).\n\n## Jira Ticket References\n\nWhen a commit resolves or is tracked by a Jira ticket, place the ticket ID in\nbrackets immediately after `type(scope): `, before the description:\n\n```\ntype(optional scope): [JIRA-XXX] description\n```\n\n- Brackets are required: `[ENF-123]` not `ENF-123`.\n- Place it in the subject only, never in the body or footer.\n- Omit entirely when no Jira ticket applies.\n",".cursor/skills/tracee-testing-guide/unit-test-checklist.md":"# Unit Test Checklist\n\nUse this checklist when creating or revising unit tests in Tracee.\n\n## Design\n\n- test behavior contracts, not implementation internals\n- include at least one failure-path assertion for new logic\n- cover boundary values and empty-input scenarios\n\n## Structure\n\n- keep tests close to source in `*_test.go`\n- prefer table-driven tests for repeated input/output patterns\n- keep test setup minimal and explicit\n\n## Assertions\n\n- use `require` for prerequisites and `assert` for follow-up checks\n- make assertion messages explain the expected behavior\n- avoid brittle assertions based on unrelated formatting or ordering\n\n## Reliability\n\n- clean up resources with `defer`\n- avoid shared mutable state across test cases\n- remove sleeps when deterministic synchronization is possible\n\n## Execution\n\n- iterate quickly:\n  - `make test-unit PKG=<pkg> TEST=<TestName>`\n- verify package:\n  - `make test-unit PKG=<pkg>`\n- verify full suite before finalizing:\n  - `make test-unit`\n\n## Optional Coverage Review\n\n- generate coverage summary:\n  - `make coverage`\n- generate coverage html report:\n  - `make coverage-html`\n",".cursor/skills/tracee-testing-guide/SKILL.md":"---\nname: tracee-testing-guide\ndescription: Run Tracee tests correctly, especially BPF unit tests via make targets. Use when writing tests, debugging test failures, or validating changes before commit.\n---\n\n# Tracee Testing Guide\n\n## Critical Rule\n\nFor BPF-related unit tests, do not run `go test` directly.\nUse `make test-unit` so the required BPF environment is configured.\n\n## When To Use This Skill\n\nUse this skill when:\n- creating new unit tests for changed behavior\n- revising existing `*_test.go` files after refactors\n- fixing flaky tests or false assumptions in assertions\n- tightening coverage for bug fixes\n\n## Fast Development Commands\n\n- All unit tests: `make test-unit`\n- Package-only: `make test-unit PKG=pkg/detectors`\n- Function-only: `make test-unit TEST=TestKernelVersionRequirement_Basic`\n- Function in package: `make test-unit PKG=pkg/ebpf/probes TEST=TestProbeCompatibility_Basic`\n\n## Other Test Suites\n\n- Integration tests: `make test-integration` (root required)\n- E2E tests: `make test-e2e`, `make test-e2e-net`, `make test-e2e-kernel` (root required)\n- Coverage: `make coverage`, `make coverage-html`\n\n## Troubleshooting\n\n- `fatal error: bpf/bpf.h: No such file or directory`\n  - Use `make test-unit` instead of direct `go test`.\n- Slow runs\n  - Use `PKG=` and `TEST=` during iteration.\n- Integration or E2E failures\n  - Verify root privileges and kernel eBPF support.\n\n## Test Authoring Notes\n\n- Use `testify/assert` and `testify/require`.\n- Keep test files near source (`*_test.go`).\n- Prefer explicit cleanup with `defer`.\n- Maintain or improve coverage for changed code.\n\n## Unit Test Creation Workflow\n\n1. Identify the behavior contract and edge cases from changed code.\n2. Add focused test cases first for success path, then error path.\n3. Use table-driven tests when only inputs/expected outputs vary.\n4. Keep each test name descriptive and behavior-based.\n5. Run targeted command first:\n   - `make test-unit PKG=<pkg> TEST=<TestName>`\n6. Run package-wide tests:\n   - `make test-unit PKG=<pkg>`\n7. Before finishing, run broader validation:\n   - `make test-unit`\n\n## Unit Test Revision Workflow\n\nWhen updating existing tests:\n- prefer fixing test intent instead of copying implementation details\n- remove stale assertions tied to old behavior\n- keep failure messages explicit so regressions are easy to diagnose\n- check cleanup paths and goroutine/resource lifecycle assumptions\n\n## Flaky Test Triage Checklist\n\n- verify timing assumptions (timeouts, retries, async ordering)\n- avoid shared mutable global state across tests\n- isolate test inputs from environment-dependent behavior\n- run the test repeatedly with:\n  - `make test-unit PKG=<pkg> TEST=<TestName>`\n\n## Additional Reference\n\nFor a concise checklist to apply during unit test creation and review, see\n[unit-test-checklist.md](unit-test-checklist.md).\n",".cursor/skills/shell-style-guide/SKILL.md":"---\nname: shell-style-guide\ndescription: Enforce Tracee shell standards with shellcheck and shfmt. Use when editing shell scripts, YAML run blocks, or shell code blocks in markdown.\n---\n\n# Shell Style Guide\n\n## Quick Start\n\nApply these requirements for any shell work:\n\n1. ShellCheck must pass with zero errors.\n2. Format with shfmt based on shell type.\n3. Use braces for variable expansion (`${var}`).\n4. Keep `scripts/lib*.sh` POSIX sh compatible.\n\n## Commands\n\n- Bash file:\n  - `shfmt -i 4 -ci -bn -sr -w <file>`\n  - `shellcheck -s bash <file>`\n- POSIX sh file:\n  - `shfmt -p -i 4 -ci -bn -sr -w <file>`\n  - `shellcheck -s sh <file>`\n- Library file:\n  - `shfmt -p -i 4 -ci -bn -sr -w scripts/lib_example.sh`\n  - `shellcheck -s sh -x scripts/lib_example.sh`\n\n## Core Rules\n\n- Use `#!/bin/bash` for executables unless strict POSIX compatibility is required.\n- Use `#!/bin/sh` for `scripts/lib*.sh`.\n- Do not use Bash-only features in POSIX sh (`local`, arrays, `[[ ]]`, process substitution).\n- Quote expansions and use explicit error handling (`set -euo pipefail` for Bash, `set -eu` for POSIX).\n- For POSIX sh helper variables in non-library scripts, use single underscore namespacing.\n\n## Detailed Reference\n\nFor the complete Tracee shell style details, see [reference.md](reference.md).\n",".cursor/rules/markdown-docs-style.mdc":"---\ndescription: Markdown docs style and policy alignment\nglobs:\n  - \"**/*.md\"\nalwaysApply: false\n---\n\n# Markdown Docs Rule\n\nWhen editing markdown docs:\n\n- Keep policy text aligned with canonical project sources.\n- Use normative language consistently (`must`, `should`, `may`).\n- Keep guidance actionable and concise.\n- Avoid duplicating nearby docs; prefer links to canonical references.\n- If policy changes (not only wording), update all affected docs in the same PR.\n- Apply the same standards to man-page markdown sources under `docs/docs/**/man/*.md` and `docs/docs/flags/*.md`.\n",".cursor/rules/text-ascii-safety.mdc":"---\ndescription: Forbid AI typography Unicode and hidden characters in all content\nalwaysApply: false\n---\n\n# Text ASCII Safety\n\nAll new or modified content must be plain ASCII in the allowed ranges:\n`\\x09`, `\\x0A`, and `\\x20-\\x7E`.\n\n- Typographic Unicode and hidden/control characters are forbidden.\n- Run checks only on changed files (staged or diff range), not full-repo scans.\n\n## Changed Files Check\n\n```bash\n.cursor/hooks/ascii-check-changed.sh staged\n```\n",".github/copilot-instructions.md":"# Copilot Instructions for Tracee\n\n## Repository Overview\n\nTracee is a runtime security and observability tool that uses eBPF technology to tap into system activity and expose events ranging from factual system information to sophisticated security detections. It's a large, mature codebase (~500K+ lines) written primarily in Go and C (eBPF), targeting Linux systems with kernel 4.18+.\n\n### Key Technologies\n- **Languages**: Go (1.24+), C (eBPF), Shell scripts\n- **Build Tools**: Make, Clang 12+, Go toolchain\n- **Frameworks**: eBPF/libbpf, gRPC, Kubernetes operators\n- **Target Platforms**: Linux x86_64, aarch64\n\n## Build Instructions & Environment Setup\n\n### Essential Prerequisites\nAlways ensure these requirements before building:\n- **Go 1.24+** (specifically required - earlier versions will fail)\n- **Clang 12+** (minimum version enforced by Makefile)\n- **pkg-config, build-essential, libelf-dev, libzstd-dev** (system packages)\n\n### Core Build Commands\n\n```bash\n# ALWAYS start with environment check\nmake env                    # Shows all environment variables and tool versions\n\n# Basic building (takes 1-2 minutes)\nmake clean                  # Clean all build artifacts first\nmake all                    # Builds tracee, signatures, evt, traceectl\n\n# Individual components\nmake bpf                    # eBPF object only\nmake tracee                 # Main unified binary\nmake signatures             # Go plugin signatures\nmake tracee-bench           # Benchmarking tool\n```\n\n### Testing Commands\n\n```bash\n# Unit tests (takes ~6-8 seconds)\nmake test-unit              # Fast, comprehensive unit tests\n\n# Integration tests (requires root privileges)\nsudo make test-integration  # Some tests skip without root\n\n# Types module testing\nmake test-types             # Separate Go module testing\n\n# Common module testing\nmake test-common            # Common module testing\n```\n\n### Validation & Linting\n\n**IMPORTANT**: Some validation commands require additional tools not installed by default:\n\n```bash\n# Code formatting (NEEDS goimports-reviser, clang-format-19)\nmake check-fmt              # Will fail without proper tools\nmake fix-fmt                # Auto-fix formatting issues\n\n# Other validation\nmake check-vet              # Go vet checks\nmake check-staticcheck      # Static analysis (needs staticcheck tool)\nmake check-err              # Error checking (needs errcheck tool)\nmake check-vulncheck        # Vulnerability checking (needs govulncheck tool)\nmake check-pr               # Full PR validation suite\n```\n\n**Tool Installation**: If you get \"missing required tool\" errors, install via:\n- `goimports-reviser` (v3.12.6): `go install github.com/incu6us/goimports-reviser/v3@fa5587e51ba33c58734984cb41370a5b2582d5b7`\n- `staticcheck` (2025.1): `go install honnef.co/go/tools/cmd/staticcheck@5af2e5fc3b08ba46027eb48ebddeba34dc0bd02c`\n- `errcheck` (v1.9.0): `go install github.com/kisielk/errcheck@11c27a7ce69d583465d80d808817d22d6653ee34`\n- `govulncheck` (v1.1.4): `go install golang.org/x/vuln/cmd/govulncheck@d1f380186385b4f64e00313f31743df8e4b89a77`\n- `clang-format-19`: Use system package manager or download binary\n\n### Build Flags & Options\n\n```bash\nSTATIC=1 make tracee        # Static binary linking\nDEBUG=1 make tracee         # Debug symbols included\nMETRICS=1 make tracee       # Enable BPF metrics\nBTFHUB=1 STATIC=1 make      # Embed BTF for kernel compatibility\n```\n\n### Common Build Issues & Solutions\n\n1. **\"missing required tool\"**: Install the specific tool mentioned in error\n2. **Go version errors**: Must use Go 1.24+, earlier versions fail validation\n3. **Clang version errors**: Must use Clang 12+, checked by Makefile\n4. **Integration test failures**: Many tests require root privileges\n5. **libbpf build failures**: Check system has libelf-dev and build tools\n6. **Permission errors in tests**: Integration tests need `sudo` for eBPF operations\n\n## Project Architecture & Structure\n\n### Core Directories\n\n- **`cmd/`** - Command-line binaries\n  - `tracee/` - Main unified Tracee binary\n  - `evt/` - Event generation and testing tool\n  - `traceectl/` - Control plane client tool (separate Go module)\n\n- **`pkg/`** - Main Go packages and libraries\n  - `ebpf/` - eBPF program management, event processing\n  - `events/` - Event definitions, parsing, filtering\n  - `signatures/` - Signature engine and framework\n  - `policy/` - Policy management and enforcement\n  - `containers/` - Container runtime integration\n  - `proctree/` - Process tree tracking\n  - `filters/` - Event filtering logic\n\n- **`pkg/ebpf/c/`** - eBPF C source code\n  - `tracee.bpf.c` - Main eBPF program\n  - `common/` - Shared headers and utilities\n  - `maps.h`, `types.h` - eBPF data structures\n\n- **`signatures/golang/`** - Detection signatures (Go plugins)\n  - Individual `.go` files implementing specific threat detections\n  - `export.go` - Signature plugin exports\n\n### Build Artifacts\n\nAll build outputs go to `./dist/` directory:\n- `tracee` - Main unified binary\n- `tracee.bpf.o` - Compiled eBPF object\n- `signatures/builtin.so` - Go plugin signatures\n- `libbpf/` - Static libbpf build\n\n### Configuration Files\n\n- **`.revive.toml`** - Go linting configuration (comprehensive rules)\n- **`staticcheck.conf`** - Static analysis configuration\n- **`go.mod`** - Go dependencies (main module)\n- **`types/go.mod`** - Separate types module\n- **`Makefile`** - Primary build configuration (1100+ lines)\n- **`builder/Makefile.checkers`** - Code quality validation\n\n## Continuous Integration & Validation\n\n### PR Workflow (`.github/workflows/pr.yaml`)\nThe PR workflow runs these checks:\n1. **Documentation verification** - Man page sync validation\n2. **Code verification** - Formatting, linting, vet, staticcheck, errcheck, govulncheck\n3. **Build verification** - Multiple tools and components\n4. **Testing** - Unit tests, integration tests, performance tests\n5. **Multi-kernel testing** - Matrix of kernel versions and architectures\n\n### Key Validation Steps\n- **Formatting**: gofmt, clang-format-19, goimports-reviser\n- **Linting**: revive with comprehensive rules\n- **Static Analysis**: staticcheck with custom configuration\n- **Error Checking**: errcheck for unchecked errors\n- **Vulnerability Checking**: govulncheck for known Go vulnerabilities\n- **Architecture Testing**: x86_64 and aarch64 builds\n- **Kernel Compatibility**: Testing across kernel versions 4.18-6.12\n\n### Test Requirements\n- **Unit tests**: Run in any environment, ~6-8 seconds\n- **Integration tests**: Require root privileges for eBPF operations\n- **E2E tests**: Run in CI with specific kernel versions and privileges\n\n## Development Guidelines\n\n### Making Changes\n1. **Always run formatting first**: `make fix-fmt` before commits\n2. **Validate locally**: Use `make check-pr` to run full validation suite\n3. **Test comprehensively**: Run both unit and integration tests when possible\n4. **Check dependencies**: Use `make env` to verify tool versions\n\n### Common Development Patterns\n- **eBPF changes**: Modify files in `pkg/ebpf/c/`, rebuild with `make bpf`\n- **Signature development**: Add new detection rules in `signatures/golang/`\n- **Event processing**: Core logic typically in `pkg/ebpf/` and `pkg/events/`\n- **Testing**: Unit tests alongside source files, E2E tests in `tests/`\n\n### File Locations for Common Tasks\n- **Add new event type**: `pkg/events/core.go`, `pkg/events/definition.go`\n- **Modify eBPF program**: `pkg/ebpf/c/tracee.bpf.c`\n- **Add signature**: New file in `signatures/golang/`\n- **Container integration**: `pkg/containers/`\n- **Policy management**: `pkg/policy/`\n\n## Additional Notes\n\n- **Git submodules**: Repository uses libbpf as submodule (`3rdparty/libbpf/`)\n- **Multi-module**: Main module + separate `types/` module with own `go.mod`\n- **Plugin architecture**: Signatures built as Go plugins loaded at runtime\n- **Cross-compilation**: Supports x86_64 and aarch64 architectures\n- **BTF support**: Can embed BTF for kernel compatibility via BTFHUB=1\n\nTrust these instructions and refer to `make help` for quick command reference. When in doubt about environment setup, always run `make env` first to check tool versions and paths.\n","docs/traceectl/commands/metrics.md":"# Metrics Command Usage\n\nThe `metrics` command in **traceectl** provides information about Tracee's performance and resource usage metrics. This command is helpful for monitoring how Tracee is functioning in real-time.\n\n## Usage\n\nThe `metrics` command is structured as follows:\n\n```sh\ntraceectl metrics \n```\n\n- **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n\n## Examples\n\n- **Display Metrics in Table Format**\n  \n  ```sh\n  traceectl metrics \n  ```\n\n## Summary\n\nThe `metrics` command displays tracee's performance and resource usage metrics. Use this command to monitor Tracee's operational status.\n",".cursor/skills/shell-style-guide/reference.md":"# Tracee Shell Reference\n\nThis reference captures the detailed shell constraints used by Tracee.\nUse it when the task needs exact style behavior beyond the quick checklist.\n\n## Required Tooling\n\n- ShellCheck: zero errors required.\n- shfmt with project flags:\n  - Bash: `shfmt -i 4 -ci -bn -sr -w <file>`\n  - POSIX sh: `shfmt -p -i 4 -ci -bn -sr -w <file>`\n\n## Script Types\n\n- Executables default to Bash (`#!/bin/bash`).\n- Library files `scripts/lib*.sh` must remain POSIX sh (`#!/bin/sh`).\n- Embedded shell blocks in YAML and markdown must be linted/formatted by actual shell mode.\n\n## POSIX Compatibility Notes\n\nIn POSIX sh:\n- Do not use `local`.\n- Do not use arrays.\n- Do not use `[[ ]]`; use `[ ]`.\n- Use `=` for string equality in `[ ]`.\n- Avoid Bash string replacement, regex matching, and process substitution.\n\n## Variable and Naming Rules\n\n- Use `${var}` expansion style.\n- Quote variable expansions by default.\n- In library internals (`scripts/lib*.sh`), reserve `__` namespace for helpers and status variables.\n- In non-library POSIX scripts, use `_function_name_var` style for internal helper variables.\n\n## Validation Workflow\n\nBefore commit:\n1. Format changed shell files with shfmt.\n2. Run ShellCheck in correct mode.\n3. If libraries changed, run `./scripts/lib_test.sh`.\n\n## References\n\n- [Google Shell Style Guide](https://google.github.io/styleguide/shellguide.html)\n- [ShellCheck](https://www.shellcheck.net/)\n- [shfmt](https://github.com/mvdan/sh)\n","docs/traceectl/commands/stream.md":"# Stream Command Usage\n\nThe `stream` command in **traceectl** allows users to stream events directly from Tracee in real time. This command provides flexible output formats for better integration and readability.\n\n## Usage\n\nThe `stream` command is structured as follows:\n\n```sh\ntraceectl stream [flags] [policies]...\n```\n\n- **`[policies]`**: List of policies to stream (default is all policies)\n- **`--format`**: Specifies the format (default is `table`).\n- **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n- **`--output`**: Specifies the output (default is `stdout`)\n\n## Examples\n\n- **Stream Events in JSON Format with a specified policies and a different unix socket**\n  \n  ```sh\n  traceectl stream --format json --server /tmp/tracee.sock policy1 policy2\n  ```\n\n- **Stream Events to file**\n  \n  ```sh\n  traceectl stream --output /path/to/file \n  ```\n\n- **Stream Events in JSON Format**\n  \n  ```sh\n  traceectl stream --format json\n  ```\n\n- **Stream Events in Table Format**\n  \n  ```sh\n  traceectl stream --format table\n  ```\n\n## Summary\n\nThe `stream` command provides a real-time feed of Tracee events, allowing you to monitor system activity as it happens.\n","docs/traceectl/commands/event.md":"# Event Command Usage\n\nThe `event` command in **traceectl** is used for managing events within Tracee. It allows you to list, describe, enable, and disable various event types that Tracee can capture. Below is the usage guide for the `event` command and its subcommands.\n\n## Usage\n\nThe `event` command is structured as follows:\n\n```sh\ntraceectl event [subcommand] [flags]\n```\n\n## Subcommands\n\n- **describe**: Retrieves detailed information about a specific **event** or **all the events**, including its fields, types, and other metadata.\n  \n  ```sh\n  traceectl event describe EVENT\n  ```\n\n  - **`EVENT`**: The name of the event to describe (default is all events).\n  - **`--format`**: Specifies the format (default is `table`).\n  - **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n  - **`--output`**: Specifies the output (default is `stdout`)\n\n- **enable**: Enables capturing of a specific event type in Tracee.\n  \n  ```sh\n  traceectl event enable <event_name>\n  ```\n\n  - **`EVENT`**: The name of the event to enable.\n  - **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n  - **`--output`**: Specifies the output (default is `stdout`)\n\n- **disable**: Disables capturing of a specific event type in Tracee.\n  \n  ```sh\n  traceectl event disable <event_name>\n  ```\n\n  - **`EVENT`**: The name of the event to disable.\n  - **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n  - **`--output`**: Specifies the output (default is `stdout`)\n\n## Examples\n\n- **List All Events in JSON Format**\n  \n  ```sh\n  traceectl event describe --format json\n  ```\n\n- **Describe an Event**\n  \n  ```sh\n  traceectl event describe execve\n  ```\n\n- **Enable an Event**\n  \n  ```sh\n  traceectl event enable execve\n  ```\n\n- **Disable an Event**\n  \n  ```sh\n  traceectl event disable execve\n  ```\n\n## Summary\n\nThe `event` command in traceectl is a powerful tool for managing Tracee's event capabilities. Use the, `describe`, `enable`, and `disable` subcommands to gain detailed insight and control over the events Tracee monitors.\n","docs/traceectl/commands/version.md":"# Version Command\n\nThe `version` command in **traceectl** provides detailed information about the current version of the tool. This includes the version number, build date, and other relevant metadata.\n\n## Usage\n\nTo display the version information, use the following command:\n\n``` bash\ntraceectl version\n```\n\n- **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n\nThis command will output details such as:\n\n- **Version Number**: The current version of traceectl.\n- **Commit Hash**: The Git commit hash associated with the current build (if applicable).\n\n### Example Output\n\n``` bash\nv0.22.0\n```\n\n### Summary\n\n- **`traceectl version`**: Displays detailed version information.\n\nUse this command to verify your version or to gather information for troubleshooting purposes.\n"},"items":[{"name":"reference.md","path":".cursor/skills/shell-style-guide/reference.md","rawUrl":"https://raw.githubusercontent.com/aquasecurity/tracee/HEAD/.cursor/skills/shell-style-guide/reference.md","title":"Shell-style-guide Skill","category":"anthropic-skill","format":"markdown","content":"# Tracee Shell Reference\n\nThis reference captures the detailed shell constraints used by Tracee.\nUse it when the task needs exact style behavior beyond the quick checklist.\n\n## Required Tooling\n\n- ShellCheck: zero errors required.\n- shfmt with project flags:\n  - Bash: `shfmt -i 4 -ci -bn -sr -w <file>`\n  - POSIX sh: `shfmt -p -i 4 -ci -bn -sr -w <file>`\n\n## Script Types\n\n- Executables default to Bash (`#!/bin/bash`).\n- Library files `scripts/lib*.sh` must remain POSIX sh (`#!/bin/sh`).\n- Embedded shell blocks in YAML and markdown must be linted/formatted by actual shell mode.\n\n## POSIX Compatibility Notes\n\nIn POSIX sh:\n- Do not use `local`.\n- Do not use arrays.\n- Do not use `[[ ]]`; use `[ ]`.\n- Use `=` for string equality in `[ ]`.\n- Avoid Bash string replacement, regex matching, and process substitution.\n\n## Variable and Naming Rules\n\n- Use `${var}` expansion style.\n- Quote variable expansions by default.\n- In library internals (`scripts/lib*.sh`), reserve `__` namespace for helpers and status variables.\n- In non-library POSIX scripts, use `_function_name_var` style for internal helper variables.\n\n## Validation Workflow\n\nBefore commit:\n1. Format changed shell files with shfmt.\n2. Run ShellCheck in correct mode.\n3. If libraries changed, run `./scripts/lib_test.sh`.\n\n## References\n\n- [Google Shell Style Guide](https://google.github.io/styleguide/shellguide.html)\n- [ShellCheck](https://www.shellcheck.net/)\n- [shfmt](https://github.com/mvdan/sh)\n","isInternal":false,"tokens":363,"sizeBytes":1468},{"name":"SKILL.md","path":".cursor/skills/shell-style-guide/SKILL.md","rawUrl":"https://raw.githubusercontent.com/aquasecurity/tracee/HEAD/.cursor/skills/shell-style-guide/SKILL.md","title":"shell-style-guide","category":"anthropic-skill","format":"markdown","content":"---\nname: shell-style-guide\ndescription: Enforce Tracee shell standards with shellcheck and shfmt. Use when editing shell scripts, YAML run blocks, or shell code blocks in markdown.\n---\n\n# Shell Style Guide\n\n## Quick Start\n\nApply these requirements for any shell work:\n\n1. ShellCheck must pass with zero errors.\n2. Format with shfmt based on shell type.\n3. Use braces for variable expansion (`${var}`).\n4. Keep `scripts/lib*.sh` POSIX sh compatible.\n\n## Commands\n\n- Bash file:\n  - `shfmt -i 4 -ci -bn -sr -w <file>`\n  - `shellcheck -s bash <file>`\n- POSIX sh file:\n  - `shfmt -p -i 4 -ci -bn -sr -w <file>`\n  - `shellcheck -s sh <file>`\n- Library file:\n  - `shfmt -p -i 4 -ci -bn -sr -w scripts/lib_example.sh`\n  - `shellcheck -s sh -x scripts/lib_example.sh`\n\n## Core Rules\n\n- Use `#!/bin/bash` for executables unless strict POSIX compatibility is required.\n- Use `#!/bin/sh` for `scripts/lib*.sh`.\n- Do not use Bash-only features in POSIX sh (`local`, arrays, `[[ ]]`, process substitution).\n- Quote expansions and use explicit error handling (`set -euo pipefail` for Bash, `set -eu` for POSIX).\n- For POSIX sh helper variables in non-library scripts, use single underscore namespacing.\n\n## Detailed Reference\n\nFor the complete Tracee shell style details, see [reference.md](reference.md).\n","frontmatter":{"name":"shell-style-guide","description":"Enforce Tracee shell standards with shellcheck and shfmt. Use when editing shell scripts, YAML run blocks, or shell code blocks in markdown."},"isInternal":false,"tokens":345,"sizeBytes":1292},{"name":"SKILL.md","path":".cursor/skills/tracee-testing-guide/SKILL.md","rawUrl":"https://raw.githubusercontent.com/aquasecurity/tracee/HEAD/.cursor/skills/tracee-testing-guide/SKILL.md","title":"tracee-testing-guide","category":"anthropic-skill","format":"markdown","content":"---\nname: tracee-testing-guide\ndescription: Run Tracee tests correctly, especially BPF unit tests via make targets. Use when writing tests, debugging test failures, or validating changes before commit.\n---\n\n# Tracee Testing Guide\n\n## Critical Rule\n\nFor BPF-related unit tests, do not run `go test` directly.\nUse `make test-unit` so the required BPF environment is configured.\n\n## When To Use This Skill\n\nUse this skill when:\n- creating new unit tests for changed behavior\n- revising existing `*_test.go` files after refactors\n- fixing flaky tests or false assumptions in assertions\n- tightening coverage for bug fixes\n\n## Fast Development Commands\n\n- All unit tests: `make test-unit`\n- Package-only: `make test-unit PKG=pkg/detectors`\n- Function-only: `make test-unit TEST=TestKernelVersionRequirement_Basic`\n- Function in package: `make test-unit PKG=pkg/ebpf/probes TEST=TestProbeCompatibility_Basic`\n\n## Other Test Suites\n\n- Integration tests: `make test-integration` (root required)\n- E2E tests: `make test-e2e`, `make test-e2e-net`, `make test-e2e-kernel` (root required)\n- Coverage: `make coverage`, `make coverage-html`\n\n## Troubleshooting\n\n- `fatal error: bpf/bpf.h: No such file or directory`\n  - Use `make test-unit` instead of direct `go test`.\n- Slow runs\n  - Use `PKG=` and `TEST=` during iteration.\n- Integration or E2E failures\n  - Verify root privileges and kernel eBPF support.\n\n## Test Authoring Notes\n\n- Use `testify/assert` and `testify/require`.\n- Keep test files near source (`*_test.go`).\n- Prefer explicit cleanup with `defer`.\n- Maintain or improve coverage for changed code.\n\n## Unit Test Creation Workflow\n\n1. Identify the behavior contract and edge cases from changed code.\n2. Add focused test cases first for success path, then error path.\n3. Use table-driven tests when only inputs/expected outputs vary.\n4. Keep each test name descriptive and behavior-based.\n5. Run targeted command first:\n   - `make test-unit PKG=<pkg> TEST=<TestName>`\n6. Run package-wide tests:\n   - `make test-unit PKG=<pkg>`\n7. Before finishing, run broader validation:\n   - `make test-unit`\n\n## Unit Test Revision Workflow\n\nWhen updating existing tests:\n- prefer fixing test intent instead of copying implementation details\n- remove stale assertions tied to old behavior\n- keep failure messages explicit so regressions are easy to diagnose\n- check cleanup paths and goroutine/resource lifecycle assumptions\n\n## Flaky Test Triage Checklist\n\n- verify timing assumptions (timeouts, retries, async ordering)\n- avoid shared mutable global state across tests\n- isolate test inputs from environment-dependent behavior\n- run the test repeatedly with:\n  - `make test-unit PKG=<pkg> TEST=<TestName>`\n\n## Additional Reference\n\nFor a concise checklist to apply during unit test creation and review, see\n[unit-test-checklist.md](unit-test-checklist.md).\n","frontmatter":{"name":"tracee-testing-guide","description":"Run Tracee tests correctly, especially BPF unit tests via make targets. Use when writing tests, debugging test failures, or validating changes before commit."},"isInternal":false,"tokens":662,"sizeBytes":2845},{"name":"unit-test-checklist.md","path":".cursor/skills/tracee-testing-guide/unit-test-checklist.md","rawUrl":"https://raw.githubusercontent.com/aquasecurity/tracee/HEAD/.cursor/skills/tracee-testing-guide/unit-test-checklist.md","title":"Tracee-testing-guide Skill","category":"anthropic-skill","format":"markdown","content":"# Unit Test Checklist\n\nUse this checklist when creating or revising unit tests in Tracee.\n\n## Design\n\n- test behavior contracts, not implementation internals\n- include at least one failure-path assertion for new logic\n- cover boundary values and empty-input scenarios\n\n## Structure\n\n- keep tests close to source in `*_test.go`\n- prefer table-driven tests for repeated input/output patterns\n- keep test setup minimal and explicit\n\n## Assertions\n\n- use `require` for prerequisites and `assert` for follow-up checks\n- make assertion messages explain the expected behavior\n- avoid brittle assertions based on unrelated formatting or ordering\n\n## Reliability\n\n- clean up resources with `defer`\n- avoid shared mutable state across test cases\n- remove sleeps when deterministic synchronization is possible\n\n## Execution\n\n- iterate quickly:\n  - `make test-unit PKG=<pkg> TEST=<TestName>`\n- verify package:\n  - `make test-unit PKG=<pkg>`\n- verify full suite before finalizing:\n  - `make test-unit`\n\n## Optional Coverage Review\n\n- generate coverage summary:\n  - `make coverage`\n- generate coverage html report:\n  - `make coverage-html`\n","isInternal":false,"tokens":237,"sizeBytes":1126},{"name":"commit-pr-conventions.mdc","path":".cursor/rules/commit-pr-conventions.mdc","rawUrl":"https://raw.githubusercontent.com/aquasecurity/tracee/HEAD/.cursor/rules/commit-pr-conventions.mdc","title":"Cursor Rule: commit-pr-conventions","category":"cursor-rule","format":"mdc","content":"---\ndescription: Commit and pull request conventions for Tracee contributors\nalwaysApply: false\n---\n\n# Commit and PR Conventions\n\nWhen preparing commits or PR text in this repository, follow these rules from `docs/contributing/overview.md`:\n\n- Use Conventional Commits: `type(optional scope): description`.\n- Allowed types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`.\n- Write subject in imperative mood and keep it at 50 chars max.\n- Optional body explains **why**, not **how**; wrap at 72 chars.\n- Breaking changes must use `!` in subject and include a `BREAKING CHANGE:` footer.\n- Keep code details in commit message; keep review/process details in PR description.\n- For cross-area work, suggest splitting into self-contained commits when possible.\n- Remind contributors that commits must be signed (GPG/SSH/S/MIME).\n\n## Jira Ticket References\n\nWhen a commit resolves or is tracked by a Jira ticket, place the ticket ID in\nbrackets immediately after `type(scope): `, before the description:\n\n```\ntype(optional scope): [JIRA-XXX] description\n```\n\n- Brackets are required: `[ENF-123]` not `ENF-123`.\n- Place it in the subject only, never in the body or footer.\n- Omit entirely when no Jira ticket applies.\n","frontmatter":{"description":"Commit and pull request conventions for Tracee contributors","alwaysApply":false},"isInternal":false,"tokens":306,"sizeBytes":1256},{"name":"markdown-docs-style.mdc","path":".cursor/rules/markdown-docs-style.mdc","rawUrl":"https://raw.githubusercontent.com/aquasecurity/tracee/HEAD/.cursor/rules/markdown-docs-style.mdc","title":"Cursor Rule: markdown-docs-style","category":"cursor-rule","format":"mdc","content":"---\ndescription: Markdown docs style and policy alignment\nglobs:\n  - \"**/*.md\"\nalwaysApply: false\n---\n\n# Markdown Docs Rule\n\nWhen editing markdown docs:\n\n- Keep policy text aligned with canonical project sources.\n- Use normative language consistently (`must`, `should`, `may`).\n- Keep guidance actionable and concise.\n- Avoid duplicating nearby docs; prefer links to canonical references.\n- If policy changes (not only wording), update all affected docs in the same PR.\n- Apply the same standards to man-page markdown sources under `docs/docs/**/man/*.md` and `docs/docs/flags/*.md`.\n","frontmatter":{"description":"Markdown docs style and policy alignment","globs":["**/*.md"],"alwaysApply":false},"isInternal":false,"tokens":128,"sizeBytes":584},{"name":"text-ascii-safety.mdc","path":".cursor/rules/text-ascii-safety.mdc","rawUrl":"https://raw.githubusercontent.com/aquasecurity/tracee/HEAD/.cursor/rules/text-ascii-safety.mdc","title":"Cursor Rule: text-ascii-safety","category":"cursor-rule","format":"mdc","content":"---\ndescription: Forbid AI typography Unicode and hidden characters in all content\nalwaysApply: false\n---\n\n# Text ASCII Safety\n\nAll new or modified content must be plain ASCII in the allowed ranges:\n`\\x09`, `\\x0A`, and `\\x20-\\x7E`.\n\n- Typographic Unicode and hidden/control characters are forbidden.\n- Run checks only on changed files (staged or diff range), not full-repo scans.\n\n## Changed Files Check\n\n```bash\n.cursor/hooks/ascii-check-changed.sh staged\n```\n","frontmatter":{"description":"Forbid AI typography Unicode and hidden characters in all content","alwaysApply":false},"isInternal":false,"tokens":109,"sizeBytes":461},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/aquasecurity/tracee/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# Copilot Instructions for Tracee\n\n## Repository Overview\n\nTracee is a runtime security and observability tool that uses eBPF technology to tap into system activity and expose events ranging from factual system information to sophisticated security detections. It's a large, mature codebase (~500K+ lines) written primarily in Go and C (eBPF), targeting Linux systems with kernel 4.18+.\n\n### Key Technologies\n- **Languages**: Go (1.24+), C (eBPF), Shell scripts\n- **Build Tools**: Make, Clang 12+, Go toolchain\n- **Frameworks**: eBPF/libbpf, gRPC, Kubernetes operators\n- **Target Platforms**: Linux x86_64, aarch64\n\n## Build Instructions & Environment Setup\n\n### Essential Prerequisites\nAlways ensure these requirements before building:\n- **Go 1.24+** (specifically required - earlier versions will fail)\n- **Clang 12+** (minimum version enforced by Makefile)\n- **pkg-config, build-essential, libelf-dev, libzstd-dev** (system packages)\n\n### Core Build Commands\n\n```bash\n# ALWAYS start with environment check\nmake env                    # Shows all environment variables and tool versions\n\n# Basic building (takes 1-2 minutes)\nmake clean                  # Clean all build artifacts first\nmake all                    # Builds tracee, signatures, evt, traceectl\n\n# Individual components\nmake bpf                    # eBPF object only\nmake tracee                 # Main unified binary\nmake signatures             # Go plugin signatures\nmake tracee-bench           # Benchmarking tool\n```\n\n### Testing Commands\n\n```bash\n# Unit tests (takes ~6-8 seconds)\nmake test-unit              # Fast, comprehensive unit tests\n\n# Integration tests (requires root privileges)\nsudo make test-integration  # Some tests skip without root\n\n# Types module testing\nmake test-types             # Separate Go module testing\n\n# Common module testing\nmake test-common            # Common module testing\n```\n\n### Validation & Linting\n\n**IMPORTANT**: Some validation commands require additional tools not installed by default:\n\n```bash\n# Code formatting (NEEDS goimports-reviser, clang-format-19)\nmake check-fmt              # Will fail without proper tools\nmake fix-fmt                # Auto-fix formatting issues\n\n# Other validation\nmake check-vet              # Go vet checks\nmake check-staticcheck      # Static analysis (needs staticcheck tool)\nmake check-err              # Error checking (needs errcheck tool)\nmake check-vulncheck        # Vulnerability checking (needs govulncheck tool)\nmake check-pr               # Full PR validation suite\n```\n\n**Tool Installation**: If you get \"missing required tool\" errors, install via:\n- `goimports-reviser` (v3.12.6): `go install github.com/incu6us/goimports-reviser/v3@fa5587e51ba33c58734984cb41370a5b2582d5b7`\n- `staticcheck` (2025.1): `go install honnef.co/go/tools/cmd/staticcheck@5af2e5fc3b08ba46027eb48ebddeba34dc0bd02c`\n- `errcheck` (v1.9.0): `go install github.com/kisielk/errcheck@11c27a7ce69d583465d80d808817d22d6653ee34`\n- `govulncheck` (v1.1.4): `go install golang.org/x/vuln/cmd/govulncheck@d1f380186385b4f64e00313f31743df8e4b89a77`\n- `clang-format-19`: Use system package manager or download binary\n\n### Build Flags & Options\n\n```bash\nSTATIC=1 make tracee        # Static binary linking\nDEBUG=1 make tracee         # Debug symbols included\nMETRICS=1 make tracee       # Enable BPF metrics\nBTFHUB=1 STATIC=1 make      # Embed BTF for kernel compatibility\n```\n\n### Common Build Issues & Solutions\n\n1. **\"missing required tool\"**: Install the specific tool mentioned in error\n2. **Go version errors**: Must use Go 1.24+, earlier versions fail validation\n3. **Clang version errors**: Must use Clang 12+, checked by Makefile\n4. **Integration test failures**: Many tests require root privileges\n5. **libbpf build failures**: Check system has libelf-dev and build tools\n6. **Permission errors in tests**: Integration tests need `sudo` for eBPF operations\n\n## Project Architecture & Structure\n\n### Core Directories\n\n- **`cmd/`** - Command-line binaries\n  - `tracee/` - Main unified Tracee binary\n  - `evt/` - Event generation and testing tool\n  - `traceectl/` - Control plane client tool (separate Go module)\n\n- **`pkg/`** - Main Go packages and libraries\n  - `ebpf/` - eBPF program management, event processing\n  - `events/` - Event definitions, parsing, filtering\n  - `signatures/` - Signature engine and framework\n  - `policy/` - Policy management and enforcement\n  - `containers/` - Container runtime integration\n  - `proctree/` - Process tree tracking\n  - `filters/` - Event filtering logic\n\n- **`pkg/ebpf/c/`** - eBPF C source code\n  - `tracee.bpf.c` - Main eBPF program\n  - `common/` - Shared headers and utilities\n  - `maps.h`, `types.h` - eBPF data structures\n\n- **`signatures/golang/`** - Detection signatures (Go plugins)\n  - Individual `.go` files implementing specific threat detections\n  - `export.go` - Signature plugin exports\n\n### Build Artifacts\n\nAll build outputs go to `./dist/` directory:\n- `tracee` - Main unified binary\n- `tracee.bpf.o` - Compiled eBPF object\n- `signatures/builtin.so` - Go plugin signatures\n- `libbpf/` - Static libbpf build\n\n### Configuration Files\n\n- **`.revive.toml`** - Go linting configuration (comprehensive rules)\n- **`staticcheck.conf`** - Static analysis configuration\n- **`go.mod`** - Go dependencies (main module)\n- **`types/go.mod`** - Separate types module\n- **`Makefile`** - Primary build configuration (1100+ lines)\n- **`builder/Makefile.checkers`** - Code quality validation\n\n## Continuous Integration & Validation\n\n### PR Workflow (`.github/workflows/pr.yaml`)\nThe PR workflow runs these checks:\n1. **Documentation verification** - Man page sync validation\n2. **Code verification** - Formatting, linting, vet, staticcheck, errcheck, govulncheck\n3. **Build verification** - Multiple tools and components\n4. **Testing** - Unit tests, integration tests, performance tests\n5. **Multi-kernel testing** - Matrix of kernel versions and architectures\n\n### Key Validation Steps\n- **Formatting**: gofmt, clang-format-19, goimports-reviser\n- **Linting**: revive with comprehensive rules\n- **Static Analysis**: staticcheck with custom configuration\n- **Error Checking**: errcheck for unchecked errors\n- **Vulnerability Checking**: govulncheck for known Go vulnerabilities\n- **Architecture Testing**: x86_64 and aarch64 builds\n- **Kernel Compatibility**: Testing across kernel versions 4.18-6.12\n\n### Test Requirements\n- **Unit tests**: Run in any environment, ~6-8 seconds\n- **Integration tests**: Require root privileges for eBPF operations\n- **E2E tests**: Run in CI with specific kernel versions and privileges\n\n## Development Guidelines\n\n### Making Changes\n1. **Always run formatting first**: `make fix-fmt` before commits\n2. **Validate locally**: Use `make check-pr` to run full validation suite\n3. **Test comprehensively**: Run both unit and integration tests when possible\n4. **Check dependencies**: Use `make env` to verify tool versions\n\n### Common Development Patterns\n- **eBPF changes**: Modify files in `pkg/ebpf/c/`, rebuild with `make bpf`\n- **Signature development**: Add new detection rules in `signatures/golang/`\n- **Event processing**: Core logic typically in `pkg/ebpf/` and `pkg/events/`\n- **Testing**: Unit tests alongside source files, E2E tests in `tests/`\n\n### File Locations for Common Tasks\n- **Add new event type**: `pkg/events/core.go`, `pkg/events/definition.go`\n- **Modify eBPF program**: `pkg/ebpf/c/tracee.bpf.c`\n- **Add signature**: New file in `signatures/golang/`\n- **Container integration**: `pkg/containers/`\n- **Policy management**: `pkg/policy/`\n\n## Additional Notes\n\n- **Git submodules**: Repository uses libbpf as submodule (`3rdparty/libbpf/`)\n- **Multi-module**: Main module + separate `types/` module with own `go.mod`\n- **Plugin architecture**: Signatures built as Go plugins loaded at runtime\n- **Cross-compilation**: Supports x86_64 and aarch64 architectures\n- **BTF support**: Can embed BTF for kernel compatibility via BTFHUB=1\n\nTrust these instructions and refer to `make help` for quick command reference. When in doubt about environment setup, always run `make env` first to check tool versions and paths.\n","isInternal":false,"tokens":2067,"sizeBytes":8132},{"name":"event.md","path":"docs/traceectl/commands/event.md","rawUrl":"https://raw.githubusercontent.com/aquasecurity/tracee/HEAD/docs/traceectl/commands/event.md","title":"Command: /event","category":"command-prompt","format":"markdown","content":"# Event Command Usage\n\nThe `event` command in **traceectl** is used for managing events within Tracee. It allows you to list, describe, enable, and disable various event types that Tracee can capture. Below is the usage guide for the `event` command and its subcommands.\n\n## Usage\n\nThe `event` command is structured as follows:\n\n```sh\ntraceectl event [subcommand] [flags]\n```\n\n## Subcommands\n\n- **describe**: Retrieves detailed information about a specific **event** or **all the events**, including its fields, types, and other metadata.\n  \n  ```sh\n  traceectl event describe EVENT\n  ```\n\n  - **`EVENT`**: The name of the event to describe (default is all events).\n  - **`--format`**: Specifies the format (default is `table`).\n  - **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n  - **`--output`**: Specifies the output (default is `stdout`)\n\n- **enable**: Enables capturing of a specific event type in Tracee.\n  \n  ```sh\n  traceectl event enable <event_name>\n  ```\n\n  - **`EVENT`**: The name of the event to enable.\n  - **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n  - **`--output`**: Specifies the output (default is `stdout`)\n\n- **disable**: Disables capturing of a specific event type in Tracee.\n  \n  ```sh\n  traceectl event disable <event_name>\n  ```\n\n  - **`EVENT`**: The name of the event to disable.\n  - **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n  - **`--output`**: Specifies the output (default is `stdout`)\n\n## Examples\n\n- **List All Events in JSON Format**\n  \n  ```sh\n  traceectl event describe --format json\n  ```\n\n- **Describe an Event**\n  \n  ```sh\n  traceectl event describe execve\n  ```\n\n- **Enable an Event**\n  \n  ```sh\n  traceectl event enable execve\n  ```\n\n- **Disable an Event**\n  \n  ```sh\n  traceectl event disable execve\n  ```\n\n## Summary\n\nThe `event` command in traceectl is a powerful tool for managing Tracee's event capabilities. Use the, `describe`, `enable`, and `disable` subcommands to gain detailed insight and control over the events Tracee monitors.\n","isInternal":false,"tokens":545,"sizeBytes":2119},{"name":"metrics.md","path":"docs/traceectl/commands/metrics.md","rawUrl":"https://raw.githubusercontent.com/aquasecurity/tracee/HEAD/docs/traceectl/commands/metrics.md","title":"Command: /metrics","category":"command-prompt","format":"markdown","content":"# Metrics Command Usage\n\nThe `metrics` command in **traceectl** provides information about Tracee's performance and resource usage metrics. This command is helpful for monitoring how Tracee is functioning in real-time.\n\n## Usage\n\nThe `metrics` command is structured as follows:\n\n```sh\ntraceectl metrics \n```\n\n- **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n\n## Examples\n\n- **Display Metrics in Table Format**\n  \n  ```sh\n  traceectl metrics \n  ```\n\n## Summary\n\nThe `metrics` command displays tracee's performance and resource usage metrics. Use this command to monitor Tracee's operational status.\n","isInternal":false,"tokens":142,"sizeBytes":641},{"name":"stream.md","path":"docs/traceectl/commands/stream.md","rawUrl":"https://raw.githubusercontent.com/aquasecurity/tracee/HEAD/docs/traceectl/commands/stream.md","title":"Command: /stream","category":"command-prompt","format":"markdown","content":"# Stream Command Usage\n\nThe `stream` command in **traceectl** allows users to stream events directly from Tracee in real time. This command provides flexible output formats for better integration and readability.\n\n## Usage\n\nThe `stream` command is structured as follows:\n\n```sh\ntraceectl stream [flags] [policies]...\n```\n\n- **`[policies]`**: List of policies to stream (default is all policies)\n- **`--format`**: Specifies the format (default is `table`).\n- **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n- **`--output`**: Specifies the output (default is `stdout`)\n\n## Examples\n\n- **Stream Events in JSON Format with a specified policies and a different unix socket**\n  \n  ```sh\n  traceectl stream --format json --server /tmp/tracee.sock policy1 policy2\n  ```\n\n- **Stream Events to file**\n  \n  ```sh\n  traceectl stream --output /path/to/file \n  ```\n\n- **Stream Events in JSON Format**\n  \n  ```sh\n  traceectl stream --format json\n  ```\n\n- **Stream Events in Table Format**\n  \n  ```sh\n  traceectl stream --format table\n  ```\n\n## Summary\n\nThe `stream` command provides a real-time feed of Tracee events, allowing you to monitor system activity as it happens.\n","isInternal":false,"tokens":297,"sizeBytes":1200},{"name":"version.md","path":"docs/traceectl/commands/version.md","rawUrl":"https://raw.githubusercontent.com/aquasecurity/tracee/HEAD/docs/traceectl/commands/version.md","title":"Command: /version","category":"command-prompt","format":"markdown","content":"# Version Command\n\nThe `version` command in **traceectl** provides detailed information about the current version of the tool. This includes the version number, build date, and other relevant metadata.\n\n## Usage\n\nTo display the version information, use the following command:\n\n``` bash\ntraceectl version\n```\n\n- **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n\nThis command will output details such as:\n\n- **Version Number**: The current version of traceectl.\n- **Commit Hash**: The Git commit hash associated with the current build (if applicable).\n\n### Example Output\n\n``` bash\nv0.22.0\n```\n\n### Summary\n\n- **`traceectl version`**: Displays detailed version information.\n\nUse this command to verify your version or to gather information for troubleshooting purposes.\n","isInternal":false,"tokens":172,"sizeBytes":809}],"systemPromptSnippet":"<yakaai_skills repo=\"aquasecurity/tracee\">\n<!-- File: .cursor/skills/shell-style-guide/reference.md (Tokens: ~363 | Category: anthropic-skill) -->\n# Tracee Shell Reference\n\nThis reference captures the detailed shell constraints used by Tracee.\nUse it when the task needs exact style behavior beyond the quick checklist.\n\n## Required Tooling\n\n- ShellCheck: zero errors required.\n- shfmt with project flags:\n  - Bash: `shfmt -i 4 -ci -bn -sr -w <file>`\n  - POSIX sh: `shfmt -p -i 4 -ci -bn -sr -w <file>`\n\n## Script Types\n\n- Executables default to Bash (`#!/bin/bash`).\n- Library files `scripts/lib*.sh` must remain POSIX sh (`#!/bin/sh`).\n- Embedded shell blocks in YAML and markdown must be linted/formatted by actual shell mode.\n\n## POSIX Compatibility Notes\n\nIn POSIX sh:\n- Do not use `local`.\n- Do not use arrays.\n- Do not use `[[ ]]`; use `[ ]`.\n- Use `=` for string equality in `[ ]`.\n- Avoid Bash string replacement, regex matching, and process substitution.\n\n## Variable and Naming Rules\n\n- Use `${var}` expansion style.\n- Quote variable expansions by default.\n- In library internals (`scripts/lib*.sh`), reserve `__` namespace for helpers and status variables.\n- In non-library POSIX scripts, use `_function_name_var` style for internal helper variables.\n\n## Validation Workflow\n\nBefore commit:\n1. Format changed shell files with shfmt.\n2. Run ShellCheck in correct mode.\n3. If libraries changed, run `./scripts/lib_test.sh`.\n\n## References\n\n- [Google Shell Style Guide](https://google.github.io/styleguide/shellguide.html)\n- [ShellCheck](https://www.shellcheck.net/)\n- [shfmt](https://github.com/mvdan/sh)\n\n<!-- File: .cursor/skills/shell-style-guide/SKILL.md (Tokens: ~345 | Category: anthropic-skill) -->\n---\nname: shell-style-guide\ndescription: Enforce Tracee shell standards with shellcheck and shfmt. Use when editing shell scripts, YAML run blocks, or shell code blocks in markdown.\n---\n\n# Shell Style Guide\n\n## Quick Start\n\nApply these requirements for any shell work:\n\n1. ShellCheck must pass with zero errors.\n2. Format with shfmt based on shell type.\n3. Use braces for variable expansion (`${var}`).\n4. Keep `scripts/lib*.sh` POSIX sh compatible.\n\n## Commands\n\n- Bash file:\n  - `shfmt -i 4 -ci -bn -sr -w <file>`\n  - `shellcheck -s bash <file>`\n- POSIX sh file:\n  - `shfmt -p -i 4 -ci -bn -sr -w <file>`\n  - `shellcheck -s sh <file>`\n- Library file:\n  - `shfmt -p -i 4 -ci -bn -sr -w scripts/lib_example.sh`\n  - `shellcheck -s sh -x scripts/lib_example.sh`\n\n## Core Rules\n\n- Use `#!/bin/bash` for executables unless strict POSIX compatibility is required.\n- Use `#!/bin/sh` for `scripts/lib*.sh`.\n- Do not use Bash-only features in POSIX sh (`local`, arrays, `[[ ]]`, process substitution).\n- Quote expansions and use explicit error handling (`set -euo pipefail` for Bash, `set -eu` for POSIX).\n- For POSIX sh helper variables in non-library scripts, use single underscore namespacing.\n\n## Detailed Reference\n\nFor the complete Tracee shell style details, see [reference.md](reference.md).\n\n<!-- File: .cursor/skills/tracee-testing-guide/SKILL.md (Tokens: ~662 | Category: anthropic-skill) -->\n---\nname: tracee-testing-guide\ndescription: Run Tracee tests correctly, especially BPF unit tests via make targets. Use when writing tests, debugging test failures, or validating changes before commit.\n---\n\n# Tracee Testing Guide\n\n## Critical Rule\n\nFor BPF-related unit tests, do not run `go test` directly.\nUse `make test-unit` so the required BPF environment is configured.\n\n## When To Use This Skill\n\nUse this skill when:\n- creating new unit tests for changed behavior\n- revising existing `*_test.go` files after refactors\n- fixing flaky tests or false assumptions in assertions\n- tightening coverage for bug fixes\n\n## Fast Development Commands\n\n- All unit tests: `make test-unit`\n- Package-only: `make test-unit PKG=pkg/detectors`\n- Function-only: `make test-unit TEST=TestKernelVersionRequirement_Basic`\n- Function in package: `make test-unit PKG=pkg/ebpf/probes TEST=TestProbeCompatibility_Basic`\n\n## Other Test Suites\n\n- Integration tests: `make test-integration` (root required)\n- E2E tests: `make test-e2e`, `make test-e2e-net`, `make test-e2e-kernel` (root required)\n- Coverage: `make coverage`, `make coverage-html`\n\n## Troubleshooting\n\n- `fatal error: bpf/bpf.h: No such file or directory`\n  - Use `make test-unit` instead of direct `go test`.\n- Slow runs\n  - Use `PKG=` and `TEST=` during iteration.\n- Integration or E2E failures\n  - Verify root privileges and kernel eBPF support.\n\n## Test Authoring Notes\n\n- Use `testify/assert` and `testify/require`.\n- Keep test files near source (`*_test.go`).\n- Prefer explicit cleanup with `defer`.\n- Maintain or improve coverage for changed code.\n\n## Unit Test Creation Workflow\n\n1. Identify the behavior contract and edge cases from changed code.\n2. Add focused test cases first for success path, then error path.\n3. Use table-driven tests when only inputs/expected outputs vary.\n4. Keep each test name descriptive and behavior-based.\n5. Run targeted command first:\n   - `make test-unit PKG=<pkg> TEST=<TestName>`\n6. Run package-wide tests:\n   - `make test-unit PKG=<pkg>`\n7. Before finishing, run broader validation:\n   - `make test-unit`\n\n## Unit Test Revision Workflow\n\nWhen updating existing tests:\n- prefer fixing test intent instead of copying implementation details\n- remove stale assertions tied to old behavior\n- keep failure messages explicit so regressions are easy to diagnose\n- check cleanup paths and goroutine/resource lifecycle assumptions\n\n## Flaky Test Triage Checklist\n\n- verify timing assumptions (timeouts, retries, async ordering)\n- avoid shared mutable global state across tests\n- isolate test inputs from environment-dependent behavior\n- run the test repeatedly with:\n  - `make test-unit PKG=<pkg> TEST=<TestName>`\n\n## Additional Reference\n\nFor a concise checklist to apply during unit test creation and review, see\n[unit-test-checklist.md](unit-test-checklist.md).\n\n<!-- File: .cursor/skills/tracee-testing-guide/unit-test-checklist.md (Tokens: ~237 | Category: anthropic-skill) -->\n# Unit Test Checklist\n\nUse this checklist when creating or revising unit tests in Tracee.\n\n## Design\n\n- test behavior contracts, not implementation internals\n- include at least one failure-path assertion for new logic\n- cover boundary values and empty-input scenarios\n\n## Structure\n\n- keep tests close to source in `*_test.go`\n- prefer table-driven tests for repeated input/output patterns\n- keep test setup minimal and explicit\n\n## Assertions\n\n- use `require` for prerequisites and `assert` for follow-up checks\n- make assertion messages explain the expected behavior\n- avoid brittle assertions based on unrelated formatting or ordering\n\n## Reliability\n\n- clean up resources with `defer`\n- avoid shared mutable state across test cases\n- remove sleeps when deterministic synchronization is possible\n\n## Execution\n\n- iterate quickly:\n  - `make test-unit PKG=<pkg> TEST=<TestName>`\n- verify package:\n  - `make test-unit PKG=<pkg>`\n- verify full suite before finalizing:\n  - `make test-unit`\n\n## Optional Coverage Review\n\n- generate coverage summary:\n  - `make coverage`\n- generate coverage html report:\n  - `make coverage-html`\n\n<!-- File: .cursor/rules/commit-pr-conventions.mdc (Tokens: ~306 | Category: cursor-rule) -->\n---\ndescription: Commit and pull request conventions for Tracee contributors\nalwaysApply: false\n---\n\n# Commit and PR Conventions\n\nWhen preparing commits or PR text in this repository, follow these rules from `docs/contributing/overview.md`:\n\n- Use Conventional Commits: `type(optional scope): description`.\n- Allowed types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`.\n- Write subject in imperative mood and keep it at 50 chars max.\n- Optional body explains **why**, not **how**; wrap at 72 chars.\n- Breaking changes must use `!` in subject and include a `BREAKING CHANGE:` footer.\n- Keep code details in commit message; keep review/process details in PR description.\n- For cross-area work, suggest splitting into self-contained commits when possible.\n- Remind contributors that commits must be signed (GPG/SSH/S/MIME).\n\n## Jira Ticket References\n\nWhen a commit resolves or is tracked by a Jira ticket, place the ticket ID in\nbrackets immediately after `type(scope): `, before the description:\n\n```\ntype(optional scope): [JIRA-XXX] description\n```\n\n- Brackets are required: `[ENF-123]` not `ENF-123`.\n- Place it in the subject only, never in the body or footer.\n- Omit entirely when no Jira ticket applies.\n\n<!-- File: .cursor/rules/markdown-docs-style.mdc (Tokens: ~128 | Category: cursor-rule) -->\n---\ndescription: Markdown docs style and policy alignment\nglobs:\n  - \"**/*.md\"\nalwaysApply: false\n---\n\n# Markdown Docs Rule\n\nWhen editing markdown docs:\n\n- Keep policy text aligned with canonical project sources.\n- Use normative language consistently (`must`, `should`, `may`).\n- Keep guidance actionable and concise.\n- Avoid duplicating nearby docs; prefer links to canonical references.\n- If policy changes (not only wording), update all affected docs in the same PR.\n- Apply the same standards to man-page markdown sources under `docs/docs/**/man/*.md` and `docs/docs/flags/*.md`.\n\n<!-- File: .cursor/rules/text-ascii-safety.mdc (Tokens: ~109 | Category: cursor-rule) -->\n---\ndescription: Forbid AI typography Unicode and hidden characters in all content\nalwaysApply: false\n---\n\n# Text ASCII Safety\n\nAll new or modified content must be plain ASCII in the allowed ranges:\n`\\x09`, `\\x0A`, and `\\x20-\\x7E`.\n\n- Typographic Unicode and hidden/control characters are forbidden.\n- Run checks only on changed files (staged or diff range), not full-repo scans.\n\n## Changed Files Check\n\n```bash\n.cursor/hooks/ascii-check-changed.sh staged\n```\n\n<!-- File: .github/copilot-instructions.md (Tokens: ~2067 | Category: copilot-instructions) -->\n# Copilot Instructions for Tracee\n\n## Repository Overview\n\nTracee is a runtime security and observability tool that uses eBPF technology to tap into system activity and expose events ranging from factual system information to sophisticated security detections. It's a large, mature codebase (~500K+ lines) written primarily in Go and C (eBPF), targeting Linux systems with kernel 4.18+.\n\n### Key Technologies\n- **Languages**: Go (1.24+), C (eBPF), Shell scripts\n- **Build Tools**: Make, Clang 12+, Go toolchain\n- **Frameworks**: eBPF/libbpf, gRPC, Kubernetes operators\n- **Target Platforms**: Linux x86_64, aarch64\n\n## Build Instructions & Environment Setup\n\n### Essential Prerequisites\nAlways ensure these requirements before building:\n- **Go 1.24+** (specifically required - earlier versions will fail)\n- **Clang 12+** (minimum version enforced by Makefile)\n- **pkg-config, build-essential, libelf-dev, libzstd-dev** (system packages)\n\n### Core Build Commands\n\n```bash\n# ALWAYS start with environment check\nmake env                    # Shows all environment variables and tool versions\n\n# Basic building (takes 1-2 minutes)\nmake clean                  # Clean all build artifacts first\nmake all                    # Builds tracee, signatures, evt, traceectl\n\n# Individual components\nmake bpf                    # eBPF object only\nmake tracee                 # Main unified binary\nmake signatures             # Go plugin signatures\nmake tracee-bench           # Benchmarking tool\n```\n\n### Testing Commands\n\n```bash\n# Unit tests (takes ~6-8 seconds)\nmake test-unit              # Fast, comprehensive unit tests\n\n# Integration tests (requires root privileges)\nsudo make test-integration  # Some tests skip without root\n\n# Types module testing\nmake test-types             # Separate Go module testing\n\n# Common module testing\nmake test-common            # Common module testing\n```\n\n### Validation & Linting\n\n**IMPORTANT**: Some validation commands require additional tools not installed by default:\n\n```bash\n# Code formatting (NEEDS goimports-reviser, clang-format-19)\nmake check-fmt              # Will fail without proper tools\nmake fix-fmt                # Auto-fix formatting issues\n\n# Other validation\nmake check-vet              # Go vet checks\nmake check-staticcheck      # Static analysis (needs staticcheck tool)\nmake check-err              # Error checking (needs errcheck tool)\nmake check-vulncheck        # Vulnerability checking (needs govulncheck tool)\nmake check-pr               # Full PR validation suite\n```\n\n**Tool Installation**: If you get \"missing required tool\" errors, install via:\n- `goimports-reviser` (v3.12.6): `go install github.com/incu6us/goimports-reviser/v3@fa5587e51ba33c58734984cb41370a5b2582d5b7`\n- `staticcheck` (2025.1): `go install honnef.co/go/tools/cmd/staticcheck@5af2e5fc3b08ba46027eb48ebddeba34dc0bd02c`\n- `errcheck` (v1.9.0): `go install github.com/kisielk/errcheck@11c27a7ce69d583465d80d808817d22d6653ee34`\n- `govulncheck` (v1.1.4): `go install golang.org/x/vuln/cmd/govulncheck@d1f380186385b4f64e00313f31743df8e4b89a77`\n- `clang-format-19`: Use system package manager or download binary\n\n### Build Flags & Options\n\n```bash\nSTATIC=1 make tracee        # Static binary linking\nDEBUG=1 make tracee         # Debug symbols included\nMETRICS=1 make tracee       # Enable BPF metrics\nBTFHUB=1 STATIC=1 make      # Embed BTF for kernel compatibility\n```\n\n### Common Build Issues & Solutions\n\n1. **\"missing required tool\"**: Install the specific tool mentioned in error\n2. **Go version errors**: Must use Go 1.24+, earlier versions fail validation\n3. **Clang version errors**: Must use Clang 12+, checked by Makefile\n4. **Integration test failures**: Many tests require root privileges\n5. **libbpf build failures**: Check system has libelf-dev and build tools\n6. **Permission errors in tests**: Integration tests need `sudo` for eBPF operations\n\n## Project Architecture & Structure\n\n### Core Directories\n\n- **`cmd/`** - Command-line binaries\n  - `tracee/` - Main unified Tracee binary\n  - `evt/` - Event generation and testing tool\n  - `traceectl/` - Control plane client tool (separate Go module)\n\n- **`pkg/`** - Main Go packages and libraries\n  - `ebpf/` - eBPF program management, event processing\n  - `events/` - Event definitions, parsing, filtering\n  - `signatures/` - Signature engine and framework\n  - `policy/` - Policy management and enforcement\n  - `containers/` - Container runtime integration\n  - `proctree/` - Process tree tracking\n  - `filters/` - Event filtering logic\n\n- **`pkg/ebpf/c/`** - eBPF C source code\n  - `tracee.bpf.c` - Main eBPF program\n  - `common/` - Shared headers and utilities\n  - `maps.h`, `types.h` - eBPF data structures\n\n- **`signatures/golang/`** - Detection signatures (Go plugins)\n  - Individual `.go` files implementing specific threat detections\n  - `export.go` - Signature plugin exports\n\n### Build Artifacts\n\nAll build outputs go to `./dist/` directory:\n- `tracee` - Main unified binary\n- `tracee.bpf.o` - Compiled eBPF object\n- `signatures/builtin.so` - Go plugin signatures\n- `libbpf/` - Static libbpf build\n\n### Configuration Files\n\n- **`.revive.toml`** - Go linting configuration (comprehensive rules)\n- **`staticcheck.conf`** - Static analysis configuration\n- **`go.mod`** - Go dependencies (main module)\n- **`types/go.mod`** - Separate types module\n- **`Makefile`** - Primary build configuration (1100+ lines)\n- **`builder/Makefile.checkers`** - Code quality validation\n\n## Continuous Integration & Validation\n\n### PR Workflow (`.github/workflows/pr.yaml`)\nThe PR workflow runs these checks:\n1. **Documentation verification** - Man page sync validation\n2. **Code verification** - Formatting, linting, vet, staticcheck, errcheck, govulncheck\n3. **Build verification** - Multiple tools and components\n4. **Testing** - Unit tests, integration tests, performance tests\n5. **Multi-kernel testing** - Matrix of kernel versions and architectures\n\n### Key Validation Steps\n- **Formatting**: gofmt, clang-format-19, goimports-reviser\n- **Linting**: revive with comprehensive rules\n- **Static Analysis**: staticcheck with custom configuration\n- **Error Checking**: errcheck for unchecked errors\n- **Vulnerability Checking**: govulncheck for known Go vulnerabilities\n- **Architecture Testing**: x86_64 and aarch64 builds\n- **Kernel Compatibility**: Testing across kernel versions 4.18-6.12\n\n### Test Requirements\n- **Unit tests**: Run in any environment, ~6-8 seconds\n- **Integration tests**: Require root privileges for eBPF operations\n- **E2E tests**: Run in CI with specific kernel versions and privileges\n\n## Development Guidelines\n\n### Making Changes\n1. **Always run formatting first**: `make fix-fmt` before commits\n2. **Validate locally**: Use `make check-pr` to run full validation suite\n3. **Test comprehensively**: Run both unit and integration tests when possible\n4. **Check dependencies**: Use `make env` to verify tool versions\n\n### Common Development Patterns\n- **eBPF changes**: Modify files in `pkg/ebpf/c/`, rebuild with `make bpf`\n- **Signature development**: Add new detection rules in `signatures/golang/`\n- **Event processing**: Core logic typically in `pkg/ebpf/` and `pkg/events/`\n- **Testing**: Unit tests alongside source files, E2E tests in `tests/`\n\n### File Locations for Common Tasks\n- **Add new event type**: `pkg/events/core.go`, `pkg/events/definition.go`\n- **Modify eBPF program**: `pkg/ebpf/c/tracee.bpf.c`\n- **Add signature**: New file in `signatures/golang/`\n- **Container integration**: `pkg/containers/`\n- **Policy management**: `pkg/policy/`\n\n## Additional Notes\n\n- **Git submodules**: Repository uses libbpf as submodule (`3rdparty/libbpf/`)\n- **Multi-module**: Main module + separate `types/` module with own `go.mod`\n- **Plugin architecture**: Signatures built as Go plugins loaded at runtime\n- **Cross-compilation**: Supports x86_64 and aarch64 architectures\n- **BTF support**: Can embed BTF for kernel compatibility via BTFHUB=1\n\nTrust these instructions and refer to `make help` for quick command reference. When in doubt about environment setup, always run `make env` first to check tool versions and paths.\n\n<!-- File: docs/traceectl/commands/event.md (Tokens: ~545 | Category: command-prompt) -->\n# Event Command Usage\n\nThe `event` command in **traceectl** is used for managing events within Tracee. It allows you to list, describe, enable, and disable various event types that Tracee can capture. Below is the usage guide for the `event` command and its subcommands.\n\n## Usage\n\nThe `event` command is structured as follows:\n\n```sh\ntraceectl event [subcommand] [flags]\n```\n\n## Subcommands\n\n- **describe**: Retrieves detailed information about a specific **event** or **all the events**, including its fields, types, and other metadata.\n  \n  ```sh\n  traceectl event describe EVENT\n  ```\n\n  - **`EVENT`**: The name of the event to describe (default is all events).\n  - **`--format`**: Specifies the format (default is `table`).\n  - **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n  - **`--output`**: Specifies the output (default is `stdout`)\n\n- **enable**: Enables capturing of a specific event type in Tracee.\n  \n  ```sh\n  traceectl event enable <event_name>\n  ```\n\n  - **`EVENT`**: The name of the event to enable.\n  - **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n  - **`--output`**: Specifies the output (default is `stdout`)\n\n- **disable**: Disables capturing of a specific event type in Tracee.\n  \n  ```sh\n  traceectl event disable <event_name>\n  ```\n\n  - **`EVENT`**: The name of the event to disable.\n  - **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n  - **`--output`**: Specifies the output (default is `stdout`)\n\n## Examples\n\n- **List All Events in JSON Format**\n  \n  ```sh\n  traceectl event describe --format json\n  ```\n\n- **Describe an Event**\n  \n  ```sh\n  traceectl event describe execve\n  ```\n\n- **Enable an Event**\n  \n  ```sh\n  traceectl event enable execve\n  ```\n\n- **Disable an Event**\n  \n  ```sh\n  traceectl event disable execve\n  ```\n\n## Summary\n\nThe `event` command in traceectl is a powerful tool for managing Tracee's event capabilities. Use the, `describe`, `enable`, and `disable` subcommands to gain detailed insight and control over the events Tracee monitors.\n\n<!-- File: docs/traceectl/commands/metrics.md (Tokens: ~142 | Category: command-prompt) -->\n# Metrics Command Usage\n\nThe `metrics` command in **traceectl** provides information about Tracee's performance and resource usage metrics. This command is helpful for monitoring how Tracee is functioning in real-time.\n\n## Usage\n\nThe `metrics` command is structured as follows:\n\n```sh\ntraceectl metrics \n```\n\n- **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n\n## Examples\n\n- **Display Metrics in Table Format**\n  \n  ```sh\n  traceectl metrics \n  ```\n\n## Summary\n\nThe `metrics` command displays tracee's performance and resource usage metrics. Use this command to monitor Tracee's operational status.\n\n<!-- File: docs/traceectl/commands/stream.md (Tokens: ~297 | Category: command-prompt) -->\n# Stream Command Usage\n\nThe `stream` command in **traceectl** allows users to stream events directly from Tracee in real time. This command provides flexible output formats for better integration and readability.\n\n## Usage\n\nThe `stream` command is structured as follows:\n\n```sh\ntraceectl stream [flags] [policies]...\n```\n\n- **`[policies]`**: List of policies to stream (default is all policies)\n- **`--format`**: Specifies the format (default is `table`).\n- **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n- **`--output`**: Specifies the output (default is `stdout`)\n\n## Examples\n\n- **Stream Events in JSON Format with a specified policies and a different unix socket**\n  \n  ```sh\n  traceectl stream --format json --server /tmp/tracee.sock policy1 policy2\n  ```\n\n- **Stream Events to file**\n  \n  ```sh\n  traceectl stream --output /path/to/file \n  ```\n\n- **Stream Events in JSON Format**\n  \n  ```sh\n  traceectl stream --format json\n  ```\n\n- **Stream Events in Table Format**\n  \n  ```sh\n  traceectl stream --format table\n  ```\n\n## Summary\n\nThe `stream` command provides a real-time feed of Tracee events, allowing you to monitor system activity as it happens.\n\n<!-- File: docs/traceectl/commands/version.md (Tokens: ~172 | Category: command-prompt) -->\n# Version Command\n\nThe `version` command in **traceectl** provides detailed information about the current version of the tool. This includes the version number, build date, and other relevant metadata.\n\n## Usage\n\nTo display the version information, use the following command:\n\n``` bash\ntraceectl version\n```\n\n- **`--server`**: Specifies the server unix socket path (default is `/var/run/tracee.sock`)\n\nThis command will output details such as:\n\n- **Version Number**: The current version of traceectl.\n- **Commit Hash**: The Git commit hash associated with the current build (if applicable).\n\n### Example Output\n\n``` bash\nv0.22.0\n```\n\n### Summary\n\n- **`traceectl version`**: Displays detailed version information.\n\nUse this command to verify your version or to gather information for troubleshooting purposes.\n</yakaai_skills>"}