better-dsh 0.2.5 → 0.3.0-c

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/docs/developer-guide/context-engine-plugin.md

@@ -1,272 +0,0 @@
----
-sidebar_position: 9
-title: "Context Engine Plugins"
-description: "How to build a context engine plugin that replaces the built-in ContextCompressor"
----
-
-# Building a Context Engine Plugin
-
-Context engine plugins replace the built-in `ContextCompressor` with an alternative strategy for managing conversation context. For example, a Lossless Context Management (LCM) engine that builds a knowledge DAG instead of lossy summarization.
-
-## How it works
-
-The agent's context management is built on the `ContextEngine` ABC (`agent/context_engine.py`). The built-in `ContextCompressor` is the default implementation. Plugin engines must implement the same interface.
-
-Only **one** context engine can be active at a time. Selection is config-driven:
-
-```yaml
-# config.yaml
-context:
-  engine: "compressor"    # default built-in
-  engine: "lcm"           # activates a plugin engine named "lcm"
-```
-
-Plugin engines are **never auto-activated** — the user must explicitly set `context.engine` to the plugin's name.
-
-## Directory structure
-
-Each context engine lives in `plugins/context_engine/<name>/`:
-
-```
-plugins/context_engine/lcm/
-├── __init__.py      # exports the ContextEngine subclass
-├── plugin.yaml      # metadata (name, description, version)
-└── ...              # any other modules your engine needs
-```
-
-## The ContextEngine ABC
-
-Your engine must implement these **required** methods:
-
-```python
-from agent.context_engine import ContextEngine
-
-class LCMEngine(ContextEngine):
-
-    @property
-    def name(self) -> str:
-        """Short identifier, e.g. 'lcm'. Must match config.yaml value."""
-        return "lcm"
-
-    def update_from_response(self, usage: dict) -> None:
-        """Called after every LLM call with the usage dict.
-
-        Update self.last_prompt_tokens, self.last_completion_tokens,
-        self.last_total_tokens from the response.
-        """
-
-    def should_compress(self, prompt_tokens: int = None) -> bool:
-        """Return True if compaction should fire this turn."""
-
-    def compress(self, messages: list, current_tokens: int = None,
-                 focus_topic: str = None) -> list:
-        """Compact the message list and return a new (possibly shorter) list.
-
-        The returned list must be a valid OpenAI-format message sequence.
-
-        ``focus_topic`` is an optional topic string from manual
-        ``/compress <focus>``; engines that support guided compression should
-        prioritise preserving information related to it, others may ignore it.
-        """
-```
-
-### Class attributes your engine must maintain
-
-The agent reads these directly for display and logging:
-
-```python
-last_prompt_tokens: int = 0
-last_completion_tokens: int = 0
-last_total_tokens: int = 0
-threshold_tokens: int = 0        # when compression triggers
-context_length: int = 0          # model's full context window
-compression_count: int = 0       # how many times compress() has run
-```
-
-### Optional methods
-
-These have sensible defaults in the ABC. Override as needed:
-
-| Method | Default | Override when |
-|--------|---------|--------------|
-| `on_session_start(session_id, **kwargs)` | No-op | You need to load persisted state (DAG, DB) |
-| `on_session_end(session_id, messages)` | No-op | You need to flush state, close connections |
-| `on_session_reset()` | Resets token counters | You have per-session state to clear |
-| `update_model(model, context_length, ...)` | Updates context_length + threshold | You need to recalculate budgets on model switch |
-| `get_tool_schemas()` | Returns `[]` | Your engine provides agent-callable tools (e.g., `lcm_grep`) |
-| `handle_tool_call(name, args, **kwargs)` | Returns error JSON | You implement tool handlers |
-| `should_compress_preflight(messages)` | Returns `False` | You can do a cheap pre-API-call estimate |
-| `get_status()` | Standard token/threshold dict | You have custom metrics to expose |
-| `select_context(request_messages, *, conversation_messages, incoming_message, budget_tokens)` | Returns `None` (no-op) | You select/route which context enters **this** request (retrieval, topic routing) — see below |
-| `on_turn_complete(messages, usage=None, **kwargs)` | No-op | You ingest/index/observe the finished turn — see below |
-
-## Per-turn context selection and observation
-
-`compress()` answers "context is too long → make it shorter". Two optional,
-no-op-default hooks cover the orthogonal *selection / observation* axis, so an
-engine no longer has to force `should_compress()` to `True` and abuse
-`compress()` as a per-turn callback:
-
-```python
-def select_context(self, request_messages, *, conversation_messages=None,
-                   incoming_message=None, budget_tokens=0):
-    """Choose/replace the context for THIS request, before dispatch.
-
-    Return a new message list to use for this one provider call (retrieval,
-    topic routing, role/branch switching), or None to leave it unchanged.
-    Request-only: the persisted conversation history is never mutated.
-    """
-
-def on_turn_complete(self, messages, usage=None, **kwargs):
-    """Observe a finished turn after the assistant/tool loop completes.
-
-    Receives a shallow copy of the finalized transcript plus the turn's
-    canonical usage dict (or None if no provider response was reached), so the
-    engine can ingest/index/summarize for the next select_context(). The return
-    value is ignored.
-    """
-```
-
-Contract:
-
-- **No-op by default, fail-open.** Both default to `return None`. A missing hook, an exception, or an invalid return value leaves the request untouched — so a failing engine is never worse than not installing one. The host also identity-checks for the inherited ABC default and skips it entirely, so non-implementing engines (including the built-in compressor) pay no per-request work at all.
-- **`select_context()` is request-only.** The returned list replaces the messages for a single provider call; persisted history is never written. Returning `None`, `[]`, a non-list, or a list containing non-dicts all fall open to the unmodified request.
-- **Ordering / cache stability.** The hook runs **before** prompt cache-control and every request sanitizer, so (a) a replacement still passes the same validation as any request, and (b) the no-op default leaves the request byte-identical — prompt-cache behaviour is unchanged for non-implementing engines. An engine that replaces the list changes only its own cache prefix. Evaluated per provider request (re-runs on retries).
-- **`on_turn_complete()`** is post-turn observation only; treat `messages` as read-only. **Coverage is best-effort:** it fires from the standard turn-finalization seam. Some abnormal early-return paths in the loop (e.g. a content-policy block or a provider terminal failure) persist and return without routing through finalization, so they do not currently emit this hook — treat it as a best-effort observation for completed turns, not a guaranteed callback for every early exit. Unifying all terminal paths behind one finalization seam is a separate follow-up.
-
-### When to use these hooks — and when NOT to
-
-- **Implement `select_context()` only when your engine must *replace* the
-  per-request context** — retrieval-augmented selection, topic/branch routing,
-  role switching. It is the only verb that can swap which messages enter a
-  request: the `pre_llm_call` plugin hook is inject-only by documented design
-  (it appends to the user message and never rewrites the list, to preserve the
-  prompt-cache prefix). If you don't need replacement, don't implement it.
-- **If your plugin only needs post-turn observation / ingestion** (indexing,
-  memory sync, analytics), implement a **memory provider** (`sync_turn()` —
-  see [Memory Provider Plugins](./memory-provider-plugin.md)) instead of a
-  context engine. A context engine takes ownership of the session's compaction
-  policy; a memory provider observes turns without owning anything.
-  `on_turn_complete()` exists as the observation mirror for engines that
-  *already* need `select_context()` — so the same component can learn from the
-  turn it just routed — not as a general-purpose turn callback.
-- **Prompt-cache impact of a real `select_context()`.** A non-no-op selection
-  naturally changes the prompt-cache prefix for the turns where it changes the
-  selection — that request's prefix no longer matches the provider's cached
-  prefix, so those turns re-write cache instead of reading it. Engines should
-  return **stable selections when nothing has changed** (same object or an
-  equal list), and only reshape the context when the routing decision actually
-  differs; a selection that shuffles per turn silently forfeits cache reuse
-  every turn.
-
-## Engine tools
-
-Context engines can expose tools the agent calls directly. Return schemas from `get_tool_schemas()` and handle calls in `handle_tool_call()`:
-
-```python
-def get_tool_schemas(self):
-    return [{
-        "name": "lcm_grep",
-        "description": "Search the context knowledge graph",
-        "parameters": {
-            "type": "object",
-            "properties": {
-                "query": {"type": "string", "description": "Search query"}
-            },
-            "required": ["query"],
-        },
-    }]
-
-def handle_tool_call(self, name, args, **kwargs):
-    if name == "lcm_grep":
-        results = self._search_dag(args["query"])
-        return json.dumps({"results": results})
-    return json.dumps({"error": f"Unknown tool: {name}"})
-```
-
-Engine tools are injected into the agent's tool list at startup and dispatched automatically — no registry registration needed.
-
-## Registration
-
-### Via directory (recommended)
-
-Place your engine in `plugins/context_engine/<name>/`. The `__init__.py` must export a `ContextEngine` subclass. The discovery system finds and instantiates it automatically.
-
-### Via general plugin system
-
-A general plugin can also register a context engine:
-
-```python
-def register(ctx):
-    engine = LCMEngine(context_length=200000)
-    ctx.register_context_engine(engine)
-```
-
-Only one engine can be registered. A second plugin attempting to register is rejected with a warning.
-
-## Lifecycle
-
-```
-1. Engine instantiated (plugin load or directory discovery)
-2. on_session_start() — conversation begins
-3. update_from_response() — after each API call
-4. should_compress() — checked each turn
-5. compress() — called when should_compress() returns True
-6. on_session_end() — session boundary (CLI exit, /reset, gateway shutdown)
-```
-
-`on_session_reset()` is called on `/new` or `/reset` to clear per-session state without a full shutdown.
-
-## Configuration
-
-Users select your engine via `hermes plugins` → Provider Plugins → Context Engine, or by editing `config.yaml`:
-
-```yaml
-context:
-  engine: "lcm"   # must match your engine's name property
-```
-
-The `compression` config block (`compression.threshold`, `compression.protect_last_n`, etc.) is specific to the built-in `ContextCompressor`, with one explicit exception: `compression.model_thresholds` (per-model threshold overrides) is part of the context-engine contract. The host assigns the resolved map to `engine.model_thresholds` *before* the initial `update_model()` call, and the base-class `update_model()` applies it (longest substring match, falling back to the engine's configured threshold). Engines that override `update_model()` own their own compaction policy and may honor or ignore the map — `from agent.context_compressor import resolve_model_threshold` to reuse the same resolution logic. For everything else, your engine should define its own config format if needed, reading from `config.yaml` during initialization.
-
-## Testing
-
-```python
-from agent.context_engine import ContextEngine
-
-def test_engine_satisfies_abc():
-    engine = YourEngine(context_length=200000)
-    assert isinstance(engine, ContextEngine)
-    assert engine.name == "your-name"
-
-def test_compress_returns_valid_messages():
-    engine = YourEngine(context_length=200000)
-    msgs = [{"role": "user", "content": "hello"}]
-    result = engine.compress(msgs)
-    assert isinstance(result, list)
-    assert all("role" in m for m in result)
-```
-
-See `tests/agent/test_context_engine.py` for the full ABC contract test suite.
-
-## Thread safety
-
-When `compression.context_timeout_seconds > 0` (the default), Hermes runs the
-whole compression pass — including your engine's `compress()` and boundary
-callbacks, and any memory provider's `on_pre_compress` /
-`on_session_switch` — on a pooled daemon thread with a host-side timeout.
-Your engine must therefore assume:
-
-- Calls may arrive on an arbitrary pooled thread. Do not rely on thread
-  affinity or `threading.local` state shared with the conversation thread.
-- The message list you receive is a private deep snapshot; mutating it in
-  place is allowed (legacy contract), but the mutation only becomes visible
-  if the pass commits. After a host timeout your still-running work is
-  discarded — never publish to external/durable state outside the commit.
-- Passes for *different* sessions can run concurrently on pool siblings; a
-  single engine/provider instance shared across sessions must be thread-safe.
-
-## See also
-
-- [Context Compression and Caching](/developer-guide/context-compression-and-caching) — how the built-in compressor works
-- [Memory Provider Plugins](/developer-guide/memory-provider-plugin) — analogous single-select plugin system for memory
-- [Plugins](/user-guide/features/plugins) — general plugin system overview

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/docs/developer-guide/contributing.md

@@ -1,303 +0,0 @@
----
-sidebar_position: 4
-title: "Contributing"
-description: "How to contribute to Hermes Agent — dev setup, code style, PR process"
----
-
-# Contributing
-
-Thank you for contributing to Hermes Agent! This guide covers setting up your dev environment, understanding the codebase, and getting your PR merged.
-
-## Contribution Priorities
-
-We value contributions in this order:
-
-1. **Bug fixes** — crashes, incorrect behavior, data loss
-2. **Cross-platform compatibility** — macOS, different Linux distros, WSL2
-3. **Security hardening** — shell injection, prompt injection, path traversal
-4. **Performance and robustness** — retry logic, error handling, graceful degradation
-5. **New skills** — broadly useful ones (see [Creating Skills](creating-skills.md))
-6. **New tools** — rarely needed; most capabilities should be skills
-7. **Documentation** — fixes, clarifications, new examples
-
-## Common contribution paths
-
-- Building a custom/local tool without modifying Hermes core? Start with [Build a Hermes Plugin](../developer-guide/plugins/index.md)
-- Building a new built-in core tool for Hermes itself? Start with [Adding Tools](./adding-tools.md)
-- Building a new skill? Start with [Creating Skills](./creating-skills.md)
-- Building a new inference provider? Start with [Adding Providers](./adding-providers.md)
-
-## Development Setup
-
-### Prerequisites
-
-| Requirement          | Notes                                                                                         |
-| -------------------- | --------------------------------------------------------------------------------------------- |
-| **Git**              | With the `git-lfs` extension installed                                                        |
-| **Python 3.11–3.13** | uv will install it if missing                                                                 |
-| **uv**               | Fast Python package manager ([install](https://docs.astral.sh/uv/))                           |
-| **Node.js 26+**      | Optional — needed for browser tools and WhatsApp bridge (matches root `package.json` engines) |
-
-### Install with the standard installer
-
-For most contributors, the best development bootstrap is the same path users
-take: run the standard installer, then work inside the repository it cloned.
-The installer creates the Hermes venv, wires the `hermes` command, stamps the
-install method for `hermes update`, and clones the full git project into
-`$HERMES_HOME/hermes-agent` (usually `~/.hermes/hermes-agent`). That keeps your
-development environment on the same layout the CLI, updater, lazy dependency
-installer, gateway, and docs assume.
-
-```bash
-curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
-cd "${HERMES_HOME:-$HOME/.hermes}/hermes-agent"
-
-# Add dev/test extras on top of the standard install.
-uv pip install -e ".[all,dev]"
-
-# Optional: browser tools / docs site dependencies.
-npm install
-```
-
-After that, create branches and run tests from that checkout:
-
-```bash
-git checkout -b fix/description
-scripts/run_tests.sh
-```
-
-You can also run a fully isolated Hermes instance (throwaway HERMES_HOME, separate Electron
-userData, distinct Electron app name to avoid the single-instance lock):
-
-```bash
-scripts/dev-sandbox.sh python -m hermes_cli.main
-scripts/dev-sandbox.sh --persistent python -m hermes_cli.main desktop  # state survives restarts, but lives in the worktree :)
-```
-
-### Manual clone fallback
-
-Use this only if you intentionally do not want Hermes' managed install layout
-(for example, a throwaway clone inside a container or CI job). If you install
-this way, make sure you run the `hermes` entrypoint from this venv; running the
-system `python3 -m hermes_cli.main` can pick up unrelated system Python
-packages.
-
-Create the venv **outside** the cloned source tree. A venv that lives inside
-the directory the agent operates from can be wiped by a relative-path command
-the agent runs against its own checkout (`rm -rf venv`, `uv venv venv`, etc.),
-which silently destroys the running runtime mid-session. Keeping it outside the
-tree means no relative path from the workspace resolves to it.
-
-```bash
-git clone https://github.com/NousResearch/hermes-agent.git
-cd hermes-agent
-
-# Create venv with Python 3.11, OUTSIDE the source tree
-uv venv ~/.hermes/venvs/hermes-dev --python 3.11
-export VIRTUAL_ENV="$HOME/.hermes/venvs/hermes-dev"
-export PATH="$VIRTUAL_ENV/bin:$PATH"
-
-# Install with all extras (messaging, cron, CLI menus, dev tools)
-uv pip install -e ".[all,dev]"
-
-# Optional: browser tools
-npm install
-```
-
-### Configure for Development
-
-```bash
-mkdir -p ~/.hermes/{cron,sessions,logs,memories,skills}
-cp cli-config.yaml.example ~/.hermes/config.yaml
-touch ~/.hermes/.env
-
-# Add at minimum an LLM provider key:
-echo 'OPENROUTER_API_KEY=sk-or-v1-your-key' >> ~/.hermes/.env
-```
-
-### Run
-
-```bash
-# The standard installer already put `hermes` on PATH.
-hermes doctor
-hermes chat -q "Hello"
-```
-
-If you used the manual clone fallback, run `./hermes` from the checkout or
-symlink this clone's venv explicitly:
-
-```bash
-mkdir -p ~/.local/bin
-ln -sf "$(pwd)/venv/bin/hermes" ~/.local/bin/hermes
-```
-
-### Run Tests
-
-```bash
-scripts/run_tests.sh
-```
-
-## Code Style
-
-- **PEP 8** with practical exceptions (no strict line length enforcement)
-- **Comments**: Only when explaining non-obvious intent, trade-offs, or API quirks
-- **Error handling**: Catch specific exceptions. Use `logger.warning()`/`logger.error()` with `exc_info=True` for unexpected errors
-- **Cross-platform**: Never assume Unix (see below)
-- **Profile-safe paths**: Never hardcode `~/.hermes` — use `get_hermes_home()` from `hermes_constants` for code paths and `display_hermes_home()` for user-facing messages. See [AGENTS.md](https://github.com/NousResearch/hermes-agent/blob/main/AGENTS.md#profiles-multi-instance-support) for full rules.
-
-## Cross-Platform Compatibility
-
-See **[Platform Support](../getting-started/platform-support.md)**. Native Windows uses Git Bash (from [Git for Windows](https://git-scm.com/download/win)) for shell commands. A few features require POSIX kernel primitives and are gated: the dashboard's embedded PTY terminal pane (`/chat` tab) needs a POSIX PTY (Linux, macOS, or WSL2). If you're doing Windows-heavy dev, run the Windows-footgun lint (`scripts/check-windows-footguns.py`) before pushing.
-
-When contributing code, keep these rules in mind:
-
-- **Don't add unguarded `signal.SIGKILL` references.** It's not defined on Windows. Either route through `gateway.status.terminate_pid(pid, force=True)` (the centralized primitive that does `taskkill /T /F` on Windows and SIGKILL on POSIX), or fall back with `getattr(signal, "SIGKILL", signal.SIGTERM)`.
-- **Catch `OSError` alongside `ProcessLookupError` on `os.kill(pid, 0)` probes.** Windows raises `OSError` (WinError 87, "parameter is incorrect") for an already-gone PID instead of `ProcessLookupError`.
-- **Don't force the terminal to POSIX semantics.** `os.setsid`, `os.killpg`, `os.getpgid`, `os.fork` all raise on Windows — gate them with `if sys.platform != "win32":` or `if os.name != "nt":`.
-- **Open files with an explicit `encoding="utf-8"`.** The Python default on Windows is the system locale (often cp1252), which mojibakes or crashes on non-Latin text.
-- **Use `pathlib.Path` / `os.path.join` — never manually concat with `/`.** This matters less for strings the OS gives us back and more for strings we construct to hand to subprocesses.
-
-Key patterns:
-
-### 1. File encoding
-
-Some environments may save `.env` files in non-UTF-8 encodings:
-
-```python
-try:
-    load_dotenv(env_path)
-except UnicodeDecodeError:
-    load_dotenv(env_path, encoding="latin-1")
-```
-
-### 2. Process management
-
-`os.setsid()`, `os.killpg()`, and signal handling differ across platforms:
-
-```python
-import platform
-if platform.system() != "Windows":
-    kwargs["preexec_fn"] = os.setsid
-```
-
-### 3. Path separators
-
-Use `pathlib.Path` instead of string concatenation with `/`.
-
-## Security Considerations
-
-Hermes has terminal access. Security matters.
-
-### Existing Protections
-
-| Layer                           | Implementation                                                              |
-| ------------------------------- | --------------------------------------------------------------------------- |
-| **Sudo password piping**        | Uses `shlex.quote()` to prevent shell injection                             |
-| **Dangerous command detection** | Regex patterns in `tools/approval.py` with user approval flow               |
-| **Cron prompt injection**       | Scanner blocks instruction-override patterns                                |
-| **Write deny list**             | Protected paths resolved via `os.path.realpath()` to prevent symlink bypass |
-| **Skills guard**                | Security scanner for hub-installed skills                                   |
-| **Code execution sandbox**      | Child process runs with API keys stripped                                   |
-| **Container hardening**         | Docker: all capabilities dropped, no privilege escalation, PID limits       |
-
-### Contributing Security-Sensitive Code
-
-- Always use `shlex.quote()` when interpolating user input into shell commands
-- Resolve symlinks with `os.path.realpath()` before access control checks
-- Don't log secrets
-- Catch broad exceptions around tool execution
-- Test on all platforms if your change touches file paths or processes
-
-## Pull Request Process
-
-### Branch Naming
-
-```
-fix/description        # Bug fixes
-feat/description       # New features
-docs/description       # Documentation
-test/description       # Tests
-refactor/description   # Code restructuring
-```
-
-### Before Submitting
-
-1. **Run tests**: `scripts/run_tests.sh` for CI-parity. Use direct `python -m pytest ...` only when the wrapper is unavailable or you are intentionally debugging outside the wrapper.
-2. **Test manually**: Run `hermes` and exercise the code path you changed
-3. **Check cross-platform impact**: Consider macOS, Linux, WSL2, and native Windows. If you touch file I/O, process management, terminal handling, subprocesses, or signals, run `scripts/check-windows-footguns.py`.
-4. **Keep PRs focused**: One logical change per PR
-
-### PR Description
-
-Include:
-
-- **What** changed and **why**
-- **How to test** it
-- **What platforms** you tested on
-- Reference any related issues
-
-### Commit Messages
-
-We use [Conventional Commits](https://www.conventionalcommits.org/):
-
-```
-<type>(<scope>): <description>
-```
-
-| Type       | Use for                       |
-| ---------- | ----------------------------- |
-| `fix`      | Bug fixes                     |
-| `feat`     | New features                  |
-| `docs`     | Documentation                 |
-| `test`     | Tests                         |
-| `refactor` | Code restructuring            |
-| `chore`    | Build, CI, dependency updates |
-
-Scopes: `cli`, `gateway`, `tools`, `skills`, `agent`, `install`, `whatsapp`, `security`
-
-Examples:
-
-```
-fix(cli): prevent crash in save_config_value when model is a string
-feat(gateway): add WhatsApp multi-user session isolation
-fix(security): prevent shell injection in sudo password piping
-```
-
-### Repo-local review checklists: `.agents/checks/*.md`
-
-Projects built on (or reviewed by) Hermes can keep reviewer checklists inside the repository under `.agents/checks/`. Each file is a focused, plain-markdown checklist that an agent loads before reviewing a change touching the matching area:
-
-```
-.agents/
-  checks/
-    security.md        # e.g. "grep the diff for shell interpolation; check subprocess calls quote args"
-    migrations.md      # e.g. "every schema change ships a backfill and a rollback note"
-    public-api.md      # e.g. "exported signatures changed? flag for semver review"
-```
-
-Conventions that make these work well:
-
-- **One concern per file**, named after the concern. Small files get read in full; a monolithic `checklist.md` gets skimmed.
-- **Write checks as verifiable actions** ("run X and confirm Y"), not aspirations ("code should be secure").
-- **State the trigger at the top** — which paths or change types the checklist applies to — so an agent (or human) can skip irrelevant ones cheaply.
-- Keep them in version control next to the code they guard: they evolve with the codebase, and a PR that changes the rules changes the checklist in the same diff.
-
-When you ask Hermes to review a PR in a repository that has `.agents/checks/`, tell it (or teach it via a skill) to read the relevant checklists first and report against them. This gives review agents the project-specific bar that generic review prompts miss.
-
-## Reporting Issues
-
-- Use [GitHub Issues](https://github.com/NousResearch/hermes-agent/issues)
-- Include: OS, Python version, Hermes version (`hermes --version`), full error traceback
-- Include steps to reproduce
-- Check existing issues before creating duplicates
-- For security vulnerabilities, please report privately
-
-## Community
-
-- **Discord**: [discord.gg/NousResearch](https://discord.gg/NousResearch)
-- **GitHub Discussions**: For design proposals and architecture discussions
-- **Skills Hub**: Upload specialized skills and share with the community
-
-## License
-
-By contributing, you agree that your contributions will be licensed under the [MIT License](https://github.com/NousResearch/hermes-agent/blob/main/LICENSE).