codegraph AGENTS.md

A set of project instructions for coding agents working on the Codegraph repository. It covers coding rules, project-wide and folder-specific guidance, caching, tests, documentation, and review safety.

In plain words
What is it for?
Guiding code changes and reviews in Codegraph, including writing conditions, updating tests and documentation, and respecting rules that apply to particular paths.
Why use it?
It tells the agent what standards to follow before changing code. This helps avoid unsafe edits, weak tests, outdated documentation, and style violations.

Instructions file for CodexOpenCode

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add instructions/lzehrung/codegraph/agents-md
Clone the repo
git clone --depth 1 https://github.com/lzehrung/codegraph

Made for: Codex, OpenCode.

Per session 1,919 This file is loaded in full into every session.
When invoked 1,919 The same file — it is already loaded in full.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.01919 $0.01919
Opus 5 $0.00959 $0.00959
Sonnet 5 $0.00384 $0.00384
Haiku 4.5 $0.00192 $0.00192

Measured yesterday against content hash 4fac441d4c2e, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

codegraph AGENTS.md scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

AGENTS.md · 69 lines

How it starts

The opening of the file, as written. The whole thing — 69 lines — stays where its author put it; the contents beside it link to each section on GitHub.

AGENT DIRECTIVES

General

  • Never use any or as unknown as
  • Never use nested ternary expressions. Use if/else, a helper function, or named intermediate values instead.
  • Never use === true, === false, etc. in boolean conditions; keep them as terse and simple as possible like !condition. Extract conditions to variables when the variable name adds clarity/insight into the reason for the condition.
  • In boolean condition contexts, use the shortest syntactically equivalent expression. Prefer items.length over items.length > 0, !items.length over items.length === 0, and items?.length over items && items.length > 0.
  • Always consider the impact of a change on tests or when more test cases are needed. Never make tests pass for the sake of passing; always exercise real behavior.
  • Always keep documentation updated and accurate while being minimal and concise.
  • Keep paragraphs to no more than 4 concise sentences. Prefer bullets for dense details.
  • Keep README.md as the landing page and docs index. Do not turn it back into the only canonical reference for every example and workflow.
  • When public-facing install, runtime, CLI, library API, MCP, agent workflow, or release guidance changes, update the relevant canonical docs in the same change: README.md, docs/installation.md, docs/cli.md, docs/library-api.md, docs/mcp.md, docs/agent-workflows.md, docs/how-it-works.md, and PUBLISHING.md as applicable.
  • For repo-understanding flows, start with node ./dist/cli.js doctor and node ./dist/cli.js orient --root . --budget small --json when dist is built; build first if validating the working tree from a fresh checkout.
  • For source-checkout validation and contributor examples, prefer node ./dist/cli.js ...; reserve bare codegraph ... for published/global install guidance.
  • When package metadata, install scripts, optional native dependencies, or the resolved npm graph changes, update package-lock.json in the same change and verify with npm ci --ignore-scripts --dry-run unless lifecycle scripts are part of the behavior under test. Release-candidate package installs MUST also disable lifecycle scripts unless those scripts are under test.
  • Treat --root as the project boundary for config lookup, path confinement, and output normalization. Cache/manifests may use the resolved cache anchor (--cache-dir/CODEGRAPH_CACHE_DIR, repository metadata, or project root); cached contents remain project-relative.
  • Keep discovery glob guidance accurate: codegraph.config.json globs are project-root-relative, while CLI --include-glob/--ignore-glob values are one-off filters relative to each active scan root.
  • Within any claimed cross-language capability, behavior should stay consistent across all supported languages for that capability. Avoid language-subset branches; if a limitation is intentional, document it in the parity docs and cover it with explicit tests in the same change.
  • When language support changes, update docs/language-parity.md and docs/scenario-catalog.md in the same change so support claims, limitations, and fixture coverage stay aligned.
  • When adding or changing a cross-file language scenario, add or update the nearest language test in tests/languages/*.test.ts and the shared semantic coverage in tests/goto.test.ts, tests/references.test.ts, and tests/native-semantic-parity.test.ts when the language uses the native runtime.
  • Always keep the README.md table of contents updated whenever README sections are added, removed, or renamed.
  • Human-readable CLI output is a public contract. User-facing writeCliOutput(...) callsites must provide a command-specific formatter unless the output is intentionally scalar or JSON-first, and the same change should add or update a pretty-output test.
  • Progress MUST identify the active operation. Show a count only when it is meaningful; do not report zero progress for work with no measurable total.
  • When CLI commands, flags, or output contracts change, update both docs/cli.md and codegraph-skill/codegraph/SKILL.md in the same change.
  • Always keep codegraph-skill/codegraph/SKILL.md updated when CLI commands, flags, or capabilities change. This file is the skill definition used by agents and must reflect the current tool surface.
  • Documentation and tool descriptions MUST name the exact CLI command, MCP tool, or exported API. Do not replace it with vague nouns such as "orientation", "navigation", or "targeted search".
  • Describe aggregate operations precisely: name the first-pass retrieval and derived context, and state when planning, subquery decomposition, or runtime proof is absent. Do not describe parser/backend quality as query reasoning.
  • Recommend direct primitives before bounded aggregators. Do not label an aggregate tool as the first step when exact symbol, reference, call, or file-dependency tools apply.
  • Keep each surface role-specific: help and tool descriptions give the selection rule; CLI/API docs give the contract; skills give command order. Avoid repeating tutorials across surfaces.
  • Distinguish library/session-only features from CLI/config features explicitly. If a capability exists only in exported library APIs, docs and types must say so, and CLI/config surfaces must not imply support they do not implement.
  • When changing MCP notification, transport, or progress behavior, verify both the protocol seam and the serving seam users actually hit (HTTP/stdio); do not assume protocol-level behavior survives a transport wrapper unchanged.
  • Before major commits or concluding work, run npm run check to verify formatting, lint, build, and tests together. During iteration, use the narrowest meaningful test command: targeted Vitest suites for localized changes, npm run test:fast for broader TypeScript changes, npm run test:integration for CLI/report/output contracts, and npm run test:native when touching packages/codegraph-native.
  • Installation guidance must use @lzehrung/codegraph and the @lzehrung GitHub Packages registry. Keep detailed install docs in docs/installation.md.
  • Any persistent storage schema change (e.g. SQLite tables/columns/indexes) MUST include a migration path for existing on-disk data. If using CREATE TABLE IF NOT EXISTS, you must also ALTER TABLE / backfill as needed (or introduce explicit schema versioning) and add a regression test that starts from an older schema to prove upgrades work.
  • DO NOT use curly quote variants or other non-standard characters humans would not type with a standard QWERTY keyboard.
  • Duplicate-tokenizer fingerprints must not shift with the toolchain. The TypeScript and native identifier grammars are pinned to one Unicode version: the native side through the exact unicode-ident pin in packages/codegraph-native/Cargo.toml, the TypeScript side through the generated src/duplicate-identifier-ranges.ts. Never resolve that grammar with a Unicode property escape, which follows the host Node build's Unicode version. Changing the crate pin means rerunning npm run generate:duplicate-identifier-ranges and bumping DUPLICATE_TOKENIZER_REVISION in the same change, so cached duplicate units tokenized by the previous grammar are recomputed instead of surviving DUPLICATE_UNIT_CACHE_MAX_AGE_MS.
  • packages/codegraph-native/Cargo.lock is committed because the crate ships prebuilt binaries. Update it in the same change as any Cargo.toml dependency edit.

Read the full file on GitHub · 69 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 69 lines · 1,919 tokens per session scan A 4fac441d4c2e

Subscribe to this mod's changes

codegraph AGENTS.md is an instructions file published in the GitHub repository lzehrung/codegraph (4 stars, last pushed yesterday), licensed MIT. It adds 1,919 tokens to every session, about $0.0096 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.