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.
- 1Go to vibingiq.com and click “Scan free”
- 2Authorize the VibingIQ GitHub App on the repositories you want to scan
- 3Wait ~60 seconds for the first free scan to complete
- 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.
- 1From the dashboard, click “Add project”
- 2Pick the repository you want to monitor
- 3Choose a tier (Sprout is free)
- 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.
- 1Open your project → Test Environment → Credentials
- 2Add a credential (login, invite code, API key, …)
- 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.
- 1Code Quality — smells, dead code, readability
- 2Security — OWASP patterns, unsafe APIs, weak crypto
- 3Secrets Leak — hardcoded keys, tokens, credentials
- 4Dependencies — known CVEs and outdated packages
- 5DB Health — query patterns, missing indexes, N+1 risks
- 6Data Integrity — schema drift, migration gaps
- 7API Contract — response shape and auth enforcement
- 8Integration Health — third-party creds and rate-limit risks
- 9E2E — synthetic user flows end to end
- 10Visual Regression — UI breakage across pages
- 11Adversarial — abuse, injection, and fuzzing cases
- 12Live Monitoring — drift from baseline after deploy
- 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.
- 1S1 Critical — exploit or crash risk, fix today
- 2S2 High — user-facing bug or data-integrity risk
- 3S3 Medium — likely regression, fix this sprint
- 4S4 Low — maintainability or minor UX
- 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.