Slopgate — rule engine, installers, adapters, lint detectors.

Scope

• Source of truth for rule defs / platform capability mapping.
• Bundle shared agent assets under bundle/, not scattershot into ~/.claude.
• slopgate install owns harness hook wiring; bundle fragments merge, never symlink over CLAUDE.md.
• Check target repo for slopgate.toml enrollment, not just this repo.

Platform reality

• Claude Code: richest hook surface, nearest full parity.
• Codex: partial hook model; document conservatively.
• OpenCode: plugin/event translation, not Claude-style schema.
• OMP: extension shim like Pi; enforcement via session_stop continuation; install to .omp paths.

Docs

• Keep README aligned with upstream docs; prefer "partial"/"best-effort" over parity claims.

Git remotes

• Push to GitLab only: origin (https://lab.baked.rocks/claude/slopgate.git). Never push to the github remote.
• Exception: make publish (PyPI release) pushes the release tag and branch to both origin and github.
• Beads syncs over the same GitLab remote (refs/dolt/data via bd dolt push).

GitNexus — Code Intelligence

This project is indexed by GitNexus as slopgate (19038 symbols, 32403 relationships, 300 execution flows). Use the GitNexus MCP tools to understand code, assess impact, and navigate safely.

If any GitNexus tool warns the index is stale, run ./scripts/gitnexus status from the repository root first. Only after status confirms staleness and an index write is approved, run ./scripts/gitnexus analyze; never use npx, pnpm dlx, or bunx fallback commands, never run analyze concurrently with another index writer, and never add --force without explicit approval.

Always Do

• MUST run impact analysis before editing any symbol. Before modifying a function, class, or method, run gitnexus_impact({target: "symbolName", direction: "upstream"}) and report the blast radius (direct callers, affected processes, risk level) to the user.
• MUST run gitnexus_detect_changes() before committing to verify your changes only affect expected symbols and execution flows.
• MUST warn the user if impact analysis returns HIGH or CRITICAL risk before proceeding with edits.
• When exploring unfamiliar code, use gitnexus_query({query: "concept"}) to find execution flows instead of grepping. It returns process-grouped results ranked by relevance.
• When you need full context on a specific symbol — callers, callees, which execution flows it participates in — use gitnexus_context({name: "symbolName"}).

Never Do

• NEVER edit a function, class, or method without first running gitnexus_impact on it.
• NEVER ignore HIGH or CRITICAL risk warnings from impact analysis.
• NEVER rename symbols with find-and-replace — use gitnexus_rename which understands the call graph.
• NEVER commit changes without running gitnexus_detect_changes() to check affected scope.

Resources

CLI

Beads Issue Tracker

This project uses bd (beads) for issue tracking. Run bd prime to see full workflow context and commands.

Quick Reference

bd ready              # Find available work
bd show <id>          # View issue details
bd update <id> --claim  # Claim work
bd close <id>         # Complete work

Rules

• Use bd for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists
• Run bd prime for detailed command reference and session close protocol
• Use bd remember for persistent knowledge — do NOT use MEMORY.md files

Architecture in one line: issues live in a local Dolt DB; sync uses refs/dolt/data on your git remote; .beads/issues.jsonl is a passive export. See https://github.com/gastownhall/beads/blob/main/docs/SYNC_CONCEPTS.md for details and anti-patterns.

Agent Context Profiles

The managed Beads block is task-tracking guidance, not permission to override repository, user, or orchestrator instructions.

• Conservative (default): Use bd for task tracking. Do not run git commits, git pushes, or Dolt remote sync unless explicitly asked. At handoff, report changed files, validation, and suggested next commands.
• Minimal: Keep tool instruction files as pointers to bd prime; use the same conservative git policy unless active instructions say otherwise.
• Team-maintainer: Only when the repository explicitly opts in, agents may close beads, run quality gates, commit, and push as part of session close. A current "do not commit" or "do not push" instruction still wins.

Session Completion

This protocol applies when ending a Beads implementation workflow. It is subordinate to explicit user, repository, and orchestrator instructions.

1. File issues for remaining work - Create beads for anything that needs follow-up
2. Run quality gates (if code changed) - Tests, linters, builds
3. Update issue status - Close finished work, update in-progress items
4. Handle git/sync by active profile:

   # Conservative/minimal/default: report status and proposed commands; wait for approval.
   git status
   
   # Team-maintainer opt-in only, unless current instructions forbid it:
   git pull --rebase
   bd dolt push
   git push
   git status

5. Hand off - Summarize changes, validation, issue status, and any blocked sync/commit/push step

Critical rules:

• Explicit user or orchestrator instructions override this Beads block.
• Do not commit or push without clear authority from the active profile or the current user request.
• If a required sync or push is blocked, stop and report the exact command and error.

Beads Issue Tracker

Use Beads (bd) for durable task tracking in repositories that include it. Use the beads skill at .agents/skills/beads/SKILL.md (project install) or ~/.agents/skills/beads/SKILL.md (global install) for Beads workflow guidance, then use the bd CLI for issue operations.

Quick Reference

bd ready                # Find available work
bd show <id>            # View issue details
bd update <id> --claim  # Claim work
bd close <id>           # Complete work
bd prime                # Refresh Beads context

Rules

• Use bd for all task tracking; do not create markdown TODO lists.
• Run bd prime when Beads context is missing or stale. Codex 0.129.0+ can load Beads context automatically through native hooks; use /hooks to inspect or toggle them.
• Keep persistent project memory in Beads via bd remember; do not create ad hoc memory files.

Architecture in one line: issues live in a local Dolt DB; sync uses refs/dolt/data on your git remote; .beads/issues.jsonl is a passive export. See https://github.com/gastownhall/beads/blob/main/docs/SYNC_CONCEPTS.md for details and anti-patterns.

oh-my-agent

Follow .agents/skills/_shared/core/execution-policy.md for authorization, clarification, verification, and completion. System/developer instructions and the user's request take precedence over OMA defaults. Never build, compile, bundle, or package software unless the user explicitly requests a build.

• SSOT: Do not modify .agents/ definitions (skills, workflows, rules, agents, config) directly. Run outputs under .agents/results/ and .agents/state/ are generated artifacts and may be written.
• Response language: Follow language in .agents/oma-config.yaml.
• Skills: Read the relevant .agents/skills/{name}/SKILL.md when needed.
• Subagents:
  • codex: Same-vendor native dispatch via Codex custom agents in .codex/agents/{name}.toml; cross-vendor fallback via oma agent spawn
  • cursor: @agent-name (defined in .cursor/agents/)
  • pi: pi has no native subagent API; use oma agent spawn {agent} {prompt} {sessionId} --vendor pi for CLI subprocess dispatch

Per-Agent Dispatch

Resolve each agent from .agents/oma-config.cue or .agents/oma-config.yaml, overlaid by .agents/oma-config.local.cue or .agents/oma-config.local.yaml when present. With model_preset: free, always use oma agent spawn so the subprocess receives the FreeLLMAPI route; free.model replaces per-agent model pins. Otherwise, explicit agents: overrides take priority. With model_preset: auto, follow the current vendor's native agent/model settings; use default_cli only when the runtime is unknown. Use native subagents when the target matches the current runtime; otherwise, or when native dispatch is unavailable, use oma agent spawn.

Code Search

Serena MCP is required for code search and discovery. Load deferred tools before use. Use native search/read only when Serena is unavailable or times out, or for plain non-code content.

Workflows

Run workflows only when explicitly requested or detected by a hook; never self-initiate. Read and follow .agents/workflows/{name}.md. Continue active workflows until complete or explicitly cancelled.

Project Rules

Read the relevant file from .agents/rules/ when working on matching code.