メニュー
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.
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.
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.
| name | dxkit-hooks |
| description | 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. |
This skill handles the git-hook surface dxkit ships. Use it to install hooks, debug "the hook didn't fire," chain dxkit with an existing hook system, or guide a bypass.
.githooks/pre-push (default-on under --full) — runs the guardrail check before code leaves the developer's machine. Fast on warm scanner caches (~10-30s).
.githooks/pre-commit (opt-in via --with-precommit-hook) — same guardrail check but on every commit. Slower on large repos (~1-3 min on 500+ file repos). Not in --full by default because the wall-clock cost gates adoption.
Both run npx vyuh-dxkit guardrail check. The check exits 1 (blocking) on net-new findings vs. the baseline. The same check also runs the flow integration gate — a net-new broken UI→API integration (a call to an endpoint no backend serves, or a removed route a consumer still calls) blocks or warns per .dxkit/policy.json:flow.mode. To set up, diagnose, or repair that gate, hand off to the dxkit-flow skill.
# Pre-push only (recommended for most teams)
npx vyuh-dxkit init --with-hooks --yes
# Both pre-commit + pre-push
npx vyuh-dxkit init --with-hooks --with-precommit-hook --yes
# Add to an existing dxkit install (idempotent)
npx vyuh-dxkit init --with-precommit-hook --yes
Existing hooks at .githooks/<name> or .husky/<name> trigger sidecar-write mode: dxkit puts its hook at .githooks/<name>.dxkit and emits a chain note instead of clobbering.
Hooks activate by setting core.hooksPath = .githooks in the local git config. Dxkit wires this via npm postinstall so every clone + npm install runs it automatically. Manual:
# Either of these works
npx vyuh-dxkit hooks activate
git config core.hooksPath .githooks
npx vyuh-dxkit hooks activate is idempotent — refuses to clobber a custom hooksPath (husky's .husky, lefthook's .lefthook, etc.). Run it to confirm the current state.
Walk this checklist:
ls -la .githooks/pre-push — should be executable.git config --local --get core.hooksPath should print .githooks. If empty or pointing elsewhere, run npx vyuh-dxkit hooks activate.which npx vyuh-dxkit should resolve (either project-local ./node_modules/.bin/vyuh-dxkit or global). The hook delegates to whichever it finds.test -f .dxkit/baselines/main.json — without a baseline the guardrail has nothing to compare against. Run npx vyuh-dxkit baseline create.npx vyuh-dxkit guardrail check from the repo root. Expected: exits 1 on net-new findings (red), 0 on clean diff (green).If all five pass and the hook still doesn't fire, the most common cause is a competing hook system. git config --global --get core.hooksPath could be set globally to something else.
When dxkit detects an existing hook (.husky/pre-commit or .githooks/pre-commit), it writes .githooks/pre-commit.dxkit instead and prints a chain note. To wire them together, add a line at the end of the existing hook:
# .husky/pre-commit (after husky's own logic)
sh .githooks/pre-commit.dxkit
Order matters: run the fast lint/format hooks first, then dxkit's guardrail last (so dxkit sees the actual final diff).
For pre-push, same pattern with .githooks/pre-push.dxkit.
When a hook blocks a push and the fix needs to land NOW (incident response, hotfix):
git push --no-verify
This skips ALL git hooks (not just dxkit's). After the emergency:
npx vyuh-dxkit baseline create --force
git add .dxkit/baselines/main.json
git commit -m "chore(baseline): accept regression from <ref>"
Re-baselining is a deliberate action — it grants future scans permission to keep the regression. Don't do it casually; use the policy file to suppress noisy finding kinds instead.
If pre-commit becomes a wall-clock blocker:
rm .githooks/pre-commit
git config core.hooksPath stays pointed at .githooks/ (don't unset it). Future init calls won't re-add pre-commit unless --with-precommit-hook is passed.
git config --local --unset core.hooksPath
rm -rf .githooks
# Also remove the postinstall line from package.json if you want a clean uninstall
The CI workflows in .github/workflows/dxkit-*.yml continue to enforce the guardrail at PR-time, so removing local hooks doesn't disable the safety guarantees — just shifts them to CI-only.