菜单
Manage the VPNSentinel local Docker E2E environment — start, stop, rebuild, status, logs, and a genuine end-to-end verify. Use when asked to bring the stack up locally, tear it down, or prove the system works end-to-end on Docker before/after changes.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Enforce and automate releases in CI so a promotion to the production branch can never silently ship without a version bump. Installs a release gate (block a PR that did not bump the version past the last release) plus, on the same shared version<->tag primitive, optional auto-release lanes (auto-release a dependency-bot update; auto-release every merge on a CD trunk). The enforced/automated sibling of the invoked `release` skill. Generic template - forge-adapt tailors the production branch, version source, and CI provider. Use when the user asks to "enforce version bumps", "block merge without a release", "auto release on merge", "auto-release dependency updates", or "stop forgetting to tag releases".
Find genuinely dead / unused / unreachable SOURCE code in VPNSentinel — unused functions, classes, methods, and unreachable branches that flake8's local-scope rules (F401/F811/F841) miss. Wraps vulture with a curated allowlist for this project's dynamic-reference patterns (Flask routes, console_scripts entry points, health subprocesses, the re-export shim, Telegram string dispatch, daemon threads) so findings are low-noise and safe to act on. Use when asked to "find dead code", "remove unused code", "what code is unused", "dead-code scan", or "clean up the codebase" before a refactor or release.
Expert on the VPNSentinel codebase, VPN monitoring operations, DNS leak detection, and the distributed client-server architecture. Activate for any question about VPNSentinel development, debugging, deployment, or monitoring.
| name | local-env |
| description | Manage the VPNSentinel local Docker E2E environment — start, stop, rebuild, status, logs, and a genuine end-to-end verify. Use when asked to bring the stack up locally, tear it down, or prove the system works end-to-end on Docker before/after changes. |
| disable-model-invocation | true |
Run the project's local Docker E2E stack via the CLI. Always prefer the CLI over ad-hoc
docker compose so local == CI.
Pre-flight: run bin/local-env status before acting.
| Command | Use |
|---|---|
bin/local-env start | Build + start; waits until the server is healthy; prints URLs |
bin/local-env stop | Tear down (down -v) |
bin/local-env rebuild | --no-cache rebuild, then start |
bin/local-env status | Container + health status |
bin/local-env logs [svc] | Follow logs |
bin/local-env verify | Full E2E: up (healthy) → live-stack pytest → teardown. --keep leaves it up. |
verify is the regression safety net — run it before and after any restructure/refactor.
Stack: tests/docker-compose.test.yaml (API :15554, health :15553, dashboard :18080).
