VibingIQ

Docs

A short tour of what VibingIQ does and how to use it. Deeper guides are coming as we graduate from private beta.

Getting started

Install the VibingIQ GitHub App, pick a repository, and run your first scan. The whole flow takes about 60 seconds.

  1. 1Go to vibingiq.com and click “Scan free”
  2. 2Authorize the VibingIQ GitHub App on the repositories you want to scan
  3. 3Wait ~60 seconds for the first free scan to complete
  4. 4Review the issues in the dashboard and open a fix plan

Connecting repositories

VibingIQ installs as an official GitHub App, not a personal access token. You can grant access to specific repos (recommended) or your whole account.

  1. 1From the dashboard, click “Add project”
  2. 2Pick the repository you want to monitor
  3. 3Choose a tier (Sprout is free)
  4. 4VibingIQ starts its first full scan automatically

Connecting credentials

For scanners that need to actually log into your app (synthetic user, E2E), you can connect test credentials in Test Environment → Credentials. Every value is encrypted at rest and never sent to the LLM in plaintext.

  1. 1Open your project → Test Environment → Credentials
  2. 2Add a credential (login, invite code, API key, …)
  3. 3Reference it in a test plan via “login:test_user_1” and the harness will substitute it at run time

Understanding scan results

Each scan produces issues with severity S1–S5 and a VibingIQ score out of 100. The score is a weighted combination of open issues, scanner coverage, and auto-heal pass rate. Push for 90+.

The 13 scanners

Every scan runs these checks in parallel. Each one outputs evidence (file, line, reasoning) so you can verify the finding before fixing.

  1. 1Code Quality — smells, dead code, readability
  2. 2Security — OWASP patterns, unsafe APIs, weak crypto
  3. 3Secrets Leak — hardcoded keys, tokens, credentials
  4. 4Dependencies — known CVEs and outdated packages
  5. 5DB Health — query patterns, missing indexes, N+1 risks
  6. 6Data Integrity — schema drift, migration gaps
  7. 7API Contract — response shape and auth enforcement
  8. 8Integration Health — third-party creds and rate-limit risks
  9. 9E2E — synthetic user flows end to end
  10. 10Visual Regression — UI breakage across pages
  11. 11Adversarial — abuse, injection, and fuzzing cases
  12. 12Live Monitoring — drift from baseline after deploy
  13. 13Agent #13 — synthetic users log in as each real role and try to break the app

Severity (S1–S5)

Every issue lands at one of five severities. Fix S1 and S2 first — they’re the ones that will break production or leak data.

  1. 1S1 Critical — exploit or crash risk, fix today
  2. 2S2 High — user-facing bug or data-integrity risk
  3. 3S3 Medium — likely regression, fix this sprint
  4. 4S4 Low — maintainability or minor UX
  5. 5S5 Info — advisory, good hygiene to address

Using fix plans

A fix plan takes the issues from a scan and batches them into day-by-day prompts you can paste into Claude Code, Cursor, Lovable, or ChatGPT. VibingIQ never writes to your repo without your explicit approval — every fix is a draft PR you review and merge.

Auto-heal

When auto-heal is enabled, VibingIQ opens draft PRs for eligible fixes. The PR includes the scanner evidence, the proposed change, and a self-test the scanner can re-run before you merge. Turn auto-heal on or off per project.

Something missing?

These docs are growing with the product. Email us if you need more detail on something specific.

Email us
Ready to try it? Start a free scan.