io.github.goklab/guardvibe
NPM · GUARDVIBE · SCANNED AUG 3
Deterministic security layer your AI can't be. 462 rules, 39 tools, CLI + doctor + host audit.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score →
Supply Chain Security87
- No malware found by supply-chain analysis.Pass
- Only part of the dependency tree could be resolved (96 of 100), so this covers what we could see, not the whole tree.Partial
- No install/post-install scripts declared.Pass
- Only part of the dependency tree could be resolved (96 of 100), so this covers what we could see, not the whole tree. View diagnostics → Partial
Provenance & Transparency97
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Cryptographically verified build provenance (signed, bound to goklab/guardvibe). View diagnostics → Pass
- Clear OSI-approved license (Apache-2.0).Pass
- Actively maintained (last published 10 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability71
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 4998 tokens (~128/item across 39 items; 39 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management0
- Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Unverified: 1 category
A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
npm · guardvibe
claude mcp add goklab-guardvibe -- npx -y guardvibe
codex mcp add goklab-guardvibe -- npx -y guardvibe
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"goklab-guardvibe": {
"type": "local",
"command": [
"npx",
"-y",
"guardvibe"
],
"enabled": true
}
}
} openclaw mcp add goklab-guardvibe --command npx --arg -y --arg guardvibe
mcp_servers:
goklab-guardvibe:
command: "npx"
args: ["-y", "guardvibe"] {
"mcpServers": {
"goklab-guardvibe": {
"command": "npx",
"args": [
"-y",
"guardvibe"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 3 Aug 26 +55
- Install scripts: unverified → pass ▲ security
- Provenance: unverified → pass ▲ security
- Known CVEs: unverified → partial ▲ security
- Stability: Stability not yet verified: not enough scan history yet (needs a 30-day window). security
- The attested source repository moved: goklab/guardvibe security
- Security disclosure: unverified → fail ▼ functional
- Schema quality: unverified → excellent ▲ functional
- Tool coverage: unverified → 100 ▲ functional
- License: unverified → pass ▲ functional
- Dependency health: unverified → partial ▲ functional
- Maintenance: unverified → pass ▲ functional
- MCP protocol: unverified → pass ▲ functional
- Licence: Apache-2.0 functional
- 2 Aug 26 +15
- Malware scan: unverified → pass ▲ security
- Security disclosure: fail → unverified ▼ functional
- 1 Aug 26 −15
- Tool coverage: 100 → unverified ▼ functional
- First check of Schema quality: unverified functional
- 31 Jul 26 −25
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 27 Jul 26 45
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 3 Aug 2026 · Analysed npm/[email protected]
Provenance verified
Ecosystem: npm · Outcome: verified
Reason: verified
- Source repo:
- goklab/guardvibe
- Certificate issuer:
- https://token.actions.githubusercontent.com
- Certificate SAN:
- https://github.com/goklab/guardvibe/.github/workflows/publish.yml@refs/tags/v3.31.0
- Rekor log index:
- 2227710827
- Predicate type:
- https://slsa.dev/provenance/v1
- Subject digest:
- sha512:56e080160925dd7625d5fb91109542681c7e455d73a1380ca890366537d61a3656bb95023a4a14f8d56c83b13dad48bbaa81757b736e46f7f643e3d66
- Discovery method:
- attestation_endpoint
Dependencies 96 packages
96 packages in the resolved dependency tree · 95 deprecated · 29 stale.
The dependency tree was only partially resolved, so these counts may be incomplete.
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability.
analyze_cross_file_dataflow ~139
Track user input flowing across module boundaries — detects injection vulnerabilities spanning multiple files. Pass files array with file contents. For single-file analysis, use analyze_dataflow instead. Example: analyze_cross_file_dataflow({files: [{path: 'src/api.ts', content: '...'}, {path: 'src/db.ts', content: '...'}]})
| Name | Type | Req | Description |
|---|---|---|---|
| files | array | — | List of files to analyze (ignored when path is provided) |
| format | string | — | Output format |
| path | string | — | Project directory path. When provided, auto-discovers all JS/TS files — no need to pass file contents manually. |
No output schema declared.
No examples provided.
analyze_dataflow ~89
Track user input (request body, URL params, form data) flowing into dangerous sinks (SQL queries, eval, file operations, redirects). Detects injection vulnerabilities that regex rules miss by following variable assignments through code.
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | Code to analyze for tainted data flows |
| format | string | — | Output format |
| language | string | yes | Language (JS/TS only) |
No output schema declared.
No examples provided.
audit_config ~92
Audit application config files (next.config, middleware, .env, vercel.json) for cross-file security gaps: missing headers, unprotected routes, exposed secrets. NOT the same as guardvibe_doctor which checks AI host security (MCP configs, hooks). Example: audit_config({path: '.'})
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format |
| path | string | yes | Project root directory to audit |
No output schema declared.
No examples provided.
audit_mcp_config ~96
Scan MCP configuration files (.claude/settings.json, .cursor/mcp.json, .vscode/mcp.json) for security issues: malicious hooks (CVE-2025-59536), suspicious MCP servers, overly permissive tool access, and shell injection patterns. Use this to verify MCP configurations are safe before use.
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format |
| path | string | — | Project root directory to scan |
No output schema declared.
No examples provided.
auth_coverage ~167
Analyze authentication coverage across Next.js App Router routes. Detects auth guards (Clerk, NextAuth, Supabase, custom) and reports protected vs unprotected routes. Pass files array with route file contents and middleware content. Example: auth_coverage({files: [{path: 'app/api/users/route.ts', content: '...'}], middleware: '...'})
| Name | Type | Req | Description |
|---|---|---|---|
| files | array | — | Route and page files from app/ directory (ignored when path is provided) |
| format | string | — | Output format |
| middleware | string | — | Content of middleware.ts file (ignored when path is provided) |
| path | string | — | Project directory path. When provided, auto-discovers all route, page, layout, and middleware files — no need to pass file contents manually. |
No output schema declared.
No examples provided.
check_code ~134
Analyze inline code for security vulnerabilities (OWASP Top 10, XSS, SQL injection, insecure patterns). Pass code as a string parameter. For scanning files on disk, use scan_file instead. Example: check_code({code: 'app.get(...)', language: 'javascript'})
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | The code snippet to analyze |
| format | string | — | Output format: markdown (human) or json (machine-readable for agents) |
| framework | string | — | Framework context (e.g. express, nextjs, fastapi, react, django) |
| language | string | yes | Programming language of the code |
No output schema declared.
No examples provided.
check_command ~111
Analyze a shell command for security risks before execution. Returns allow/ask/deny verdict with blast radius, safer alternatives, and context-aware risk assessment. Detects: destructive ops, git history rewrites, secret exposure, data exfiltration, deploy triggers, privilege escalation, database drops.
| Name | Type | Req | Description |
|---|---|---|---|
| branch | string | — | Current git branch (for branch-specific risk) |
| command | string | yes | Shell command to analyze |
| cwd | string | — | Current working directory |
| format | string | — | Output format |
No output schema declared.
No examples provided.
check_dependencies ~83
Check npm, PyPI, or Go packages for known security vulnerabilities (CVEs) using the OSV database. Use this before adding new dependencies or to audit existing ones.
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format: markdown (human) or json (machine-readable for agents) |
| packages | array | yes | List of packages to check: [{name, version, ecosystem}] |
No output schema declared.
No examples provided.
check_package_health ~91
Check npm packages for typosquat risk, maintenance status, adoption metrics, and deprecation. Use this before adding new dependencies to catch suspicious or risky packages.
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format: markdown (human) or json (machine-readable for agents) |
| packages | array | yes | List of package names to check (e.g. ['lodash', 'expres', 'react-qeury']) |
No output schema declared.
No examples provided.
check_project ~71
Scan multiple files for security vulnerabilities and generate a project-wide security report with a security score. Use this for comprehensive security audits.
| Name | Type | Req | Description |
|---|---|---|---|
| files | array | yes | List of files to scan: [{path, content}] |
| format | string | — | Output format: markdown (human) or json (machine-readable for agents) |
No output schema declared.
No examples provided.
compliance_report ~151
Map security findings to compliance controls (SOC2, PCI-DSS, HIPAA, GDPR, ISO27001, EUAIACT). Scans a directory and groups issues by control. Output includes a summary section at the top; for large projects, findings are truncated to top 50. Use mode=executive for C-level summary. Example: compliance_report({path: '.', framework: 'SOC2'})
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format: markdown (human) or json (machine-readable for agents) |
| framework | string | yes | Compliance framework |
| mode | string | — | Report mode: full (detailed) or executive (C-level summary) |
| path | string | yes | Directory to scan |
No output schema declared.
No examples provided.
deep_scan ~219
LLM-powered deep security analysis for vulnerabilities that pattern-matching cannot detect: IDOR, business logic flaws, race conditions, stale auth, mass assignment, privilege escalation. Defaults to Claude Haiku 4.5 (~cents per scan); pass `model: 'sonnet'` for deeper analysis at higher cost. Requires ANTHROPIC_API_KEY or OPENAI_API_KEY env var.
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | Code to analyze |
| context | string | — | Additional context (e.g., 'This is a payment endpoint') |
| existingFindings | array | — | Already-detected findings to avoid duplicating |
| focus | string | — | Focus area — narrows the prompt to a specific vulnerability class |
| format | string | — | Output format |
| language | string | yes | Programming language |
| maxBytes | integer | — | Max prompt size in bytes — caps cost. Code over this limit is truncated. |
| model | string | — | LLM model. haiku = fast & cheap (default), sonnet = deeper analysis |
No output schema declared.
No examples provided.
explain_remediation ~114
Pass a GuardVibe rule ID (e.g. VG154) to get a detailed explanation: risk assessment, exploit scenario, minimum fix, secure alternative, and test strategy. Optionally pass the affected code snippet for context-aware guidance. Example: explain_remediation({rule_id: 'VG402'})
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | — | Affected code snippet for context |
| format | string | — | Output format |
| rule_id | string | yes | GuardVibe rule ID (e.g. VG001, VG402) |
No output schema declared.
No examples provided.
export_sarif ~55
Scan a directory and export results in SARIF v2.1.0 format for CI/CD integration (GitHub, GitLab, Azure DevOps). Returns JSON string.
| Name | Type | Req | Description |
|---|---|---|---|
| path | string | yes | Directory to scan |
No output schema declared.
No examples provided.
fix_code ~135
Pass vulnerable code as a string and get fix suggestions with before/after patches. Returns structured edit instructions (line numbers, severity, confidence). Use verify_fix afterwards to confirm the fix resolved the issue. Example: fix_code({code: '...', language: 'typescript'})
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | The code snippet to analyze and fix |
| format | string | — | Output format: json (for agent auto-fix) or markdown (human review) |
| framework | string | — | Framework context (e.g. express, nextjs, fastapi, react, django) |
| language | string | yes | Programming language of the code |
No output schema declared.
No examples provided.
full_audit ~147
Single command that runs ALL checks: code scan (429 rules), secret detection, dependency CVEs, config audit, taint analysis, and auth coverage. Returns PASS/FAIL/WARN verdict with deterministic hash. IMPORTANT: If verdict is FAIL or WARN, you MUST call remediation_plan next to get a section-by-section fix checklist — do NOT skip any section. After fixing, call verify_remediation to confirm ALL sections are addressed. Example: full_audit({path: '.'})
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format |
| path | string | — | Project root directory |
| skipDeps | boolean | — | Skip dependency vulnerability check |
| skipSecrets | boolean | — | Skip secret scanning |
No output schema declared.
No examples provided.
generate_policy ~84
Auto-detect project stack (Next.js, Supabase, Stripe, Clerk, Prisma, etc.) and generate tailored security policies. Outputs ready-to-use CSP headers, CORS configuration, Supabase RLS policies, rate limiting rules, and security headers based on detected frameworks.
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format |
| path | string | yes | Project root directory to scan |
No output schema declared.
No examples provided.
get_security_docs ~100
Get security best practices and remediation guidance for a specific topic, framework, or vulnerability type. Covers OWASP Top 10, framework-specific hardening (Next.js, Supabase, Stripe), and secure coding patterns. Returns actionable guidance with code examples.
| Name | Type | Req | Description |
|---|---|---|---|
| topic | string | yes | Security topic to look up (e.g. "express authentication", "sql injection prevention", "nextjs csrf", "react xss", "owasp top 10") |
No output schema declared.
No examples provided.
guardvibe_doctor ~160
Check AI host security: MCP configurations, hooks, base URL hijacking, environment variable exposure. NOT the same as audit_config which checks application config files (next.config, .env, headers). Use scope=project (default) for project-only, scope=host to include shell profiles and global AI configs. Example: guardvibe_doctor({scope: 'project'})
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format: markdown (human) or json (machine-readable) |
| path | string | — | Project root directory |
| scope | string | — | Scan scope: project (default, .claude.json + .cursor/ + .vscode/ + .env), host (+ shell profiles + global MCP configs), full (+ home dir configs) |
No output schema declared.
No examples provided.
policy_check ~88
Check project against compliance policies defined in .guardviberc. Use this in CI/CD pipelines to enforce security gates, or before releases to verify compliance requirements are met. Validates custom framework requirements, severity thresholds, required controls, and risk exceptions. Returns pass/fail status with detailed findings per control.
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format |
| path | string | yes | Project root directory |
No output schema declared.
No examples provided.
remediation_plan ~119
Generate a mandatory section-by-section remediation plan from full_audit results. MUST be called after full_audit when verdict is FAIL or WARN. Returns ordered steps for ALL 6 sections (secrets, code, dependencies, config, taint, auth-coverage) with specific tool calls and actions. AI assistants MUST complete every section — skipping sections is not allowed. Example: remediation_plan({path: '.'})
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format: json for agents (recommended), markdown for humans |
| path | string | — | Project root directory |
No output schema declared.
No examples provided.
repo_security_posture ~68
Analyze a repository's overall security posture. Maps sensitive areas (auth, payments, PII, admin, API, infrastructure), identifies high-risk workflows, recommends guard mode, and lists priority fixes.
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format |
| path | string | yes | Repository root path |
No output schema declared.
No examples provided.
review_pr ~139
Review a pull request for security issues. Scans only changed lines (diff-only mode) and produces output for GitHub Check Runs, PR comments, or inline annotations. Supports severity gating to block PRs.
| Name | Type | Req | Description |
|---|---|---|---|
| base | string | — | Base branch to diff against |
| diff_only | boolean | — | Only report findings in changed lines (true) or all findings in changed files (false) |
| fail_on | string | — | Block PR if findings at this severity or above exist |
| format | string | — | Output: markdown (PR comment), json (structured), annotations (GitHub Check Runs) |
| path | string | — | Repository root path |
No output schema declared.
No examples provided.
scan_changed_files ~145
Scan only files that have changed since a given git ref (branch, commit, or HEAD~N). Ideal for PR checks, pre-push hooks, and incremental CI. Diff-aware by default: returns only findings on newly-added lines (set diff_aware:false for whole changed files).
| Name | Type | Req | Description |
|---|---|---|---|
| base | string | — | Git ref to diff against (e.g. 'main', 'HEAD~3', commit SHA) |
| diff_aware | boolean | — | Report only newly-introduced findings on added lines (true, default) vs. all findings in changed files (false) |
| format | string | — | Output format |
| path | string | — | Repository root path |
No output schema declared.
No examples provided.
scan_config_change ~99
Compare before/after versions of a config file to detect security downgrades: CORS relaxation, CSP weakening, HSTS removal, debug mode, cookie flag changes, TLS disabling, new hardcoded secrets, removed security headers.
| Name | Type | Req | Description |
|---|---|---|---|
| after | string | yes | New config file content |
| before | string | yes | Previous config file content |
| file_path | string | — | Config file path for context |
| format | string | — | Output format |
No output schema declared.
No examples provided.
scan_dependencies ~113
Parse a lockfile or manifest (package.json, package-lock.json, requirements.txt, go.mod) and check all dependencies for known CVEs via the OSV database. Reads the file directly. Use this after installing dependencies, during CI, or when auditing existing projects for vulnerable packages.
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format: markdown (human) or json (machine-readable for agents) |
| manifest_path | string | yes | Path to manifest file (e.g. 'package.json', 'requirements.txt', 'go.mod') |
No output schema declared.
No examples provided.
scan_directory ~155
Scan all files in a directory on disk for security vulnerabilities. Pass a directory path — reads files from filesystem. Returns security score (A-F) and findings. Results may be truncated for large projects — check fileRanking in JSON output for top files. Example: scan_directory({path: './src'})
| Name | Type | Req | Description |
|---|---|---|---|
| baseline | string | — | Path to a previous scan JSON output file for baseline comparison (new/fixed/unchanged findings) |
| exclude | array | — | Additional directories to exclude |
| format | string | — | Output format: markdown (human) or json (machine-readable for agents) |
| path | string | yes | Directory path to scan (e.g. './src', '.') |
| recursive | boolean | — | Scan subdirectories |
No output schema declared.
No examples provided.
scan_file ~135
Scan a single file on disk by path for security vulnerabilities. Pass a file path — the tool reads the file itself. For inline code snippets, use check_code instead. The 'agent' format returns the structured guardvibe.agent.v1 contract (finding + exact edit + confidence + verify step). Example: scan_file({file_path: 'src/api/route.ts', format: 'agent'})
| Name | Type | Req | Description |
|---|---|---|---|
| file_path | string | yes | Absolute or relative path to the file to scan |
| format | string | — | Output format. 'agent' = machine-actionable guardvibe.agent.v1 (exact edits + confidence + verify) |
No output schema declared.
No examples provided.
scan_hallucinated_packages ~222
Detect AI-hallucinated and slopsquatted packages in a repo — the supply-chain seam commodity SCA misses. OFFLINE (deterministic): flags phantom imports (a package imported in source but absent from every package.json — a classic LLM hallucination tell) and typosquats of popular packages. ONLINE (opt-in, default on; gracefully degrades offline): adds npm-registry truth — packages that return 404 (definitive hallucination) and brand-new low-download packages (slopsquat-registration pattern). Run on AI-generated code at PR time, before `npm install`. Pass online:false for a fully deterministic, air-gapped scan.
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format: markdown (human) or json (guardvibe.slopscan.v1 for agents) |
| online | boolean | — | Query the npm registry for existence/age/downloads. false = deterministic offline-only (phantom imports + typosquats). |
| path | string | — | Repository root to scan (default current directory) |
No output schema declared.
No examples provided.
scan_host_config ~118
Scan host environment for AI security issues: API base URL hijacking (CVE-2026-21852), credential exposure in shell profiles, .env file leaks, and environment variable sniffing. Checks .env files at project scope; add scope=host to also check shell profiles and global AI configs.
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format |
| path | string | — | Project root directory |
| scope | string | — | Scan scope: project (.env files only), host (+ shell profiles, global configs), full (+ home dir) |
No output schema declared.
No examples provided.
scan_secrets ~116
Scan files and directories for leaked secrets, API keys, tokens, and credentials. Detects high-entropy strings, known API key patterns (AWS, Stripe, OpenAI, GitHub, Supabase), exposed .env files, and missing .gitignore coverage. Returns findings with exact line numbers and remediation steps.
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format: markdown (human) or json (machine-readable for agents) |
| path | string | yes | File or directory path to scan |
| recursive | boolean | — | Scan subdirectories |
No output schema declared.
No examples provided.
scan_secrets_history ~92
Scan git history for leaked secrets. Finds secrets that were committed in the past — even if they were later removed. Marks each finding as 'active' (still in code) or 'removed' (in git history only, needs rotation).
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format |
| max_commits | number | — | Maximum number of commits to scan |
| path | string | yes | Repository root path |
No output schema declared.
No examples provided.
scan_staged ~115
Scan git-staged files for security vulnerabilities before committing. Run this before every commit to catch issues early. No input needed — automatically reads staged files. Diff-aware by default: reports only issues on newly-staged lines (set diff_aware:false for whole staged files).
| Name | Type | Req | Description |
|---|---|---|---|
| diff_aware | boolean | — | Report only findings on newly-staged lines (true, default) vs. all lines in staged files (false) |
| format | string | — | Output format: markdown (human) or json (machine-readable for agents) |
No output schema declared.
No examples provided.
secure_prompt ~278
Shift-left security at the prompt level: analyze a raw coding prompt BEFORE any code is written and return a structured enhancement directive that embeds GuardVibe security requirements (auth checks, input validation, webhook signature verification, SQL injection prevention, secrets handling) into the prompt you are about to execute. Deterministic — no LLM, no network: triage verdict NO_MOD (prompt already specific and security-aware → proceed with the ORIGINAL prompt unchanged), LIGHT_MOD (inject missing security constraints only), or HEAVY_MOD (also surface clarifying questions — never invent answers to them). Detects stack (Next.js, Supabase, Clerk, Stripe, Prisma, Express, Hono...) and attack surfaces (auth, payments, file upload, user input, SQL, secrets, redirects) from the prompt text, matches them against GuardVibe's rule set, and returns verdict + intent summary + numbered [rule-id] requirements + rewrite directive. Call this with the user's prompt before generating code; prevents vulnerabilities before code generation instead of scanning after. Example: secure_prompt({raw_prompt: 'add login to my app'})
| Name | Type | Req | Description |
|---|---|---|---|
| context | string | — | Known stack/framework context if the client has it (e.g. 'Next.js app router, Supabase, Stripe') |
| raw_prompt | string | yes | The user's original coding prompt, verbatim |
No output schema declared.
No examples provided.
secure_this ~262
Close the loop on vulnerabilities in code: scan, apply only the fixes that VERIFIABLY land (each candidate edit is re-scanned and rolled back if it fails to resolve the issue or introduces a new one), and return the verified code plus a definition-of-done gate. Prefer this over fix_code+verify_fix when you want a guarantee the fix landed — not just a suggestion. Returns { status: clean|secured|partial|no_autofix, fixedCode, applied[], remaining[], definitionOfDone:{passed,message}, proofTest }. Write fixedCode to disk, then require definitionOfDone.passed before claiming the task complete; anything in remaining[] needs a manual fix. When fixes were applied, proofTest is a runnable regression test (GuardVibe-as-oracle) you can drop into the project to guard against regressions. Example: secure_this({code: '...', language: 'typescript'})
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | The code to scan and secure |
| filePath | string | — | File path for context-aware analysis (the file is NOT written; apply fixedCode yourself) |
| framework | string | — | Framework context (e.g. express, nextjs, react) |
| language | string | yes | Programming language of the code |
No output schema declared.
No examples provided.
security_stats ~82
Show cumulative security statistics, grade trend, and vulnerability fix progress for this project. Use this to demonstrate the value of GuardVibe security scanning over time. Data is stored locally in .guardvibe/stats.json.
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | — | Output format |
| path | string | — | Project root path |
| period | string | — | Time period for stats |
No output schema declared.
No examples provided.
security_workflow ~175
Get the recommended GuardVibe tool sequence for your current task. Returns which tools to call, in what order, and with what parameters. Use this when unsure which tool to use. Example: security_workflow({task: 'pre_commit'})
| Name | Type | Req | Description |
|---|---|---|---|
| task | string | yes | Current task: writing_code (after edits), pre_commit (before commit), pr_review (reviewing PR), new_project (initial setup), fix_vulnerabilities (fixing known issues), compliance_mapping (audit again… |
No output schema declared.
No examples provided.
verify_fix ~112
Verify that a specific security fix was applied correctly. Re-scans the updated code and checks if the target vulnerability (by rule ID) is resolved. Returns 'fixed', 'still_vulnerable', or 'new_issues' status with details.
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | Updated code after applying the fix |
| filePath | string | — | File path for context-aware analysis |
| language | string | yes | Programming language |
| ruleId | string | yes | Rule ID to verify (e.g. VG402) |
No output schema declared.
No examples provided.
verify_remediation ~127
Compare before/after audit results to verify ALL sections were addressed. MUST be called after completing remediation to confirm success. Runs a fresh audit and compares against the before snapshot. Explicitly flags skipped sections and refuses to return 'complete' status unless every section is addressed. Pass the before audit hash or let it re-run. Example: verify_remediation({path: '.', before_hash: 'abc123'})
| Name | Type | Req | Description |
|---|---|---|---|
| before_hash | string | — | Result hash from the initial full_audit (for tracking) |
| format | string | — | Output format |
| path | string | — | Project root directory |
No output schema declared.
No examples provided.