/security-fix

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select security-fix from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv security-fix, /just-vibe security-fix and /jv:security-fix in Claude. See shortcut setup and context examples.

What the agent does

1. Reproduce the affected vulnerable path in a safe fixture.
2. Enforce the control at the owning boundary.
3. Test abuse, legitimate behavior and alternate bypass routes, and document remaining operational work.

Inputs

• confirmed vulnerability, affected versions/paths, desired compatibility, and safe reproduction.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Remediation of the identified weakness and necessary regression coverage.

Writes

Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.

Mode

Apply; confirmed vulnerability, affected versions/paths, desired compatibility, and safe reproduction.

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

• Patch with the vulnerable trigger, boundary correction, safe proof of remediation through abuse and legitimate checks, and residual exposure and operational tasks.

How the work is checked

• The original attack path no longer works; valid authorized behavior remains functional.

When to stop or clarify

• Credential rotation, history rewriting, production changes, and public disclosure require their explicit scope. Do not claim historical exposure was erased by a code fix.

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

Resolve the established attacker path, prerequisite, original behavior, affected callers and accepted compatibility requirements.

Method

Repair the enforcing boundary rather than adding a pattern-specific block; retain normal behavior and check alternate encodings/entry points.

Pitfall

Hiding a scanner warning or adding client validation can leave the server exploit path intact.

Check

Demonstrate the original unsafe behavior with an isolated regression, then verify rejection and legitimate behavior after remediation; rerun relevant available scanners.

Situational decisions

When a code fix leaves historical credential exposure or persisted bad data: Report the remaining rotation/recovery work separately from the repaired path.

When the fix is a dependency upgrade: Resolve the fixed version from the advisory, prefer a direct bump over an override, check peer and engine ranges, inspect the lockfile diff for unrelated churn, run behavior checks, and confirm the resolved version by re-running the audit. Never force-upgrade or delete the lockfile to clear a report.

When the vulnerability is an exposed credential: Follow the security-secrets containment order: confirm revocation or rotation comes first, replace the value with a secret-store reference in code and configuration, and leave history rewriting and force-push to their separate exact requests.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring