← ClaudeAtlas

system-modellisted

Understand how this codebase actually hangs together, and why. Use when the task needs the components behind a feature, the blast radius of a change, a risk assessment before planning, or the reason an existing implementation is the way it is.
yanisapths/sa-agent · ★ 0 · AI & Automation · score 62
Install: claude install-skill yanisapths/sa-agent
# System Model A deterministic graph of this repository in `.sa/system-model.db`, plus the engineering decisions behind it in `.sa/decisions/`. The live database tells you **what exists**. The index tells you **what was written down**. This tells you **what connects to what**, and **why**. ## Build it first `build_system_model` scans the repo and reads the live schema. It is deterministic and costs nothing, so run it whenever the code may have moved: ``` build_system_model ``` Read the report. Two lines matter: - *Live schema: not reachable* — table nodes came from SQL in the code and are unverified. Say so in your artifact rather than presenting them as fact. - *Referenced in code but absent from the live schema* — each one is a real finding: a stale query, a view in another schema, or a typo. ## What is in the graph | Node | Comes from | | --- | --- | | `endpoint` | route declarations, resolved through `app.use` mount prefixes | | `service`, `repository`, `module` | backend files, named after their principal class | | `component` | frontend files | | `test`, `doc` | test files, markdown | | `table`, `column` | the live PostgreSQL schema | | `decision` | `.sa/decisions/*.md` | Every edge points **from the dependent to the dependency**, so "what breaks if I change X" is a walk backwards from X. That is what `simulate_impact` does. ## Procedure 1. **Find the real components.** `query_system_model "<name>"` for a class, file, `table.column`, or `GET /path`. `