dotdotgod
Change a file, know what else must be checked.
$ dotdotgod graph impact . --changed packages/cli/src/core.mjs --compact
docs:
- docs/spec/REFERENCE_EXPANSION.md (91; incoming:implemented_by, semantic_similarity)
- docs/test/REFERENCE_EXPANSION.md (65.3; verified_by, semantic_similarity)
- docs/spec/LOAD_PROJECT.md (35.8; related_doc, semantic_similarity)
tests:
- packages/cli/test/core.test.mjs (78.6; semantic_similarity, incoming:semantic_similarity, verified_by)
- packages/cli/test/e2e.test.mjs (51.4; verified_by)
files:
- packages/cli/src/core.mjs (100; changed-file)
- packages/pi/extensions/plan-mode/index.ts (45; implemented_by, semantic_similarity)
graph impact ranks the specs, tests, architecture notes, config docs, and source files most likely to matter for a change. --compact keeps the result agent-facing: grouped by docs/tests/files and annotated with the reasons each item is likely relevant. It uses the project-memory graph built from Markdown links, README routes, headings, traceability blocks, package metadata, memory areas, and deterministic routing hints.
Dotdotgod is a context curation kit for AI coding agents. It turns specs, architecture notes, tests, commands, active plans, archives, and graph/cache metadata into bounded project memory for safer agent work.
It is for builders who use coding agents and still want product intent, design rationale, verification standards, and project memory to remain clear and durable. Coding agents can help write, refine, and navigate the documents, while the project keeps a stable source of truth for what should be built, why, and how it is verified.
Repository: https://github.com/dotdotgod/dotdotgod
For the detailed workflow diagram, docs management rules, graph sources, and memory categories, see Context mechanics and Context curation. For an evidence-backed comparison, see docs/concept/GRAPHIFY_COMPARISON.md.
Core Idea
Agents work better from shaped project memory than from raw conversation history. dotdotgod turns scattered repo knowledge into a reusable context system that keeps product decisions reviewable while coding agents do the implementation work:
AGENTS.md for canonical working rules.docs/spec/ for product truth and expected behavior.docs/arch/ for engineering constraints and boundaries.docs/test/ for verification knowledge.docs/plan/ for active task intent and executable plans.docs/archive/ for completed decisions, reports, and reusable historical memory.
What Initialization Creates
The initializer gives a project a predictable memory surface that any supported agent can load:
AGENTS.md # canonical instructions for all coding agents
CLAUDE.md # thin Claude Code entrypoint pointing to AGENTS.md
CODEX.md # thin Codex entrypoint pointing to AGENTS.md
docs/
README.md # docs map and naming/index rules
spec/README.md # product behavior and requirements index
arch/README.md # architecture and code-convention index
test/README.md # verification strategy and smoke-test index
plan/README.md # active local task plans, ignored by git
archive/README.md # completed-work history map, ignored by git
This structure separates stable project truth from temporary chat state. Specs explain what should happen, architecture explains why it is built that way, tests explain how to verify it, plans capture current intent before implementation, and archive indexes make completed decisions discoverable later. The workflow treats documentation as part of product execution, not as after-the-fact notes.
Why Loading Works Better with This Structure
When an agent runs /dd:load, dd:load, or dotdotgod load-snapshot, it does not need to rediscover the repository from scratch. It can follow the same durable map every time:
- Read the baseline instructions and docs indexes.
- Use the bounded CLI snapshot for cache status, graph size, memory areas, communities, and archive policy.
- Inspect only the relevant spec, architecture, test, or active plan files.
- Use
docs/archive/README.md as the history map and read archived bodies only when a task needs a targeted past decision.
The result is a project load that is repeatable, bounded, and task-directed. New sessions start with the same rules and context map, long-running work survives compaction, and agent handoffs do not depend on remembering what happened in a previous chat.
Why This Structure Is the Strength
Dotdotgod's advantage is its project-defined memory model. The index and the agent know the intended retrieval structure before retrieval starts.
