Menu
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).
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
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 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.
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.
Basé sur la classification professionnelle SOC
| name | package |
| description | 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). |
Produce a .vsix for sideloading or sharing test builds. This is for testing — real releases happen via CI on tag push (see the release skill / release-manager agent).
The extension .vsix is not just extension/. The build pipeline assembles three sources:
webview/dist/ rsynced into extension/media/.server/src/ plus pyproject.toml and uv.lock rsynced into extension/server-src/. The extension spawns a local uv to run this server at activation; if it's stale, the installed extension talks to an old server.extension/src/.Skipping any of these silently ships a broken or stale build. The canonical recipe lives in Taskfile.yml so the slash command, the agent, and manual runs stay aligned. Do not reimplement the steps inline — call task targets.
Install — task install:webview install:extension. Idempotent; npm ci runs only if node_modules is missing or out of date.
Package — task package. Runs the full build + sync + vsce package pipeline.
Report — ls -lh extension/*.vsix. Print path and size so the user can locate it for sideloading.
Sanity-check the server bundle — diff a known file from both sides:
diff -q server/src/dbterd_server/logging_setup.py \
extension/server-src/src/dbterd_server/logging_setup.py
If the files differ, the rsync did not run (or ran against a stale server/src/). Investigate before reporting success — a passing task package with a stale server bundle is a silent failure.
extension/package.json version matches a published tag (gh release view v$(node -p "require('./extension/package.json').version") returns a real release), tell the user that installing this .vsix may confuse VS Code's update tracking versus the marketplace build. Suggest bumping the version locally for the test build, or uninstalling the marketplace copy first.This skill never:
vsce publish.extension/package.json's version field. (The release workflow does that from the tag — see the release skill.)For any of those, redirect to the release skill or the release-manager agent.