dt-usagelisted

Use when the user adds, changes, removes, or announces a change to business behavior — a new endpoint, model, command, signal, event, validation rule, form, page, module, architectural decision, feature flag, supersedes relation, or dependency between modules — and the knowledge graph should reflect it. This covers both explicit asks ("persist that", "register this") and conversational announcements of edits the user just made. Also use when the user wants to capture, note, or record a change for later, even when phrased informally. Also use when the user asks "how does X work", "what flows touch Y", "which rules protect Z", or any question whose answer should live in a project knowledge graph. Read the graph before answering, write nodes/edges after deciding. Skip pure refactors with no behavior change, dependency bumps, styling-only edits, and exploratory talk.
yacb2/domaintome · ★ 0 · AI & Automation · score 73

Install: claude install-skill yacb2/domaintome

# DomainTome — read-first, write-on-decision This project ships with the **DomainTome MCP server** (`dt_*` tools) that stores business knowledge as a typed graph: modules, capabilities, flows, events, rules, forms, entities and decisions. Treat DomainTome as the project's **living memory**. ## Scope: where does "the project" live? DomainTome has no opinion about whether a project is a single repo or a workspace holding several repos/packages. The graph lives in `.dt/graph.db` relative to whatever directory Claude Code was launched from — that's the "root of analysis". Workspaces with multiple repos (split-repo setups, monorepos of independent packages, `*_ws/` scaffolding) typically keep `.dt/` at the workspace root so a single graph captures cross-repo relations. Single-repo projects keep it at the repo root. Both are valid; pick whichever matches the unit of knowledge you want to capture. The MCP server logs the resolved DB path on startup so you can always verify which one it is using. ## Read before acting Before answering "how does X work?" or writing non-trivial code that touches a known concept, consult the graph: 0. `dt_overview()` — **call this first** when landing on a project. One compact payload with node counts, top capabilities, recent decisions and recent changes. Cheaper than several exploratory calls. 1. `dt_query(text_or_id, depth=1)` — **`text_or_id` is required**. Exact id / title substring / tag. 2. `dt_list(type=..., include_body=False)` — ch