just-vibeGeneral · inspect by default
/security
Examine concrete security risks in a defined scope
Use for a scoped security review; security-* commands investigate one specific attack surface, and security-fix repairs confirmed findings.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select security from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv security, /just-vibe security and /jv:security in Claude. See shortcut setup and context examples.
/just-vibe:security Audit authorization around invoice exports using source evidence only./just-vibe:security Audit an export endpoint with tenant filtering and an alternate download route./just-vibe:security Review source only without probing real accounts or using suspected credentials.What the agent does
- Identify the requested scope, assets, entry points, trust boundaries and available source/runtime evidence. Read the security methods and review selector, then the matching vulnerability and framework sections.
- Trace each relevant attacker-controlled source through transformations and existing controls to the sensitive effect. Challenge suspected findings with legitimate controls; use available scanners according to their evidence procedure and keep unknown or skipped coverage explicit.
Inputs
- application boundary, threat concerns, and authorized environment.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Concrete security risks in the specified system; no intrusive remote scanning or automatic remediation.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Inspect; application boundary, threat concerns, and authorized environment.
- Prerequisites
- Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
Expected output
- Findings with attacker prerequisites, reachable path, evidence, impact and remediation options.
How the work is checked
- A reachable authorization gap is explained; a suspicious function with effective protections is not automatically labeled vulnerable.
When to stop or clarify
- Do not expose secrets or user records as proof. Missing environment access narrows confidence and coverage.
Handling missing context
- Infer
- Resolve the named files, existing scripts, current task and earlier corrections from the conversation and repository.
- Assume
- Use the narrowest interpretation that completes a reversible local task; state a consequential assumption once.
- Ask
- Ask when competing targets or incompatible success conditions would change the result; continue independent inspection first.
Technical guidance
- Evidence
- Identify scoped assets, attacker-controlled entry points, deployed assumptions and existing trust controls.
- Method
- Read the security review selector, relevant vulnerability cards and matching framework defaults before tracing source to sensitive effect.
- Pitfall
- A suspicious API or generic checklist entry is not proof of exploitability; unseen deployment defenses remain unknown.
- Check
- For each finding establish prerequisites, reachable path, missing control and impact, plus a safe rejection/legitimate-control check where feasible.
Situational decisions
When suspicious code is protected by an earlier verified boundary: Explain the effective protection and avoid a confirmed-vulnerability label.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.