agentleFS
kekzlkekzl/imp/CLAUDE.md

imp

CLAUDE.md77 starsChanged 5 days agoMITView on GitHub

C++23/CUDA LLM inference engine for sm_120a only: every compute capability 12.0 card (RTX 50, RTX PRO Blackwell, 8-96 GB: card table). Tuned and gated on the RTX 5090 (32 GB, 1792 GB/s). A VRAM or "fits" claim names the card size. No portability layer, no FP16 dequant fallback in the hot path. Architecture: docs/internals/ARCHITECTURE.md; sm_120 vs datacenter: docs/internals/SM120.md. Router: rules for every task here, playbooks in skills. A rule a skill also covers lives in the skill.

  • Commits and pushes

The file

We split this CLAUDE.md into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    No CUDA toolkit on the host: build in Docker.

    line 40

≈ “Common” is an estimate: at least 1 in 5 of the 26,980 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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
CLAUDE.md
<!-- layer: L3 audience: agents verified: 2026-11-04 commit: a4070e6a -->

imp - Project Instructions

C++23/CUDA LLM inference engine for sm_120a only: every compute capability 12.0 card (RTX 50, RTX PRO Blackwell, 8-96 GB: card table). Tuned and gated on the RTX 5090 (32 GB, 1792 GB/s). A VRAM or "fits" claim names the card size. No portability layer, no FP16 dequant fallback in the hot path. Architecture: docs/internals/ARCHITECTURE.md; sm_120 vs datacenter: docs/internals/SM120.md.

Router: rules for every task here, playbooks in skills. A rule a skill also covers lives in the skill.

Task -> entry point

TaskStart here
Build, tests, CI red, dep bumpskill building-and-testing
Write/optimize a CUDA kernelskill sm120-cuda-expert
Benchmark, profile, perf baselineskill benchmark-cuda
Touched forward pass, MoE routing, KV cache, GDN state, graph captureskill check-degeneration
Quant formats, loaders, dequant (GGUF, NVFP4, FP8)skill quant-formats
imp-server, OpenAI/Anthropic HTTP APIskill server-api
New model architectureskill add-model-arch
PR, merge, releaseskill shipping-prs
Who calls/launches X, blast radius, still usedskill code-graph, before grepping
Structure audit, dead code, File size gate redskill codebase-audit; first docs/audit/SETTLED.md
Stub, ignored request field, dead kernel, test asserting nothingskill find-stubs
Docs after a changeskill docs-sync
Doc layer, header, PROV; docs/citations gate redskill docs-layers
VRAM, ownership, lifetimedocs/internals/MEMORY.md first
  • Generic build/test commands only here; directory CLAUDE.md files hold area rules.
  • scripts/docs_lint.py gates the doc layers (L0 README.md, L1 docs/*.md, L2 docs/internals/, L3 CLAUDE.md tree): root <= 2000 tokens, directory files <= 800, L3 verified: > 14 days behind last commit = error.
  • Also canonical: AGENTS.md (subagent roles), docs/internals/BENCHMARKING.md (measurement contract), docs/internals/CPP23.md.

Build & test

  • Before each GPU job: card free? User skill gpu-stats (gpu-busy-check.sh, exit 0 = free). Criterion is load (utilization + VRAM), not docker ps (WDDM tenants are invisible there). Busy: report and ask, no wait loop, no start.
  • No CUDA toolkit on the host: build in Docker. build/, build-dev/ are root-owned: make dev-clean or a throwaway container, never sudo.
make dev / make dev-test   # incremental (seconds) + the CI lane (ctest -L unit): iterate here
make preflight             # CPU only, before every push: CI static gates, tidy + format on changed lines, actionlint
make build                 # full image (minutes): anything measured or pushed
make verify-fast           # pre-push gate, the only gate that runs a kernel against a check
make verify                # full
  • Commit and push WITHOUT --no-verify. Both hooks (make install-hooks) run make preflight (~20 s); exit 0 = every row ok or skip. GPU tests only with IMP_HOOK_GPU=1.
  • make test-unit != the CI lane binary. CI has no GPU. Targets and CI job names: skill building-and-testing.
  • Never bare make format. CI checks changed lines only: format files you created, in edited files only your lines.

Conventions

  • English in the repo; chat in the user's language. No em dashes in the repo.
  • SafeTensors (NVFP4, FP8) first; GGUF is legacy (docs/DESIGN_DECISIONS.md): keep it loading, no new GGUF kernel or perf work, GPU gates and test models are SafeTensors only. Competitor reference: vLLM on the same SafeTensors checkpoint.
  • CHANGELOG: 1-3 lines, <= 360 characters per entry (gated), plus the checkable number. Investigation goes to docs/.
  • Branch off main, gh pr create --base main, never stack PRs; batch.
  • Perf gate: tests/perf_baseline.json (8 % decode / 8 % prefill). Refresh via scripts/gen_perf_baseline.sh only for an intentional move, stated in the PR.
  • Runtime config only via RuntimeConfig (src/runtime/config.h: imp.conf + --config + --set). Seeded env vars: IMP_DETERMINISTIC, IMP_FMHA_FA2; diagnostics.*: IMP_SPEC_TRACE, IMP_JUMP_TRACE, IMP_PPL_DUMP, IMP_WORKER_TIMING. No ad-hoc env reads.
  • Dependency pins only in cmake/imp-deps.cmake. Dockerfile: no --mount=type=cache on the build dir (stale ninja objects, 03a2cc19); the ccache mount stays.
  • File size gate: per file, per function body (> 500 code LOC hard), per TU (an #included .cu counts against its includer). Exceptions: [allow] with reason in docs/audit/AUDIT_FILESIZE.md.
  • VRAM (WSL2/WDDM): a successful cudaMalloc proves nothing, bandwidth tells resident from spilled (#1103), free VRAM only decreases within a process. Capacity is planned: docs/internals/MEMORY.md.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.