菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
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
| name | dxkit-init |
| description | 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. |
This skill scaffolds dxkit on a repo: chooses flags, runs init, captures a baseline, and points at the next steps.
Ask the user what they want, then pick the right invocation:
npm init @vyuhlabs/dxkit (collapses install + init), or if dxkit is already a devDep: npx vyuh-dxkit init --full --yesnpx vyuh-dxkit init --with-dxkit-agents --yesnpx vyuh-dxkit init --with-hooks --with-dxkit-agents --yes--full --yes already does this (pre-commit is opt-in via --with-precommit-hook because it's slow on large repos)npx vyuh-dxkit init (no --yes) and let it prompt| Flag | What it ships | Default under --full? |
|---|---|---|
--with-dxkit-agents | The dxkit-* skills + AGENTS.md + CLAUDE.md shim | Yes |
--with-hooks | .githooks/pre-push + postinstall activation wire-up | Yes |
--with-precommit-hook | Adds .githooks/pre-commit (slow on large repos) | No (still opt-in) |
--with-devcontainer | .devcontainer/devcontainer.json (per-stack features) + post-create.sh | Yes |
--with-ci | .github/workflows/dxkit-guardrails.yml (PR gate) — plus, when the stack declares a capability the ubuntu runner can't serve (e.g. a net*-windows build), a generated dxkit-gate-<host>.yml per required host; tell the user to mark it a required PR check alongside dxkit-guardrails | Yes |
--with-baseline-refresh | .github/workflows/dxkit-baseline-refresh.yml (post-merge regen; on a multi-environment stack with lint gating enabled it also captures each placed host's baseline slice and merges before committing) | Yes |
--with-pr-review | .github/workflows/pr-review.yml (AI PR review; needs ANTHROPIC_API_KEY) | No (still opt-in) |
--claude-loop | Stop-gate hook for autonomous loops (additive merge into .claude/settings.json + CLAUDE.md); implies the dxkit skills. Pair with --loop-preset security-only|full-debt | No (opt-in — registers a hook that blocks the agent from stopping) |
--flow / --no-flow | Set up / suppress the UI→API integration gate. When init detects a UI→API surface it offers this automatically (interactive prompt for the posture); --flow forces it on with warn, --no-flow skips it. There is no standalone flow init — flow setup lives inside init. | Auto-offered when a UI→API surface is detected (silent otherwise) |
--yes accepts all prompts; --force overwrites existing files instead of writing .dxkit sidecars on conflict.
When init finds client HTTP calls and/or server routes, it offers the integration gate: a PR that breaks a UI→API binding (a call to an endpoint no backend serves, or a removed route a consumer still calls) fails the guardrail. Interactively it asks for the posture with a one-line description of each — warn (default, surfaces breaks without failing a build), block (fails on an exact break), off (scaffold config only). It also confirms the dominant base-URL helper to strip and any multiple backend services. On a repo with no UI→API surface (a library, a CLI) the step is silent. Re-run or adjust later with init --flow; tune the posture in .dxkit/policy.json:flow.mode.
Install with stack auto-detection — --detect auto-detects the stack and
installs with minimal prompts:
npx vyuh-dxkit init --detect
Note: --detect INSTALLS (it is not a dry-run preview). To see the detected
stack without installing, run a read-only analyzer first (e.g. npx vyuh-dxkit health .), or inspect the plan from a throwaway checkout.
Run init:
# Most common case — full setup, no prompts
npx vyuh-dxkit init --full --yes
Capture the brownfield baseline — must do this before hooks/CI become useful:
npx vyuh-dxkit baseline create
git add .dxkit/baselines/
git commit -m "chore: capture dxkit baseline"
Verify the install:
npx vyuh-dxkit doctor
This checks: hooks active, baseline present, workflows installed, scanner toolchain available.
Hand off:
dxkit-config skilldxkit-hooks skilldxkit-reports skilldxkit guardrails check + require PR reviewnpm init @vyuhlabs/dxkit seeds a minimal one. For Python-only / Go-only repos, install dxkit globally instead: npm install -g @vyuhlabs/dxkit && npx vyuh-dxkit init --full --yes..claude/ files are preserved. To switch to the new dxkit-specific shape, delete the old .claude/ dir first, then re-init.npm install: npm init @vyuhlabs/dxkit automatically retries with --legacy-peer-deps. Manual installs may need that flag.init --full writesA complete install lays down ~15-20 files (down from the 2.5.0 ~73-file scaffold). Per-repo:
.dxkit/baselines/main.json (after baseline create).dxkit-ignore (starter template).npx vyuh-dxkit.json (manifest).githooks/pre-push.github/workflows/dxkit-guardrails.yml.github/workflows/dxkit-baseline-refresh.yml.devcontainer/devcontainer.json (per-stack features).devcontainer/post-create.sh.devcontainer/install-agent-clis.sh.claude/skills/dxkit-{learn,init,config,hooks,reports,action}/SKILL.md.claude/rules/<lang>.md (per active language pack).claude/settings.json (narrowed: dxkit-binary permissions only)AGENTS.md (project prose context for any agent — Claude, Codex, Cursor, Aider)CLAUDE.md (shim pointing at AGENTS.md)package.json (postinstall = npx vyuh-dxkit hooks activate).gitignore (additive: .dxkit/reports/, .dxkit/cache/, graphify-out/)