-
Notifications
You must be signed in to change notification settings - Fork 2
developer contribution guide
Thank you for contributing to Siyarix. Please read and follow these guidelines.
- Python 3.11+
- Git
- Familiarity with
asyncio, type hints, andpytest - GitHub account
git clone https://github.com/YOUR-USERNAME/siyarix.git
cd siyarix
python -m venv .venv
# source .venv/bin/activate (Linux/macOS)
# .\.venv\Scripts\Activate.ps1 (Windows)
pip install -e ".[all,cli,siem,dev]"- Find or create an issue — discuss significant changes before starting
- Create a branch:
git checkout -b feat/my-feature - Make changes following code conventions
- Run quality checks:
pytest # Run tests (asyncio_mode=auto) ruff check src/ tests/ # Lint mypy src/siyarix/ # Type check (strict mode)
- Commit with conventional commit message (DCO signed)
- Push and open a pull request targeting
main
- PEP 8 as enforced by Ruff (line length: 100)
- Type hints on all public functions and methods
-
from __future__ import annotationsat top of every module - Dataclasses for structured data
-
asynciofor I/O-bound operations
| Element | Convention | Example |
|---|---|---|
| Classes | PascalCase | ExecutionEngine |
| Functions | snake_case | get_health() |
| Variables | snake_case | scan_target |
| Constants | UPPER_CASE | DEFAULTS |
| Private | Leading underscore | _get_engine() |
Group in order separated by blank lines:
- Standard library (
os,sys,asyncio) - Third-party (
typer,rich,pydantic) - Internal (
siyarix.config,.audit_log)
- Raise
SiyarixExceptionsubclasses for domain errors - Use specific exception types; avoid bare
except: - Map exceptions to exit codes via
exit_code_for()
Follow Conventional Commits:
<type>(<scope>): <description>
[optional body]
[optional footer]
| Type | Usage |
|---|---|
feat |
New feature |
fix |
Bug fix |
docs |
Documentation |
test |
Adding/updating tests |
refactor |
Code change (neither fix nor add) |
perf |
Performance improvement |
style |
Formatting, linting (no logic change) |
ci |
CI/CD configuration |
chore |
Build, dependencies, tooling |
security |
Security fix or hardening |
Every commit must include a Signed-off-by trailer certifying the Developer Certificate of Origin:
git commit -s -m "type(scope): description"- All tests pass:
pytest -q - Lint clean:
ruff check src/ tests/ - Type checks pass:
mypy src/siyarix/ - New functionality includes tests
- Changed behavior includes documentation updates
Include what changed, why (link to issue), how it was tested, and screenshots/logs for UI changes.
- At least one maintainer review required
- CI must pass (tests, lint, type check, security scan)
- Address review feedback promptly
- Create a provider profile in
src/siyarix/providers/profiles/ - Register in
ProviderManager - Add API key environment variable to setup docs
- Add tests in
tests/test_providers.py - Update provider lists in documentation
- Create parser in
src/siyarix/parsers/implementingBaseParserprotocol - Register in
ParserRegistry - Add test fixtures with sample tool output
- Add tests in
tests/test_parsers/
- Follow SECURITY.md for vulnerability disclosure
- Standard PRs welcome for non-critical hardening
- Contributors credited in release notes (with permission)
- You are responsible for all submitted code regardless of authorship method
- Disclose AI assistance in PR description if majority was AI-generated
- AI-generated code must follow all project standards and include tests
- Maintainers may request modifications to AI-generated contributions
By contributing, you agree that your contributions are licensed under AGPL-3.0-or-later. Every commit must be DCO-signed.
- Confirm your employer's open-source contribution policy
- By signing off, you represent you have authorization to contribute under AGPL-3.0-or-later
- Do not submit proprietary code without explicit written permission
- Use your personal GitHub account
Third-party plugins in ~/.siyarix/plugins/ are not required to be AGPL-licensed. See Plugin Exception.
Every source file must include:
# SPDX-License-Identifier: AGPL-3.0-or-laterNote
👋 Welcome to Siyarix! This is a personal passion project built by a single developer. It's currently under active development and growing fast. Expect rough edges, but lots of love! ❤️
Welcome to the Siyarix Documentation Map! This page serves as your master compass for navigating the extensive documentation we have built for the platform.
Whether you are a brand new user, a seasoned security operator, or a developer looking to contribute to the core engine, you can find exactly what you need here.
Not sure where to start? Pick the path that best describes you:
Just getting started? We highly recommend following these guides in order:
- Installation Guide — Get Siyarix running on your machine.
- Onboarding Wizard — Let our interactive wizard help you set up your API keys and environment.
- Setup & Configuration — A deeper dive into customizing your setup.
- Your First Run — A gentle walkthrough of your very first Siyarix command.
Ready to put Siyarix to work? Dive into our operational guides:
- Interactive Chat (REPL) — Learn how to use the powerful interactive terminal.
- Security Workflows — Best practices for recon, vulnerability assessment, and incident response.
- Cloud & IaC Scanning — How to secure your cloud environments and infrastructure code.
- Compliance Frameworks — Map your scans to SOC 2, HIPAA, ISO 27001, and more.
Looking under the hood or wanting to write some code? Start here:
- Contribution Guide — Our workflow, standards, and how you can help!
- Codebase Overview — A comprehensive map of our 82+ source modules.
- Testing Standards — How we ensure reliability with pytest and CI/CD.
- Module Architecture — Component design and responsibilities.
If you prefer to browse the raw structure, here is a complete layout of the docs/ folder:
docs/
├── 🚀 getting-started/ # Installation, onboarding, and configuration
│ ├── installation.md # Multi-platform install (pip, brew, winget, docker)
│ ├── onboarding.md # The interactive 11-step setup wizard
│ ├── setup.md # Managing API keys, credentials, and settings
│ ├── first-run.md # A walkthrough of your first session
│ ├── configuration.md # A deep-dive into advanced settings
│ └── troubleshooting.md # Common issues and how to fix them instantly
│
├── 📖 user/ # Daily operations and workflows
│ ├── cli-commands.md # Reference for 50+ CLI commands across 12 groups
│ ├── interactive-chat.md # Mastering the AI REPL and 54+ slash commands
│ ├── security-workflows.md # Recon, vulnerability assessment, incident response
│ ├── cloud-scanning.md # Multi-cloud security scanning (under development)
│ ├── compliance.md # Framework mapping (SOC 2, NIST, GDPR, PCI-DSS)
│ ├── threat-intelligence.md# Integrations with OTX, NVD, and MITRE ATT&CK
│ ├── playbooks.md # Building automated YAML-based IR playbooks
│ ├── workflow-files.md # DAG workflow reference (programmatic API)
│ ├── reporting.md # Multi-format report generation
│ ├── offline-registry.md # Running without AI (Offline/Registry execution mode)
│ └── ai-workflows.md # Advanced AI-driven autonomous operations
│
├── 💻 developer/ # Building, testing, and extending Siyarix
│ ├── codebase-overview.md # Full module structure mapping
│ ├── contribution-guide.md # How to submit PRs and our coding standards
│ ├── module-architecture.md# Component design and responsibilities
│ ├── testing.md # Writing tests (pytest), coverage, and CI/CD
│ └── building.md # Packaging, distribution, and Docker builds
│
├── 🏗️ architecture/ # System design and core internals
│ ├── overview.md # High-level data flow and layered orchestration
│ ├── ai-agent-pipeline.md # The AgentCore reasoning and execution pipeline
│ ├── provider-abstraction.md# How we unify 26 different AI providers
│ ├── execution-engine.md # Plan-based step orchestration
│ ├── memory-and-state.md # Knowledge graph, session persistence, and learning
│ ├── security-model.md # The Permission Gate, DLP, audit logging, and OPSEC
│ └── intent-routing.md # Semantic intent classification and routing
│
├── 🧠 ai/ # Deep dive into the AI provider & agent systems
│ ├── routing.md # Managing 26 providers, failovers, and circuit breakers
│ ├── persona-system.md # Overview of our 10 security personas
│ ├── agent-reasoning.md # The Observe-Reason-Act loop and tool call repair
│ ├── tool-execution.md # The tool registry, capability graph, and parsers
│ ├── ensemble.md # Parallel LLM voting strategies
│ ├── multi-wave.md # Iterative goal execution with context carry-over
│ ├── prompt-architecture.md# System prompt design and management
│ └── safety.md # Our rigorous 8-layer hallucination mitigation system
│
├── 🛡️ security/ # Safety, ethics, and threat models
│ ├── reporting.md # How to safely report vulnerabilities to us
│ ├── threat-model.md # System threat model and our mitigations
│ ├── operational-security.md# TOR routing, stealth modes, and OPSEC controls
│ ├── ethical-policy.md # Mandatory rules of engagement for all users
│ └── abuse-prevention.md # How we prevent misuse of the AI engine
│
└── ⚖️ legal/ # Licensing and governance
├── agpl-guide.md # A plain-English overview of the AGPL-3.0-or-later license
├── why-agpl.md # The philosophy behind our license choice
├── trademark-policy.md # Branding and trademark guidelines
├── responsible-ai.md # Our framework for ethical AI usage
├── disclaimer.md # Important legal disclaimers
└── plugin-exception.md # The license exception for building custom plugins
As you read through the documentation, you might encounter some specific terms. Here is a quick cheat sheet:
| Term | What It Means |
|---|---|
| Provider | The backend AI engine powering Siyarix (e.g., OpenAI, Anthropic, Ollama). |
| Tool | A traditional security executable installed on your system (e.g., nmap, nuclei). |
| Plan | A step-by-step sequence of tool commands intelligently generated by the AI. |
| Workflow | A hardcoded, predefined execution path (usually defined in YAML/JSON) that doesn't require AI generation. |
| Persona | A specialized behavioral profile given to the AI (e.g., instructing it to act specifically as a "Network Recon Specialist"). |
| Knowledge Graph | Siyarix's internal memory where it stores findings (like IP addresses, open ports) to contextually inform future steps. |
Need help finding something specific? Feel free to use the search bar at the top of the documentation site, or open a discussion on our GitHub!