agent-code-intel
AGENTS.md0 starsChanged 2 months agoMITView on GitHub
This project is indexed by GitNexus as agent-code-intel (1558 symbols, 3883 relationships, 62 execution flows). Index stale? Run node .gitnexus/run.cjs analyze --index-only from the project root — it auto-selects an available runner. No .gitnexus/run.cjs yet? Bootstrap with npx, bunx, or pnpm dlx — e.g. bunx gitnexus@latest analyze (npm 11 npx crash; #1939). Use the repo-scoped agent-code-intel-routing skill for code exploration, debugging, reviews, refactoring, implementation, architecture, and dependency analysis. Codex discovers it automatically; other agents must read .agents/skills/agent-code-intel-routing/SKILL.md. The skill is…
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,774 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository17 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- agent-code-intel-routingSkill
- code-contextSkill
- gitnexus-cliSkill
- gitnexus-debuggingSkill
- gitnexus-exploringSkill
- gitnexus-guideSkill
- gitnexus-impact-analysisSkill
- gitnexus-refactoringSkill
- agent-code-intel-routingSkill
- code-contextSkill
- gitnexus-cliSkill
- gitnexus-debuggingSkill
- gitnexus-exploringSkill
- gitnexus-guideSkill
- gitnexus-impact-analysisSkill
- gitnexus-refactoringSkill
The file
Show its rules and text
We split this AGENTS.md into the rules it gives an agent
13 rules. About 0 are common, 3 are distinctive, and 10 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
10
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 10
MUST run impact before editing: Use impact({target: "symbolName", direction: "upstream"}) or node .gitnexus/run.cjs impact "symbolName" …
- Very specific: line 11
MUST analyze graph changes before committing: Use detect_changes({scope: "all"}) (MCP) or node .gitnexus/run.cjs detect-changes --scope all …
- Very specific: line 12
MUST warn on HIGH/CRITICAL risk pre-edit.
- Distinctive: line 19
NEVER edit a function, class, or method before MCP/CLI impact analysis.
- Very specific: line 20
NEVER ignore HIGH or CRITICAL risk warnings from impact analysis, and never read UNKNOWN as an all-clear — it means the walk could not …
- Very specific: line 21
NEVER rename symbols with find-and-replace — use rename which understands the call graph.
- Distinctive: line 22
NEVER commit before MCP/CLI graph change analysis.
- Very specific: line 48
Use the repo-scoped agent-code-intel-routing skill for code exploration, debugging, reviews, refactoring, implementation, architecture, and …
- Very specific: line 55
Never hand-edit .grepai/config.yaml.
- Very specific: line 58
After a task changes code, run agent-code-intel --refresh from the project root.
- Very specific: line 63
Before reading a source file, use the code-context skill: derive the exact definition range with ctags instead of guessing a line window, …
- Very specific: line 70
When a change is finished and a user would notice it — behaviour or a default changes, a bug is fixed, a flag/message/exit code/JSON key …
- Distinctive: line 83
Not every edit earns an entry.
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.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
<!-- gitnexus:start -->GitNexus — Code Intelligence
This project is indexed by GitNexus as agent-code-intel (1558 symbols, 3883 relationships, 62 execution flows).
Index stale? Run
node .gitnexus/run.cjs analyze --index-onlyfrom the project root — it auto-selects an available runner. No.gitnexus/run.cjsyet? Bootstrap withnpx,bunx, orpnpm dlx— e.g.bunx gitnexus@latest analyze(npm 11 npx crash; #1939).
Always Do
- MUST run impact before editing. Use
impact({target: "symbolName", direction: "upstream"})ornode .gitnexus/run.cjs impact "symbolName" --direction upstream --repo .; report callers, processes, and risk. Never substitute grep for graph analysis. - MUST analyze graph changes before committing. Use
detect_changes({scope: "all"})(MCP) ornode .gitnexus/run.cjs detect-changes --scope all --repo .(CLI fallback).partial: trueortruncated: trueis not a clean check — a zero means unseen, not unaffected; re-run it. For regression review:detect_changes({scope: "compare", base_ref: "main"})ornode .gitnexus/run.cjs detect-changes --scope compare --base-ref "main" --repo .. - MUST warn on HIGH/CRITICAL
riskpre-edit; never useriskSharedAxesto waive a HIGH/CRITICALriskwarning. Compare File/symbol: MCP File omits axes; Graph-RAG expands File. - MUST treat
risk: UNKNOWNas unresolved, not as low. An empty caller set is not evidence the symbol is unused — it can also mean the callers are not resolvable by the index (plain-object property access, dynamic dispatch, cross-language calls).impactpairsUNKNOWNwith ariskNotesaying so. Confirm with a text search before treating the symbol as safe to change or delete; do not proceed on the strength of a zero. - MUST use
query({search_query: "concept"})for concepts/flows,context({name: "symbolName"})for a named symbol, orimpactfor blast radius, on read-only callers, dependencies, imports, or execution flow. Graph first; text search only for empty/UNKNOWN/literals. - For security review,
explain({target: "fileOrSymbol"})lists taint findings (source→sink flows; needsanalyze --pdg).
Never Do
- NEVER edit a function, class, or method before MCP/CLI impact analysis.
- NEVER ignore HIGH or CRITICAL risk warnings from impact analysis, and never read
UNKNOWNas an all-clear — it means the walk could not answer, which is the one verdict that requires confirming by other means. - NEVER rename symbols with find-and-replace — use
renamewhich understands the call graph. - NEVER commit before MCP/CLI graph change analysis.
Resources
| Resource | Use for |
gitnexus://repo/agent-code-intel/context | Codebase overview, check index freshness |
gitnexus://repo/agent-code-intel/clusters | All functional areas |
gitnexus://repo/agent-code-intel/processes | All execution flows |
gitnexus://repo/agent-code-intel/process/{name} | Step-by-step execution trace |
CLI
| Task | Read this skill file |
| Understand architecture / "How does X work?" | .claude/skills/gitnexus-exploring/SKILL.md |
| Blast radius / "What breaks if I change X?" | .claude/skills/gitnexus-impact-analysis/SKILL.md |
| Trace bugs / "Why is X failing?" | .claude/skills/gitnexus-debugging/SKILL.md |
| Rename / extract / split / refactor | .claude/skills/gitnexus-refactoring/SKILL.md |
| Tools, resources, schema reference | .claude/skills/gitnexus-guide/SKILL.md |
| Index, status, clean, wiki CLI commands | .claude/skills/gitnexus-cli/SKILL.md |
<!-- gitnexus:end --><!-- code-intel:start -->Code intelligence
Use the repo-scoped agent-code-intel-routing skill for code exploration,
debugging, reviews, refactoring, implementation, architecture, and dependency
analysis. Codex discovers it automatically; other agents must read
.agents/skills/agent-code-intel-routing/SKILL.md. The skill is the source of
truth for choosing between GrepAI, GitNexus, and ripgrep. Keep GitNexus safety
requirements for impact analysis, graph-aware renames, and change detection.
Never hand-edit .grepai/config.yaml; run agent-code-intel --apply to repair
generated configuration.
After a task changes code, run agent-code-intel --refresh from the project
root. If the command or its local stack is unavailable, report that and
continue; code intelligence is a navigation aid, not a correctness gate.
Docs-only changes do not need a refresh.
Before reading a source file, use the code-context skill: derive the exact
definition range with ctags instead of guessing a line window, and use
rg/ast-grep — not the knowledge graphs — for exhaustive reference lists.
<!-- code-intel:end -->Changelog and README
When a change is finished and a user would notice it — behaviour or a default changes, a bug is fixed, a flag/message/exit code/JSON key comes or goes, a requirement is raised — do two documentation steps before the commit and before reporting the work as done:
- MUST add an entry under
## [Unreleased]inCHANGELOG.md— English, Keep a Changelog categories, explaining what changed and why, with(#NN)when there is an issue or PR. - MUST check
README.mdis still in sync with the new behaviour (flag and exit-code tables, requirements, error messages, version strings) and update what drifted. Verify withrg, don't assume; report either "README updated: …" or "README checked, no drift".
Not every edit earns an entry. Internal refactors and renames with no
observable difference, formatting, comments, typos, docs-only and test-only
changes stay out — don't pad the changelog. When you leave a change out, say so
in a sentence. See docs/agents/changelog.md for the threshold, the README
section map and the release procedure.
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.

