Skip to content

AGENTS.md

Latest commit

 

History

History
38 lines (30 loc) · 2.32 KB

AGENTS.md

File metadata and controls

38 lines (30 loc) · 2.32 KB
Raw

ShellRoute Node — Agent Instructions

Forked mysterium node — WireGuard/netstack, proxyclient, P2P, connection manager.

Repo layout

All ShellRoute repos live under ~/dev/shellroute/ as siblings:

Path What
shellroute/ API server, admin UI, dashboard, docker-compose
shellroute-cli/ CLI — open source
gateway/ Proxy gateway
node/ Forked mysterium node (this repo)
homebrew-tap/ Homebrew formula
shellroute.com/ Marketing site (Astro)

Agent Rules

  • Questions are questions. When the user asks a question, answer it. Do not start implementing or changing code — just answer.
  • Commit after each change. Stage only the files you changed — never git add -A or git add .. Commit with a concise Conventional Commit message.
  • No AI attribution. Never add Co-Authored-By, Generated by, or any agent/AI credit lines in commit messages.
  • No subagents unless asked. Do not spawn background or parallel agents unless the user explicitly requests it. Do the work directly.
  • Never git add -A or git add .. Always stage specific files by name.
  • Never git push. Only commit locally. The user decides when and where to push.
  • Never create or switch branches. Work on whatever branch is currently checked out. If the current branch seems wrong, ask — don't switch.
  • Never work on main / master directly. All work must happen on a feature or wip branch. If you find yourself on main/master, stop and tell the user before making any commits.
  • This is a fork. Upstream is mysteriumnetwork/node. Be careful with changes that diverge from upstream — they make future rebases harder. Prefer minimal, targeted edits.
  • Keep files under ~500 LOC. Split when needed.
  • Conventional Commits (feat|fix|refactor|docs|test|chore|build|ci|perf|style).

Rules

  1. No dead code. When replacing a function or code path, delete the old code immediately.
  2. Never delete tests without approval. Convert tests to work with new implementation — don't delete them.
  3. Don't assume architecture or requirements. When unsure, ask the developer.
  4. Find the root cause. Don't rationalize broken behavior as expected.
  5. Research before acting. Confirm the original path is truly impossible before proposing workarounds.