dxkit

Manage the dxkit allowlist over its whole lifecycle — list, inspect, audit (including orphaned entries after a re-baseline), bulk-defer newly published dep-vuln advisories, remove stale entries, prune expired ones, and export Snyk-originated suppressions to a .snyk policy. Use when the user says "review our allowlist", "what suppressions do we have", "the guardrail blocked my PR for advisories published after the baseline", "defer these new CVEs", "this allowlist entry is stale", "remove this fingerprint", "the allowlist drifted after re-baselining", "audit our accepted-risk entries", or "push our Snyk ignores back to Snyk". For the fix-vs-suppress DECISION and adding a new individual entry, defer to dxkit-action.

Read a dxkit report and execute fixes — prioritize findings by severity, plan the fix sequence, run the fix, verify the score moved, re-baseline if appropriate. Supports a SCOPED pass to burn down one category at a time (dependency/BOM vulnerabilities, security, code quality, tests, docs), and a BASELINE-CLEANUP pass driven by `vyuh-dxkit debt` (the prioritized inventory of grandfathered debt — the broken build / failing tests recorded in the baseline's floor-debt envelope, then findings by severity; fix the build first). Use when the user says "fix these findings", "act on the health report", "close out these vulnerabilities", "just fix the dependency vulns", "only the security findings", "clean up the baseline", "burn down the debt", "fix the build the baseline grandfathered", "pay down the grandfathered findings", or after dxkit-reports / doctor's debt recommendation has surfaced something concrete.

Declare and operate custom repo invariants as first-class guardrail gates — a project rule (a "no imports from X" check, an architecture script, a license audit) or the built-in per-language lint gate. Use when the user says "make our lint errors block the PR", "gate our custom check", "add a repo rule to the guardrail", "enforce our architecture script", "why isn't my check running", "block net-new lint but grandfather the backlog", or "run our checks without gating". For suppressing an individual finding, defer to dxkit-allowlist; for the fix-vs-suppress decision, dxkit-action.

Repair a broken dxkit install — read doctor's structured output and walk the customer through each fix. Use when the user asks "fix dxkit", "fix my dxkit install", "doctor says X but Y is broken", "the pre-push hook isn't firing", "vyuh-dxkit command not found", or anything else that points at a broken-install state. Hands off to dxkit-init for fresh installs and dxkit-hooks for hook-specific deep dives.

Walk the user through installing and configuring dxkit on a fresh repo. Use when the user asks "how do I install dxkit?", "set up dxkit on this repo", "what flags should I use?", or wants to scaffold the guardrail surface. Defers to dxkit-config / dxkit-hooks for post-install tuning.

Answer questions about dxkit — what each scanner does, what a baseline is, what the 6 health dimensions score, how guardrails work. Use when the user asks "what does dxkit X do?", "what's a baseline?", "what's the slop score?", "how do hooks fit in?", or anything else about dxkit concepts.

Walk a customer through setting up dxkit on a repo from scratch — checks state, installs, scaffolds, configures hooks, runs doctor, fixes any gaps, captures the first baseline, sets up branch protection + Codespaces prebuild. Also drives a DETERMINISTIC deep-configuration pass — it runs `vyuh-dxkit configure --plan`, which COMPUTES the config each capability should take from observable repo facts (not the agent's judgment, so the same repo yields the same plan every run), shows it, gets confirmation, then `configure --apply` merge-writes it into policy.json without clobbering existing settings. The plan is registry-driven, so new capabilities join it automatically as dxkit grows. Use when the user asks "set me up", "install dxkit on this repo", "I want to use dxkit", "walk me through dxkit setup", "help me get started with dxkit", "configure dxkit for this repo", "what should I set up", or anything about onboarding or fully configuring a repo. Asks for confirmation at each step with sensible defaults; hands o

Bring an external SAST engine's findings (Snyk Code, SonarQube/SonarCloud, CodeQL, or any SARIF) into dxkit so they're fingerprinted, baselined, guardrailed, graph-linked, and fixable. Use when the user says "ingest Snyk", "ingest Sonar", "pull our Snyk Code findings", "bring in our SonarQube issues", "import a SARIF file", "run CodeQL and bring it in", or asks why dxkit's SAST finds less than Snyk/Sonar/CodeQL.

Produce a shareable, honest snapshot of a repo — its stack, its HTTP flow spine (routes served, calls made, how they bind), and its data models — with every fact labeled observed / derived / inferred / unknown, plus a self-contained contract-map HTML you can screenshot. Use when the user says "describe this repo", "what does this codebase look like", "give me a map of the services / API", "show the integration seams", "make a repo card", or wants a visual/onboarding overview to share. Writes nothing to the repo unless the user asks to save the HTML.

Run dxkit's zero-write trial — replay a repo's recent merged changes through the deterministic gate and report what it would have blocked and what enabling dxkit costs, without writing anything to the repo. Use when the user asks "would dxkit help here", "try dxkit on this repo", "what would dxkit have caught", "is dxkit worth enabling", or wants to evaluate dxkit before installing it.

Configure, diagnose, and repair the dxkit UI→API integration gate — set up flow gating, explain the flow-contract diagnosis, fix a net-new broken integration a guardrail flagged, and run the cross-repo handshake. Use when the user says "set up the flow gate", "why is this call unresolved", "the guardrail says I broke an integration", "a route was removed but something still calls it", "wire up flow across repos", "publish the flow contract", or anything about the UI→API integration gate.

Open a pull request with a title + body grounded in the branch's real commits and diff — what changed, features implemented, findings fixed — plus a reviewer checklist and the dxkit guardrail/allowlist/score signals a reviewer needs. Use when the user says "raise a PR", "open a pull request", "create the PR", "write the PR description", or after dxkit-feature / dxkit-action finishes a change and it's ready to push for review.

Run dxkit reports and explain their output, including the consolidated dashboard view. Use when the user asks "run health", "check security", "show me the dashboard", "open the dashboard", "tour the dashboard", "explain the dashboard", "what does this score mean", or anything about generating / interpreting dxkit analyzer output. Always reach for this skill even when the user names a specific subcommand (health, vulnerabilities, dashboard, bom, etc.) — running the command is only half of the value; the skill wraps the output with the right framing. Hands off to dxkit-action for fixing findings.

Configure, read, and act on the dxkit model-schema drift gate — list the data-model inventory, preview drift before pushing, explain why the guardrail blocked a model change, and ship a deliberate breaking change the safe way (migration + expiring accepted-risk allowlist entry). Use when the user says "set up the schema gate", "what models does this repo declare", "the guardrail says I broke a model", "why is removing this field blocked", "we're intentionally changing this schema", or anything about data-model / schema drift gating.

Write a dxkit extension FOR the user from a prose description of what they want extracted, verified, or delivered — pick the lowest rung (declared artifact → external script → TypeScript plugin), generate the manifest/adapter/plugin, and drive `extensions dev` until green. Use when the user describes a bespoke convention ("our screens are JSX files with a <Screen> root", "our API client is acmeApi.request", "our permissions are hasPermission() calls") or asks to port an existing extractor/report script into dxkit.

Plug the repo's own extractors, inventories, and delivery sinks into dxkit as extensions — any language, no porting. Use when the user says "run our Python extractor through dxkit", "track our screens/permissions inventory", "make our custom scanner's findings gate the PR", "send dxkit reports to our dashboard/spreadsheet", "declare our Postman collection / pact / HAR", or "how do I write a dxkit extension". For gate-time repo COMMANDS (a lint gate, an architecture script), defer to dxkit-checks; extensions run at refresh time and gates read their committed snapshots offline.

Edit dxkit configuration — add/remove paths in .dxkit-ignore, tune .npx vyuh-dxkit.json, adjust .dxkit/policy.json guardrail severity. Use when the user wants to exclude a directory from scanning, change scoring thresholds, or modify what blocks a PR.

Walk the customer through upgrading dxkit to a newer version safely. Use when the user asks "update dxkit", "upgrade to latest", "what's new in dxkit", "is there a new dxkit version", "should I upgrade dxkit", or anything about moving an existing dxkit install forward. Reads version delta + changelog + recommended steps; confirms each step. Hands off to dxkit-fix if post-upgrade doctor surfaces broken signals.

Develop a new feature with the code graph as your map — orient cheaply by querying structure instead of reading whole files, implement following the patterns already in the repo, then verify the change did not regress security, tests, or quality before you push. Use when the user says "add a feature", "implement X", "build the Y flow", "where should this live", or otherwise starts net-new development in a dxkit-scaffolded repo. Yields to a repo-specific feature or architecture skill when one exists: if this repo defines its own skill for building a module/feature (e.g. "/add-module", a platform architecture guide), that skill owns the architecture contract and this one runs inside it as the orientation-and-verification layer — not a replacement for it.

Write the tests a repo is missing — read the test-gaps report (blast-radius-weighted), orient on what the untested code actually does via the graph, then write real tests that close the highest-risk gaps and move the Tests score without coverage theater. Use when the user says "write tests", "add tests for this module", "improve the test coverage / Tests score", "close the test gaps", "cover the untested files", or after a health report flags Testing.

Cleanly and non-intrusively remove dxkit from a repo, restoring its exact pre-dxkit state — reverse every additive merge (settings.json, CLAUDE.md, .gitignore, package.json), delete every file dxkit created, and clean up hooks + CI + the .dxkit/ tree. Dry-run first. Use when the user says "remove dxkit", "uninstall dxkit", "get rid of dxkit", "clean up dxkit from this repo", "how do I undo dxkit init", or wants to stop using dxkit.

Install, configure, troubleshoot, or remove dxkit git hooks. Use when the user asks "set up hooks", "pre-push isn't firing", "how do I chain with husky", "bypass the hook", or anything about pre-commit/pre-push behavior in a dxkit-managed repo.

Set up and operate the dxkit Stop-gate for autonomous coding loops — register the hook, run the preflight, explain why a loop was blocked, read the loop ledger, and switch the blocking posture (security-only vs full-debt). Use when the user says "set up the loop gate", "why did the loop get blocked", "stop the agent from shipping debt", "run a safe agent loop", "show the loop ledger", "switch the loop to full-debt", or anything about running an unattended Claude Code loop behind dxkit.

Generate the documentation a repo is missing — read the Documentation dimension's gaps, orient on the real code via the graph, then write a grounded README / docstrings / API + architecture docs that move the score without tripping the slop check. Use when the user says "write docs", "document this module", "improve the documentation score", "generate a README", "add docstrings", or after a health report flags Documentation.