360 Secure SkillHub
360 安全技能中心

vibecheck

用于在 psyb0t/vibecheck 仓库中开发、测试和验证这个 Go 服务:调用方提交状态与可信事实,选择版本化策略,返回类型化 Jev 结果和确定性决策;提供 REST /v1、MCP 工具、策略引擎、持久化、审计和 Docker 镜像。适合实现或审查策略、API、MCP 与测试;通过 Make 命令运行构建、lint、测试和覆盖率检查,输出可验证行为与测试结果。

psyb0t
psyb0t
热度 18.06
最近更新 2026-09-22 18:44:34
分类:开发依赖:代码执行 / 读写文件 / 第三方 API / MCP 服务应用场景:代码生成 / 代码审查 / 调试排错 / API 集成 ...

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add vibecheck
Metadata
name
vibecheck
description
Develop and verify psyb0t/vibecheck, a Go service for typed classification, scoring, and policy decisions backed by TypeSafe Jev. Use when working in the Vibecheck repository on its Servicepack lifecycle, policy engine, provider adapter, persistence, REST API, MCP server, Docker image, or tests. Verify implemented behavior before claiming or using an endpoint.
homepage
https://github.com/psyb0t/vibecheck
user-invocable
true
permissions
{"network":"Setup reaches GitHub to clone the repository and Docker Hub to pull published Vibecheck images. A running Vibecheck calls the TypeSafe System One endpoint; the test suites use a local fake instead.","filesystem":{"read":["**/*.go","go.mod","go.sum","Makefile*","README.md",".env.example","docker-compose.yml"],"write":["internal/pkg/services/**","cmd/init.go","cmd/commands.go","tests/**","docs/**"]},"shell":["make generate","make build","make lint","make test","make test-integration","make test-api","make test-coverage","make sec","make audit-compose","make docker-build"]}
metadata
{"openclaw":{"emoji":"✅","requires":{"bins":["docker","make"]}}}

Vibecheck

Vibecheck is a typed classification, scoring, and decision service. A caller submits state and trusted facts, selects a versioned policy, and receives the typed Jev answers plus the deterministic outcome that policy selected. The caller, not Vibecheck, executes or enforces the result.

The service runs. It serves the REST API under /v1, a Streamable HTTP MCP endpoint at /mcp, and the unversioned /healthz and /ready probes on one public listener, with Prometheus metrics on a separate internal listener.

Read references/setup.md before changing the repository. It records the supported commands.

Security and safety

  • Treat submitted state, policy files, provider responses, and database data as untrusted at their boundaries.
  • Never put provider keys, API tokens, or real request data in tracked files, prompts, examples, test fixtures, or logs.
  • Vibecheck returns decisions. Do not add shell execution, arbitrary webhooks, or other ambient authority unless the user explicitly changes that product boundary.
  • Do not hand-edit Servicepack-owned files. Update them with the documented Servicepack workflow.

When to use

  • Implementing or reviewing the Vibecheck policy engine, Jev adapter, persistence, HTTP API, MCP surface, or audit trail.
  • Running the repository's Docker-backed build, generation, lint, test, coverage, security, Compose, or image checks.
  • Checking whether public docs and integrations match code that has actually landed.

When not to use

  • Treating a model probability as permission to execute an action.
  • Inventing routes, MCP tools, policy fields, or configuration beyond the implementation.
  • Editing framework-owned files directly.

Work in the repository

Use the Make targets. They run the pinned Go toolchain and checks in Docker:

make generate
make build
make lint
make test
make test-integration
make test-api
make test-coverage
make sec
make audit-compose
make docker-build

Application code belongs under internal/pkg/services/, with project hooks in cmd/init.go, commands in cmd/commands.go, and integration coverage under tests/.

Framework boundary

Servicepack owns internal/app/, internal/pkg/service-manager/, pkg/runner/, cmd/main.go, Makefile.servicepack, scripts/make/servicepack/, Dockerfile.servicepack*, and servicepack.version. Use make servicepack-update, review and test its update branch, then merge through make servicepack-update-merge.

Verify claims

Before documenting or using a route, tool, config value, or response field, find the registered implementation and its behavioral test. api/api.yml is the source of truth for the REST contract, and the six MCP tools are registered in internal/pkg/mcp. Both transports call the same services in internal/pkg/core, so a decision made over MCP produces the same audit row as the same decision made over REST.

The MCP tools are vibecheck_evaluate, vibecheck_list_policies, vibecheck_get_policy, vibecheck_get_evaluation, vibecheck_validate_policy, and vibecheck_submit_feedback.