القائمة
Use when wrapping, calling, or extending the dbterd Python API from the FastAPI server — parsing manifest.json/catalog.json, extracting nodes and FK relationships, and mapping to the ErdPayload schema.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use whenever any change touches the shape of the /erd JSON payload (nodes, edges, columns, relationships) — whether in the FastAPI Pydantic models, the generated TypeScript types, or the React consumers. Ensures all three layers stay in sync.
Use when building or modifying custom React Flow node components in the webview — especially the table-card node that lists columns inside. Covers registration, handle placement, theming, and performance patterns. Targets @xyflow/react v12 (the successor to the old `reactflow` package).
Use when building a local .vsix of the VS Code extension for sideloading or ad-hoc testing. Covers the build/sync pipeline, sanity-checking the bundled server source, and the boundary with the release flow (this skill never publishes).
Use when cutting a release of the VS Code extension — creating a GitHub Release that triggers the marketplace publish workflow. Covers version selection, the "do not hand-bump package.json" rule, release-notes generation, and post-publish verification.
| name | dbterd-api |
| description | Use when wrapping, calling, or extending the dbterd Python API from the FastAPI server — parsing manifest.json/catalog.json, extracting nodes and FK relationships, and mapping to the ErdPayload schema. |
dbterd is a library for generating ERDs from dbt artifacts. We use it as a library, not via its CLI. The server imports from dbterd and converts its output into our ErdPayload schema.
A dbt target/ directory containing:
manifest.json — nodes, sources, tests, refscatalog.json — column types from the warehouseConfiguration comes from the extension: the user picks a dbt project root; we read {project}/target/*.json.
Use the dbterd.api.DbtErd façade with its built-in json target (shipped
since dbterd 1.28). get_erd() then returns the canonical ERD payload as a JSON
string — already the nodes/edges/metadata shape, so there's no need to drop down
to the algo adapter or hand-assemble (tables, relationships) tuples:
from dbterd.api import DbtErd
erd_json = DbtErd(target="json", artifacts_dir=str(target_dir), **config).get_erd()
payload = json.loads(erd_json) # {"nodes": [...], "edges": [...], "metadata": {...}}
Native shape (what the server maps near-passthrough into ErdPayload):
id (dbt unique_id), name, label, description,
resource_type, schema_name, database, columns, compiled_sql.name, data_type, description, is_primary_key,
is_foreign_key (the json target already sets the FK flag on child-side
columns — the server does not re-derive it).id, from_id (child), to_id (parent), from_columns,
to_columns, relationship_type, name, label, cardinality.generated_at, dbt_project_name (the json target may emit
more, e.g. dbterd_version, but ErdMetadata maps only these two).DbtErd(target="json") parse the
artifacts — it resolves relationships tests, merges catalog columns, and
filters by resource_type for you.dbterd CLI. We're a library consumer, not a
subprocess orchestrator.catalog.json is missing, a synthetic catalog is staged in a
temp dir via a context manager — the user's target/ stays untouched.)manifest.json on every /erd request
is slow. Cache keyed on the file's mtime; invalidate when it changes.catalog.json is absent, return nodes with
data_type=None and a warning header X-Erd-Warnings: catalog-missing.
Don't 500.compiled_sql, not file paths. The webview opens a node's
compiled SQL in an untitled editor; the json target supplies it directly.Fixtures live at server/tests/fixtures/jaffle_shop/target/ (minimal manifest + catalog). Tests should exercise:
data_type, warning header set.