just-vibeSecurity · inspect by default
/security-config
Review application, container, and deployment configuration
Use for effective security-relevant settings; vercel-audit is a deployment-specific configuration comparison, and security-fix repairs a confirmed misconfiguration.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select security-config from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv security-config, /just-vibe security-config and /jv:security-config in Claude. See shortcut setup and context examples.
/just-vibe:security-config Audit production configuration without changing infrastructure settings./just-vibe:security-config Review debug exposure and cross-origin settings in separate dev and production configurations./just-vibe:security-config Audit configuration files without infrastructure access or changing live settings.What the agent does
- Compare declared and effective settings for the exact environment with the intended boundaries.
- Trace high-impact settings and trust boundaries, distinguishing local development exceptions from public production exposure, and verify available deployment evidence.
Inputs
- app/container/deployment configuration and exact environment.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Debug settings, permissions, network exposure, cookies/headers, transport assumptions, and default credentials.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Inspect; app/container/deployment configuration and exact environment.
- Prerequisites
- Defined application boundary, authorized code/environment, relevant trust/access rules, and evidence sources. Default to defensive inspection; active tests use owned or explicitly authorized isolated targets. Minimize sensitive evidence and never print usable credentials.
Expected output
- Setting/environment/evidence/impact table with target-specific fixes and validation steps.
How the work is checked
- Public debug exposure is identified; intentionally local development settings are not mislabeled as production incidents.
When to stop or clarify
- No infrastructure edits or broad hardening that breaks required behavior. Unknown effective settings remain unknown.
Handling missing context
- Infer
- Resolve the requested surface, source/runtime version, reachable callers and actual trust/access boundaries.
- Assume
- Start with source analysis and bounded owned fixtures; treat scanner output as leads and preserve legitimate controls.
- Ask
- Ask when target authorization or necessary trust semantics are unresolved before active probing; source inspection need not wait for production access.
Technical guidance
- Evidence
- Inspect effective production settings, network exposure, cookie/CORS/proxy rules, container privileges and CI trust paths.
- Method
- Load only the matching framework and deployment branches; compare actual deployed behavior to configuration intent.
- Pitfall
- Debug defaults, broad proxy trust or client-visible secrets can invalidate otherwise safe code; development settings are not production evidence.
- Check
- Check a trusted and untrusted origin/host/identity where relevant and report inaccessible effective settings as unknown.
Situational decisions
When effective deployment configuration is unavailable: Report source-established risks conditionally instead of asserting the live setting.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.