DeepInit — grounded, verified code-truth for your coding agent

Your agent can see every file — and still misses what matters.

Point an agent at a large codebase it's never seen — half a million lines, years of decisions — and it'll rewrite a function with total confidence, then break a business rule that was never written down.

And the obvious fix backfires: piling everything into a "document everything" file (think a giant CLAUDE.md or AGENTS.md) makes agents do worse, not better — a 2026 ETH Zurich study measured lower task success and 20%+ more cost per task, because the few things that matter get buried. The evidence →

Lean, verified context — and the problems it finds, in the same pass.

DeepInit writes a lean, always-loaded context file your agent auto-loads — CLAUDE.md for Claude Code, the open AGENTS.md standard plus per-tool rules for Cursor, Copilot and Windsurf (.cursorrules, .github/copilot-instructions.md, .windsurf/rules/) — and a deep .ai/docs/ layer it pulls on demand, flagging the real problems in the same pass. Both come from one engine, and both obey the same rule: every claim cites a file:line, gets verified against your code before it's written, and is trimmed to only what your agent couldn't work out on its own. Nothing fabricated, nothing restated, nothing it can't point at.

It writes a short, always-loaded front-door file — CLAUDE.md for Claude Code (which loads it natively), or the cross-tool AGENTS.md standard for other agents — plus deeper files your agent opens on demand, kept small on purpose so the few things that matter aren't buried.

Every line meets one test — it’s something your agent can’t already figure out for itself.

Seven waves. Parallel. Adversarial. Thorough.

It comes down to three moves — parse, understand, verify. Most tools hand your whole repo to an LLM and hope; DeepInit parses your code first (real AST parsing via Graphify, 25 languages), reasons about meaning on top, then verifies every finding against the code before it's written. Under the hood that's seven waves: parallel subagents analyze each component and then the patterns across them, before findings are cross-checked and adversarially reviewed.

Inside waves 3 & 4 — go deep, then go wide

Your database, and what stays private

DeepInit reads your live database schema read-only — SQL this release (Postgres, MySQL, SQLite), where it compares the live schema against your code and flags the drift. NoSQL stores (Mongo, Redis and others) are stub-level for now — honestly labeled, not implied as done. A secret/PII redaction gate scrubs anything sensitive before a single file is written to disk. (A cross-model verification pass — a second model double-checking findings — is on the roadmap, not shipped yet.)

The philosophy: tokens are fuel, not a constraint.

DeepInit burns tokens generously on the first pass — parsing, inspecting your database, cross-checking and verifying every finding — because one thorough analysis is worth far more than a cheap guess your agent will trust for months. Quality is the default, not an upsell.

And counterintuitively, it costs you less.

Two ways. At runtime: your agent reads a lean, ready-made brief instead of burning tokens re-exploring the codebase from scratch every session — and a tight file is cheaper per task than a bloated one (the same ETH study measured 20%+ more cost from oversized context).

Over time: you pay for the deep analysis once, then /deep-init-update refreshes only the diffs and /deep-init-check is free — instead of re-deriving the whole picture every session, on every machine, for every teammate. Spend on depth once; coast for months.

Run it once — then it stays current, proportional to the diff.

After the first run you never re-pay for the whole repo. An edit re-documents only its blast radius — the components you touched, plus anything whose public interface actually moved. Here is exactly how /deep-init-update stays proportional to the change:

Two things it therefore guarantees — the two ways docs usually rot, closed:

And it tells you — for free — the moment the docs fall behind.

Two plugin-shipped hooks do the surfacing, both calling the same 0-token, no-LLM status script (the only kind of check a git hook can actually run): a post-commit nudge that prints how far the docs have drifted, and a SessionStart offer — open a session while the docs are behind and DeepInit offers a one-click refresh. Beyond those, a real headless auto-refresh exists but is off by default, because it’s the only level that spends tokens. None of them ever auto-commits — you always review the diff.

The honest part: a git hook can’t summon an AI session, so DeepInit doesn’t pretend your docs silently regenerate on every commit — the free nudge and the session-start offer are the real, visible surface.

The problems fall out as a byproduct — grounded, ranked, report-only.

Because DeepInit already extracts your rules, your schema, and the why, the problems surface as a byproduct — now across about ten issue families plus a class-conformance census, every finding grounded to the line, framed as “likely” rather than asserted, and report-only — it never touches your source. Anything a linter already catches is suppressed, because false positives are what kill tools like this. Five of the kinds it looks for:

The goal — a short, trustworthy list worth a human's attention, not a wall of warnings. Findings are framed as likely and grounded to a file:line rather than proven, and this isn't a security product.

One report you can read — and act on.

What it actually writes down.

## Business rules — billing  (vertical — per component)
[BR-billing:003] CORE — An invoice can't be voided once its payment has settled;
            void attempts must go through the refund flow instead.
            from  src/billing/invoice.ts:142          ✓ checked · HIGH

## Database vs. code — orders  (vertical)
⚠  orders.legacy_status (text) is still read by the reporting job, but your
            Prisma schema dropped it — an agent trusting the schema will miss it.
            from  prisma/schema.prisma:88  ↔  src/orders/order.ts:24     ✓ checked

## Use case — cross-component  (horizontal — across components)
[UC-014] Checkout → charge → fulfil: orders.create() calls billing.charge();
            on success it emits `paid` → fulfilment.start(). A failure *after* the charge
            must call billing.refund() — orders can't roll the payment back itself.
            spans  orders/ · billing/ · fulfilment/     ✓ checked

How every “✓ checked” is earned

Grounded + verified isn't a slogan — it's a pipeline stage. Before a single claim reaches your context file, it walks this chain. If a citation doesn't resolve, the claim is dropped from the lean tier, never silently kept.

Verified means the citation exists and is plausible — not that the claim is provably correct. A confidently-wrong claim is worse than a gap, so DeepInit prefers omission over a guess.

Every finding is typed, tagged by importance and confidence, points to the exact file:line, and is checked against your code before it's written. Findings are traceable by ID:

This example is TypeScript — DeepInit's AST parser reads 25 languages (Rails/Ruby, Python, Go, Rust, Java, C#, PHP, Kotlin and more), with a grep fallback for the few it doesn't (e.g. Crystal, OCaml).

Wikis and graphs give you a place to ask. DeepInit puts the answer where your agent already looks.

Wikis, code graphs, and index tools give you a separate place to go ask questions — a system that's only as current as its last crawl. DeepInit writes verified markdown straight into the context files your agent already loads — CLAUDE.md for Claude Code, AGENTS.md for the rest — so the context is just there, in front of the model, on every run. And it carries a second axis nothing else does: it's measured. The same file:line grounding that makes the context trustworthy is what lets it flag problems without crying wolf — a precision discipline we test on every change, not a promise.

Two rows are the whole story — start here, then the full table substantiates the rest.

✓ = does it · ~ = partial / adjacent · — = doesn't · "n/a" = not that kind of tool.

A closer look at the main alternatives

Comparisons reflect publicly available information about third-party products as of June 2026. These tools evolve fast — details may be out of date. "Starter-file generators" are lightweight tools (Apify's generator, hcc, Intent and similar) that scaffold a short AGENTS.md — useful, but shallow by design; several deliberately cap themselves at ~20–30 lines. Product names and trademarks belong to their respective owners and are used for identification only; mention does not imply endorsement or affiliation. Something inaccurate? Open an issue and we'll fix it.

Grounded in research — and honest about the limits.

DeepInit's design is a response to a measured, counterintuitive result: handing a coding agent a big, auto-generated context file makes it perform worse — and costs more to run. So DeepInit does the opposite of "document everything."

What the research says

• Across multiple agents and models, auto-generated context files reduced task success and cost 20%+ more per task — yet with a project’s existing docs stripped away, trimming to only the non-obvious flipped it to a +2.7% gain. That inversion is the whole design.Gloaguen et al., Evaluating AGENTS.md — ETH Zurich / LogicStar, Feb 2026 · arXiv:2602.11988 (CC BY 4.0)
• Why bloat backfires: models lose what’s buried mid-context, and output quality degrades as input grows — well before the window is full.Liu et al., Lost in the Middle — Stanford / TACL 2024 (accuracy drops 30%+ when key info sits mid-context) · Chroma Research, Context Rot, 2025 (18 frontier models)
• The problems DeepInit flags target the costly, hard-to-find faults — functional and integration bugs, and the business-logic flaws pattern-matching scanners miss.DeepInit design rationale — the full evidence trail, every decision traced to its source, lives in the repo
• Our own precision is measured and exact — 0 of 22 false positives on real, human-merged bug fixes. The task-success upside is still being benchmarked; that number goes here when the runs finish, not before.How we tested it → · every figure self-derives from committed records

The limits

Engineered to be right — measured not to cry wolf.

A finding earns trust two ways: it is grounded in your actual code, and it is not noise. DeepInit is built for the first and measured for the second — on its own fixtures, on 22 real human-merged bug fixes, and on real open-source repos.

Right — grounded, verified, demonstrated

• Grounded to the line, verified before written — Every claim cites a real file:line and is checked to exist against your code first — the difference between analysis and a confident guess.
• It reasons about your code, not just patterns — On real repos it read legitimately-open endpoints as valid exceptions, diagnosed a documented rule that had gone de-facto stale, and re-found a fixed restic bug blind. On a full-pipeline analysis of the kemal web framework it raised zero issues — all nine structural near-candidates suppressed by a named guard rather than raised as a guess. Comprehension, not keyword-matching.
• Tested like production software — A 331-check regression harness runs on every change; blind multi-lens runs and an independent oracle (a held-out answer key the runs are graded against — nothing to do with databases) keep the numbers honest as the model evolves.

Then the harder half — the false-positive rate, because a false alarm is what gets a tool turned off:

• False positives 0/22 on real fixed bugs — Replaying 22 real human-merged bug fixes (3 of them CVEs), it never re-flagged a line already fixed.
• 0 false alarms where a naive scanner fires ~90 — Across four real repos with documented rules the guards held: about 90 naive false defects avoided, none raised.
• A record of detectors we refused to ship — When a check would cry wolf, we leave it off — and say so.

These are DeepInit’s own measurements on real code, kept exact. Recall (the false-negative side) on those real bug fixes was 14/22 — labeled indicative, below our own ship-gate, not a headline — and the speedup benefit is still being benchmarked, so this page leaves it blank rather than invent one.

The five layers — and the limit of each

Trust comes from stating what each test proves and what it can’t. In rough order of independence:

1. A 331-check regression harness across 72 oracle sections (deterministic, no model) — proves the engine’s mechanical logic stays correct on every change: dependency ordering, the cost math, the issue oracles, the census arithmetic, SARIF shape, and the scoring that grades the blind runs below. Doesn’t prove the model-driven findings are right — it grounds and scores fixtures, it doesn’t run the live analysis.
2. Blind runs on our own fixtures — multiple independent lenses, each blind to the answer key, agree: recall 9/9, false positives 0. Doesn’t prove real-world recall — these fixtures were designed alongside the spec, so 9/9 over-states what you’d see on unseen code. We say so.
3. An independent oracle on real fixed bugs — 22 human-merged bug fixes across 22 repos and 4 languages (3 of them CVEs). The hard, gated result: it never re-flagged a line a maintainer had already fixed (0/22). Doesn’t prove a headline recall number — recall here was 14/22, small-sample and below our own ship bar, so it stays an indicative sub-line, never a claim.
4. Naive-vs-guarded precision — on four real repos carrying a documented rule, a naive “mismatch = violation” checker would have fired ~90 false alarms; the guarded detector raised none, every census signal arithmetically correct. Doesn’t prove those repos had bugs — they’re clean; this measures precision and scope-honesty, not recall.
5. A record of the checks we refused to ship — where a check’s decidable rule couldn’t be told apart from its real-defect rule (it would cry wolf), we measured it, left it off, and wrote down why. Doesn’t prove those problem classes are undetectable — each deferral names exactly what would unblock it.

How we keep it honest — the techniques, not just the count

A big test count is easy to fake. What makes the 331 checks across 72 oracle sections trustworthy is how they’re built — four disciplines borrowed from how you’d test production-grade software, not a prompt:

The 331 checks run with no model in the loop (deterministic) and grow only by addition — the original engine checks must never regress. Recall is reported, never gated, and kept below the headline because our own fixtures over-state it; precision (the false-alarm side) is what we gate on.

Field-validated across 15 language stacks (of the 25 its parser supports)

The same detectors, run over ~1.12M lines of real open-source code in 15 languages — Go, Rust, C, C++, Java, C#, Kotlin, PHP, Ruby/Rails, Elixir, OCaml, Swift, Python, TypeScript, Crystal — comprehend each language’s own structure rather than matching a surface pattern. The clearest example is circular dependencies: the identical check stays silent where the language forbids cycles (Go packages, Rust crates, C# assemblies, and the OCaml and Swift build manifests — verified by building the real dependency graph), fires on a genuine one where the language permits it (a 33-package cycle in a Java backend, a 31-component cycle across a PHP framework’s separately-published packages, a 14-package cycle in a Kotlin HTTP client, two namespace cycles inside a C# media server, and a real cycle in nginx’s foundational C core), and reads the subtler cases right: on Elixir it separates the compile-time graph the compiler keeps acyclic from the runtime cycle it allows, and on the C/C++ pair — the same #include model — it fires on nginx yet stays silent on a strictly-layered C++ library, because that regime permits cycles without requiring them. Sharper still: the same swallowed-error check is inapplicable on pure C (which has no exception construct to match) yet correctly re-activates on C++ — same check, different language. Each fire was independently re-computed a second way before it was trusted.

Same check, five compiler regimes. It builds the real dependency graph for each language's actual unit of modularity, then runs a genuine cycle search — so it fires where cycles are real and permitted, and stays silent where the language forbids them. The C/C++ row is the proof: identical #include model, nginx firing a real triad while a strictly-layered C++ library stays clean.

Every one of these is recorded as a structural observation, never filed as a bug or published — and these are direct detector sweeps, not the full graded pipeline. The point is comprehension across the ecosystem, not a bug count on famous repos.

Where Graphify ends and the understanding begins. Graphify is the AST extractor that sharpens the structural graph on 25 languages — it resolves an import to the file that defines the symbol, which a grep can’t. But it’s an accelerant, not the engine. A stack with no grammar (Crystal, OCaml) automatically falls through to a ctags/grep import graph that still captures roughly 80% of cross-component imports — the run just carries lower certainty, and the rule is always degrade, don’t false-flag. The proof it isn’t a crutch: most of these 15 field sweeps were run on the grep fallback, before Graphify was wired in as the default — so the comprehension above stands on its own. The language reasoning — knowing a cycle is even possible in this language before flagging one — is DeepInit’s, layered on top of whatever parser is available.

Tested across a language × size matrix

Beyond the sweeps, the full pipeline is run on a deliberate matrix of 16 leading repositories — 13 languages × three size tiers, each pinned to a commit and measured, not cherry-picked. The kinds of project span how real codebases actually differ: web frameworks (gin/Go, express/JS, sinatra/Ruby, laravel/PHP at 330k lines, phoenix/Elixir), libraries & CLIs (click, gorilla/mux, itsdangerous, fmt/C++, a Kotlin schema lib, uniffi-rs/Rust), and larger apps, data stores & SDKs (redis/C at 346k lines, excalidraw/TypeScript at 157k, pyccel transpiler, a commercetools Java SDK). 15 of the 16 parse on the designed AST path; the one that doesn’t (Crystal, no grammar) proves the grep-fallback degradation path end-to-end.

Measured per size tier — and it tells you before it spends

DeepInit estimates the cost up front, before a token is spent. We measured the real output across the matrix to keep that estimate honest: a small library runs around 150–160k tokens, a medium framework 80–230k, and a large 100k-line transpiler about 200k — one thorough pass, then incremental updates that re-read only what changed. We’re holding the dollar figure blank on purpose: the token counts are measured, but a published price waits on one clean end-to-end accounting run rather than an estimate. (INDICATIVE; Claude Opus pricing as of June 2026; re-derivable from committed records.)

Why real understanding beats “just send it to an LLM”

We measured it. On three of those repos we ran the analysis three ways — the full designed path (AST + grounding + verification), the grep fallback, and a naive LLM-only baseline (the controlled stand-in for “dump the code into a model and ask for docs”, no structural parse / no grounding / no verification) — and scored each, blind, against the parsed graph and the real code. The full path grounded ~99% of its claims to a verified file:line; the naive baseline grounded ~44% (and 0% on one repo — it cites filenames, not lines), inflated the dependency graph with edges that aren’t imports, and surfaced none of the grounded security-relevant findings the verified paths did. The honest part: on these famous repos every mode was ~99–100% faithful (the model knows them) — so the real difference isn’t hallucination, it’s whether you can trust which line a claim refers to, and whether the gaps get caught. That is the whole thesis: a prompt gives you a plausible description; the harness gives you a grounded, verified one.

All figures here are DeepInit’s own, INDICATIVE (small-n, repo@SHA-grounded, re-derivable from committed records); the precision result above stays the headline. We also run DeepInit on our own tools — an independent review of a dogfood run on our plugin returned “would use”, 10 of 11 spot-checked claims correct, every hard count exact.

An instruction-defined engine — with real algorithms under the markdown.

DeepInit is defined in markdown, so the honest measure of its depth isn’t a line count — it’s the validation surface and the decision log that make a model’s understanding trustworthy. And under that markdown it runs genuine graph, AST and set-algebra algorithms over a whole-system model, not text a single clever prompt could match. Put plainly, it’s closer to a research result and the lab that proves it than to an app — a small, dense instruction-set, with the overwhelming majority of the committed repo given to controlled fixtures, real-world field runs, and a decision log built to show it produces grounded, correct output. The engine that runs it is Claude itself.

The algorithms a one-file linter can’t reproduce

The decision log — we measured what not to ship

The depth no prompt has is the record of detectors we deliberately rejected after measuring them. Each was put through a design workshop and then an independent adversarial panel — reviewers blind to the verdict, told to try their hardest to ship it — left a frozen specification, and named exactly what would unblock it. We added no green test for any deferred check, because a test you co-designed to pass proves the wrong thing. Several detector families were measured and shelved this way; the engine ships only the checks whose decidable rule can’t be confused with a guess.

Every fire shown across this page is a structural observation — recorded, never filed as a bug or published. DeepInit is report-only and 100% local; it writes context and flags problems, it does not build a graph for you to explore or run your code.

Run it the moment a codebase outgrows what an agent can infer on its own.

The four questions everyone asks.

Install the plugin once. Then run /deep-init.

DeepInit ships as a Claude Code plugin. To be clear, “plugin” and “skill” aren’t alternatives — the plugin is just the delivery package, and the /deep-init skill that does the work lives inside it. Installing the plugin is how you get the skill; after that, you run /deep-init in any project. No subscriptions, no API keys, no servers.

1 · Add the marketplace, install the plugin

/plugin marketplace add deepfusionlabs/deep-init
/plugin install deep-init@deepfusionlabs-deep-init

These are slash commands you type into the Claude Code chat (not your terminal). They install from DeepFusion Labs’ plugin marketplace on GitHub.

2 · Reload so the plugin loads

Claude Code reads plugin commands only at startup, so run /reload-plugins (or start a new session). A window reload won’t pick it up. Running Claude Code inside VS Code or JetBrains? Restart the IDE itself — reloading the editor window isn’t enough.

3 · Run it, in any project

/deep-init      # zero config — the full, thorough analysis (2 review cycles). The whole getting-started.

Updating later

/deep-init-upgrade   # pulls the newest version on one confirm, then guides the reload

Requirements: Claude Code. DeepInit is free and MIT-licensed; its public repo is coming soon — once it’s live, the two commands above work for anyone, with no access step or sign-up.

• Stays fresh on its own — honestly. The plugin ships a session-start check (0 tokens): open a session when the docs have fallen behind the code and DeepInit offers a one-click refresh. It never spends a token to detect, and never updates without your click — the off-switch is one line.
• Safe on existing files. If your repo already has a CLAUDE.md (or AGENTS.md), DeepInit backs it up first and preserves anything inside your keep-markers — your hand-written notes survive.

More control, when you want it

A bare /deep-init is the zero-friction default. Beyond it, a curated menu of slash commands — no flags to memorize, nothing to mistype:

Type-safe by design — no flags to memorize. Each option lives where it costs you least: a command for the common dials, a button picker (/deep-init-customize) for the rest, and a JSON-Schema-validated .ai/deepinit.config your editor autocompletes and checks before you run. The literal flags and natural language still work for power users and CI.

It even knows its own version. Claude Code loads a plugin’s commands once per session, so after an update you can’t normally tell what’s actually running — /deep-init-version compares the loaded version against what’s on disk and tells you if you need to reload, and /deep-init-upgrade pulls the newest in one confirm. Most plugins can’t tell you what’s live.

Zero setup: DeepInit checks for its one dependency (scc) and installs it for you if it’s missing. Graphify gives richer parsing and installs the same way — optional; if you skip it during setup, DeepInit falls back to ctags/grep.

Built in the open — no lock-in.

DeepInit by Deep Fusion Labs is free and MIT-licensed, built with a research-first process — every choice traced to evidence and checked before a line was written.

No lock-in: no proprietary format, nothing to escape from — DeepInit writes plain markdown into the files your agent already reads. For Claude Code that's CLAUDE.md (loaded natively — the grounded replacement for /init); for the other tools it emits the open AGENTS.md standard (Agentic AI Foundation, under the Linux Foundation; already used by 60,000+ repositories) plus per-tool rule files (.cursorrules, .github/copilot-instructions.md, .windsurf/rules/). Generate once and any agent — Claude Code, Codex, Cursor, GitHub Copilot, Google Jules — can use it; remove DeepInit and your context files still work. Claude Code gets first-class support as a native skill. And it all runs 100% locally — no server to keep running — reading only your code, with a secret/PII redaction gate that scrubs detected secrets before anything is written.