slopgate
CLAUDE.md1 starsChanged 51 days agoMITView on GitHub
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…
- Commits and pushes
We split this CLAUDE.md into the rules it gives an agent
24 rules. About 0 are common, 7 are distinctive, and 17 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
17
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 16
MUST run impact analysis before editing any symbol: Before modifying a function, class, or method, run gitnexus_impact({target: …
- Distinctive: line 18
MUST warn the user: if impact analysis returns HIGH or CRITICAL risk before proceeding with edits.
- Very specific: line 19
When exploring unfamiliar code, use gitnexus_query({query: "concept"}) to find execution flows instead of grepping.
- Very specific: line 20
When you need full context on a specific symbol — callers, callees, which execution flows it participates in — use gitnexus_context({name: …
- Very specific: line 24
NEVER edit a function, class, or method without first running gitnexus_impact on it.
- Distinctive: line 25
NEVER ignore HIGH or CRITICAL risk warnings from impact analysis.
- Very specific: line 26
NEVER rename symbols with find-and-replace — use gitnexus_rename which understands the call graph.
- Very specific: line 27
NEVER commit changes without running gitnexus_detect_changes() to check affected scope.
- Very specific: line 68
Use bd for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists
- Very specific: line 69
Run bd prime for detailed command reference and session close protocol
- Very specific: line 70
Use bd remember for persistent knowledge — do NOT use MEMORY.md files
- Very specific: line 78
Conservative (default): Use bd for task tracking. Do not run git commits, git pushes, or Dolt remote sync unless explicitly asked.
- Very specific: line 79
Minimal: Keep tool instruction files as pointers to bd prime.
- Distinctive: line 80
Team-maintainer: Only when the repository explicitly opts in, agents may close beads, run quality gates, commit, and push as part of …
- Distinctive: line 86
File issues for remaining work: - Create beads for anything that needs follow-up
- Distinctive: line 103
Do not commit or push without clear authority from the active profile or the current user request.
- Distinctive: line 104
If a required sync or push is blocked, stop and report the exact command and error.
- Very specific: line 111
Follow .agents/skills/_shared/core/execution-policy.md for authorization, clarification, verification, and completion.
- Very specific: line 113
SSOT: Do not modify .agents/ definitions (skills, workflows, rules, agents, config) directly.
- Very specific: line 114
Response language: Follow language in .agents/oma-config.yaml.
- Very specific: line 115
Skills: Read the relevant .agents/skills/{name}/SKILL.md when needed.
- Distinctive: line 117
Write non-ASCII tool-call parameters as literal UTF-8, not Unicode escapes.
- Very specific: line 129
Run workflows only when explicitly requested or detected by a hook.
- Very specific: line 133
Read the relevant file from .agents/rules/ when working on matching code.
≈ “Common” is an estimate: at least 1 in 5 of the 25,680 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Git remotes
- Push to GitLab only:
origin(https://lab.baked.rocks/claude/slopgate.git). Never push to thegithubremote. - Exception:
make publish(PyPI release) pushes the release tag and branch to bothoriginandgithub. - Beads syncs over the same GitLab remote (
refs/dolt/dataviabd dolt push).
<!-- gitnexus:start -->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 statusfrom the repository root first. Only after status confirms staleness and an index write is approved, run./scripts/gitnexus analyze; never usenpx,pnpm dlx, orbunxfallback commands, never run analyze concurrently with another index writer, and never add--forcewithout 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_impacton it. - NEVER ignore HIGH or CRITICAL risk warnings from impact analysis.
- NEVER rename symbols with find-and-replace — use
gitnexus_renamewhich understands the call graph. - NEVER commit changes without running
gitnexus_detect_changes()to check affected scope.
Resources
| Resource | Use for |
gitnexus://repo/slopgate/context | Codebase overview, check index freshness |
gitnexus://repo/slopgate/clusters | All functional areas |
gitnexus://repo/slopgate/processes | All execution flows |
gitnexus://repo/slopgate/process/{name} | Step-by-step execution trace |
CLI
| Task | Read this skill file |
| Understand architecture / "How does X work?" | .claude/skills/gitnexus/gitnexus-exploring/SKILL.md |
| Blast radius / "What breaks if I change X?" | .claude/skills/gitnexus/gitnexus-impact-analysis/SKILL.md |
| Trace bugs / "Why is X failing?" | .claude/skills/gitnexus/gitnexus-debugging/SKILL.md |
| Rename / extract / split / refactor | .claude/skills/gitnexus/gitnexus-refactoring/SKILL.md |
| Tools, resources, schema reference | .claude/skills/gitnexus/gitnexus-guide/SKILL.md |
| Index, status, clean, wiki CLI commands | .claude/skills/gitnexus/gitnexus-cli/SKILL.md |
<!-- gitnexus:end --><!-- BEGIN BEADS INTEGRATION v:1 profile:minimal hash:6cd5cc61 -->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 workRules
- Use
bdfor ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists - Run
bd primefor detailed command reference and session close protocol - Use
bd rememberfor 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
bdfor 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.
- File issues for remaining work - Create beads for anything that needs follow-up
- Run quality gates (if code changed) - Tests, linters, builds
- Update issue status - Close finished work, update in-progress items
- 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 git push git status - 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.
<!-- END BEADS INTEGRATION --><!-- OMA:START — managed by oh-my-agent. Do not edit this block manually. -->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
languagein.agents/oma-config.yaml. - Skills: Read the relevant
.agents/skills/{name}/SKILL.mdwhen needed. - Subagents: Same-vendor native dispatch via Claude Code Agent tool with
.claude/agents/{name}.md; cross-vendor fallback viaoma agent spawn - Write non-ASCII tool-call parameters as literal UTF-8, not Unicode escapes.
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.
| Rule | File | Scope |
| backend | .agents/rules/backend.md | on request |
| commit | .agents/rules/commit.md | on request |
| database | .agents/rules/database.md | **/*.{sql,prisma} |
| debug | .agents/rules/debug.md | on request |
| design | .agents/rules/design.md | on request |
| dev-workflow | .agents/rules/dev-workflow.md | on request |
| frontend | .agents/rules/frontend.md | **/*.{tsx,jsx,css,scss} |
| i18n-arb | .agents/rules/i18n-arb.md | **/*.arb |
| i18n-guide | .agents/rules/i18n-guide.md | always |
| infrastructure | .agents/rules/infrastructure.md | **/*.{tf,tfvars,hcl} |
| market | .agents/rules/market.md | on request |
| mobile | .agents/rules/mobile.md | **/*.{dart,swift,kt} |
| quality | .agents/rules/quality.md | on request |
<!-- OMA:END -->In this repository115 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .cursor/rules/backend.mdcCursor rule
- .cursor/rules/commit.mdcCursor rule
- .cursor/rules/database.mdcCursor rule
- .cursor/rules/debug.mdcCursor rule
- .cursor/rules/design.mdcCursor rule
- .cursor/rules/dev-workflow.mdcCursor rule
- .cursor/rules/frontend.mdcCursor rule
- .cursor/rules/i18n-arb.mdcCursor rule
- .cursor/rules/i18n-guide.mdcCursor rule
- .cursor/rules/infrastructure.mdcCursor rule
- .cursor/rules/market.mdcCursor rule
- .cursor/rules/mobile.mdcCursor rule
- .cursor/rules/quality.mdcCursor rule
- beadsSkill
- gitnexus-area-adaptersSkill
- gitnexus-area-cliSkill
- gitnexus-area-contextSkill
- gitnexus-area-dashboardSkill
- gitnexus-area-detectorsSkill
- gitnexus-area-engineSkill
- gitnexus-area-enrichmentSkill
- gitnexus-area-hooksSkill
- gitnexus-area-installerSkill
- gitnexus-area-integrationSkill
- gitnexus-area-lintSkill
- gitnexus-area-payloadsSkill
- gitnexus-area-project-indexSkill
- gitnexus-area-resourcesSkill
- gitnexus-area-rules-2Skill
- gitnexus-area-rulesSkill
- gitnexus-area-scriptsSkill
- gitnexus-area-test-smellsSkill
- gitnexus-area-testsSkill
- gitnexus-area-uiSkill
- gitnexus-cliSkill
- gitnexus-debuggingSkill
- gitnexus-exploringSkill
- gitnexus-guideSkill
- gitnexus-impact-analysisSkill
- gitnexus-refactoringSkill
- impeccableSkill
- oma-academic-writingSkill
- oma-architectureSkill
- oma-backendSkill
- oma-brainstormSkill
- oma-coordinationSkill
- oma-dbSkill
- oma-debugSkill
- oma-deepsecSkill
- oma-designSkill
- oma-dev-workflowSkill
- oma-docsSkill
- oma-explanationSkill
- oma-frontendSkill
- oma-hwpSkill
- oma-imageSkill
- oma-marketSkill
- oma-mobileSkill
- oma-observabilitySkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

